RE: WGLC on draft-ietf-bfd-yang

Qin Wu <bill.wu@huawei.com> Tue, 06 March 2018 01:14 UTC

Return-Path: <bill.wu@huawei.com>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC65127601 for <rtg-bfd@ietfa.amsl.com>; Mon, 5 Mar 2018 17:14:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.23
X-Spam-Level:
X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 jgsCVnmY1ebY for <rtg-bfd@ietfa.amsl.com>; Mon, 5 Mar 2018 17:14:53 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 158EF1241F5 for <rtg-bfd@ietf.org>; Mon, 5 Mar 2018 17:14:53 -0800 (PST)
Received: from LHREML713-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id B0EF4637ABC69 for <rtg-bfd@ietf.org>; Tue, 6 Mar 2018 01:14:48 +0000 (GMT)
Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.382.0; Tue, 6 Mar 2018 01:14:49 +0000
Received: from NKGEML513-MBS.china.huawei.com ([169.254.2.231]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0361.001; Tue, 6 Mar 2018 09:14:42 +0800
From: Qin Wu <bill.wu@huawei.com>
To: "Reshad Rahman (rrahman)" <rrahman@cisco.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: RE: WGLC on draft-ietf-bfd-yang
Thread-Topic: WGLC on draft-ietf-bfd-yang
Thread-Index: AQHToRcWBm73xJ1GeEmHmnjXxZG+zqOfqWoAgBE1MICAAHL1MIAAAxzVgABGPdCAAJy/AIANhgOAgALQIJA=
Date: Tue, 06 Mar 2018 01:14:41 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABA9AD7936E@nkgeml513-mbs.china.huawei.com>
References: <20180124182206.GP5950@pfrc.org> <20180208200252.GA4073@pfrc.org> <20180211152046.GB4073@pfrc.org> <BE6310D2-6B52-48A5-9FBF-18A4B37F2CBE@cisco.com> <B8F9A780D330094D99AF023C5877DABA9AD66603@nkgeml513-mbs.china.huawei.com> <F9A40C4B-9217-4CD2-A3CB-3927C8CEB46E@cisco.com> <B8F9A780D330094D99AF023C5877DABA9AD66BF6@nkgeml513-mbs.china.huawei.com> <8BF7AEBB-86CD-4BF2-8235-3EB2F54ED1F9@cisco.com> <DABEFA80-F3A0-447C-A64C-A44454797D81@cisco.com>
In-Reply-To: <DABEFA80-F3A0-447C-A64C-A44454797D81@cisco.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.136.79.67]
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA9AD7936Enkgeml513mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/k6E83tEkHhn1kuJa1KS__VW2AZQ>
X-Mailman-Approved-At: Mon, 05 Mar 2018 17:21:49 -0800
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Mar 2018 01:14:58 -0000

Sorry for late reply.

These changes sounds good to me, you forgot to add reference to [I-D.ietf-netmod-yang-tree-diagrams<https://tools.ietf.org/html/draft-ietf-lime-yang-connection-oriented-oam-model-07#ref-I-D.ietf-netmod-yang-tree-diagrams>].
[I-D.ietf-netmod-yang-tree-diagrams<https://tools.ietf.org/html/draft-ietf-lime-yang-connection-oriented-oam-model-07#ref-I-D.ietf-netmod-yang-tree-diagrams>] will be published before your document.

For RPC, I am okay you keep as it does, but it still looks you leave rpc for future extension.

-Qin
发件人: Reshad Rahman (rrahman) [mailto:rrahman@cisco.com]
发送时间: 2018年3月4日 22:14
收件人: Qin Wu; rtg-bfd@ietf.org
主题: Re: WGLC on draft-ietf-bfd-yang

Hi Qin,

We have made changes in revs 10 and 11 to address YD comments and WGLC comments from yourself.

Regards,
Reshad.

From: Rtg-bfd <rtg-bfd-bounces@ietf.org<mailto:rtg-bfd-bounces@ietf.org>> on behalf of "Reshad Rahman (rrahman)" <rrahman@cisco.com<mailto:rrahman@cisco.com>>
Date: Friday, February 23, 2018 at 6:43 PM
To: Qin Wu <bill.wu@huawei.com<mailto:bill.wu@huawei.com>>, "rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>" <rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>>
Subject: Re: WGLC on draft-ietf-bfd-yang

Hi Qin,

Thank you for the review, please see inline.

From: Qin Wu <bill.wu@huawei.com<mailto:bill.wu@huawei.com>>
Date: Friday, February 23, 2018 at 1:58 AM
To: "rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>" <rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>>
Cc: Jeffrey Haas <jhaas@pfrc.org<mailto:jhaas@pfrc.org>>, "Reshad Rahman (rrahman)" <rrahman@cisco.com<mailto:rrahman@cisco.com>>
Subject: RE: WGLC on draft-ietf-bfd-yang

I have read v-(09) of draft-ietf-bfd-yang and have a few comments and suggestions:

1.  I think tree diagram defined in this draft should follow notation defined in draft-ietf-netmod-yang-tree-diagrams

Suggest to add a new section 1.1 as follows:

“

1.1 Tree Diagrams



Tree diagrams used in this document follow the notation defined in

[I-D.ietf-netmod-yang-tree-diagrams<https://tools.ietf.org/html/draft-ietf-lime-yang-connection-oriented-oam-model-06#ref-I-D.ietf-netmod-yang-tree-diagrams>].



”

<RR> Will do.

2.  In the abstract and introduction, please add text to clarify this draft is NMDA compliant.

You can follow NMDA compliant example defined in draft-ietf-lime-yang-connection-oriented-oam-model-06.

Introduction sections mention I-D.dsdt-nmda-guidelines, I believe I-D.dsdt-nmda-guidelines

 Has been merged into RFC6087bis, suggest to remove that paragraph.

<RR> Will do.

3.  Section 2.1 said:

“ The mechanism how the BFD sessions are created by the BFD

   clients is outside the scope of this document.  For BFD clients which

   create BFD sessions via their own configuration, authentication

   parameters (if required) are still specified in BFD.

”

Looks like these last two sentence contradict. Suggest to change as follows:

s/ are still specified in BFD/ are still specified in BFD model.

<RR> The BFD authentication parameters are actually in BFD, i.e. not in the BFD client.
4.I didn’t see any RPC operation defined in this model, looks like RPC operation is incomplete,
Suggest to remove all RPC related text if no RPC operation is defined.
<RR> Correct, no RPCs. Will remove all RPC related text.
5.Section 2 mentions:

“   BFD can operate in the following contexts:



   1.  Network devices as described in Network Device YANG

       Organizational Models [I-D.ietf-rtgwg-device-model]

”

It is not clear that [I-D.ietf-rtgwg-device-model] will be standardized since it provides static model structure to assemble

All the other YANG models. But we have schema mount, schema mount can help us to assemble YANG model in any mounting point.

I would suggest to remove bullet 1 mentioned above.

<RR> I can remove the reference, but the point is that the model can be used at the “top-level”, i.e. without being schema-mounted. I want to keep that piece of info here.
6. Section 2: suggest to replace RFC8022 with RFC8022bis since RFC8022bis will obsolete RFC8022.
<RR> Will do.
7. Section 2 said:

“ A new control-plane protocol "bfdv1" is defined and a "bfd" container

   is created under control-plane-protocol as specified in A YANG Data

   Model for Routing Management [RFC8022].  This new "bfd" node is

   augmented by all the YANG modules for their respective specific

   information.
”
Where "bfdv1" is defined, I think it is in the ietf-bfd-types module.
<RR> Correct.
Is "bfd" container same as "bfd" node? If yes, please make the term consistent.
<RR> Yes and will do.

In addition, it looks to me you first define ietf-bfd module which is the extension of ietf-routing defined in RFC8022bis.

And then all the other technology specific modules are extension of ietf-bfd module.

But this is not clear in the text, would it be great to list all the modules defined in this document? Clarify their dependency relationship.
<RR> Correct. Will add text to clarify. Note that this is what 2nd paragraph of section 2 is trying to convey.



8. The YANG Modules defined in this draft import from

> ietf-te

> ietf-inet-types

> ietf-interfaces

>ietf-routing

But some of them lack reference, some of reference are outdated.

See draft-ietf-netmod-rfc7277bis or draft-ietf-netmod-rfc8022bis for examples of how this might be

Handled

<RR> Will update the references (got this from YD review).



Regards,

Reshad.




-Qin
On Thu, Feb 08, 2018 at 03:02:52PM -0500, Jeffrey Haas wrote:



Reminder, WGLC ends tomorrow.

On Wed, Jan 24, 2018 at 01:22:07PM -0500, Jeffrey Haas wrote:



Working Group,

The authors of the BFD Yang module have declared their work on that document
complete.  Thus, working group last call is in progress for this document.
Please provide your hopefully final reviews on the text.

The last several revisions of the document have largely been done to resolve
lingering RFC 6087bis comments, and interwork/usability issues by the
importing protocol modules.

A parallel request for directorate review has been done with the routing and
security directorates along with the yang doctors.

The deadline for last call comments is February 9.

-- Jeff (for the chairs)