Dale, thanks for your review. I entered a DISCUSS ballot. I think some of the questions you raise about Appendix B deserve some further discussion. Thanks, Alissa > On Jul 13, 2020, at 11:32 PM, Dale Worley via Datatracker <noreply@xxxxxxxx> wrote: > > Reviewer: Dale Worley > Review result: Ready with Nits > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > Document: draft-ietf-idr-rfc8203bis-06 > Reviewer: Dale R. Worley > Review Date: 2020-07-13 > IETF LC End Date: 2020-07-14 > IESG Telechat date: not known > > Summary: > > This draft is basically ready for publication, but has nits that > should be fixed before publication. > > * Minor issues: > > 3. Operational Considerations > > See the comments about Appendix B. > > Appendix B. Changes to RFC 8203 > > xThis appendix should describe upward-compatibility considerations. > The body says that the Communication should be limited to 128 octets > if feasible. But there could be situations where the sender sends a > longer Communication without knowing that the receiver implements > 8203bis, and the receiver in fact does not. How to recover from that > situation? E.g., will the NOTIFICATION be rejected with a specific > error message? Can the sender detect the problem by the subsequent > behavior of the receiver? Is it even well-defined that the receiver > will reject the message? Can the situation be compensated by > immediately sending another NOTIFICATION without the Communication? > > Indeed these considerations probably should be put in section 3. > > * Nits/editorial comments: > > Abstract > > It seems like it would be useful to note here "This document updates > RFC 4486 and obsoletes RFC 8203 by defining an Extended BGP > Administrative Shutdown Communication >>>of up to 255 octets<<< to > improve communication using multibyte character sets." since the > length extension is the only significant change this document > introduces. > > 1. Introduction > > via offline methods such email or telephone calls. This document > > Insert "such >>>as<<< email". > > 2. Shutdown Communication > > This field is not NULL terminated. > > The best phrasing is "NUL terminated", as the name of the character is > NUL. (See RFC 20.) However, it is common to say "null terminated", > which is valid because "null" is a common adjective (i.e., not a > proper adjective) that describes the variety of termination. But > "NULL terminated", though not infrequently used, isn't reallly > correct. (Unless the RFC Editor says otherwise!) > > 6. Security Considerations > > UTF-8 "Shortest Form" encoding is > REQUIRED to guard against the technical issues outlined in [UTR36]. > > It might be useful to repeat this restriction in the description of > the Communication field in section 2. > > [END] > > > > _______________________________________________ > Gen-art mailing list > Gen-art@xxxxxxxx > https://www.ietf.org/mailman/listinfo/gen-art -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
