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

[Ryan Moats <rmoats@lemurnetworks.net>]

On Thu, Nov 29, 2001 at 10:31:23PM -0800, Kurt D. Zeilenga wrote:
| 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.

Lets add that then, because it certainly wasn't clear to me from reading
the document that that was the case.

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

Please clarify those points then, as again, that did not come through
on my reading of the draft, but only after discussing it with you here.

Ryan