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


To: Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>, shollenbeck@verisign.com, Andre.Cormier@viagenie.qc.ca
Cc: ietf-provreg@cafax.se, brunner@nic-naa.net
From: "Jordyn A. Buchanan" <jordyn@register.com>
Date: Wed, 14 Feb 2001 12:33:13 -0500
In-Reply-To: <200102141655.f1EGt6C09101@nic-naa.net>
Sender: owner-ietf-provreg@cafax.se
Subject: Re: grrp-reqs-06, 3.2 Identification and Authentication [3]

At 11:55 AM 2/14/2001 -0500, Eric Brunner-Williams in Portland Maine wrote:
>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".

Since we haven't seen what our protocol looks like, I think it's premature 
to say whether or not BEEP is a good way to transport it.  I'm guessing 
that BEEP adds way too much overhead to be practical for high volume 
registries.  I'm willing to concede that it's too early to say that BEEP is 
not appropriate, but I'd be opposed to putting BEEP into the requirements.


> >          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.

I think the concern expressed above is valid, but do we really have to 
worry about a generic mechanism to negotiate these things?  Given the 
general extensibility that we envision for the protocol, adding commands or 
extending objects to establish the appropriate policy set can be 
accomplished at a later time.

My guess is that many elements of data policy that you are describing will 
be implemented by the registry or registrar outside of the context of this 
protocol.

Jordyn


Home | Date list | Subject list