Subject: Re: [Netconf] Last Call: <draft-ietf-netconf-rfc7895bis-06.txt> (YANG Library) to Proposed Standard

From: "t.petch" <[email-masked]>
Date: Mon, 2 Jul 2018 11:32:12 +0100

One aspect of this leaves me puzzled; what is a module set?

Yes, I see that a data store schema is made up of module sets, which are
made up of modules, but given, say, 40 modules, what criteria decide
whether this is one set of 40, two of 20, half a dozen of varying size
or what?

Tom Petch

----- Original Message -----
From: "The IESG" <[email-masked]>
To: "IETF-Announce" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Thursday, June 14, 2018 5:22 PM

> The IESG has received a request from the Network Configuration WG
(netconf)
> to consider the following document: - 'YANG Library'
>   <draft-ietf-netconf-rfc7895bis-06.txt> as Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
final
> comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2018-06-28. Exceptionally, comments may
be
> sent to [email-masked] instead. In either case, please retain the
beginning of
> the Subject line to allow automated sorting.
>
> Abstract
>
>
>    This document describes a YANG library that provides information
>    about the YANG modules, datastores, and datastore schemas used by a
>    network management server.  Simple caching mechanisms are provided
to
>    allow clients to minimize retrieval of this information.  This
>    version of the YANG library supports the Network Management
Datastore
>    Architecture by listing all datastores supported by a network
>    management server and the schema that is used by each of these
>    datastores.
>
>    This document obsoletes RFC 7895.
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-netconf-rfc7895bis/
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-ietf-netconf-rfc7895bis/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
>
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 2 Jul 2018 12:48:09 +0200

> whether this is one set of 40, two of 20, half a dozen of varying size

Why does the size of the module set matter? Creating these module sets
is left to the implementations, some may want to go for big module
sets, other for more modular module sets (that may be easier to share
and combine). Some implementors may have 'packages' or 'bundles' of
modules that they may map to module sets. For the clients, it should
not matter how a server splits things into module sets.

/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: Robert Wilton <[email-masked]>
Date: Mon, 2 Jul 2018 11:51:06 +0100

Hi Tom,

It is entirely up to the server implementation to decide what modules 
should be put together into a single module set.

Some examples of categories that could be used to group different 
related modules together:

(i) Modules that are common across all datastores, vs modules that are 
only used for particular datastores (e.g. a dynamic datastore).

(ii) Modules for different versions of software could be reported as 
separate module sets.  Only the module set(s) associated with a 
particular software version would expect to be used.  This hypothetical 
example is from the YANG versioning work, and may or may not become a 
recommendation depending on how that work pans out ...

(iii) Sometimes vendors want to split their software up into separate 
packages, and module sets could be used to represent these different 
packages (e.g. core, vs L2VPN, vs L3VPN, vs Subscribers, etc).

(iv) Sometimes devices need to support different schemas at the same 
time (e.g. The IETF ecosystem, vs OpenConfig ecosystem, vs vendor native 
ecosystem).  Again, this is another case where module sets may be useful 
to differentiate between the different groups.

Of course, if a server is very simple, and none of the above applies, 
then it could choose to have just a single module set.

Does that help clarify their potential usage?

Thanks,
Rob

On 02/07/2018 11:32, t.petch wrote:
> .

---

From: "t.petch" <[email-masked]>
Date: Mon, 2 Jul 2018 15:58:45 +0100

----- Original Message -----
From: "Robert Wilton" <[email-masked]>
Sent: Monday, July 02, 2018 11:51 AM

> Does that help clarify their potential usage?

Robert, Juergen

Yes; in which case, I suggest adding a line to that effect.

NEW s.3 after "... (and their submodules) used only for imports."

The assignment of a module to a module-set is at the user's discretion.
YANG library attaches no semantics as to which module-set a module is
listed in.

Tom Petch

---

From: Robert Wilton <[email-masked]>
Date: Mon, 2 Jul 2018 16:10:23 +0100

> YANG library attaches no semantics as to which module-set a module is
I don't mind us adding this text, except that I would replace "user's" 
with "server's".

Juergen?

Thanks,
Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 2 Jul 2018 17:18:52 +0200

On Mon, Jul 02, 2018 at 04:10:23PM +0100, Robert Wilton wrote:
> I don't mind us adding this text, except that I would replace "user's" with
> "server's".

Yes, its at the server's discretion and I do not mind to spell this
out. But once we gain more experience and/or create additional
standards, we may in the future be more specific. Perhaps be specific
that at this point in time, this is entirely the server's choice?

  The assignment of a module to a module-set is at the server's discretion.
  This revision of the YANG library attaches no semantics as to which
  module-set a module is listed in.

/js

---

From: Robert Wilton <[email-masked]>
Date: Mon, 2 Jul 2018 16:31:57 +0100

On 02/07/2018 16:18, Juergen Schoenwaelder wrote:
> standards, we may in the future be more specific.
Agreed.

>   Perhaps be specific
Yes, I agree.

>    module-set a module is listed in.
Works for me.

Thanks,
Rob

---

From: "t.petch" <[email-masked]>
Date: Mon, 2 Jul 2018 16:57:20 +0100

----- Original Message -----
From: "Robert Wilton" <[email-masked]>
Sent: Monday, July 02, 2018 4:31 PM

> >    module-set a module is listed in.

And me too

Tom Petch

---

From: Robert Wilton <[email-masked]>
Date: Mon, 2 Jul 2018 17:07:45 +0100

>>>     module-set a module is listed in.
I've updated the github copy.

Tom, thanks for the review comment and suggestion.

Rob

---

From: Lou Berger <[email-masked]>
Date: Mon, 30 Jul 2018 13:01:15 -0400

Hi,

     I have a late comment on this document that I discovered while 
reviewing draft-ietf-netconf-nmda-netconf.  Sorry about the timing, but 
better to make the comment now rather then as an errata...

This document says:
    All NETCONF servers supporting YANG 1.1 [RFC7950] are required to
    support YANG Library (see Section 5.6.4 of RFC 7950).  NETCONF
    servers implementing the NETCONF extensions to support the NMDA
    [I-D.ietf-netconf-nmda-netconf] MUST implement at least the version
    of the YANG library defined in this document.  Similarly, all
    RESTCONF servers are required to support YANG Library (see Section 10
    of RFC 8040).  RESTCONF servers implementing the RESTCONF extensions
    to support the NMDA [I-D.ietf-netconf-nmda-restconf] MUST implement
    at least the version of the YANG library defined in this document.

I read this as an  update to RFC7950 and this should be noted in the 
document header, the abstract and Intro.

Lou

On 6/14/2018 12:22 PM, The IESG wrote:
> The IESG has received a request from the Network Configuration WG (netconf)
> The IESG plans to make a decision in the next few weeks, and solicits final
> [email-masked] mailing lists by 2018-06-28. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the beginning of
>     network management server.  Simple caching mechanisms are provided to
>     version of the YANG library supports the Network Management Datastore
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 30 Jul 2018 13:10:35 -0700

Hi Lou,

> On Jul 30, 2018, at 10:01 AM, Lou Berger <[email-masked]> wrote:
> 
> Hi,
> 
>     I have a late comment on this document that I discovered while reviewing draft-ietf-netconf-nmda-netconf.  Sorry about the timing, but better to make the comment now rather then as an errata...
> 
> This document says:
> I read this as an  update to RFC7950 and this should be noted in the document header, the abstract and Intro.

Your read of the update to RFC7950 is that it should now reference rfc7895bis in Section 5.6.4. Is that correct? How is that different from 7895bis obsoleting 7895, and thus all references to 7895 should now be to 7895bis?

>> No IPR declarations have been submitted directly on this I-D.

Mahesh Jethanandani
[email-masked]

---

From: Lou Berger <[email-masked]>
Date: Mon, 30 Jul 2018 16:19:41 -0400

Hi,

> Your read of the update to RFC7950 is that it should now reference rfc7895bis in Section 5.6.4. Is that correct? How is that different from 7895bis obsoleting 7895, and thus all references to 7895…
All this means is that  draft-ietf-netconf-rfc7895bis should note it 
updates RFC 7950 in the header and abstract...

Lou