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

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.

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.

<rant>
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?
</rant>

The RFC editor's note addresses my concerns.  Thanks!

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

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.