Early IANA Allocation of Standards Track Code Points
draft-cotton-rfc4020bis-02

[Ballot comment]
Former DISCUSS:

This document changes the meaning of several review policies listed in RFC 5226 to IESG Review.  RFC 5226 neither discusses nor updates RFC 4020, but was published later.  So it seems to me that we effectively have two BCPs that disagree with each other.  I think this needs to update RFC 5226.

I've cleared based on the notion that we will deal with this cross-reference in rfc5226bis.

[Ballot discuss]
This document changes the meaning of several review policies listed in RFC 5226 to IESG Review.  RFC 5226 neither discusses nor updates RFC 4020, but was published later.  So it seems to me that we effectively have two BCPs that disagree with each other.  I think this needs to update RFC 5226.

[Ballot comment]

It's appropriate that this document is on the same telechat as draft-kolkman-proposed-standards-clarified -- both documents are about the bloat in the RFC approval process.  The stability criteria laid out in this document basically mean that a protocol has to be feature-frozen (at least as regards the code point) before an early allocation can be made.  But an early allocation can only be useful if there's some significant amount of time between the allocation and the approval of the RFC.  What are we doing in the intermediate time?

[Ballot comment]

- What if an IRTF RG wants to run this process? Should we include
text on that? Did anyone ask Lars/the-IRSG? (I think we have a
case of that in the works now btw.) I realise that this says its
only for IETF stream, which is fine, but we might be better off
just checking if the IRTF want to play the same game now.

- Why 1 year for the temporary registration? Would "at least one
year" be better? Why "at most" one renewal?  I don't object, but
that seems like it might make more and not less work.

[Ballot comment]
Note: I had an interesting discussion with Michelle, who clarified a few things, and saved many emails.

Feel free to engage on the discussion on points 1 to 5.

1.
I would add a clarification that IANA assigns the code point(s) as soon as the document is approved by the IESG. I had to ask Michelle, so I guess I'm not the only who was not sure about this.
Therefore, this procedure is not applicable to documents sitting in the RFC editor queue (we know that they can sit there for a long time, waiting for a normative reference).


2.

  If the document
  progresses to the point at which IANA normally makes code point
  allocations, it is the responsibility of the authors and the WG
  chairs to remind IANA that there were early allocations, and of the
  code point values so allocated, in the IANA Considerations section of
  the RFC-to-be.

I believe it's the responsibility of the authors and document shepherd/WG chairs.
If the document left the WG already (IETF LC), so the chairs are not involved.
So maybe
  it is the responsibility of the authors and the WG chairs (or the document
  shepherd if the document left the WG) to remind IANA that there were early allocations

Same remark for this sentence

  If an early
  allocation expires 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.

Discussing with Michelle, she thinks that this procedure doesn't really apply to situations where the draft left the WG (IETF LC), because it's not too far from IESG approval. So this procedure is not really worth it.
One way or the others, this should be clarified. Clarifying first the point 1 would help in solving this point 2.

3.
section 3.1

  2.  The WG chairs determine whether the conditions for early
      allocations described in section 2 are met; particularly,
      conditions (c) and (d).

  3.  The WG chairs gauge whether there is consensus within the WG that
      early allocation is appropriate in the case of the given
      document.

3 is basically the means to check (d), right?
NEW:

  2.  The WG chairs determine whether the conditions for early
      allocations described in section 2 are met; particularly,
      conditions (c) and (d). The WG chairs gauge the consensus
      for (d) within the WG.

4.
   
  If the document
  progresses to the point at which IANA normally makes code point
  allocations, it is the responsibility of the authors and the WG
  chairs to remind IANA that there were early allocations, and of the
  code point values so allocated, in the IANA Considerations section of
  the RFC-to-be.  Allocation is then just a matter of removing the
  "Temporary" tag from the allocation description.

    So basically, you want to the IANA considerations section to clearly
    specify that a temporary code point has been allocated, with a RFC
editor or IANA Note. Shouldn't you clearly spell that out?


5.

3.3. Expiry
  As described in Section 3.1, each Temporary assignment is recorded in
  the registry with the date of expiry of the assignment.  If an early
  allocation expires 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.

Is there some sort of automatic notification: without it, I'm sure people will forgot



PURELY EDITORIAL (take it or leave it)
- regarding

4. IANA Considerations

  This document defines procedures for early allocation of code points
  in the registries with the "Specification Required", "RFC Required",
  "IETF Review", and "Standards Action" policies and as such directly
  affects IANA.  This document removes the need for registries to be
  marked as specifically allowing early allocation.  IANA is requested
  to clean up the registries by removing any such markings.

Maybe I didn't read carefully the first time. I was confused by a registry entry being marked temporary and the IANA note at the top of a registry.

NEW: This document removes the need for registries to be
  marked as specifically allowing early allocation. 
  IANA is requested to clean up the registries by removing registry notes.


Editorial:
- "format, semantic" or "formats, semantics" in

      The format, semantics, processing, and other rules related to
      handle the protocol entities defined by the code points
      (henceforth called "specifications") must be adequately described
      in an Internet-Draft.

[Ballot comment]
I have concerns about the lifetime being a bit short.

More deeply albiet probably not addressable I have concerns about the actual effectiveness of the revocation procedure. TCP 465 reminds me of how badly this can go sideways even when things are penciled in and then removed.

[Ballot comment]
This is an update that we need to make.

I do however have a question concerning the one year lifetime of an early allocation. Given that wa have a lot of experience since RFC4020 was published, what does the evidence say about the 1+1 year lifetime.

My qualitative experience suggests that it is a bit short, but presumably we have statistical evidence that gives us a firm view on what it should be.

[Ballot comment]
I agree with Sean's discuss.


-- Section 3.1 --

  5.  If the Area Directors approve step 4, the WG chairs request IANA
      to make an early allocation.

Obligatory nit: we request an action, not an actor.  The chairs "request that IANA make an early allocation."

[Ballot discuss]
Drafts that use code points from a Specification Required RFC can come through the ISE.  When this happens and they ask for an early allocation is it the responsibility of the ISE to follow the steps in Section 3, is it the AD's responsibility who does the 5742 review to follow the steps in Section 3, or should early allocation for ISE drafts be prohibited in Section 2?

IESG/Authors/WG Chairs:

IANA has reviewed draft-cotton-rfc4020bis-01.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments/questions:

IANA understands that this document defines procedures for early allocation of code points in the registries with the "Specification Required", "RFC Required", "IETF Review", and "Standards Action" policies. Upon publication, IANA will adopt the procedures in this document.

IANA also understands that there are no other actions IANA needs to complete upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Early IANA Allocation of Standards Track Code Points) to Best Current Practice


The IESG has received a request from an individual submitter to consider
the following document:
- 'Early IANA Allocation of Standards Track Code Points'
  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
ietf@ietf.org mailing lists by 2013-09-24. Exceptionally, comments may be
sent to iesg@ietf.org 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.

AD review
===

Michelle,

Thanks for this. It reads well, is clear, and is (I think) what we want
for the IETF. Good job!

At this stage in the process, I review the document to make sure it
is clean and has the best chance of making it through the IETF last
call and IESG review.

I have a bunch of nits that are listed below. Can you spin a new
version to pick them up and then I can take the I-D to the next step.

There is one gotcha that the IESG may ask for. There is no section that
describes the changes from RFC 4020. Usually, when we do a bis, we
include this sort of section. It doesn't have to be very big, but it
needs to highlight the salient points... For example: RFC 4020 only
allowed early allocation from registries with allocation policy foo.
Do you think you could throw that together?

All this is up for negotiation if you feel it is wrong or unnecessary.
Please shout if you fell hard done by ;-)

Thanks,
Adrian

===

Meta-data

I think "Best Current Practice" is better that "Informational" since:
a. that is what it is
b. you are obsoleting the RFC that forms BCP 100

---

Section 1
OLD
  are described in RFC 5226 [5226].  Some of them, such as "First Come
NEW
  are described in RFC 5226 [RFC5226].  Some of them, such as "First Come
END

---

Section 1
OLD
  before the document becomes a RFC.
NEW
  before the document becomes an RFC.
END

---

Section 1

  The early allocation mechanisms are applied only to
  spaces whose allocation policy is "Specification Required" (where an
  RFC is used as the stable reference), "RFC Required", "IETF Review",
  and "Standards Action".

s/and/or/

---

Section 3.1
s/Internet Drafts/Internet-Drafts/

---

Section 6
You can remove the unused reference to RFC 2119.

---

Section 6
I would think that [RFC4020] and [RFC4794] are Informational references.