Re: [Idr] AD Review of draft-ietf-idr-rfc8203bis-06

Jakob: 

If you cannot fix this issues, you may delete the example. 

Sue Hares 

-----Original Message-----
From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jakob Heitz (jheitz)
Sent: Tuesday, July 14, 2020 1:18 PM
To: Susan Hares; 'Alvaro Retana'; draft-ietf-idr-rfc8203bis@ietf.org
Cc: idr-chairs@ietf.org; 'idr@ietf. org'
Subject: Re: [Idr] AD Review of draft-ietf-idr-rfc8203bis-06

Sue, Did you have any luck with the Cyrillic?

The draft says: (See PDF for non-ASCII character string), but when I click
the PDF link, it is exactly the same.

Sasha, are you able to create a PDF with the Cyrillic correctly rendered and
upload it?

Alvaro, if we can make it work in the PDF, is it good enough?

If we can't fix this, could we delete the example?
I think the problem is clear enough even without the example.

Regards,
Jakob.

-----Original Message-----
From: Susan Hares <shares@ndzh.com>
Sent: Monday, June 29, 2020 7:53 AM
To: 'Alvaro Retana' <aretana.ietf@gmail.com>;
draft-ietf-idr-rfc8203bis@ietf.org
Cc: idr-chairs@ietf.org; 'idr@ietf. org' <idr@ietf.org>
Subject: RE: AD Review of draft-ietf-idr-rfc8203bis-06

Alvaro: 

Thank you for your AD report. 

A bit thank you for  catching the major issue - that RFC8203 is being
declared obsolete. 
(blush).   I'm sorry I missed that one. 

I'll work to try to fix the Cyrillic script. 

Cheerily, Susan Hares 

-----Original Message-----
From: Alvaro Retana [mailto:aretana.ietf@gmail.com]
Sent: Monday, June 29, 2020 10:48 AM
To: draft-ietf-idr-rfc8203bis@ietf.org
Cc: Susan Hares; idr-chairs@ietf.org; idr@ietf. org
Subject: AD Review of draft-ietf-idr-rfc8203bis-06

Dear authors:

Thank you for this document!

I only have a couple of comments (see below).  I think these should be easy
to address -- I'm starting the IETF Last Call.

Thanks!

Alvaro.

[Line numbers from idnits.]

....
80	1.  Introduction

82	   It can be troublesome for an operator to correlate a BGP-4
[RFC4271]
83	   session teardown in the network with a notice that was
transmitted
84	   via offline methods such email or telephone calls.  This document
85	   updates [RFC4486] by specifying a mechanism to transmit a short
86	   freeform UTF-8 [RFC3629] message as part of a Cease NOTIFICATION
87	   message [RFC4271] to inform the peer why the BGP session is being
88	   shutdown or reset.  This document obsoletes [RFC8203]; the
specific
89	   differences and rationale are discussed in detail in Appendix B.

[nit] s/such email/such as email

91	2.  Shutdown Communication
....
102	    0                   1                   2                   3
103	    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
104	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
105	   | Error code 6  |    Subcode    |    Length     |     ...       \
106	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               /
107	   \                                                               \
108	   /                 ... Shutdown Communication ...                /
109	   \                                                               \
110	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

[nit] s/Error code/Error Code
Capitalized in rfc486...

....
168	5.  IANA Considerations

170	   Per this document, IANA is requested to reference this document
at
171	   subcode "Administrative Shutdown", and at subcode "Administrative
172	   Reset" in the "BGP Cease NOTIFICATION message subcodes" registry
173	   under the "Border Gateway Protocol (BGP) Parameters" group in
174	   addition to [RFC4486] and [RFC8203].

[nit] s/Per this document, /

[major] s/ and [RFC8203]./.
rfc8203 is being declared obsolete.

....
207	7.1.  Normative References
....
231	   [RFC8203]  Snijders, J., Heitz, J., and J. Scudder, "BGP
232	              Administrative Shutdown Communication", RFC 8203,
233	              DOI 10.17487/RFC8203, July 2017,
234	              <https://www.rfc-editor.org/info/rfc8203>.

[minor] This reference should be Informative.

....
271	Appendix B.  Changes to RFC 8203
....
275	   Feedback from operators based in regions which predominantly use
276	   multibyte character sets, showed that messages similar in meaning
to
277	   what can be send in other languages in using single-byte
encoding,
278	   failed to fit within the Length constraints as specified by
279	   [RFC8203].  For example, the phrase: 'Planned work to add switch
to
280	   stack.  Completion time - 30 minutes' has length 65 bytes.  Its
281	   translation in Russian
282	   '&#1055;&#1083;&#1072;&#1085;&#1086;&#1074;&#1099;&#1077;
283	   &#1088;&#1072;&#1073;&#1086;&#1090;&#1099; &#1087;&#1086;
&#1076;&#10
284	   86;&#1073;&#1072;&#1074;&#1083;&#1077;&#1085;&#1080;&#1102;
&#1082;&#
285
1086;&#1084;&#1084;&#1091;&#1090;&#1072;&#1090;&#1086;&#1088;&#1072;&
286	   #1074;
287	   &#1089;&#1090;&#1077;&#1082;.&#1042;&#1088;&#1077;&#1084;&#1103;
&#10
288
79;&#1072;&#1074;&#1077;&#1088;&#1096;&#1077;&#1085;&#1080;&#1103; -
289	   30&#1084;&#1080;&#1085;&#1091;&#1090;' (See PDF for non-ASCII
290	   character string) has length 139 bytes.

[major] I looked at all the other versions and none of them rendered
Cyrillic script.  I have no idea how to fix that, maybe ask the rfc-editor.
I also don't know if there's something special about the new v3 format that
would make this easier...  I'll rely on the authors/Shepherd to solve this
before approval.

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr