Dale, Sorry for not responding directly to your email. Your concerns were addressed in -07 and more so in https://tools.ietf.org/html/draft-ietf-idr-rfc8203bis-08 Regards, Jakob. -----Original Message----- From: Dale Worley via Datatracker <noreply@xxxxxxxx> Sent: Monday, July 13, 2020 8:33 PM To: gen-art@xxxxxxxx Cc: draft-ietf-idr-rfc8203bis.all@xxxxxxxx; last-call@xxxxxxxx; idr@xxxxxxxx Subject: Genart last call review of draft-ietf-idr-rfc8203bis-06 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] -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
