Re: Last Call: <draft-cotton-rfc4020bis-01.txt> (Early IANA Allocation of Standards Track Code Points) to Best Current Practice

[John C Klensin <[e-mail]>]

--On Thursday, August 29, 2013 12:43 -0400 Barry Leiba
<[e-mail]> wrote:

>> In Section 2:
>> 
>>   'a.  The code points must be from a space designated as
>>   "Specification Required" (where an RFC will be used as the
>>        stable reference), "RFC Required", "IETF Review", or
>>        "Standards Action".'
>> 
>> I suggest not having the comment (where) and leaving it to
>> RFC 5226 to define "Specification Required".
> 
> Yes, except that's not what this means.
> 
> I tripped over the same text, and I suggest rephrasing it this
> way:
> 
> NEW
>    The code points must be from a space designated as
> "Specification    Required" (in cases where an RFC will be
> used as the stable reference),    "RFC Required", "IETF
> Review", or "Standards Action".

Barry, that leaves me even more confused because it seems to
essentially promote "Specification Required" into "RFC Required"
by allowing only those specifications published as RFCs.  

Perhaps, given that this is about Standards Track code points,
that is just what is wanted.  If so the intent would be a lot
more clear if the text went a step further and said:

NEWER:

	The code points must normally be from a space designated
	as "RFC Required", "IETF Review", or "Standards Action".
	In addition, code points from the "Specification
	Required" are allowed if the specification will be
	published as an RFC.

There is still a small procedural problem here, which is that
IANA is asking that someone guarantee RFC publication of a
document (or its successor) that may not be complete.  There is
no way to make that guarantee.  In particular, the guarantee of
Section 2 (c) without constraining the actions that IETF LC can
reasonably consider.  As I have argued earlier today in another
context, language that suggests really strong justification for
the tradeoff may be acceptable, but a guarantee to IANA by the
WG Chairs and relevant ADs, or even the full IESG, that
constrains a Last Call is not.   Section 3.2 begins to examine
that issue, but probably doesn't go quite far enough, especially
in the light of the "four conditions" of Section 2.

It would probably be appropriate to identify those conditions as
part of good-faith beliefs.

It might even be reasonable to require at least part of tee
"what if things change" analysis that Section 3.2 calls for
after the decision is made to be included in the request for
early allocation.  Requiring that analysis would also provide a
small additional safeguard against the scenarios discussed in
the Security Considerations section.

Incidentally, while I'm nit-picking about wording, the last
sentence of Section 3.3 has an unfortunate dependency on a form
of the verb "to expire".  Language more similar to that used for
RFCs might be more appropriate, e.g., that the beginning of IESG
Review (or issuance of an IETF Last Call) suspends the
expiration date until either an RFC is published or the IESG or
authors withdraws the document. 

   best,
   john