IETF Logo Mail Archive

Re: [Idr] [RTG-DIR] RtgDir Review: draft-ietf-idr-error-handling-16.txt

"John G. Scudder" <jgs@juniper.net> Fri, 12 December 2014 18:56 UTC

Return-Path: <jgs@juniper.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0581A88C2; Fri, 12 Dec 2014 10:56:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 IO-Zr7rt1QyC; Fri, 12 Dec 2014 10:56:27 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0799.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::799]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D2DE1A7020; Fri, 12 Dec 2014 10:56:26 -0800 (PST)
Received: from BY2PR05MB728.namprd05.prod.outlook.com (10.141.223.25) by BY2PR05MB127.namprd05.prod.outlook.com (10.242.38.24) with Microsoft SMTP Server (TLS) id 15.1.31.17; Fri, 12 Dec 2014 18:56:02 +0000
Received: from msims-sslvpn-nc.jnpr.net (66.129.241.13) by BY2PR05MB728.namprd05.prod.outlook.com (10.141.223.25) with Microsoft SMTP Server (TLS) id 15.1.31.17; Fri, 12 Dec 2014 18:55:59 +0000
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: "John G. Scudder" <jgs@juniper.net>
In-Reply-To: <F69F913F-3008-4C99-8500-F4A4CF2B04C3@juniper.net>
Date: Fri, 12 Dec 2014 13:55:49 -0500
Content-Transfer-Encoding: quoted-printable
Message-ID: <35D92225-7901-4D98-80E3-2415EC651484@juniper.net>
References: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE28B326E3D@SZXEMA510-MBX.china.huawei.com> <F69F913F-3008-4C99-8500-F4A4CF2B04C3@juniper.net>
To: Mach Chen <mach.chen@huawei.com>
X-Mailer: Apple Mail (2.1878.6)
X-Originating-IP: [66.129.241.13]
X-ClientProxiedBy: CY1PR09CA0026.namprd09.prod.outlook.com (25.160.223.36) To BY2PR05MB728.namprd05.prod.outlook.com (10.141.223.25)
X-Microsoft-Antispam: UriScan:;UriScan:;
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB728;
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601003); SRVR:BY2PR05MB728;
X-Forefront-PRVS: 04238CD941
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(377454003)(164054003)(24454002)(189002)(199003)(21056001)(122386002)(50226001)(4396001)(97736003)(76176999)(19580405001)(47776003)(50986999)(20776003)(66066001)(99396003)(31966008)(64706001)(82746002)(57306001)(89996001)(230783001)(69596002)(19580395003)(120916001)(107046002)(83716003)(1720100001)(86362001)(33656002)(77096005)(101416001)(23676002)(15975445007)(68736005)(42186005)(50466002)(62966003)(53416004)(81156004)(110136001)(46102003)(105586002)(87976001)(77156002)(92566001)(106356001)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB728; H:msims-sslvpn-nc.jnpr.net; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB728;
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB127;
X-OriginatorOrg: juniper.net
Archived-At: http://mailarchive.ietf.org/arch/msg/idr/iCfjBJPbCWD-08jw7heCelMEz7Q
Cc: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "idr@ietf.org" <idr@ietf.org>, "draft-ietf-idr-error-handling@tools.ietf.org" <draft-ietf-idr-error-handling@tools.ietf.org>, "rtg-ads@tools.ietf.org" <rtg-ads@tools.ietf.org>
Subject: Re: [Idr] [RTG-DIR] RtgDir Review: draft-ietf-idr-error-handling-16.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Fri, 12 Dec 2014 18:56:29 -0000

Chris Hall kindly pointed out to me that RFC 5549 only relates to the MP-BGP encoding and NOT the legacy NEXT_HOP attribute, and thus my last change was in error. I've reverted that change and will post it as -18. (The two editorial changes are still there.) Section 7.11 did already capture the "4 or 16" point for MP_REACH_NLRI, so no change needed there.

Thanks, Chris!

--John

On Dec 12, 2014, at 9:37 AM, John G. Scudder <jgs@juniper.net> wrote:

> Hi Mach,
> 
> Thanks for your review and comments. I will make the changes and issue a new version. Good catch on the RFC 5549 issue.
> 
> Regards,
> 
> --John
> 
> On Dec 12, 2014, at 2:51 AM, Mach Chen <mach.chen@huawei.com> wrote:
> 
>> Hello, 
>> 
>> I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir 
>> 
>> Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. 
>> 
>> Document: draft-ietf-idr-error-handling-16.txt 
>> Reviewer: Mach Chen 
>> Review Date: Nov. 12, 2014 
>> Intended Status: Standards Track
>> 
>> Summary: 
>> This document is well written and easy to understand. I found some nits and one minor issue that I think should be resolved before publication.
>> 
>> Comments: 
>> None.
>> 
>> Major Issues: 
>> No major issues found. 
>> 
>> Minor Issues: 
>> Section 7.3
>> "The attribute is considered malformed if its length is not 4 [RFC4271]."
>> 
>> If only according to RFC4271, this is the case, but seems that RFC5549 allows that the length of Nexthop attribute can be either 4 or 16.
>> 
>> Nits: 
>> Section 2.
>> s/to handling/to handle
>> 
>> in the last bullet of the 4 approaches.
>> s/must not/MUST NOT
>> 
>> Best regards,
>> Mach
>> 
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr

v2.23.0 | Report a Bug | By Email