RE: WGLC on draft-ietf-bfd-yang

[Qin Wu <[e-mail]>]

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



”

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.

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.
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.
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.
6. Section 2: suggest to replace RFC8022 with RFC8022bis since RFC8022bis will obsolete RFC8022.
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.
Is "bfd" container same as "bfd" node? If yes, please make the term consistent.

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.



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




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