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

From: t.p. <[email-masked]>
Date: Thu, 29 Aug 2013 15:39:32 +0100

This I-D uses the term 'deprecated' without defining it nor is the term
defined in "IANA Considerations" [RFC5226] " (It does however already
appear in the IANA Registry).

I am familiar with the SMI definition but that seems not quite right for
this context; some of the IANA uses of this have been there for decades
and are unlikely ever to be removed.  I think that this I-D needs a
definition and, since I have seen disagreement on WG Lists as to what
the term means, I think that that definition should be agree on the ietf
list before this I-D is approved by the IESG.

Tom Petch

----- Original Message -----
From: "The IESG" <[email-masked]>
To: "IETF-Announce" <[email-masked]>
Sent: Tuesday, August 27, 2013 10:52 PM
>
> The IESG has received a request from an individual submitter to
consider
> the following document:
> - 'Early IANA Allocation of Standards Track Code Points'
>   <draft-cotton-rfc4020bis-01.txt> as Best Current Practice
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2013-09-24. Exceptionally, comments may
be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
>    This memo describes the process for early allocation of code points
>    by IANA from registries for which "Specification Required", "RFC
>    Required", "IETF Review", or "Standards Action" policies apply.
This
>    process can be used to alleviate the problem where code point
>    allocation is needed to facilitate desired or required
implementation
>    and deployment experience prior to publication of an RFC that would
>    normally trigger code point allocation.
>
>    This document obsoletes RFC 4020.
>
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-cotton-rfc4020bis/
>
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-cotton-rfc4020bis/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>

---

From: SM <[email-masked]>
Date: Thu, 29 Aug 2013 08:44:02 -0700

At 14:52 27-08-2013, The IESG wrote:
>The IESG has received a request from an individual submitter to consider
>the following document:
>[email-masked] mailing lists by 2013-09-24. Exceptionally, comments may be

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

Regards,
-sm

---

From: Barry Leiba <[email-masked]>
Date: Thu, 29 Aug 2013 12:43:00 -0400

> 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

---

From: SM <[email-masked]>
Date: Thu, 29 Aug 2013 09:56:34 -0700

Hi Barry,
>    "RFC Required", "IETF Review", or "Standards Action".

That looks better.

Regards,
-sm

---

From: John C Klensin <[email-masked]>
Date: Thu, 29 Aug 2013 13:48:02 -0400

--On Thursday, August 29, 2013 12:43 -0400 Barry Leiba
<[email-masked]> 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".
> 
>    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