Summary: Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved.
"If a Shutdown Communication longer than 128 octets is sent to a BGP speaker that implements [RFC8203], then that speaker will treat it as an error, the consequence of which is a log message. For this reason, operators would be wise to keep shutdown communications to less than 128 octets when feasible." I have a similar question to what Éric asked. Doesn't the above mostly undercut the value of doing this bis at all? If operators can't expect longer messages to be understood, will they implement some kind of policy logic or heuristics to decide when to try to send them and when not? Otherwise, under what circumstances will they send them? Was it considered to instead add a new subcode to the BGP Cease NOTIFICATION subcode registry to capture this case (admin reset or shutdown with long shutdown message)? That way at least those who want to use it can differentiate between recipients that don't support RFC 8203, those that do, and those that support longer communications. I'm not at all steeped in BGP so I'm happy to drop this if it's unworkable, but I wanted to ask.
Please respond to the Gen-ART review. For the IESG: it would be good to discuss a bit if there is some process we can use to avoid this kind of oversight (that occurred with RFC 8203) in the future. i18ndir didn't exist when it was published, but even if it had I'm not sure we would have caught this.
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.
Thanks to Dan for the OpsDir reivew.
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
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
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