Subject: [netmod] *one* week 2nd WG Last Call: draft-ietf-netmod-revised-datastores-07

From: Lou Berger <[email-masked]>
Date: Mon, 4 Dec 2017 09:35:13 -0500

All,

This starts a second working group last call on
draft-ietf-netmod-revised-datastores.

As this is a 2nd LC that is focused on changes since the last LC, it closes in *one* week. The working group last call ends on December 11. Please send your comments to the netmod mailing list.

At this point, we're most interested in verifying that previous comments are addressed since the last call on the -04 rev of the draft was held.

A summary of changes can be found at 
https://mailarchive.ietf.org/arch/msg/netmod/DWtD12bGkBZabEygRfiwZfcnUU4

A diff can be found at 
https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url1=draft-ietf-netmod-revised-datastores-04.txt&url2=draft-ietf-netmod-revised-datastores-07.txt

Comments along the of: I have reviewed this version of the document and it addresses my previous comments would be particularly helpful.

Thank you,
Netmod Chairs

---

From: Andy Bierman <[email-masked]>
Date: Fri, 8 Dec 2017 12:35:50 -0800

Hi,

I have reviewed draft-07 and my previous comments about NMDA have been
addressed.

This might be the most important sentence in the draft:

sec. 5.3

   The datastore schema for <operational> MUST be a superset of the
   combined datastore schema used in all configuration datastores except
   that YANG nodes supported in a configuration datastore MAY be omitted
   from <operational> if a server is not able to accurately report them.

The MUST implies that there is no need to design a YANG library that can
support
an implementation that violates this MUST (i.e., 1 schema tree for the
super-set)

The MAY is troublesome because it completely contradicts the conformance
expressed
in each YANG module supported by the server.  Any data node without any
if-feature-stmts is mandatory to implement.

What about config=false subtrees within a config=true subtree?
Can they be omitted from <operational> as well, or does the draft just
intend to
omit the operational value of config=true nodes?  Should be specific.

Perhaps this draft does not need the MAY half of the sentence at all.
The YANG library can specify that it is for conformance-reporting, not
conformance-defining.

Andy

On Mon, Dec 4, 2017 at 6:35 AM, Lou Berger <[email-masked]> wrote:

> As this is a 2nd LC that is focused on changes since the last LC, it
> closes in *one* week. The working group last call ends on December 11.
> Please send your comments to the netmod mailing list.
>
> At this point, we're most interested in verifying that previous comments
> are addressed since the last call on the -04 rev of the draft was held.
>
> https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url1=draft-ietf-netmod-
> revised-datastores-04.txt&url2=draft-ietf-netmod-revised-datastores-07.txt
>
> Comments along the of: I have reviewed this version of the document and it
> addresses my previous comments would be particularly helpful.
>
> Thank you,
> Netmod Chairs
>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Lou Berger <[email-masked]>
Date: Tue, 12 Dec 2017 10:41:59 -0500

Hi,
	These comments are based on my Shepherd review of this document and
should be addressed as part of addressing any LC comments:

1) Considering the recent discussion on Library made me consider the
general case of a module that is composed entirely of operational state.
 I think this case is subject to interpretation and therefore needs to
be explicitly covered.  For example section 5.3 states:

This could be read that a module that an operational state MUST be
present (but presumably empty>?) in some other DS to be present in
operational.  I don't believe this is your intent, but it should be
explicitly covered for the benefit of future readers.  I suspect that
this also should translate to an explicit case in section 6.1 as well.

2) The abstract needs to mention that it updates RFC7950 (per idnits)

3) A minor point, the document uses the terms boot and reboot.  I
suspect that these terms are intended to cover any full or partial,
e.g., protocol, restart operation supported on a system - which may not
include a full boot.  I think the document needs to be clear on this
point.  Perhaps just add a definition, or note that full and partial
restart operations are included when the document refers to boot and reboot.

Thank you,
Lou
(As Shepherd)

---

From: Lou Berger <[email-masked]>
Date: Tue, 12 Dec 2017 10:45:25 -0500

All,

This LC is closed.

Authors,
	Please address any/all comments received during the LC.  Once you've
published the version that you believe addresses all comments/pending
changes, please summarize the changes on the list and let us all know
that you believe that the version is ready to submit to the IESG for
publication.

Thank you,
Lou

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 19 Dec 2017 21:25:14 +0100 (CET)

Hi Andy,

> if-feature-stmts is mandatory to implement.

This is required for transition purposes; a server that wants to
implement <operational> should not have to implement all modules at
once (as applied config).

> omit the operational value of config=true nodes?  Should be specific.

The text says "nodes supported in a configuration datastore MAY be
omitted from <operational>".  So it is implicit that it only applies
to config true nodes (since config false cannot be supported in a
config ds).  How about:

OLD:

NEW:

    The datastore schema for <operational> MUST be a superset of the
    combined datastore schema used in all configuration datastores
    except that YANG "config true" nodes supported in a configuration
    datastore MAY be omitted from <operational> if a server is not
    able to accurately report them.

> The YANG library can specify that it is for conformance-reporting, not

I think we should keep the MAY, since the YANG library has to be
designed to support this case.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 19 Dec 2017 21:31:01 +0100 (CET)

Hi Lou,

Lou Berger <[email-masked]> wrote:
> explicitly covered for the benefit of future readers.

Ok.  How about we add to the paragraph above a sentence:

    If a module does not contain any configuration data then it MAY be
    omitted from the schema for the configuration datastores.

> I suspect that

I don't understand why that would be neeed.

> 2) The abstract needs to mention that it updates RFC7950 (per idnits)

Ok.

> restart operations are included when the document refers to boot and reboot.

RFC 6241 uses the same terms, so using them is at least consistent
with that document.  I'm not sure I think they need to be defined in
this document.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Tue, 19 Dec 2017 12:41:28 -0800

>     omitted from the schema for the configuration datastores.

I liked the old YANG library better.
It allows a client to create of a list of all the
modules/revisions/features/deviations
that will be needed to match the schema tree used by the server.
The compiler does not care if it is looking for a typedef vs. a data node.
The YANG library details help the compiler find the correct definitions.

Consider iana-crypt-hash that has only typedefs and features.
Leaving this module out of the library can cause problems for a client.

Andy

> > > At this point, we're most interested in verifying that previous
> comments are addressed since the last call on the -04 rev of the draft was
> held.
> > >
> > > https://tools.ietf.org/rfcdiff?difftype=--hwdiff&
> url1=draft-ietf-netmod-revised-datastores-04.txt&url2=draft-ietf-netmod-
> revised-datastores-07.txt
> > >
> > > Comments along the of: I have reviewed this version of the document
> and it addresses my previous comments would be particularly helpful.
> > >
> > > Thank you,
> > > Netmod Chairs
> > >

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 19 Dec 2017 21:54:22 +0100

> Leaving this module out of the library can cause problems for a client.

I think this is not the intention. If a module is needed to satisfy
imports, it has to be listed as part of the schema. So perhaps this is
better?

    If a module does not contain any configuration data and it is not
    needed to satisfy any imports, then it MAY be omitted from the
    schema for the configuration datastores.

/js

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

---

From: Robert Wilton <[email-masked]>
Date: Wed, 20 Dec 2017 08:28:41 +0000

>      schema for the configuration datastores.
One minor tweak, I think that "configuration" would be better than 
"configuration data" for consistency reasons.

Thanks,
Rob

---

From: Lou Berger <[email-masked]>
Date: Wed, 20 Dec 2017 06:25:04 -0500

> Lou Berger <[email-masked]> wrote:
...

> with that document.

Umm, so are pre-NMDA datastores.

>  I'm not sure I think they need to be defined in
> this document.

If the text above is accurate, I think something along its lined along its 
lined should be added.  If not accurate, then I think you have a new point 
to clarify...

Lou

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 20 Dec 2017 13:06:27 +0100

> lined should be added.  If not accurate, then I think you have a new point

Saying that '[re]boot' includes full and partial [re]boots does not
really help unless there is somewhere a definition what a full reboot
is and what a partial reboot is.

/js

---

From: Lou Berger <[email-masked]>
Date: Wed, 20 Dec 2017 07:25:34 -0500

> is and what a partial reboot is.

Humm, this sounds like more of can of worms that is worth addressing
here/in this draft at this time. Let's see if it comes up in IESG
processing or IETF LC...

Lou

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 21 Dec 2017 14:07:55 +0100

>     except that YANG "config true" nodes supported in a configuration

If this is about schema or data nodes, I suggest to state it
explicitly:

    ... "config true" schema/data nodes ...

> designed to support this case.

Shouldn't the server add corresponding deviations to the schema for
<operational> in this case?

Lada

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

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 21 Dec 2017 14:25:05 +0100 (CET)

>     ... "config true" schema/data nodes ...

Yes, the new text uses "configuration data nodes".

> <operational> in this case?

We wanted to explicitly support the case that a server doesn't (yet)
implement a given module with config nodes in operational.  But maybe
we should design for the future and remove the MAY half of the
sentence, as suggested above, and let such servers use deviations in
this case.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 21 Dec 2017 17:03:21 +0100

> implement a given module with config nodes in operational.  But maybe

But with the new schema of YANG library, say Alt B, such a server can simply
omit this module from the schema of <operational>, right?

Lada

> comments

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 21 Dec 2017 17:05:30 +0100 (CET)

> omit this module from the schema of <operational>, right?

Right; note that this document specifies the requirements, and yang
library is designed accordingly.

/martin