Re: [Idr] Routing directorate QA review of draft-ietf-idr-ext-opt-param-04
Susan Hares <shares@ndzh.com> Wed, 22 June 2016 22:35 UTC
Return-Path: <shares@ndzh.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 B35A812DD92; Wed, 22 Jun 2016 15:35:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.106
X-Spam-Level:
X-Spam-Status: No, score=-1.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no 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 MAZulbEUqneD; Wed, 22 Jun 2016 15:35:24 -0700 (PDT)
Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EE8612DD7D; Wed, 22 Jun 2016 15:34:40 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=107.92.122.226;
Date: Wed, 22 Jun 2016 18:34:33 -0400
Message-ID: <m8h688tnbwxkug7d8u82j25c.1466634873538@email.android.com>
Importance: normal
From: Susan Hares <shares@ndzh.com>
To: "Bocci, Matthew (Nokia - GB)" <matthew.bocci@nokia.com>, "idr@ietf.org" <idr@ietf.org>, "jgs@juniper.net" <jgs@juniper.net>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "draft-ietf-idr-ext-opt-param@ietf.org" <draft-ietf-idr-ext-opt-param@ietf.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_189308569651720"
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/Zwpb2acIpZk7CPqjvNe9Hetm5Aw>
Subject: Re: [Idr] Routing directorate QA review of draft-ietf-idr-ext-opt-param-04
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
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: Wed, 22 Jun 2016 22:35:27 -0000
Matthew Thank you for the QA review. The authors will get back to you with their changes.Sue Sent via the Samsung Galaxy Note5, an AT&T 4G LTE smartphone-------- Original message --------From: "Bocci, Matthew (Nokia - GB)" <matthew.bocci@nokia.com> Date: 6/21/2016 6:10 AM (GMT-05:00) To: idr@ietf.org, Susan Hares <shares@ndzh.com>, jgs@juniper.net, rtg-dir@ietf.org, draft-ietf-idr-ext-opt-param@ietf.org Subject: [Idr] Routing directorate QA review of draft-ietf-idr-ext-opt-param-04 Authors, I have been asked to do a QA review of draft-ietf-idr-ext-opt-param-04.txt. Summary: The document is reasonably straight forward and is well written. I have a few comments below. Comments: Minor Issues: 1) Section 2, Protocol Extensions. You have labelled the existing Length and Type fields as 0xFF. I assume the meaning of the second is still 'Type' since that is what any implementation would reasonably interpret it as, and that is the registry you are using a code point from. So it might be better to say in the text above the figure at the top of page 3 that the length and type fields in [RFC4271] are set to 0xFF. Also, you don't explicitly define what a receiver should do with the length field if the type is 0xFF. Does it ignore it, or does it check that it is 0xFF and treat the OPEN message as malformed if it is < 0xFF? Since the document changes the procedures in RFC4271 for BGP Open optional parameters where length > 255, in that the original length field is no longer to be interpreted as the actual length, then I think you should mark this draft as 'Updates: 4271'. 2) Section 5: Security Extensions The security considerations section seems to be lacking detail and amounts to one line: "This extension to BGP does not change the underlying security issues" It might be worth being a little more explicit, or at least use wording similar to RFC5492, and saying that it does not add any new security issues that are not inherent in BGP [RFC4272]. Regards Matthew
- Re: [Idr] Routing directorate QA review of draft-… Bocci, Matthew (Nokia - GB)
- Re: [Idr] Routing directorate QA review of draft-… John G. Scudder
- Re: [Idr] Routing directorate QA review of draft-… Jakob Heitz (jheitz)
- Re: [Idr] Routing directorate QA review of draft-… John G. Scudder
- Re: [Idr] Routing directorate QA review of draft-… Enke Chen
- Re: [Idr] Routing directorate QA review of draft-… Jakob Heitz (jheitz)
- Re: [Idr] Routing directorate QA review of draft-… John G. Scudder
- Re: [Idr] Routing directorate QA review of draft-… John G. Scudder
- Re: [Idr] Routing directorate QA review of draft-… Jakob Heitz (jheitz)
- Re: [Idr] Routing directorate QA review of draft-… Enke Chen
- Re: [Idr] Routing directorate QA review of draft-… John G. Scudder
- Re: [Idr] Routing directorate QA review of draft-… Susan Hares
- [Idr] Routing directorate QA review of draft-ietf… Bocci, Matthew (Nokia - GB)
- Re: [Idr] Routing directorate QA review of draft-… Jakob Heitz (jheitz)