[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: comments/change control (Was: IETF ldapbis WG Last Call: draft-ietf-ldapbis-iana-04.txt)



At 06:41 PM 2001-11-29, Ryan Moats wrote:
>On Thu, Nov 29, 2001 at 03:35:36PM -0800, Kurt D. Zeilenga wrote:
>| At 02:07 PM 2001-11-29, Ryan Moats wrote:
>| >| >2. In section 5.3, there a reference to a change control request.
>| >| >It is not clear from the rest of the document what the process is for
>| >| >the change control request triggering a specification update or IESG
>| >| >asserting ownership. I think this needs to be addressed to provide some
>| >| >guidance to requesters (both for initial requests and subsequent requests).
>| >| 
>| >| I think the last sentence of 5.3 needs to be replaced with:
>| >|   For registrations owned by the IESG, the objections SHOULD
>| >|   be addressed by initiating a request for Expert Review.      
>| >| 
>| >|   The form of these requests is ad hoc but MUST include the 
>| >|   specific objections to be reviewed and SHOULD contain
>| >|   (directly or by reference) materials supporting the
>| >|   objections.
>| >| 
>| >| Does this address your concern(s)?
>| >
>| >Partially.  In addition to the above, I got lost in the following scenario:
>| >scenario:
>| >
>| >Somebody registeres an "e-" or "x-" item, so its owned by the register.
>| >Somebody else makes a change request on that item (this looks to be allowed)
>| >
>| >Now what happens?  If the owner doesn't make the requested change, at what
>| >point does/should IESG take ownership?
>| 
>| Comments are handled per 5.3.  Upon Expert Review comments can be
>| attached to the registration.  But this doesn't change ownership
>| of the registration or the registration itself.
>
>While this makes sense for Standards Track and Expert Review registrations.
>I don't see why Expert Review is necessary for changes to First Come First
>Serve registrations, when they weren't necessary to the initial FCFS
>registration?

5.3 applies to comments made by someone other than the owner.
If the owner agrees to make changes, then those changes can
be made by the owner under the same constraints and review of the
original registration.  If the owner doesn't agree to make the
changes, then Expert Review is required.

>| Changes to a registration are handled per 5.2.  The IESG can
>| assert ownership at any point when it believes changes are
>| necessary and the registered owner is not willing or able to
>| make them.
>
>What I'm looking for is some guidance to the register of the "e-" or
>"x-" information as to "how quickly" they need to process change requests.

First, "x-" information cannot be registered.  That's private namespace.
I would assume the register (IANA) will process new and change requests
in a reasonable amount of time.  What's reasonable depends on a number
of factors, but in general I suspect days to weeks for most requests.

>The more I think about it, the more I'm bothered that a FCFS registration
>can be taken away because the owner doesn't make a change.

Owners may be unwilling or unable to make a necessary change.  They
could be dead.  The change could be quite necessary.  The clause
ensures that in the rare case that the IESG believes it is
appropriate to assert ownership to make a necessary change, it can.
For example, maybe a significant flaw is found in an authentication
method and the owner is unable to change it to OBSOLETE.  This
clause allows the IESG to make this change if it becomes necessary.

>If I compare them with the OID allocation model, there seems to be
>a higher bar here than there (I don't know of any procedure for 
>undelegating an OID arc).  I'm not sure that's a good idea.

First, I note that the OID is a hierarchical name space, not a flat
name space.  It's also used for a far wider variety of things and
the allocation differs quite significant depending on what the
OIDs are being used for.

I would say for LDAP use, the allocation is the same as for descriptors.
Once publicly delegated to identify a particular element, that
delegation cannot be revoked (not even by the owner).

Consider what would happen if the owner changing a registration
such that it breaks all well establish uses of that identifier.  The
community would no recourse.  These clause gives the community the
right to raise objections.  With Expert Review, comments can be
attached.  With IESG action, the IESG can assert ownership and
revert the registration to a specification detailing the established
use.

>As a counter proposal, I'm ok with the IESG assert ownership of a
>Expert Review registration because changes are necessary and the
>registered owner is not willing or able to make them.

I believe it very important to allow the IESG to assert ownership
over the public name space when necessary.  If the requester doesn't
want to allow the IESG to do this, private name space can be used.