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

["Jakob Heitz (jheitz)" <[e-mail]>]

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 <[e-mail]> 
Sent: Monday, July 13, 2020 8:33 PM
To: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
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]