Hi Qin,

Thank you for the review, please see inline.

From: Qin Wu <bill...@huawei.com>
Date: Friday, February 23, 2018 at 1:58 AM
To: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Cc: Jeffrey Haas <jh...@pfrc.org>, "Reshad Rahman (rrahman)" <rrah...@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 

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



<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 

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

 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 
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

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 

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


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


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



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)

Reply via email to