LC comments on draft-cotton-rfc4020bis-01.txt

[Eric Rosen <[e-mail]>]

I think the procedures proposed in this draft could be simplified a bit if
we'd just focus on the actual issue, viz., that the implementation and
deployment of a new specification is completely decoupled from the progress
of that specification through the standards process.  Once any significant
deployment has begun, the codepoints used by that deployment become de facto
unavailable for future use.  The only real issue is whether we want that
codepoint usage to be recorded in a public place, or whether we want to
pretend officially that the codepoints aren't used, and just let the
conflicts arise in the field.

>From this perspective, I think the following procedures are problematic:

- Section 2, point d:  early allocation is conditioned upon whether there is
  sufficient interest in early (pre-RFC) implementation and deployment in
  the community as judged by working group chairs or ADs.

  What the WG chairs and ADs really have to judge is whether failure to
  issue an early allocation is likely to result in de facto allocation of
  a codepoint, with consequent conflicts in the future.

  Of course, there have also been many cases where the codepoint is already
  in significant deployment before any "official" request for it has been
  made; WG chairs and ADs should take notice of this fact.

- Section 3.1, step 6: "IANA makes an allocation from the appropriate
  registry, marking it as 'Temporary', valid for a period of one year from
  the date of allocation.  The date of first allocation the date of expiry
  should also be recorded in the registry and made visible to the public."

  What is the point of marking it as "temporary"?  Once the codepoint is
  placed into use, it is not any more or less temporary than any other
  codepoint; the codepoint is unavailable for future reuse as long as the
  deployments.  Any codepoint that is no longer in use can of course be
  reused, even if its allocation is not marked "temporary".

  I do not understand the idea of making the allocation "expire" after just
  one year.  Are the deployments going to disappear after one year?  If not,
  then the codepoint allocation will not expire after one year.

- Section 3.3: "If early allocations expire before the document progresses
  to the point where IANA normally makes allocations, the authors and WG
  chairs may repeat the process in section 3.1 to request renewal of the
  code points.  At most, one renewal request may be made; thus, authors
  should choose carefully when the original request is to be made."

  First, it is not up to the authors to "choose carefully" when the original
  request is to be made.  At a certain point in the implementation process,
  the codepoint is needed.  Failure to get the codepoint soon enough will
  just cause the implementors to make up their own codepoint, which will
  invariably leak out into deployment.  

  Second, there is no reason whatsoever to put a two-year limit on the early
  allocation, unless one expects that the deployments using it will
  magically disappear after two years.

  I've seen a number of IETF standardization efforts lag six or seven years
  beyond the actual deployment of the standard.

  It might be worthwhile for the WG chairs to ask every few years whether
  the proposed use of a codepoint has been abandoned, but without some
  assurance that the codepoint will never be used as specified, there is no
  sense declaring it to be expired.

- Section 3.1: "Note that Internet-Drafts should not include a specific
  value of a code point until this value has been formally allocated by
  IANA."

  To me, this seems entirely counter-productive.  Failure to publicize the
  codepoint you're deploying doesn't solve or prevent any problems.  To the
  contrary, including the codepoint values you're using helps to find
  conflicts.

- Section 5: "There is a significant concern that the procedures in this
  document could be used as an end-run on the IETF process to achieve code
  point allocation when an RFC will not be published."

  This concern only makes sense when the codepoint is being requested by
  another SDO. If it's being requested by a vendor (or set of vendors),
  well, no vendor will tell it's customers "sorry, you can't have this
  feature because IETF hasn't allocated a codepoint".

  The real concern is the opposite -- folks will try to delay the allocation
  of a codepoint, in order to prevent their quicker competitors from gaining
  an advantage.  But this only leads to the use of codepoints that are not
  officially allocated.
  
My concrete suggestions for improving the draft would be:

- Emphasize that WG chairs and ADs should base their approval of a request
  on the likelihood that an unofficial codepoint will otherwise get
  allocated (or the fact that it is already in use).

- Eliminate the "temporary" and "automatic expiry" features, aldn eliminate
  the need to refresh a request after one year.

- Eliminate the requirement that an i-d not specify a codepoint value until
  IANA has allocated it

I also think it would be better if the draft stated explicitly that
deployment and standardization are completely decoupled, and that pre-RFC
deployments are a normal and common practice.

The ultimate solution to codepoint allocation problems is to require that
new protocols avoid the use of codepoint fields that contain 8 or fewer
bits.  But perhaps that's not within the scope of this draft.