Skip to main content

IANA Registry for P-Multicast Service Interface (PMSI) Tunnel Type Code Points
draft-ietf-l3vpn-pmsi-registry-07

Yes

(Adrian Farrel)
(Alia Atlas)

No Objection

(Alissa Cooper)
(Jari Arkko)
(Joel Jaeggli)
(Kathleen Moriarty)
(Martin Stiemerling)
(Richard Barnes)
(Spencer Dawkins)
(Stephen Farrell)
(Ted Lemon)

Note: This ballot was opened for revision 03 and is now closed.

Adrian Farrel Former IESG member
Yes
Yes (for -03) Unknown

                            
Alia Atlas Former IESG member
Yes
Yes (for -06) Unknown

                            
Barry Leiba Former IESG member
Yes
Yes (2014-08-12 for -05) Unknown
This is a very fine document that does what needs to be done.  Please don't take any further comments as any sort of criticism of that.  Please note and consider the substantive comments after the rant in the following paragraph.

As we've noted before, the IESG itself doesn't know what to do with this sort of thing, but I think this is a perfect example of a document that "updates" a Standards Track document, but should not, itself, be Standards Track.  Informational is the correct status of this document, and I urge the IESG to make it so.  I see no reason to *require* all updates to Standards Track documents to be Standards Track, and this document changes nothing that would indicate that status.  If it defined new values, it probably should be Standards Track.  But as it just creates the registry and registers what was already defined, it should not.

Now, substantive comments -- not blocking (note the "Yes" ballot), but please consider making these changes:

   The allocation policy for values 0x00 to 0xFA is IETF Review.  Values
   0xFB to 0xFE are experimental and are not to be assigned. 0xFF is
   reserved.

1. I think you need a citation to RFC 5226 here, and a normative reference.

2. FB to FE are not to be assigned; what about FF?  I suggest "0xFF is reserved for possible extensibility, and may only be assigned via Standards Action [RFC5226]."

3. For the values you register from 6514, you give the reference as "[RFC 6514] [RFC-to-be]".  I suggest just "[RFC 6514]", as this RFC says nothing substantive that would be useful to someone looking up what, say, 0x03 means.

4. I don't think Section 2 has any value, and I would simply remove it.  Section 4 says all that's needed.
Alissa Cooper Former IESG member
No Objection
No Objection (for -06) Unknown

                            
Brian Haberman Former IESG member
No Objection
No Objection (2014-08-18 for -06) Unknown
I agree with Barry's point that this document does not need to be Standards Track.
Jari Arkko Former IESG member
No Objection
No Objection (for -06) Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (for -06) Unknown

                            
Kathleen Moriarty Former IESG member
No Objection
No Objection (for -06) Unknown

                            
Martin Stiemerling Former IESG member
No Objection
No Objection (for -06) Unknown

                            
Pete Resnick Former IESG member
No Objection
No Objection (2014-08-18 for -06) Unknown
I agree that this shouldn't be on the Standards Track.
Richard Barnes Former IESG member
No Objection
No Objection (for -06) Unknown

                            
Spencer Dawkins Former IESG member
No Objection
No Objection (for -06) Unknown

                            
Stephen Farrell Former IESG member
No Objection
No Objection (for -06) Unknown

                            
Ted Lemon Former IESG member
No Objection
No Objection (for -06) Unknown