[Idr] RtgDir QA review on draft-ietf-idr-bgp-gr-notification-07

Mach Chen <mach.chen@huawei.com> Wed, 15 June 2016 09:42 UTC

Return-Path: <mach.chen@huawei.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 80A0212D0FE; Wed, 15 Jun 2016 02:42:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.647
X-Spam-Level:
X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-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 b3ZL54iGy05i; Wed, 15 Jun 2016 02:42:20 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E12012D09D; Wed, 15 Jun 2016 02:33:35 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CLZ50081; Wed, 15 Jun 2016 09:33:32 +0000 (GMT)
Received: from SZXEMA411-HUB.china.huawei.com (10.82.72.70) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 15 Jun 2016 10:33:31 +0100
Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.42]) by szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id 14.03.0235.001; Wed, 15 Jun 2016 17:33:22 +0800
From: Mach Chen <mach.chen@huawei.com>
To: "draft-ietf-idr-bgp-gr-notification@tools.ietf.org" <draft-ietf-idr-bgp-gr-notification@tools.ietf.org>, Susan Hares <shares@ndzh.com>, "'John G. Scudder'" <jgs@juniper.net>
Thread-Topic: RtgDir QA review on draft-ietf-idr-bgp-gr-notification-07
Thread-Index: AdHG6PR/x2LfjUXuTCG85tlH1QdySg==
Date: Wed, 15 Jun 2016 09:33:21 +0000
Message-ID: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE28CC815B2@SZXEMA510-MBX.china.huawei.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.102.135]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.576120ED.0151, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.42, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 374cfd1819078a730277bfa8be34444d
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/kqoI3zsgl8V5ULjveUroTtIdzio>
Cc: Jonathan Hardwick <Jonathan.Hardwick@metaswitch.com>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "idr@ietf.org" <idr@ietf.org>, "Zhangxian (Xian)" <zhang.xian@huawei.com>, "rtg-ads@tools.ietf.org" <rtg-ads@tools.ietf.org>
Subject: [Idr] RtgDir QA review on draft-ietf-idr-bgp-gr-notification-07
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, 15 Jun 2016 09:42:21 -0000

Hi Authors,

I was assigned to do a QA review on draft-ietf-idr-bgp-gr-notification-07. For more detail what's is RtgDir QA review, please refer to https://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa 

Overall, the document is well-written and clear, after review, I have the following comments. 

1.  Abstract
s/BGP NOTIFICATION Message/ BGP NOTIFICATION message;

2.  Section 2:
"
    Flags for Address Family:

            This field contains bit flags relating to routes that were
            advertised with the given AFI and SAFI.

                0 1 2 3 4 5 6 7
               +-+-+-+-+-+-+-+-+
               |F|N| Reserved  |
               +-+-+-+-+-+-+-+-+

   The usage of second most significant bit "N" (which was defined in a
   previous draft version of this specification) is deprecated.  This
   bit MUST be advertised as 0 and MUST be ignored upon receipt.
"
The "N" bit was firstly introduced in a previous version of this document, but deprecated in later version. I don't understand why a document need deprecate a functionality introduced by itself, why not just remove it? If we really want to keep this history, maybe a better way is to move above text to an appendix.  

If you agree above, then the last sentence of the first paragraph of section 2 should be changed as bellow:

OLD:
"the Restart flags field and the Flags field for Address Family are augmented as follows:"

New:
"the Restart flags field are augmented as follows:"

3.  Section 3.1

"Subcode is a BGP Error Subcode (as documented in the IANA BGP Error
   Subcodes registry) as appropriate for the ErrCode.  Similarly, Data
   is as appropriate for the ErrCode and Subcode."
This is just an introduction to the Subcode itself, it's better to explicitly state that the subcode should be set to the Hard Reset (9).


Hope you find above review useful.

Best regards,
Mach