Re: [Gen-art] Genart last call review of draft-ietf-idr-rfc8203bis-06

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@ietf.org> 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@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art