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.decraene@orange.com> Thu, 25 July 2019 22:42 UTC

Return-Path: <bruno.decraene@orange.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D46F1202C2 for <idr@ietfa.amsl.com>; Thu, 25 Jul 2019 15:42:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8JPii_JSh0vn for <idr@ietfa.amsl.com>; Thu, 25 Jul 2019 15:42:02 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE6351202CF for <idr@ietf.org>; Thu, 25 Jul 2019 15:42:00 -0700 (PDT)
Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 45vnJk6qlkz1y1X; Fri, 26 Jul 2019 00:41:58 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.26]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 45vnJk5qS4z1xpC; Fri, 26 Jul 2019 00:41:58 +0200 (CEST)
Received: from OPEXCAUBM43.corporate.adroot.infra.ftgroup ([fe80::b846:2467:1591:5d9d]) by OPEXCAUBM31.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0439.000; Fri, 26 Jul 2019 00:41:58 +0200
From: bruno.decraene@orange.com
To: John Scudder <jgs=40juniper.net@dmarc.ietf.org>, Hares Susan <shares@ndzh.com>, idr wg <idr@ietf.org>
Thread-Topic: [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
Thread-Index: AdVDLuY5u1pV58n8Sf2Gi0aZSH3chAABsV2AAACS/QA=
Date: Thu, 25 Jul 2019 22:41:57 +0000
Message-ID: <20045_1564094518_5D3A3036_20045_426_1_53C29892C857584299CBF5D05346208A48BB98D4@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
References: <034e01d5432f$8841b870$98c52950$@ndzh.com> <680B90BD-9201-4B89-BAF4-79925825AC67@juniper.net>
In-Reply-To: <680B90BD-9201-4B89-BAF4-79925825AC67@juniper.net>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.247]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/tBUlAYCaPeVG7XMDP0rB7m1JZ5w>
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
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jul 2019 22:42:09 -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:grow-bounces@ietf.org] On Behalf Of John Scudder
Sent: Thursday, July 25, 2019 6:10 PM
To: Hares Susan; idr wg
Cc: grow@ietf.org
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

(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 <shares@ndzh.com> 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 
>  
> From: Idr [mailto:idr-bounces@ietf.org] 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 
>  
_______________________________________________
GROW mailing list
GROW@ietf.org
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.