[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: shollenbeck@verisign.com, Andre.Cormier@viagenie.qc.ca
cc: ietf-provreg@cafax.se, brunner@nic-naa.net
From: Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>
Date: Wed, 14 Feb 2001 11:55:06 -0500
Sender: owner-ietf-provreg@cafax.se
Subject: Re: grrp-reqs-06, 3.2 Identification and Authentication [3]

Andre,

>> Absent BEEP, this requirement places upon the provreg design group the
>> participant policy negociation problem.
>To my knowledge this is not a big problem since SASL describes how to do
>this and BEEP is using it. SASL = RFC 2222

My concern is that BEEP isn't in grrp-reqs-06, and without it (or equivalent)
provreg needs at least one participant policier negociation mechanism. I'm
quite happy with BEEP in grrp-reqs-06, but until it is I'm concerned about
the consequences of "MUST provide services to negotiate".

>As i understand it this is for Registrars authentication to the
>registry. 

Symmetric, or rather participant indifferent, in -07.

>          I do not see a problem with this requirement. If we don't have
>a negociation mecanism, we are bound to change the protocol if we wish
>to change the authentication method.

And identification method, and anything else which participants use to
policy data flows, e.g., data collection practices or any other policy
possibly arising from political geography or generica or R-* practical
considerations falls into the WHAT box of "MUST provide services to
negotiate [WHAT]".

I'm concerned that Identification and Authentication do not exhaust the
criteria for provreg participants to policy data flows.

Cheers,
Eric

Home | Date list | Subject list