Registry and Extensions for P-Multicast Service Interface Tunnel Attribute Flags
RFC 7902

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

Alvaro Retana Yes

(Jari Arkko) No Objection

(Alia Atlas) No Objection

Deborah Brungard No Objection

(Ben Campbell) No Objection

Comment (2016-05-03)
No email
send info
I do not suggest a change to the draft, but I am curious why the "Additional PMSI Tunnel Attribute Flags" registry needs a standards-action policy. It's pretty obvious why for the main flag registry, due to the small value-space. Are people concerned that the Additional flag will also run out of space? Or that people will define "bad" or non-interoperable extensions?

(Benoît Claise) No Objection

Alissa Cooper No Objection

(Stephen Farrell) No Objection

Comment (2016-05-03 for -02)
No email
send info
The discussion resulting from the secdir review [1] lead
to some suggested changes that haven't yet been included
in an update. This is just to remind ourselves about
that.

   [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06525.html

(Joel Jaeggli) No Objection

Suresh Krishnan No Objection

Comment (2016-05-03)
No email
send info
Section 2:

* Some of the MUST and MUST NOT requirements are stated on the message itself without stating the sender side rules.

e.g. 

   The Additional PMSI Tunnel Attribute Flags Extended Community MUST
   NOT be carried by a given BGP UPDATE message unless the following
   conditions both hold:

It would be far more useful to state this as a sender rule

e.g. 

   The sender of a given BGP UPDATE message MUST NOT include an Additional 
   PMSI Tunnel Attribute Flags Extended Community unless the following
   conditions both hold:

* The following text seems to be redundant as there is a receiver rule that verifies exactly this. What exactly is the intent of this text and who is expected to adhere to/enforce it?

   If a given BGP UPDATE message is carrying a PMSI Tunnel attribute,
   but is not carrying an Additional PMSI Tunnel Attribute Flags
   Extended Community, then the Extension flag in the PMSI Tunnel
   attribute MUST be clear.

Mirja Kühlewind No Objection

Comment (2016-04-26 for -02)
No email
send info
Not important but why is the Extension flag bit 1 and not bit 0?

(Terry Manderson) No Objection

Alexey Melnikov No Objection

Comment (2016-04-24 for -02)
No email
send info
Can you please clarify how extended flags are encoded on the wire? I don't think this is clear from the document.

(Kathleen Moriarty) No Objection