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

Alvaro Retana Yes

(Alexey Melnikov; former steering group member) No Objection

Can you please clarify how extended flags are encoded on the wire? I don't think this is clear from the document.

(Alia Atlas; former steering group member) No Objection

(Alissa Cooper; former steering group member) No Objection

(Ben Campbell; former steering group member) No Objection

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; former steering group member) No Objection

(Deborah Brungard; former steering group member) No Objection

(Jari Arkko; former steering group member) No Objection

(Joel Jaeggli; former steering group member) No Objection

(Kathleen Moriarty; former steering group member) No Objection

(Mirja Kühlewind; former steering group member) No Objection

Not important but why is the Extension flag bit 1 and not bit 0?

(Stephen Farrell; former steering group member) No Objection

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

(Suresh Krishnan; former steering group member) No Objection

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.

(Terry Manderson; former steering group member) No Objection