Subject: IETF ldapbis WG Last Call: draft-ietf-ldapbis-iana-04.txt

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Thu, 29 Nov 2001 07:33:38 -0800 (PST)

This message initiates a LDAPbis Working Group Last Call on the
document:

                    IANA Considerations for LDAP
                  <draft-ietf-ldapbis-iana-04.txt>
                          20 November 2001

The purpose of this WG Last Call it to ensure that the Working Group
has achieved consensus that the document is suitable for publication
as an IETF Best Current Practice.

Please review the document for both technical and editorial problems.
Technical issues should be discussed on this list.  Editorial issues
may be sent to the document editor.

The Last Call period will end on Monday, December 17, 2001.

Upon completion of the last call, the WG chair(s) will take action
based upon the consensus of the WG.  Possible actions include:

  1) recommending to the IETF Application Area Directors that the
     document, after possible editorial or other minor changes, be
     considered by the IESG for publication as a Best Current Practice
     (which generally involves an IETF-wide Last Call); or

  2) requiring that outstanding issues be adequately addressed prior
     to further action (including, possibly, another Last Call).

Remember that it is our responsibility as Working Group members to
ensure the quality of our documents and of the Internet Standards
process.  So, please read and comment!

 - RL "Bob" Morgan
   LDAPbis co-chair

---

From: Ryan Moats <[email-masked]>
Date: Thu, 29 Nov 2001 12:19:27 -0600

Having finished my first pass of draft-ietf-ldapbis-iana-04.txt, I have
a couple of editorial suggestions (to clean up punctuation and grammar)
and two technical issues.

===Editorial points===

-In section 3.5, shouldn't the sentence

   Keywords associated with integers in the range 0-1023 SHALL NOT start
   with "e-" or "x- the range 1024-8191 SHALL start with "e-".

be #"

   Keywords associated with integers in the range 0-1023 SHALL NOT start
   with "e-" or "x-". Further, the range 1024-8191 SHALL start with "e-"
   only.

-In section 3.7, the sentence 

   For historical purposes, the current list of registered names SHOULD be
   remain available.

should read

   For historical purposes, the current list of registered names SHOULD
   remain available.

-In section 4, the sentence 

   The requester is viewed is the owner of values registered under Expert
   Review.

should read

   The requester is viewed as the owner of values registered under Expert
   Review.

-Also in section 4, the sentence 

   The requester is viewed is the owner of values registered under First
   Come First Served.

should read

   The requester is viewed as the owner of values registered under First
   Come First Served.

===Technical issues===

1. Several searches on the ldapbis mailing archives failed to show any
discussion on the limits on protocol descriptors and option strings.
I for one am uncomfortable with applying such limits without more discussion.
Rather, once the requester has met the "SHOULD" consideration, I don't
think IANA should be given the right to arbitrarily refuse a request just
because of length.  I propose striking the sentences

"IANA MAY refuse to register any descriptor over 48 characters in length."

and

"IANA MAY refuse to register any option over 16 characters in length."

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

Ryan Moats

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 29 Nov 2001 13:44:05 -0800

>===Editorial points===

Noted for later review.

>because of length. 

Well, I would argue that IANA should have the right to refuse
a request solely the item is too long.  What this sentence does,
is give the requester and the IANA guidance as to what lengths
MAY be considered too long.

>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)?

---

From: Ryan Moats <[email-masked]>
Date: Thu, 29 Nov 2001 16:07:18 -0600

On Thu, Nov 29, 2001 at 01:44:05PM -0800, Kurt D. Zeilenga wrote:
| At 10:19 AM 2001-11-29, Ryan Moats wrote:
| 
| >===Technical issues===
| >
| >1. Several searches on the ldapbis mailing archives failed to show any
| >discussion on the limits on protocol descriptors and option strings.
| >I for one am uncomfortable with applying such limits without more discussion.
| >Rather, once the requester has met the "SHOULD" consideration, I don't
| >think IANA should be given the right to arbitrarily refuse a request just
| >because of length. 
| 
| Well, I would argue that IANA should have the right to refuse
| a request solely the item is too long.  What this sentence does,
| is give the requester and the IANA guidance as to what lengths
| MAY be considered too long.

I disagree.  Assigning a "MAY" limit creates (to me) an arbitrary limit
in an unlimited field.  If IANA says "no you can't register that, its
too long" then what recourse does the register have?  If they've already
passed review, then why should IANA stop them?

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

Ryan

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 29 Nov 2001 15:35:36 -0800

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

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.

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 29 Nov 2001 15:58:42 -0800

At 02:07 PM 2001-11-29, Ryan Moats wrote:
>in an unlimited field.

The bottom line is that we need to provide requesters, reviewers,
and the register (who often is the sole reviewer) guidance as to
what is "too long" (or not "short").

I'm prefer the current language:
   IANA MAY refuse to register any descriptor over 48 characters
   in length.

but would fine with:
   Any descriptor over 48 characters MAY be viewed as too long to
   be registered.

If neither is acceptable, do you have a counter suggestion?

>If IANA says "no you can't register that, its
>too long" then what recourse does the register have?

I assume IANA has some process for addressing appeals.  If not,
then recourse would be, I guess, to take the appeal to IANA's
board of directors.

>If they've already passed review, then why should IANA stop them?

Well, assuming that IANA is not the sole reviewer of the request,
I would think it quite unlikely that IANA would refuse to accept
a request from the Expert or IESG who are acting in accordance
with the guidelines.  If there was no guidance on "too long"
or the Expert or IESG exceed requested something which was in
fact "too long" for IANA to register, I wouldn't be surprised
if they pushed back.

If they were the sole reviewer, I would expect they would
follow the guidance given and/or to seek advice in cases where
the requester was persistent.

Kurt

---

From: Ryan Moats <[email-masked]>
Date: Thu, 29 Nov 2001 20:41:34 -0600

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?

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

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.

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 think the FCFS review/update should be left to the individuals.

Ryan

---

From: Ryan Moats <[email-masked]>
Date: Thu, 29 Nov 2001 20:52:09 -0600

On Thu, Nov 29, 2001 at 03:58:42PM -0800, Kurt D. Zeilenga wrote:
| At 02:07 PM 2001-11-29, Ryan Moats wrote:
| >On Thu, Nov 29, 2001 at 01:44:05PM -0800, Kurt D. Zeilenga wrote:
| >| At 10:19 AM 2001-11-29, Ryan Moats wrote:
| >| >1. Several searches on the ldapbis mailing archives failed to show any
| >| >discussion on the limits on protocol descriptors and option strings.
| >| >I for one am uncomfortable with applying such limits without more discussion.
| >| >Rather, once the requester has met the "SHOULD" consideration, I don't
| >| >think IANA should be given the right to arbitrarily refuse a request just
| >| >because of length. 
| >| 
| >| Well, I would argue that IANA should have the right to refuse
| >| a request solely the item is too long.  What this sentence does,
| >| is give the requester and the IANA guidance as to what lengths
| >| MAY be considered too long.
| >
| >I disagree.  Assigning a "MAY" limit creates (to me) an arbitrary limit
| >in an unlimited field.
| 
| The bottom line is that we need to provide requesters, reviewers,
| and the register (who often is the sole reviewer) guidance as to
| what is "too long" (or not "short").
| 
| I'm prefer the current language:
|    IANA MAY refuse to register any descriptor over 48 characters
|    in length.
| 
| but would fine with:
|    Any descriptor over 48 characters MAY be viewed as too long to
|    be registered.
| 
| If neither is acceptable, do you have a counter suggestion?

I'm still struggling with the '"SHOULD" be short' phrase to begin with.
As the document says, I don't see any reason for this in the protocol
specifications themselves, so my proposal are:

  While the protocol places no maximum length restriction upon
  descriptors, any descriptor over 48 characters MAY be viewed as too
  long to be registered.

and 

  While the protocol places no maximum length restriction upon option
  strings, any option string over 32 characters MAY be viewd as too
  long to be registered.

I'll admit I'm using DNS as a guide for making this larger.

| >If they've already passed review, then why should IANA stop them?
| 
| Well, assuming that IANA is not the sole reviewer of the request,
| I would think it quite unlikely that IANA would refuse to accept
| a request from the Expert or IESG who are acting in accordance
| with the guidelines.  If there was no guidance on "too long"
| or the Expert or IESG exceed requested something which was in
| fact "too long" for IANA to register, I wouldn't be surprised
| if they pushed back.
| 
| If they were the sole reviewer, I would expect they would
| follow the guidance given and/or to seek advice in cases where
| the requester was persistent.

Ok, that's fair.

Ryan

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 29 Nov 2001 22:31:23 -0800

>Serve registrations, when they weren't necessary to the initial FCFS

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.

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

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

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

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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 29 Nov 2001 22:22:10 -0800

>specifications themselves, so my proposal are:

The "core" specification didn't make any IANA considerations.  But,
I did take "short" from the RFC 2251 statement: "... identified by a
short descriptive name and an OID (object identifier)."   It used
only once (with regard to attribute types), but the rationale for
short names applies to all identifiers used in the protocol and
elsewhere.  But I note that what this I-D provides is registration
guidelines, it doesn't restrict what can or cannot be used in
the protocol.

The short statement and length guidance is an IANA consideration.
They are aimed at making the registries management without placing
undue restrictions upon protocol/schema designers.

I choose 48 characters for descriptors as it hard to write a
specification for a descriptor of greater length than that (given
I-D guidelines).  I choose 16 for options as it hard to write a
specification for options of greater length (especially when one
considers detailing interaction with other options).  There are
other practical considerations, such as the ability to publish
the registries in table format printable on a normal width
computer terminal.

As 48 and 16 allow for huge number of descriptors/options to be
registered, I cannot imagine any need for longer descriptors/options
to be allowed.  Why do you think longer names should not be viewed
as too large to register?

Kurt

---

From: Ryan Moats <[email-masked]>
Date: Fri, 30 Nov 2001 12:01:48 -0600

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

---

From: Ryan Moats <[email-masked]>
Date: Fri, 30 Nov 2001 12:07:15 -0600

On Thu, Nov 29, 2001 at 10:22:10PM -0800, Kurt D. Zeilenga wrote:
| At 06:52 PM 2001-11-29, Ryan Moats wrote:
| >On Thu, Nov 29, 2001 at 03:58:42PM -0800, Kurt D. Zeilenga wrote:
| >| At 02:07 PM 2001-11-29, Ryan Moats wrote:
| >| >On Thu, Nov 29, 2001 at 01:44:05PM -0800, Kurt D. Zeilenga wrote:
| >| >| At 10:19 AM 2001-11-29, Ryan Moats wrote:
| >| >| >1. Several searches on the ldapbis mailing archives failed to show any
| >| >| >discussion on the limits on protocol descriptors and option strings.
| >| >| >I for one am uncomfortable with applying such limits without more discussion.
| >| >| >Rather, once the requester has met the "SHOULD" consideration, I don't
| >| >| >think IANA should be given the right to arbitrarily refuse a request just
| >| >| >because of length. 
| >| >| 
| >| >| Well, I would argue that IANA should have the right to refuse
| >| >| a request solely the item is too long.  What this sentence does,
| >| >| is give the requester and the IANA guidance as to what lengths
| >| >| MAY be considered too long.
| >| >
| >| >I disagree.  Assigning a "MAY" limit creates (to me) an arbitrary limit
| >| >in an unlimited field.
| >| 
| >| The bottom line is that we need to provide requesters, reviewers,
| >| and the register (who often is the sole reviewer) guidance as to
| >| what is "too long" (or not "short").
| >| 
| >| I'm prefer the current language:
| >|    IANA MAY refuse to register any descriptor over 48 characters
| >|    in length.
| >| 
| >| but would fine with:
| >|    Any descriptor over 48 characters MAY be viewed as too long to
| >|    be registered.
| >| 
| >| If neither is acceptable, do you have a counter suggestion?
| >
| >I'm still struggling with the '"SHOULD" be short' phrase to begin with.
| >As the document says, I don't see any reason for this in the protocol
| >specifications themselves, so my proposal are:
| 
| The "core" specification didn't make any IANA considerations.  But,
| I did take "short" from the RFC 2251 statement: "... identified by a
| short descriptive name and an OID (object identifier)."   It used
| only once (with regard to attribute types), but the rationale for
| short names applies to all identifiers used in the protocol and
| elsewhere.  But I note that what this I-D provides is registration
| guidelines, it doesn't restrict what can or cannot be used in
| the protocol.
| 
| The short statement and length guidance is an IANA consideration.
| They are aimed at making the registries management without placing
| undue restrictions upon protocol/schema designers.
| 
| I choose 48 characters for descriptors as it hard to write a
| specification for a descriptor of greater length than that (given
| I-D guidelines).  I choose 16 for options as it hard to write a
| specification for options of greater length (especially when one
| considers detailing interaction with other options).  There are
| other practical considerations, such as the ability to publish
| the registries in table format printable on a normal width
| computer terminal.
| 
| As 48 and 16 allow for huge number of descriptors/options to be
| registered, I cannot imagine any need for longer descriptors/options
| to be allowed.  Why do you think longer names should not be viewed
| as too large to register?

Because I've seen far too many cases where what was originally thought
to be "enough space" ran out.  While, I don't see how 48 characters
arises from the I-D guidelines, I'm willing to let other's in the WG
give their opinion (realizing that silence is assent).  However,
16 strikes me as too short.  If I look at DNS, a comparible limit there
is 32, so why not that?  Given the history of DNS, I would then agree that
there would be "plenty of space".

Ryan

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 30 Nov 2001 11:42:36 -0800

At 10:07 AM 2001-11-30, Ryan Moats wrote:
>to be "enough space" ran out.

But these aren't limits.  They don't cause us to "run out" of anything.

>While, I don't see how 48 characters
>is 32, so why not that?

In DNS, it is a LIMIT.  In this BCP, this is not a limit, it's
a guideline.

>Given the history of DNS, I would then agree that

Again, the statement doesn't reduce the amount of name space
available.  It only suggests that folks use short names over
long names.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 30 Nov 2001 11:43:57 -0800

>on my reading of the draft, but only after discussing it with you here.

I'll try to produce alternative text for 5.2 and 5.3 for the
WG to consider.  I'll send you a rough draft soon.

Kurt

---

From: Ryan Moats <[email-masked]>
Date: Fri, 30 Nov 2001 14:17:41 -0600

On Fri, Nov 30, 2001 at 11:42:36AM -0800, Kurt D. Zeilenga wrote:
| At 10:07 AM 2001-11-30, Ryan Moats wrote:
| >Because I've seen far too many cases where what was originally thought
| >to be "enough space" ran out.
| 
| But these aren't limits.  They don't cause us to "run out" of anything.

I think you are trying to have it both ways.  You are saying "anything
longer MAY be refused as being too long" and then saying "these aren't
limits".  They *are* a barrier to names (call it a guideline, call it
a limit, it doesn't matter).

| >While, I don't see how 48 characters
| >arises from the I-D guidelines, I'm willing to let other's in the WG
| >give their opinion (realizing that silence is assent).  However,
| >16 strikes me as too short.  If I look at DNS, a comparible limit there
| >is 32, so why not that?
| 
| In DNS, it is a LIMIT.  In this BCP, this is not a limit, it's
| a guideline.
| 
| >Given the history of DNS, I would then agree that
| >there would be "plenty of space".
| 
| Again, the statement doesn't reduce the amount of name space
| available.  It only suggests that folks use short names over
| long names.

That's a null semantic.  If you say "anything over X may be refused"
you are putting up a barrier, no matter how soft.  I want that 
barrier out where we won't have to come back and change it in the
forseeable future.  Why can't we do that?  What's so special of
16 over 32?

Ryan

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 30 Nov 2001 14:44:33 -0800

>a limit, it doesn't matter).

There is a huge difference between:
        Descriptors MUST be no longer than 48 characters.
than saying
        Registrations of descriptors longer than 48 characters
        MAY be refused.

The former is a limit or barrier.  The latter is guidance.

While we could strike the whole consideration and leave it
up to IANA to determine what "too large" to register, I think
that BCP 26 calls for us to provide sufficient guidance.

I've tried to make these choices in a manner which gives
requesters, reviewers, and the register wiggle room.  That's
why it's a MAY, not a MUST or a SHOULD.

It should be obvious that if the requester tries to register
something which "too long" per the guideline AND there are
no reasonable alternatives, that the register would exercise
appropriate judgement and not refuse the registration.

> What's so special of 16 over 32?

Basically, I choose 16 as, IMO, 8 seemed is too small and
32 is excessive [taking everything into consideration].

But, with this said, 16 isn't "so" special.  I could likely
live with 16 or 24 or 32.  I suggest we have Bob do a straw
poll at IETF#52 and take it from there.