BGP Administrative Shutdown Communication
RFC 8203
Yes
Alvaro Retana
(Alia Atlas)
(Benoît Claise)
(Terry Manderson)
No Objection
(Alissa Cooper)
(Ben Campbell)
(Deborah Brungard)
(Eric Rescorla)
(Kathleen Moriarty)
Note: This ballot was opened for revision 08 and is now closed.
Alvaro Retana
Yes
Warren Kumari
Yes
Comment
(2017-05-22 for -08)
Having had to deal with many instances of "<ring ring>Hey, my BGP session with you just went down, whatsup?!", "Yes, it's a maintenance. I sent you mail about it last month, then last week, then this morning, then 5 minutes before pulling the session. You even generated a ticket for me, it's # [1432323] 'kthnxbye...<click>" I think that this is the best thing since sliced bread (of course, I also thought jabber over BGP was cool).
Some nits:
2. Shutdown Communication
Shutdown Communication: to support international characters, the
Shutdown Communication field MUST be encoded using UTF-8.
perhaps:
"MUST be encoded using UTF-8 "Shortest Form" encoding"? (from Security Considerations) - or Alexey Melnikov's suggestion...
Also, *perhaps* it is worth noting that it might be possible for someone to send:
'BGP going down\nMay 22 11:19:12 rtr1 mib2d[42]: SNMP_TRAP_LINK_TYPE: ifIndex 501, ifOperStatus "Interface is a small turnip", ifName ge-1/2/3'
and that logging of these should strip control characters. This may already be covered in syslog...
Alia Atlas Former IESG member
Yes
Yes
(for -08)
Benoît Claise Former IESG member
Yes
Yes
(for -08)
Spencer Dawkins Former IESG member
Yes
Yes
(2017-05-24 for -08)
(So obviously the right thing to do that even TSV ADs ballot Yes - thanks!)
Terry Manderson Former IESG member
Yes
Yes
(for -08)
Adam Roach Former IESG member
No Objection
No Objection
(2017-05-23 for -08)
The portion of Section 6 (Security Considerations) that discusses confusable characters is describing a problem that isn't obvious on first reading. As these strings are human-produced and human-consumed, it's not clear what harm would arise through the use of spoofing. If there is a real risk here that the authors are aware of, it should be described in more detail to allow implemetors to more adeptly steer around it. If not, the statement around spoofing should probably be removed so as to avoid implementors scratching their heads regarding what mitigating actions they might take.
Alexey Melnikov Former IESG member
No Objection
No Objection
(2017-05-22 for -08)
In Section 2:
Shutdown Communication: to support international characters, the
Shutdown Communication field MUST be encoded using UTF-8. A
receiving BGP speaker MUST NOT interpret invalid UTF-8 sequences.
Note that when the Shutdown Communication contains multibyte
characters, the number of characters will be less than the length
value. This field is not NUL terminated.
I think you should stick a reference to RFC 5198, which talks about subset of UTF-8 intended for human consumption.
I was also thinking about language tagging (RFC 5646) for human readable text, but I suspect that nobody will implement it in your extension.
Alissa Cooper Former IESG member
No Objection
No Objection
(for -08)
Ben Campbell Former IESG member
No Objection
No Objection
(for -08)
Deborah Brungard Former IESG member
No Objection
No Objection
(for -08)
Eric Rescorla Former IESG member
No Objection
No Objection
(for -08)
Kathleen Moriarty Former IESG member
No Objection
No Objection
(for -08)
Mirja Kühlewind Former IESG member
No Objection
No Objection
(2017-05-22 for -08)
I wondering why there is this addition cited below to the copyright notice needed given there is no IPR declared. Can you please explain?! „This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.“
Suresh Krishnan Former IESG member
No Objection
No Objection
(2017-05-23 for -08)
Since this notification message is only defined for two of the subcodes, shouldn't the error handling in Section 4 also check for invalid subcodes? Why is the length limited to 128 (instead of the possible 255)? Could be useful to clarify.