Subject: [netmod] LC on YANG Library (bis)

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 1 Feb 2018 10:59:47 -0800

WG,

The authors of rfc7895bis have indicated that they believe the document is ready for LC[1].

This starts a two week LC on the draft <https://tools.ietf.org/html/draft-ietf-netconf-rfc7895bis-04>. The LC will end on February 15. 

Please send your comments on this thread. Reviews of the document, and statement of support are particularly helpful to the authors. If you have concerns about the document, please state those too.

Authors please indicate if you are aware of any IPR on the document.

Thanks.

[1] https://www.ietf.org/mail-archive/web/netconf/current/msg13980.html <https://www.ietf.org/mail-archive/web/netconf/current/msg13980.html>

Mahesh & Kent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 1 Feb 2018 20:42:31 +0100

> Authors please indicate if you are aware of any IPR on the document.

I am not.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 01 Feb 2018 20:56:10 +0100 (CET)

Mahesh Jethanandani <[email-masked]> wrote:
> This starts a two week LC on the draft
> <https://tools.ietf.org/html/draft-ietf-netconf-rfc7895bis-04>. The LC
> will end on February 15.
> 
> Please send your comments on this thread. Reviews of the document, and
> statement of support are particularly helpful to the authors. If you
> have concerns about the document, please state those too.
> 

I am not aware of any IPR related to this document.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 1 Feb 2018 12:18:19 -0800

On Thu, Feb 1, 2018 at 10:59 AM, Mahesh Jethanandani <
[email-masked]> wrote:

> statement of support are particularly helpful to the authors. If you have
> concerns about the document, please state those too.
>

> Thanks.
>
> [1] https://www.ietf.org/mail-archive/web/netconf/current/msg13980.html
>
> Mahesh & Kent
>
>

Andy

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

---

From: Robert Wilton <[email-masked]>
Date: Fri, 2 Feb 2018 09:30:11 +0000

Thanks,
Rob

---

From: Kent Watsen <[email-masked]>
Date: Fri, 2 Feb 2018 13:51:18 +0000

As co-author, I am not aware of any IPR related to this document.

As a contributor, I have read this document and think that it is ready for advancement.

Kent

On 2/2/18, 4:30 AM, "Netconf on behalf of Robert Wilton" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Thanks,
Rob

This starts a two week LC on the draft<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dnetconf-2Drfc7895bis-2D04&d=DwMD-g&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=fi_opjj4kio7eufRXSQSi8dSjJNlkVDo8a1F0zsCrfE&s=MqbVljnYqIk9w78kcfp7oUqGR-qVoNV90njyTwLAdpc&e=>. The LC will end on February 15.

Thanks.

[1] https://www.ietf.org/mail-archive/web/netconf/current/msg13980.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_netconf_current_msg13980.html&d=DwMD-g&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=fi_opjj4kio7eufRXSQSi8dSjJNlkVDo8a1F0zsCrfE&s=XhRSSTWifO-SkPi2CWK5Z5aUni2F1qRQ8Moj7T7gI-Y&e=>

Mahesh & Kent

Netconf mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/netconf<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwMD-g&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=fi_opjj4kio7eufRXSQSi8dSjJNlkVDo8a1F0zsCrfE&s=mcDF-v5I4epgsuWLHvr32pZ5mRonROKN8zpKcZWBC0o&e=>

---

From: Alexander Clemm <[email-masked]>
Date: Tue, 13 Feb 2018 19:38:31 +0000

Hi,

I have taken a look at this document.

My main comment is that one aspect that is missing, that I believe should be added, concerns the inclusion of certain metadata about the modules.  Specifically, in the context of YANG-Push we had a discussion about being able to mark nodes that are notifiable on change.  This is just one particular use case of a more general issue; in YANG-Push after much debate the conclusion was for now to simply make implementors aware of this issue and advise that a solution to this must be provided, with the clear understanding that eventually a standard solution should be defined.

Since the goal of YANG-Library is to allow clients to find out what is actually supported on a given server, this is the right place to keep this information.  One possible way to address this would be, for a given module, to maintain a list of "meta-info", with a key "meta-tag", and a list with references to the nodes to which the metadata applies.  In the case of notifiable-on-change, you would have a list with one entry "notifiable-on-change", and then the list with the node definitions to which this tag applies.

Editorial nit:
2nd paragraph Introduction: informaton --> information

Thanks
--- Alex

From: Netconf [mailto:[email-masked]] On Behalf Of Mahesh Jethanandani
Sent: Thursday, February 01, 2018 11:00 AM
To: NETCONF WG <[email-masked]>
Cc: NETMOD WG <[email-masked]>
Subject: [Netconf] LC on YANG Library (bis)

WG,

This starts a two week LC on the draft<https://tools.ietf.org/html/draft-ietf-netconf-rfc7895bis-04>. The LC will end on February 15.

Thanks.

Mahesh & Kent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 13 Feb 2018 20:48:21 +0100

Alexander,

I disagree. This YANG Library is mandatory for all implementations;
what you talk about seems to concern only implementations that support
YANG push. Hence, this is an extension that should go in its own
module.

/js

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

---

From: Alexander Clemm <[email-masked]>
Date: Tue, 13 Feb 2018 19:58:37 +0000

Well, we need a general solution for that.  YANG-push is just one use case.  There are other cases where there will be "metadata" (that does not pertain to instance data)  and capabilities that clients want to discover.  YANG library (in itself providing "metadata" about what a server supports and is capable of) is an excellent place to maintain this information.  It also provides the opportunity to be systemic about it, as opposed to requiring everyone to define their own little custom extensions.  
--- Alex

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:[email-masked]]
> Sent: Tuesday, February 13, 2018 11:48 AM
> To: Alexander Clemm <[email-masked]>
> Cc: Mahesh Jethanandani <[email-masked]>; NETCONF WG
> <[email-masked]>; NETMOD WG <[email-masked]>
> Subject: Re: [netmod] [Netconf] LC on YANG Library (bis)
> 
> Alexander,
> 
> I disagree. This YANG Library is mandatory for all implementations; what you talk
> about seems to concern only implementations that support YANG push. Hence,
> this is an extension that should go in its own module.
> 
> /js
> 
> > My main comment is that one aspect that is missing, that I believe should be
> added, concerns the inclusion of certain metadata about the modules.
> Specifically, in the context of YANG-Push we had a discussion about being able to
> mark nodes that are notifiable on change.  This is just one particular use case of a
> more general issue; in YANG-Push after much debate the conclusion was for now
> to simply make implementors aware of this issue and advise that a solution to
> this must be provided, with the clear understanding that eventually a standard
> solution should be defined.
> >
> > Since the goal of YANG-Library is to allow clients to find out what is actually
> supported on a given server, this is the right place to keep this information.  One
> possible way to address this would be, for a given module, to maintain a list of
> "meta-info", with a key "meta-tag", and a list with references to the nodes to
> which the metadata applies.  In the case of notifiable-on-change, you would have
> a list with one entry "notifiable-on-change", and then the list with the node
> definitions to which this tag applies.
> >
> > Editorial nit:
> > This starts a two week LC on the draft<https://tools.ietf.org/html/draft-ietf-
> netconf-rfc7895bis-04>. The LC will end on February 15.
> >
> statement of support are particularly helpful to the authors. If you have concerns
> about the document, please state those too.
> >
> > [1]
> > https://www.ietf.org/mail-archive/web/netconf/current/msg13980.html
> >
> > Mahesh & Kent
> >
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 13 Feb 2018 21:28:58 +0100

I must have missed your actionable proposal that is relevant for _all_
NETCONF and RESTCONF implementations.

YANG data models are extensible so lets use that.

/js

---

From: Alexander Clemm <[email-masked]>
Date: Tue, 13 Feb 2018 21:25:46 +0000

My proposal is to add this to the YANG data model.  I think this logically belongs to YANG library which is why I would like to see it there.  I also think it will be useful to many implementations.  All, probably not, but they have also survived without YANG library for a while:-) Of course, it is always possible to write another draft or do a bisbis.  
Cheers
--- Alex

> Sent: Tuesday, February 13, 2018 12:29 PM
> I must have missed your actionable proposal that is relevant for _all_ NETCONF
> and RESTCONF implementations.
> 
> > Well, we need a general solution for that.  YANG-push is just one use case.
> There are other cases where there will be "metadata" (that does not pertain to
> instance data)  and capabilities that clients want to discover.  YANG library (in
> itself providing "metadata" about what a server supports and is capable of) is an
> excellent place to maintain this information.  It also provides the opportunity to
> be systemic about it, as opposed to requiring everyone to define their own little
> custom extensions.
> > --- Alex
> >
> > > From: Juergen Schoenwaelder
> > > [mailto:[email-masked]]
> > > what you talk about seems to concern only implementations that
> > > support YANG push. Hence, this is an extension that should go in its own
> module.
> > >
> > > /js
> > >
> > > Specifically, in the context of YANG-Push we had a discussion about
> > > being able to mark nodes that are notifiable on change.  This is
> > > just one particular use case of a more general issue; in YANG-Push
> > > after much debate the conclusion was for now to simply make
> > > implementors aware of this issue and advise that a solution to this
> > > must be provided, with the clear understanding that eventually a standard
> > > supported on a given server, this is the right place to keep this
> > > information.  One possible way to address this would be, for a given
> > > module, to maintain a list of "meta-info", with a key "meta-tag",
> > > and a list with references to the nodes to which the metadata
> > > applies.  In the case of notifiable-on-change, you would have a list
> > > with one entry "notifiable-on-change", and then the list with the node
> > > > The authors of rfc7895bis have indicated that they believe the
> > > > document is
> > > ready for LC[1].
> > > >
> > > > This starts a two week LC on the
> > > > draft<https://tools.ietf.org/html/draft-ietf-

---

From: Andy Bierman <[email-masked]>
Date: Tue, 13 Feb 2018 13:42:36 -0800

On Tue, Feb 13, 2018 at 1:25 PM, Alexander Clemm <[email-masked]
> wrote:

> My proposal is to add this to the YANG data model.  I think this logically
> belongs to YANG library which is why I would like to see it there.  I also
> think it will be useful to many implementations.  All, probably not, but
> they have also survived without YANG library for a while:-) Of course, it
> is always possible to write another draft or do a bisbis.
>

Or the IETF can learn about the augment-stmt and create additional objects
without
constantly rewriting the base modules.

Cheers

Andy

---

From: Robert Wilton <[email-masked]>
Date: Wed, 14 Feb 2018 10:10:43 +0000

Hi Alex,

I see no real advantages to putting this directly in YANG library bis, 
but I think that augmenting the YANG library bis structure is just fine 
(in the same way that the latest version of schema mount has proposed to 
do).

Generally, I think that it is good that NETCONF/YANG is built up of 
fairly loosely coupled components.  E.g. implementations can choose 
which subset of features are required for their particular circumstances 
(e.g. protocol, encoding, schema mount, YANG push, with-defaults, etc).  
If over time it becomes clear that it is critical for good interop that 
particular features must always be supported then we can define NETCONF 
2.0 or 3.0 that mandates that a particular set of technologies must be 
implemented to meet the standard.

The added bonus of having these components loosely coupled is that they 
can be improved and refined independently, potentially allowing IETF to 
move a bit quicker advancing the technologies.

Finally, even if there is common meta-data structure that is shared by 
multiple features, that still doesn't mean that it has to go in the base 
YANG library spec, that can still just be shared common extension.

Thanks,
Rob

On 13/02/2018 21:25, Alexander Clemm wrote:
> .

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 14 Feb 2018 14:07:19 +0100

> YANG library spec, that can still just be shared common extension.

+1

Lada

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: Kent Watsen <[email-masked]>
Date: Thu, 15 Feb 2018 15:51:17 +0000

Alex,

What you want makes sense to me.  How about putting it into an I-D that augments the yang library bis?  It doesn't have to be in this document, right?

Kent

===== original message =====

> > This starts a two week LC on the draft<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2D&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=oALb7LKrUkKDsJ06VIM3Anx_iD05BkmxjaM0TZF1heA&s=NaY8R9DBhInZQAxL35_KjFzeYHfyTOVJLnMHAKGeKF0&e=
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_netconf_current_msg13980.html&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=oALb7LKrUkKDsJ06VIM3Anx_iD05BkmxjaM0TZF1heA&s=Qm6U9CIpDHS0jqUnGGZl8X05qeA_VvMyyuOtwDHBf1M&e=
> >
> > Mahesh & Kent
> >
> 
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=oALb7LKrUkKDsJ06VIM3Anx_iD05BkmxjaM0TZF1heA&s=GPdqlio_2laQl93jobGXgXOs-WpouxE1W4MeGxvh558&e=
> 
> 
> --
> Fax:   +49 421 200 3103         <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.jacobs-2Duniversity.de_&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=oALb7LKrUkKDsJ06VIM3Anx_iD05BkmxjaM0TZF1heA&s=z9V8kyto9EgyGp3JswA2QbJBSQd3eczfciztcC1gNt4&e=>

_______________________________________________
Netconf mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=oALb7LKrUkKDsJ06VIM3Anx_iD05BkmxjaM0TZF1heA&s=j9edlpIGbuEeS7yMrV4iRWY7vvq0c2FqIemuHf17LLU&e=

---

From: Robert Wilton <[email-masked]>
Date: Thu, 15 Feb 2018 17:03:32 +0000

I should add, as a contributor, I have read this document and think that 
is ready for advancement.

I have three minor comments:

1) module "feature" in YANG library is a leaf-list, but currently it is 
a list in YANG libary bis. I suspect that this is due to one of the 
incarnations when it contained additional information.  I think that we 
should revert it back to being a leaf list for consistency.

2) Lada recommended that module "deviation" be made a leaf-list. I also 
support changing this for consistency with "feature" above, but don't 
feel too strongly on this one.

3) I think the "modules" list is also allowed to included modules that 
don't actually contain any nodes that require implementation.  Hence, it 
might be useful of the "modules" description statement explicitly stated 
this.  I.e. perhaps something like:

"This list may contain modules that do not contain any schema nodes that 
require implementation.  For example, it could contain a module that 
only defines types and not any data nodes, RPCs, actions, notifications, 
or deviations."

Thanks,
Rob

On 02/02/2018 13:51, Kent Watsen wrote:
> On 2/2/18, 4:30 AM, "Netconf on behalf of Robert Wilton" 
> <[email-masked] <mailto:[email-masked]> on behalf 
> of [email-masked] <mailto:[email-masked]>> wrote:
>
>     document is ready for LC[1].
>
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dnetconf-2Drfc7895bis-2D04&d=DwMD-g&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=fi_opjj4kio7eufRXSQSi8dSjJNlkVDo8a1F0zsCrfE&s=MqbVljnYqIk9w78kcfp7oUqGR-qVoNV90njyTwLAdpc&e=>.
>     The LC will end on February 15.
>
>     Please send your comments on this thread. Reviews of the document,
>     and statement of support are particularly helpful to the authors.
>     If you have concerns about the document, please state those too.
>
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_netconf_current_msg13980.html&d=DwMD-g&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=fi_opjj4kio7eufRXSQSi8dSjJNlkVDo8a1F0zsCrfE&s=XhRSSTWifO-SkPi2CWK5Z5aUni2F1qRQ8Moj7T7gI-Y&e=>
>
>     Mahesh & Kent
>
>
>
>
>     [email-masked] <mailto:[email-masked]>
>
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwMD-g&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=fi_opjj4kio7eufRXSQSi8dSjJNlkVDo8a1F0zsCrfE&s=mcDF-v5I4epgsuWLHvr32pZ5mRonROKN8zpKcZWBC0o&e=>
>
>
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 15 Feb 2018 19:09:55 +0100

On Thu, Feb 15, 2018 at 05:03:32PM +0000, Robert Wilton wrote:
> 
> 1) module "feature" in YANG library is a leaf-list, but currently it is a
> list in YANG libary bis. I suspect that this is due to one of the
> support changing this for consistency with "feature" above, but don't feel
> too strongly on this one.
>

I suggest we either make both leaf-lists or keep both as lists. I am
fine with making both lead-lists.

/js

---

From: Andy Bierman <[email-masked]>
Date: Thu, 15 Feb 2018 11:03:02 -0800

> fine with making both lead-lists.

The reason the deviation is a list is because it has a name and revision.
Or it did until it was removed.

I prefer to keep the contents of the "module" list the
same as RFC 7895.  The "improvement" is much worse --
harder to use by clients and provides less information to clients.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 15 Feb 2018 21:12:15 +0100

> harder to use by clients and provides less information to clients.

Which "improvement" do you mean? Which information is lost? In which
situations are things harder to use?

/js

---

From: Andy Bierman <[email-masked]>
Date: Thu, 15 Feb 2018 12:50:34 -0800

> situations are things harder to use?

The supposed improvement is the /yang-library subtree.

It is now much harder to determine the modules used by the server
because there are 3 data structures to retrieve and process instead of 1.

The module list used to have a deviation list so revisions could be
identified

    list deviation {
           key "name revision";
           description
             "List of YANG deviation module names and revisions
              used by this server to modify the conformance of
              the module associated with this entry.  Note that
              the same module can be used for deviations for
              multiple modules, so the same entry MAY appear
              within multiple 'module' entries.

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

         }

Andy

---

From: Alexander Clemm <[email-masked]>
Date: Fri, 16 Feb 2018 01:27:06 +0000

Hi Kent,

yes, it wouldn't have to be in this document.  But I do think a solution for this is clearly needed, and YANG library (or augmentation to it) is the best way to put it.  

I wasn't planning to put out an I-D on this myself, but can put it on my to-do list (and will be happy to contribute if someone wants to take the lead).  

--- Alex

> From: Kent Watsen [mailto:[email-masked]]
> Sent: Thursday, February 15, 2018 7:51 AM
> To: Alexander Clemm <[email-masked]>; Juergen
> Schoenwaelder <[email-masked]>
> Cc: NETCONF WG <[email-masked]>; NETMOD WG <[email-masked]>
> Subject: Re: [Netconf] [netmod] LC on YANG Library (bis)
> 
> Alex,
> 
> What you want makes sense to me.  How about putting it into an I-D that
> augments the yang library bis?  It doesn't have to be in this document, right?
> 
> Kent
> 
> Well, we need a general solution for that.  YANG-push is just one use case.  There
> are other cases where there will be "metadata" (that does not pertain to instance
> data)  and capabilities that clients want to discover.  YANG library (in itself
> providing "metadata" about what a server supports and is capable of) is an
> > YANG push. Hence, this is an extension that should go in its own module.
> >
> > /js
> >
> > being able to mark nodes that are notifiable on change.  This is just
> > one particular use case of a more general issue; in YANG-Push after
> > much debate the conclusion was for now to simply make implementors
> > aware of this issue and advise that a solution to this must be
> > provided, with the clear understanding that eventually a standard solution
> should be defined.
> > >
> > module, to maintain a list of "meta-info", with a key "meta-tag", and
> > a list with references to the nodes to which the metadata applies.  In
> > the case of notifiable-on-change, you would have a list with one entry
> > "notifiable-on-change", and then the list with the node definitions to which this
> tag applies.
> > >
> > > Editorial nit:
> > > draft<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.iet
> > > f.org_html_draft-2Dietf-
> 2D&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-nd
> > >
> b3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=oAL
> b7L
> > >
> KrUkKDsJ06VIM3Anx_iD05BkmxjaM0TZF1heA&s=NaY8R9DBhInZQAxL35_KjFze
> YHfy
> > > TOVJLnMHAKGeKF0&e=
> > > and
> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_ma
> > > il-
> 2Darchive_web_netconf_current_msg13980.html&d=DwICAg&c=HAkYuh63rs
> > > uhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGT
> > >
> vjISlaJdcZo&m=oALb7LKrUkKDsJ06VIM3Anx_iD05BkmxjaM0TZF1heA&s=Qm6
> U9CIp
> > > DHS0jqUnGGZl8X05qeA_VvMyyuOtwDHBf1M&e=
> > >
> > > Mahesh & Kent
> > >
> >
> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_ma
> > > ilman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voD
> > >
> TXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=oALb7LKr
> UkK
> > > DsJ06VIM3Anx_iD05BkmxjaM0TZF1heA&s=GPdqlio_2laQl93jobGXgXOs-
> WpouxE1W
> > > 4MeGxvh558&e=
> >
> >
> > --
> > Fax:   +49 421 200 3103
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.jacobs-
> 2Duniversity.de_&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=o
> ALb7LKrUkKDsJ06VIM3Anx_iD05BkmxjaM0TZF1heA&s=z9V8kyto9EgyGp3JswA
> 2QbJBSQd3eczfciztcC1gNt4&e=>
> 
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_netconf&d=DwICAg&c=HAkYuh63rsuhr6S
> cbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=o
> ALb7LKrUkKDsJ06VIM3Anx_iD05BkmxjaM0TZF1heA&s=j9edlpIGbuEeS7yMrV4i
> RWY7vvq0c2FqIemuHf17LLU&e=
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 16 Feb 2018 10:06:54 +0100

> feel too strongly on this one.

I agree to have both as leaf-lists.

> only defines types and not any data nodes, RPCs, actions, notifications, 

Hmm, such modules belong to the other list "import-only-modules", don't
they?

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 16 Feb 2018 10:18:42 +0100

> harder to use by clients and provides less information to clients.

So we currently have:

1. "deviation": [
     {
       "module": "foo-devs"
     },
     {
       "module": "bar-devs"
     }
   ]

and the proposal is to have instead

2. "deviation-module": [
     "foo-devs",
     "bar-dev"
   ]

I fail to see why #2 is harder to use for clients, I would say it is the
opposite. Also, #2 doesn't provide less information than RFC 7895 - the
revision parameter is readily available in the "module" list.

I also expect that this data will be used not only in machine-to-machine
communication but could also be perused by humans - see
e.g. draft-lengyel-netmod-yang-instance-data. For this purpose, #2 is a
clear winer.

Lada

---

From: Robert Wilton <[email-masked]>
Date: Fri, 16 Feb 2018 11:20:41 +0000

Hi Lada,

> Hmm, such modules belong to the other list "import-only-modules", don't
So my reasoning is that either is valid.

I.e. a module being listed under "modules" means that it implements all 
data nodes, RPCs, actions, notifications, deviations, etc.  If a module 
doesn't contain any data nodes, RPCs, actions, notifications, 
deviations, etc then it is trivially implemented :-)

As an aside, RFC 7950 states in 5.6.5:

  A server implements a module if it implements the module's data
    nodes, RPCs, actions, notifications, and deviations.

I wonder whether identities shouldn't also be on this list, since 
section 9.10.2 states:

On a particular server, the valid values are further restricted
to the set of identities defined in the modules implemented by the server.

Thanks,
Rob

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 16 Feb 2018 16:33:52 +0100

> deviations, etc then it is trivially implemented :-)

OK, so if a module contains only groupings and typedefs, it can appear
either in "modules" or in "import-only-modules", and the effect is the
same, right?

This sounds reasonable.

> I wonder whether identities shouldn't also be on this list, since 

Yes, and extensions as well.

Lada

---

From: Robert Wilton <[email-masked]>
Date: Fri, 16 Feb 2018 16:04:08 +0000

> either in "modules" or in "import-only-modules", and the effect is the
Yes.

Thanks,
Rob

---

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 26 Feb 2018 15:50:05 -0800

This officially closes the LC on YANG Library bis draft. I know that separately there has been a YANG Doctors review of this draft.

Authors, please post an updated draft addressing the comments received during LC and other reviews on the document. I will then do a shepherd’s writeup and send it for publication.

Thanks.

Mahesh //as shepherd

> On Feb 16, 2018, at 8:04 AM, Robert Wilton <[email-masked]> wrote:
> 
> 
>