Subject: RE: LC comments on draft-cotton-rfc4020bis-01.txt

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 28 Sep 2013 23:44:16 +0100

Hi,

I am working with Michelle on responses and updates after IETF last call. Most
of the issues give rise to relatively easy changes, and Michelle can handle them
in a new revision with a note saying what has changed and why.

But Eric's email gives rise to a wider and more difficult point on which I want
to comment.

Eric wrote:

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

This is, indeed, the fundamental issue. And it is sometimes called "squatting".

Squatting arises from legitimate early implementations of Internet-Drafts that
will one day be published as RFCs, from legitimate early implementations of
Internet-Drafts that turn out to be substantially modifies before publication,
from legitimate early implementations of Internet-Drafts that will turn out to
be dead-ends and never get published, from companies that do their own things
that they may or may not reveal to the world, and from other SDOs who decide to
publish standards that need code points.

The way we have handled this in the past is by partitioning our code spaces and
assigning each part an allocation policy. There is a good spectrum of allocation
policies available in RFC 5226, but it is up to working group consensus (backed
by IETF consensus) to assign the allocation policy when the registry is created,
and to vary that policy at any time.

IANA cannot vary the allocation policies for a registry - these are ours to set,
and IANA simply acts on them.

The early allocation thing was created to "blur the edges." That is, to cover
the case where exactly the case that Eric describes arises, but where the
registries require publication of a document (usually an RFC). The procedures
were documented in RFC 4020, but that was almost in the nature of an experiment.
The document in hand is attempting to tighten up the rules so that IANA knows
how to handle early allocations.

The base assumptions are:

- Early implementations really ought to be happening within two years of a
publication request, but if things go wrong we can run an exception process to
save ourselves.

- That implementations that get early deployment (i.e., beyond lab tests) will
be of I-Ds that are fundamentally stable and do not risk code points being
abandoned.

- That some code spaces are quite small and have precious resources.

- That IANA should not have to apply judgement, but should follow rules.

Now, to the rest of Eric's points...

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

This gives me heartburn. It says that anyone can write any half-arsed protocol,
implement and deploy it and then demand that the code point is allocated
regardless of what the registry allocation rules are. I could even do a DoS on
some protocols by claiming all the remaining available code points.

This is so fundamentally different from the existing way that we run our
registries that I don't think we can hold it as a comment against this document.
You might raise it as part of the discussion of the bis on RFC 5226 that is in
the pipe. Or you might raise it as an existential question for our existing
processes.

However, we can change to read...

   d.  The working group chairs and ADs judge that there is sufficient
       interest in the community for early (pre-RFC) implementation 
       and deployment, or that failure to make an early allocation might
       lead to contention for the code point in the field.

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

Yes, in practice some code points do disappear after early allocation.
This happens when the implementation is not actually deployed, when the
allocated code point is not actually used in the implementation, when the
deployed early implementation is replaced with a different implementation
(perhaps of a more stable spec or perhaps of another protocol).

However, I think that most of your objection here is tied back to your main
point (above) about how we handle our registries and allocations. I don't think
this document can address that, because I don't think that early allocation is
to be used as an end-run on RFC 5226 and our other processes. If they are broken
we should fix them, not use early allocation as a sticking plaster.

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

Well, that is a good point at which to choose.
What "choose carefully" really means is "Don't ask for the code points at the
point of writing the first draft. Don't even ask at the point of starting to
code an implementation. Ask when you need them."

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

Again, I think this comes back to your main point although it is closer to the
substance of this document.
This text makes early allocations soft state. If there was some screw up or if
the protocol never made it we should be able to reclaim the code points.

Furthermore, as the text explains, the two year limit can be varied by the ADs.

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

Mutter :-)
I don't think the standard was deployed.
But really, this should not be happening. Let's fix the real problem and not try
to fix the consequences.

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

This formulation requires the chairs to know what is going on, to drive their
documents, and to ask every year.
I prefer the idea of us getting on with our work in a timely way.

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

I wish that was the case.
When it was common practice to include numbers in I-Ds as they went forward to
publication, there were many cases where two I-Ds would clash for a number.
(This probably arises because people try to pick the next available number).
In several cases this gave rise to implementations competing for a number and
one of them having to change.

OTOH, I see no reason why values should not be included in an I-D once early
allocation has been done. The "formal allocation" should be clarified to include
early allocation.

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

And it takes very strong management of an SDO to its members "you can't have
this standard because the IETF hasn't allocated a code point."

Perhaps we come to the nub of the issue. The standards process and the
management of registries is hugely based on a form of cooperative good will. If
people, companies, or SDOs are not willing to play by the rules of engagement it
would be more useful to set the rules in a way that flushes them out, than it
would be to remove the rules and have a Wild West.
 
>   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.

I am sure you do not put yourself in the category of someone who would act like
this. So are you are claiming here that WG chairs and ADs will use their IETF
positions for commercial benefit?

I suggest that if you see it happen you should call it loud and clear. We have a
complaints process and an appeal process. We can recall ADs. Rather than imply
that this will happen, act when/if it does.

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

OK. Factored into 2d.

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

I don't think so, but I would be interested to hear from others.
For me, the refresh just keeps things clean without causing damage.

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

As above, I disagree with this as well, but would be interested to hear from
others.
With the clarification in 3.1 that early allocation counts for this point, if
you *need* to mention a code point, then get an early allocation.

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

I don't think that is the job of this document.
I think that people who care about this (for the protocols they work on) should
make sure the registries allow this type of development. RFC 5226 gives plenty
of options for allocation policies where code points can be granted "on demand".
Don't break all of the allocation policies. Pick the one you need.

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

Right.

Many thanks for the considerable thought you have given this issue.
I hope the above captures at least some of your concerns and gives direction to
the other ones.

Adrian

---

From: John C Klensin <[email-masked]>
Date: Sat, 28 Sep 2013 20:36:28 -0400

--On Saturday, 28 September, 2013 23:44 +0100 Adrian Farrel
<[email-masked]> wrote:

> Hi,
> 
> I am working with Michelle on responses and updates after IETF
> last call. Most of the issues give rise to relatively easy
> changes, and Michelle can handle them in a new revision with a
> note saying what has changed and why.
> 
> But Eric's email gives rise to a wider and more difficult
> point on which I want to comment.
>...
>...
> The way we have handled this in the past is by partitioning
> our code spaces and assigning each part an allocation policy.
> There is a good spectrum of allocation policies available in
> RFC 5226, but it is up to working group consensus (backed by
> IETF consensus) to assign the allocation policy when the
> registry is created, and to vary that policy at any time.
>...
> The early allocation thing was created to "blur the edges."
> That is, to cover the case where exactly the case that Eric
> describes arises, but where the registries require publication
> of a document (usually an RFC). The procedures were documented
> in RFC 4020, but that was almost in the nature of an
> experiment. The document in hand is attempting to tighten up
> the rules so that IANA knows how to handle early allocations.
>...

Adrian,

Everything you say seems fine to me for the cases you are
focusing on, but I hope that any changes to 4020bis keep two
things in mind lest we find ourselves tangled in rules and
prohibiting some reasonable behavior (a subset of which is used
now).

(1) RFC 5226 provides, as you put it, "a good spectrum of
allocation policies" but a WG (or other entity creating a
registry) can specify variations on them and, if necessary,
completely different strategies and methods.  As long as they
are acceptable to IANA and whatever approving bodies are
relevant, 5226 is not a closed list.  In particular, more than
one registry definition process has discovered that the 5226
language describing the role of a Designated Expert and the
various publication models are not quite right for their needs.

(2) We've discovered in several WGs and registries that early
allocation is just the wrong thing to do, often for reasons that
overlap some of Eric's concerns.  I don't see that as a problem
as long as 4020bis remains clear that early allocation is an
option that one can choose and, if one does, this is how it
works rather than appearing to recommend its broad use.

thanks,
   john

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 29 Sep 2013 09:19:03 +0100

Hi John,

Thanks for the additions.

> prohibiting some reasonable behavior (a subset of which is used

4020bis is certainly not intended to prohibit actions we do now. AFAICS it
actually opens up more scope for early allocation that was not there before.

> various publication models are not quite right for their needs.

I am pretty sure that nothing in this document impacts on 5226 at all except to
define how early allocation works for certain allocation policies defined by
5226. You are correct that 5226 is not a closed list. However we may observe
that it is used in the significant majority of cases. I think that means that if
some non-5226 policy is agreed by a WG and "the relevant approving bodies"
together with IANA, then that policy needs to define its own early allocaiton
procedure if one is wanted.

> works rather than appearing to recommend its broad use.

Quite true.
This document, therefore requires the WG chairs and the AD to be involved in the
decision to do early allocation.

Adrian

---

From: John C Klensin <[email-masked]>
Date: Sun, 29 Sep 2013 08:00:16 -0400

--On Sunday, 29 September, 2013 09:19 +0100 Adrian Farrel
<[email-masked]> wrote:

>> prohibiting some reasonable behavior (a subset of which is
>> used now).
> 
> 4020bis is certainly not intended to prohibit actions we do
> now. AFAICS it actually opens up more scope for early
> allocation that was not there before.
>...
> I am pretty sure that nothing in this document impacts on 5226
> at all except to define how early allocation works for certain
> allocation policies defined by 5226. You are correct that 5226
> is not a closed list. However we may observe that it is used
> in the significant majority of cases. I think that means that
> if some non-5226 policy is agreed by a WG and "the relevant
> approving bodies" together with IANA, then that policy needs
> to define its own early allocaiton procedure if one is wanted.
>...
> This document, therefore requires the WG chairs and the AD to
> be involved in the decision to do early allocation.

That was how I read the current version, so we are on the same
page.  Eric's note was considerably wider-ranging so, at you and
Michelle work on revisions, I just wanted to caution against
accidentally going too far in a direction that could be
construed as changing other things.   

>From my point of view, it would be a good thing to further
emphasize that a code point, once allocated through any process,
is, in a lot of cases, unlikely to be usable in the future for
anything else.   That is largely independent of whether the
allocation is identified as "early", "preliminary",
"provisional", "easy", or "final".  The current version is, I
think, good enough about that, but better would be, well, better.

thanks,
    john