IETF Logo Mail Archive

[RTG-DIR] Routing directorate QA review of draft-ietf-idr-ext-opt-param-04

"Bocci, Matthew (Nokia - GB)" <matthew.bocci@nokia.com> Tue, 21 June 2016 10:10 UTC

Return-Path: <matthew.bocci@nokia.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D793D12D0AD; Tue, 21 Jun 2016 03:10:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham 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 xEpk69WCnW5J; Tue, 21 Jun 2016 03:10:30 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A8C112D093; Tue, 21 Jun 2016 03:10:26 -0700 (PDT)
Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id E830A60945EF5; Tue, 21 Jun 2016 10:10:21 +0000 (GMT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u5LAANHo005444 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 21 Jun 2016 10:10:24 GMT
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u5LAAL9U009174 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Jun 2016 12:10:23 +0200
Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.240]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Tue, 21 Jun 2016 12:10:22 +0200
From: "Bocci, Matthew (Nokia - GB)" <matthew.bocci@nokia.com>
To: "idr@ietf.org" <idr@ietf.org>, Susan Hares <shares@ndzh.com>, "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>
Thread-Topic: Routing directorate QA review of draft-ietf-idr-ext-opt-param-04
Thread-Index: AQHRy6UfQEUW7Xqfm0G1XhSr365WJw==
Date: Tue, 21 Jun 2016 10:10:22 +0000
Message-ID: <A203A2D7-4F07-4790-B996-AB0310CBEF0D@nokia.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.17.0.160611
x-originating-ip: [135.239.27.40]
Content-Type: multipart/alternative; boundary="_000_A203A2D74F074790B996AB0310CBEF0Dnokiacom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/obh1Yz71liQxKQGvHoDBKMfdM10>
Subject: [RTG-DIR] Routing directorate QA review of draft-ietf-idr-ext-opt-param-04
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Jun 2016 10:10:32 -0000

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

v2.23.0 | Report a Bug | By Email