Subject: [Netconf] Review comments on draft-ietf-netconf-yang-library-03

From: Robert Wilton <[email-masked]>
Date: Wed, 20 Jan 2016 17:32:12 +0000

Hi,

Generally I found this document pretty easy to read, and hence only have 
a few minor comments/questions:

Section 2.1.2 ....
- It was unclear to me what multi-protocol conflicts might arise on a 
managed device.  Are these genuine conflicts, or is it just that some 
YANG modules are only relevant/specific to particular YANG management 
access protocols?

Section 2.2: identity yang-protocol ...
- What is the plan going forward to update these identities?  Is the 
expectation that a new version of the Yang Library Module, and hence a 
new version of this draft be published whenever a new version of 
NETCONF/RESTCONF is published?

Section 2.2 grouping common-leafs ...
  - Perhaps a more specific name would help here, or should it be 
common-leaves instead of common-leafs?
  - I appreciate that they are only used as list keys, but would it be 
more clear to the reader if the name and revision leaves were marked as 
mandatory?

Section 2.2 list deviation ...
  - It wasn't clear to me exactly what was meant by "If the deviation 
module is available for download".  Further, if the deviation module 
isn't available for download then would it help to have "uses 
schema-leaf" here so that it could potentially reference the deviation?

Section 2.2 restricted-protocol ....
  - I guess not understanding the exact requirement for 
restricted-protocols I was wondering whether it wouldn't be better if 
this list was written with the reverse sense?  I.e. list the protocols 
that are supported rather than the ones that are not.

Section 4: Security Considerations ....
  - This seems to only consider NETCONF.  On the presumption that YANG 
library is useful for RESTCONF as well then does this section need to be 
updated to also cover RESTCONF?

Appendix B.  Open Issues ...
  - The URL lists 3 open issues.  Should those issues now be 
closed/resolved and this text removed?

Thanks,
Rob

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 21 Jan 2016 12:28:33 +0100 (CET)

Hi Robert,

Thank you for your review!  Comments inline.

Robert Wilton <[email-masked]> wrote:
> Hi,
> 
> Generally I found this document pretty easy to read, and hence only
> have a few minor comments/questions:
> 
> Section 2.1.2 ....
> - It was unclear to me what multi-protocol conflicts might arise on
> a managed device.  Are these genuine conflicts, or is it just that
> some YANG modules are only relevant/specific to particular YANG
> management access protocols? 

Since we agreed to remove all protocol-specifics, this section has
been removed.

> expectation that a new version of the Yang Library Module, and hence
> a new version of this draft be published whenever a new version of

See above - these identities are removed.

> common-leaves instead of common-leafs? 

It think the name is ok; note that it is a locally scoped grouping,
which cannot be used outside of "module-list" grouping.

>  - I appreciate that they are only used as list keys, but would it
> be more clear to the reader if the name and revision leaves were
> marked as mandatory?

Since the grouping can only be used internally in this module, I don't
think it is necessary.

> schema-leaf" here so that it could potentially reference the

Actually, I think this statement is not correct.  I think the
deviation module MUST be present in the "module" list:

OLD:

           If the deviation module is available for download
           from the server then a 'module' entry for that module
           will exist, with the same name and revision values.
           The 'conformance' value will be 'implement' for
           the deviation module.";

NEW:

           The deviation module MUST be present in the 'module'
           list, with the same name and revision values.
           The 'conformance' value will be 'implement' for
           the deviation module.";

> restricted-protocols I was wondering whether it wouldn't be better
> if this list was written with the reverse sense?  I.e. list the
> protocols that are supported rather than the ones that are not.

This leaf is also removed.

>  - This seems to only consider NETCONF.  On the presumption that
> YANG library is useful for RESTCONF as well then does this section
> need to be updated to also cover RESTCONF?

This was also noted by Bert.  I think we need to update the Security
Considerations template to also take RESTCONF into account.

> closed/resolved and this text removed?

I have closed the issues now.

/martin

---

From: Robert Wilton <[email-masked]>
Date: Thu, 21 Jan 2016 14:16:38 +0000

Hi Martin,

>             The 'conformance' value will be 'implement' for
Yes, with that change it makes sense.

I'm also happy with all your other responses.

Thanks,
Rob

---

From: Andy Bierman <[email-masked]>
Date: Thu, 21 Jan 2016 08:32:50 -0800

> Since we agreed to remove all protocol-specifics, this section has

When did the WG agree to this and what are the details?

> I have closed the issues now.

Andy

>
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 21 Jan 2016 21:07:07 +0100 (CET)

> When did the WG agree to this and what are the details?

See the mail thread starting at
https://mailarchive.ietf.org/arch/msg/netconf/H6IW7pHJ3dJ_y0uvkhIb9BQ5t5A

/martin