BGP Administrative Shutdown Communication

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

Alia Atlas Yes

Benoit Claise Yes

Spencer Dawkins Yes

Comment (2017-05-24 for -08)
(So obviously the right thing to do that even TSV ADs ballot Yes - thanks!)

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.
"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...

Terry Manderson Yes

Alvaro Retana Yes

Deborah Brungard No Objection

Ben Campbell No Objection

Alissa Cooper No Objection

Suresh Krishnan No Objection

Comment (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.

Mirja Kühlewind No Objection

Comment (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.“

Alexey Melnikov No Objection

Comment (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.

Kathleen Moriarty No Objection

Eric Rescorla No Objection

Adam Roach No Objection

Comment (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.