Registry and Extensions for P-Multicast Service Interface Tunnel Attribute Flags
draft-ietf-bess-pta-flags-03
Yes
(Alvaro Retana)
No Objection
(Alia Atlas)
(Alissa Cooper)
(Benoît Claise)
(Deborah Brungard)
(Jari Arkko)
(Joel Jaeggli)
(Kathleen Moriarty)
(Terry Manderson)
Note: This ballot was opened for revision 02 and is now closed.
Alvaro Retana Former IESG member
Yes
Yes
(for -02)
Unknown
Alexey Melnikov Former IESG member
No Objection
No Objection
(2016-04-24 for -02)
Unknown
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 IESG member
No Objection
No Objection
()
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
(for -02)
Unknown
Ben Campbell Former IESG member
No Objection
No Objection
(2016-05-03)
Unknown
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 IESG member
No Objection
No Objection
(for -02)
Unknown
Deborah Brungard Former IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
()
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
()
Unknown
Kathleen Moriarty Former IESG member
No Objection
No Objection
()
Unknown
Mirja Kühlewind Former IESG member
No Objection
No Objection
(2016-04-26 for -02)
Unknown
Not important but why is the Extension flag bit 1 and not bit 0?
Stephen Farrell Former IESG member
No Objection
No Objection
(2016-05-03 for -02)
Unknown
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 IESG member
No Objection
No Objection
(2016-05-03)
Unknown
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 IESG member
No Objection
No Objection
()
Unknown