Skip to main content

Extended BGP Administrative Shutdown Communication
draft-ietf-idr-rfc8203bis-08

Yes

(Alvaro Retana)

No Objection

Erik Kline
Murray Kucherawy
Roman Danyliw
(Deborah Brungard)
(Martin Duke)
(Martin Vigoureux)

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

Warren Kumari
Yes
Comment (2020-10-05 for -07) Sent
Thanks to Dan for the OpsDir reivew.
Erik Kline
No Objection
Murray Kucherawy
No Objection
Roman Danyliw
No Objection
Éric Vyncke
No Objection
Comment (2020-10-02 for -07) Sent
Thank you for this short and easy to read document.

Non-blocking comment/question: I really wonder what is the use of this document (message of 0-255 octets) vs. RFC 8203 (message of 0-127 octets) especially when using the same code points... 128 octets is already a long message in ASCII (less of course in UTF-8) and there is no way to know whether the receiving BGP speaker supports this document. I.e., except within a domain, there is little use of this document. What did I get wrong ?

Regards

-éric
Alvaro Retana Former IESG member
Yes
Yes (for -07) Unknown

                            
Barry Leiba Former IESG member
Yes
Yes (2020-10-07 for -07) Sent
It would help if the document said, right up in the Introduction, that the purpose of this is to increase the valid length of the Shutdown Communication to 255 octets, up from 128, because 128 turned out not to be enough for translation of reasonable strings into some languages, such as Russian.  Such a statement might have made it clearer to the IESG, and perhaps to other reviewers, and will likely help other readers understand why this update is being made.

To respond to Alissa's comment about what we might do to avoid this in future is that it's correct that an Internationalization review probably would not have picked up that 128 octets might not be enough for, say, Russian translation of common messages.  I guess we could try doing sample translations before settling on maximum field lengths.  I suspect that the effort is likely not worth it, given how infrequently this has turned out to be a problem so far.  I don't see other I18N issues with this document.

I have one text suggestion, as this point has been confusing to people in the past:
OLD
      Note that when the Shutdown Communication contains multibyte
      characters, the number of characters will be less than the length
      value.
NEW
      Note that UTF-8 often encodes a single Unicode character as
      multiple octets. When the Shutdown Communication contains
      such multibyte characters, the length value (in UTF-8 octets) will
      be greater than the number of Unicode characters.
END
Benjamin Kaduk Former IESG member
Yes
Yes (2020-10-02 for -07) Sent
Thank you for this clear and well-written document.  Just a couple minor comments;
no reply necessary.

Section 4

   If a Shutdown Communication with an invalid UTF-8 sequence is
   received, a message indicating this event SHOULD be logged for the

Could we say "invalid or non-shortest-form-encoded UTF-8 sequence"?
I had started a comment on section 2 about the error handling, but then
I saw that there was already an error handling section!

Section 7.2

Some die-hards might argue that the "SHOULD include methods such as
syslog" promotes RFC 5424 to a normative reference, but I won't make a
big deal about it.
Alissa Cooper Former IESG member
(was Discuss) No Objection
No Objection (2020-11-25) Sent
Thanks for addressing my DISCUSS point. As a courtesy, please respond to the Gen-ART review.
Deborah Brungard Former IESG member
No Objection
No Objection (for -07) Not sent

                            
Martin Duke Former IESG member
No Objection
No Objection (for -07) Not sent

                            
Martin Vigoureux Former IESG member
No Objection
No Objection (for -07) Not sent

                            
Robert Wilton Former IESG member
No Objection
No Objection (2020-10-05 for -07) Sent
Hi,

I found this short document to be easy to read and understand, so thank you for that.

One minor nit, which you are free to take or leave:

2.  Shutdown Communication

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Error Code 6  |    Subcode    |    Length     |     ...       \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               /
   \                                                               \
   /                 ... Shutdown Communication ...                /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It would be nice to link the "Error Code 6" back to its definition of "Cease".  E.g. this could be done in the preceding paragraph 'Error Code 6 ("Cease")', by defining the Error Code field below the packet diagram (e.g. as is done for the Subcode field).

Regards,
Rob