Subject: Re: [Idr] WG LC for Extended BGP Administrative Shutdown Communication (bs) - draft-ietf-idr-rfc8203bis-04.txt (7/9 to 7/23) - Extended to 8/6/2019

From: "Susan Hares" <[email-masked]>
Date: Thu, 25 Jul 2019 17:25:50 -0400

Greetings IDR: 

The IDR WG call for input on draft-ietf-idr-rfc8203bis-04.txt has received
only 2 comments.  Since this is a draft that updates an operationally needed
feature,  I am extending the WG LC until 8/6/2019.  

If you believe this draft is ready for publication, please respond to this
WG LC. 

Sue Hares 

From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Tuesday, July 9, 2019 9:13 AM
To: 'idr wg'
Subject: [Idr] WG LC for Extended BGP Administrative Shutdown Communication
(bs) - draft-ietf-idr-rfc8203bis-04.txt (7/9 to 7/23)

This begins a 2 week WG last call for draft-ietf-idr-rfc8203bis-04.txt from
July 9, 2019 to July 23, 2019. . 

Please consider if you believe this revision of RFC8203 (Administrative
Shutdown)

a)      Will benefit operational networks,

b)      is technically complete, and 

c)       ready for publication. 

In your comments, please indicate whether you "support" or "do not support"
its publication. 

This draft contains IPR notice that causes "IPR warnings".   The authors
believe that this text is automatically generated by the IETF tools and the
warning is not appropriate.   

As the shepherd, I am  investigating this issue.   If you have specific
knowledge on this issue, you may send it to the list or to me directly. 

Cheerily, Susan Hares

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 25 Jul 2019 17:48:39 -0400

Sue,

I support publication of this draft.

Cheers,
Jeff
On Jul 25, 2019, 5:26 PM -0400, Susan Hares <[email-masked]>, wrote:
> Greetings IDR:
>
> The IDR WG call for input on draft-ietf-idr-rfc8203bis-04.txt has received only 2 comments.  Since this is a draft that updates an operationally needed feature,  I am extending the WG LC until 8/6/2019.
>
> If you believe this draft is ready for publication, please respond to this WG LC.
>
> Sue Hares
>
> Subject: [Idr] WG LC for Extended BGP Administrative Shutdown Communication (bs) - draft-ietf-idr-rfc8203bis-04.txt (7/9 to 7/23)
>
> This begins a 2 week WG last call for draft-ietf-idr-rfc8203bis-04.txt from July 9, 2019 to July 23, 2019. .
>
> Please consider if you believe this revision of RFC8203 (Administrative Shutdown)
> Will benefit operational networks,
> is technically complete, and
> ready for publication.
>
> In your comments, please indicate whether you “support” or “do not support” its publication.
>
> This draft contains IPR notice that causes “IPR warnings”.   The authors believe that this text is automatically generated by the IETF tools and the warning is not appropriate.
>
> As the shepherd, I am  investigating this issue.   If you have specific knowledge on this issue, you may send it to the list or to me directly.
>
> Cheerily, Susan Hares
>
>
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: John Scudder <[email-masked]>
Date: Thu, 25 Jul 2019 22:09:48 +0000

(As an individual contributor and co-author.)

Thanks for extending this, Sue. Maybe it will help the WG to have a reminder about what this document does. 

It’s a revision of RFC 8203. First, here is the rfcdiff vs. RFC 8203: 
http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=rfc8203&url2=draft-ietf-idr-rfc8203bis
It is quite short, especially when you skip over the boilerplate and "RFC EDITOR: REMOVE BEFORE PUBLICATION” sections. 

The sole normative change vs. 8203 is the deletion of one sentence:

OLD:
   Length:  this 8-bit field represents the length of the Shutdown
      Communication field in octets.  The length value MUST range from 0
      to 128 inclusive.  When the length value is zero, no Shutdown
      Communication field follows.
NEW:
   Length:  this 8-bit field represents the length of the Shutdown
      Communication field in octets.  When the length value is zero, no
      Shutdown Communication field follows.

The reason for this change is summarized in in Appendix B:

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

Now you do not need to actually go read the draft in order to know everything you need to respond to the WGLC. :-)

Thanks,

—John

> On Jul 25, 2019, at 5:25 PM, Susan Hares <[email-masked]> wrote:
> 
> Greetings IDR: 
>

---

From: <[email-masked]>
Date: Thu, 25 Jul 2019 22:41:57 +0000

John, thank you for the summary.

Sue, I support progressing this document.

Following a light 15 seconds review, I can see 2 consequences for this light change:

a) Extended/new speakers are not compliant with RFC8203 since they violate the original MUST.
However,
- I don't see a protocol issue: additional text is just likely to be cut after the 8203 limit. I don't really know how much there is a risk of changing the last printed character in case of multi-bytes characters cut in the middle. But even in the general case, there is a risk of miscommunication. E.g.  a message finishing with "9000" may be received as finishing by "90". You may consider raising this risk, even though it's limited to the transition period.
- I don't see any operational risk: in the end, the session is been closed.

b) In theory, as per RFC 8203 security consideration section, there is an increased security risk that "carefully constructed Shutdown Communication might be formatted by receiving systems in a way to make them appear  as additional syslog messages."
In order to mitigate, what about adding a specific delimiter before & after this Communication message, in order to highlight the separation from regular/local syslog messages? Note that the choice of the delimiter could be local/not specified in this doc and may be phrased as optional (MAY)

Regards,
--Bruno

-----Original Message-----
From: GROW [mailto:[email-masked]] On Behalf Of John Scudder
Sent: Thursday, July 25, 2019 6:10 PM
To: Hares Susan; idr wg
Cc: [email-masked]
Subject: Re: [GROW] [Idr] WG LC for Extended BGP Administrative Shutdown Communication (bs) - draft-ietf-idr-rfc8203bis-04.txt (7/9 to 7/23) - Extended to 8/6/2019

OLD:

Thanks,

—John

_______________________________________________
GROW mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/grow

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Fri, 26 Jul 2019 04:14:09 +0000

Bruno,

Would you be happy if we make mention of these points in the security considerations?

Regards,
Jakob.

-----Original Message-----
From: Idr <[email-masked]> On Behalf Of [email-masked]
Sent: Thursday, July 25, 2019 3:42 PM
To: John Scudder <jgs=[email-masked]>; Hares Susan <[email-masked]>; idr wg <[email-masked]>
Subject: Re: [Idr] [GROW] WG LC for Extended BGP Administrative Shutdown Communication (bs) - draft-ietf-idr-rfc8203bis-04.txt (7/9 to 7/23) - Extended to 8/6/2019

Regards,
--Bruno

-----Original Message-----
From: GROW [mailto:[email-masked]] On Behalf Of John Scudder
Sent: Thursday, July 25, 2019 6:10 PM
To: Hares Susan; idr wg
Cc: [email-masked]
Subject: Re: [GROW] [Idr] WG LC for Extended BGP Administrative Shutdown Communication (bs) - draft-ietf-idr-rfc8203bis-04.txt (7/9 to 7/23) - Extended to 8/6/2019

OLD:

Thanks,

—John

---

From: <[email-masked]>
Date: Fri, 26 Jul 2019 15:58:05 +0000

Jakob,

Thanks for accommodating my comments.
This works for me.

Originally I was thinking about  an operational consideration section. Something like: when you craft the text, please consider that a receiver supporting RFC 8203 but not the extension defined in this document may only receive and print the first 128 octets (not characters). 
I was trying to avoid that the sender meant "DO NOT" while the receiver read "DO" because the end of the message was not printed.
But as a matter of fact, RFC 8203 did a good job in defining the error handling (thanks) and this should not happen (as the message would not be partially printed)

So you can disregard this part of the comment. Sorry for the spam.

Thanks you,
--Bruno

-----Original Message-----
From: Jakob Heitz (jheitz) [mailto:[email-masked]] 
Sent: Friday, July 26, 2019 12:14 AM
To: DECRAENE Bruno TGI/OLN; John Scudder; Hares Susan; idr wg
Subject: RE: [Idr] [GROW] WG LC for Extended BGP Administrative Shutdown Communication (bs) - draft-ietf-idr-rfc8203bis-04.txt (7/9 to 7/23) - Extended to 8/6/2019

Bruno,

Regards,
Jakob.

-----Original Message-----
From: Idr <[email-masked]> On Behalf Of [email-masked]
Sent: Thursday, July 25, 2019 3:42 PM
To: John Scudder <jgs=[email-masked]>; Hares Susan <[email-masked]>; idr wg <[email-masked]>
Subject: Re: [Idr] [GROW] WG LC for Extended BGP Administrative Shutdown Communication (bs) - draft-ietf-idr-rfc8203bis-04.txt (7/9 to 7/23) - Extended to 8/6/2019

Regards,
--Bruno

-----Original Message-----
From: GROW [mailto:[email-masked]] On Behalf Of John Scudder
Sent: Thursday, July 25, 2019 6:10 PM
To: Hares Susan; idr wg
Cc: [email-masked]
Subject: Re: [GROW] [Idr] WG LC for Extended BGP Administrative Shutdown Communication (bs) - draft-ietf-idr-rfc8203bis-04.txt (7/9 to 7/23) - Extended to 8/6/2019

OLD:

Thanks,

—John

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 26 Jul 2019 18:30:28 +0000

I also support publication.
Thanks
Acee

From: Idr <[email-masked]> on behalf of Jeff Tantsura <[email-masked]>
Date: Thursday, July 25, 2019 at 5:49 PM
To: IDR List <[email-masked]>, Susan Hares <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Idr] WG LC for Extended BGP Administrative Shutdown Communication (bs) - draft-ietf-idr-rfc8203bis-04.txt (7/9 to 7/23) - Extended to 8/6/2019

Sue,

Cheers,
Jeff

Greetings IDR:

Sue Hares

ready for publication.

Cheerily, Susan Hares