> Co-authors, if you agree, how do we track this?

As co-author, I agree and view it as an editorial update.  

As co-chair, I recommend the authors commit the fix to 
GitHub now and wait for AD and/or IESG reviews to trigger
an update that it will get swept into.  I don't think that
it's worth fixing any sooner than that, and yet also fear
risking it will be forgotten.

Kent



On Tue, May 29, 2018 at 10:44:04AM +0000, Rohit R Ranade wrote:
> Hi Robert,
> 
> The Introduction section has :
> "
> Furthermore, the operational state datastore may support non-configurable 
> YANG modules in addition to
>    the YANG modules supported by conventional configuration datastores.
> "
> I infer that in the new Yang-library structure,  the schema for 
> "conventional" data-stores should not include the non-configurable YANG 
> module. Is my inference correct ?
>

A module that has only config false nodes will not add anything to a
conventional configuration datastore but it is not an error list such
a module. For a simple devices, it may be desirable to have just one
schema that applies to all datastores. There is no requirement to
break things apart just because there is a module that contributes
only an empty set to conventional configuration datastores.

Note that the defined term is 'conventional configuration datastore'
and not 'conventional datastore'. Oops, I see that in one place
draft-ietf-netconf-rfc7895bis-06.txt missing the 'configuration' part
of the term. That should be fixed.

OLD

   The recommended approach to populate "/modules-state" is to report
   the schema for YANG modules that are configurable via conventional
   datastores and for which config false data nodes are returned via a
   NETCONF <get> operation, or equivalent.

NEW

   The recommended approach to populate "/modules-state" is to report
   the schema for YANG modules that are configurable via conventional
   configuration datastores and for which config false data nodes are
   returned via a NETCONF <get> operation, or equivalent.

Co-authors, if you agree, how do we track this?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
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=fL-imGAsOCm0vM-RDRMkiRFU-5x4dLkKa5-hBOU9Iys&s=jmr0Y7mRCeX05op4h6BICyj9U0l0IhnbM5yBqhtcL4k&e=>

_______________________________________________
netmod mailing list
[email protected]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=fL-imGAsOCm0vM-RDRMkiRFU-5x4dLkKa5-hBOU9Iys&s=i4-lwMctjujC_UiZmGO4s83-jyKmw7jbGsS0cLfFZT4&e=


_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to