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

[Jakob Heitz (jheitz)]

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  
Sent: Monday, July 13, 2020 8:33 PM
To: gen-art@ietf.org
Cc: draft-ietf-idr-rfc8203bis@ietf.org; last-c...@ietf.org; i...@ietf.org
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

.

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

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

[Alissa Cooper]

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  
> 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
> 
> .
> 
> 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

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Dale Worley via Datatracker]

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

.

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