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

2017-12-21 Thread Martin Bjorklund 
Ladislav Lhotka  wrote:
> On Thu, 2017-12-21 at 14:25 +0100, Martin Bjorklund wrote:
> > Ladislav Lhotka  wrote:
> > > Martin Bjorklund  writes:
> > > 
> > > > Hi Andy,
> > > >
> > > > Andy Bierman  wrote:
> > > >> 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  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  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.
> > > >
> > > > This is required for transition purposes; a server that wants to
> > > > implement  should not have to implement all modules at
> > > > once (as applied config).
> > > >
> > > >> What about config=false subtrees within a config=true subtree?
> > > >> Can they be omitted from  as well, or does the draft just
> > > >> intend to
> > > >> omit the operational value of config=true nodes?  Should be specific.
> > > >
> > > > The text says "nodes supported in a configuration datastore MAY be
> > > > omitted from ".  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:
> > > >
> > > > The datastore schema for  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  if a server is not able to accurately report 
> > > > them.
> > > >
> > > > NEW:
> > > >
> > > > The datastore schema for  MUST be a superset of the
> > > > combined datastore schema used in all configuration datastores
> > > > 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 ...
> > 
> > Yes, the new text uses "configuration data nodes".
> > 
> > > > datastore MAY be omitted from  if a server is not
> > > > able to accurately report them.
> > > >
> > > >
> > > >> 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.
> > > >
> > > > I think we should keep the MAY, since the YANG library has to be
> > > > designed to support this case.
> > > 
> > > Shouldn't the server add corresponding deviations to the schema for
> > >  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
> 
> But with the new schema of YANG library, say Alt B, such a server can simply
> omit this module from the schema of , right?

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


/martin


> 
> Lada
> 
> > 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
> > 
> > 
> > 
> > 
> > > 
> > > Lada
> > > 
> > > >
> > > >
> > > > /martin
> > > >
> > > >
> > > >
> > > >
> > > >> 
> > > >> 
> > > >> 
> > > >> 
> > > >> Andy
> > > >> 
> > > >> 
> > > >> On Mon, Dec 4, 2017 at 6:35 AM, Lou Berger  wrote:
> > > >> 
> > > >> > 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/DWtD12bGkBZabEygRfiwZfcnUU
> > 4
> > > >> >
> > > >> > A diff can be found at
> > > >> >

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

2017-12-21 Thread Ladislav Lhotka 
On Thu, 2017-12-21 at 14:25 +0100, Martin Bjorklund wrote:
> Ladislav Lhotka  wrote:
> > Martin Bjorklund  writes:
> > 
> > > Hi Andy,
> > >
> > > Andy Bierman  wrote:
> > >> 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  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  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.
> > >
> > > This is required for transition purposes; a server that wants to
> > > implement  should not have to implement all modules at
> > > once (as applied config).
> > >
> > >> What about config=false subtrees within a config=true subtree?
> > >> Can they be omitted from  as well, or does the draft just
> > >> intend to
> > >> omit the operational value of config=true nodes?  Should be specific.
> > >
> > > The text says "nodes supported in a configuration datastore MAY be
> > > omitted from ".  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:
> > >
> > > The datastore schema for  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  if a server is not able to accurately report them.
> > >
> > > NEW:
> > >
> > > The datastore schema for  MUST be a superset of the
> > > combined datastore schema used in all configuration datastores
> > > 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 ...
> 
> Yes, the new text uses "configuration data nodes".
> 
> > > datastore MAY be omitted from  if a server is not
> > > able to accurately report them.
> > >
> > >
> > >> 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.
> > >
> > > I think we should keep the MAY, since the YANG library has to be
> > > designed to support this case.
> > 
> > Shouldn't the server add corresponding deviations to the schema for
> >  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

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

Lada

> 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
> 
> 
> 
> 
> > 
> > Lada
> > 
> > >
> > >
> > > /martin
> > >
> > >
> > >
> > >
> > >> 
> > >> 
> > >> 
> > >> 
> > >> Andy
> > >> 
> > >> 
> > >> On Mon, Dec 4, 2017 at 6:35 AM, Lou Berger  wrote:
> > >> 
> > >> > 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/DWtD12bGkBZabEygRfiwZfcnUU
> 4
> > >> >
> > >> > A diff can be found at
> > >> > https://tools.ietf.org/rfcdiff?difftype=--hwdiff=draft-ietf-netmod
> -
> > >> > revised-datastores-04.txt=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
> > >> > netmod@ietf.org
> > >> > https://www.ietf.org/mailman/listinfo/netmod
> >

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

2017-12-21 Thread Martin Bjorklund 
Ladislav Lhotka  wrote:
> Martin Bjorklund  writes:
> 
> > Hi Andy,
> >
> > Andy Bierman  wrote:
> >> 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  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  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.
> >
> > This is required for transition purposes; a server that wants to
> > implement  should not have to implement all modules at
> > once (as applied config).
> >
> >> What about config=false subtrees within a config=true subtree?
> >> Can they be omitted from  as well, or does the draft just
> >> intend to
> >> omit the operational value of config=true nodes?  Should be specific.
> >
> > The text says "nodes supported in a configuration datastore MAY be
> > omitted from ".  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:
> >
> > The datastore schema for  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  if a server is not able to accurately report them.
> >
> > NEW:
> >
> > The datastore schema for  MUST be a superset of the
> > combined datastore schema used in all configuration datastores
> > 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 ...

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

> > datastore MAY be omitted from  if a server is not
> > able to accurately report them.
> >
> >
> >> 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.
> >
> > I think we should keep the MAY, since the YANG library has to be
> > designed to support this case.
> 
> Shouldn't the server add corresponding deviations to the schema for
>  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




> 
> Lada
> 
> >
> >
> > /martin
> >
> >
> >
> >
> >> 
> >> 
> >> 
> >> 
> >> Andy
> >> 
> >> 
> >> On Mon, Dec 4, 2017 at 6:35 AM, Lou Berger  wrote:
> >> 
> >> > 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=draft-ietf-netmod-
> >> > revised-datastores-04.txt=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
> >> > netmod@ietf.org
> >> > https://www.ietf.org/mailman/listinfo/netmod
> >> >
> >
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> -- 
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

2017-12-20 Thread Lou Berger 
On 12/20/2017 07:06 AM, Juergen Schoenwaelder wrote:
> On Wed, Dec 20, 2017 at 06:25:04AM -0500, Lou Berger wrote:
>>
>> 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...
>>
> 
> 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.
> 

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

> /js
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

2017-12-20 Thread Juergen Schoenwaelder 
On Wed, Dec 20, 2017 at 06:25:04AM -0500, Lou Berger wrote:
> 
> 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...
>

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

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

2017-12-20 Thread Lou Berger 



On December 19, 2017 3:31:34 PM Martin Bjorklund  wrote:


Hi Lou,

Lou Berger  wrote:

Hi,

...




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.


RFC 6241 uses the same terms, so using them is at least consistent
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





/martin





___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

2017-12-20 Thread Robert Wilton 



On 19/12/2017 20:54, Juergen Schoenwaelder wrote:

On Tue, Dec 19, 2017 at 12:41:28PM -0800, Andy Bierman wrote:

On Tue, Dec 19, 2017 at 12:31 PM, Martin Bjorklund  wrote:


Hi Lou,

Lou Berger  wrote:

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:

The datastore schema for  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  if a server is not able to accurately report them.

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.

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 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.


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.
One minor tweak, I think that "configuration" would be better than 
"configuration data" for consistency reasons.


Thanks,
Rob




/js



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

2017-12-19 Thread Juergen Schoenwaelder 
On Tue, Dec 19, 2017 at 12:41:28PM -0800, Andy Bierman wrote:
> On Tue, Dec 19, 2017 at 12:31 PM, Martin Bjorklund  wrote:
> 
> > Hi Lou,
> >
> > Lou Berger  wrote:
> > > 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:
> > >
> > >The datastore schema for  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  if a server is not able to accurately report them.
> > >
> > > 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.
> >
> > 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 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.
>

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 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

2017-12-19 Thread Andy Bierman 
On Tue, Dec 19, 2017 at 12:31 PM, Martin Bjorklund  wrote:

> Hi Lou,
>
> Lou Berger  wrote:
> > 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:
> >
> >The datastore schema for  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  if a server is not able to accurately report them.
> >
> > 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.
>
> 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 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.



> I suspect that
> > this also should translate to an explicit case in section 6.1 as well.
>
> I don't understand why that would be neeed.
>
> > 2) The abstract needs to mention that it updates RFC7950 (per idnits)
>
> Ok.
>
> > 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.
>
> 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
>
>
>
>

Andy


>
> >
> > Thank you,
> > Lou
> > (As Shepherd)
> >
> > On 12/04/2017 09:35 AM, Lou Berger wrote:
> > > 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=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
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> > >
> >
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

2017-12-19 Thread Martin Bjorklund 
Hi Lou,

Lou Berger  wrote:
> 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:
> 
>The datastore schema for  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  if a server is not able to accurately report them.
> 
> 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.

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
> this also should translate to an explicit case in section 6.1 as well.

I don't understand why that would be neeed.

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

Ok.

> 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.

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




> 
> Thank you,
> Lou
> (As Shepherd)
> 
> On 12/04/2017 09:35 AM, Lou Berger wrote:
> > 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=draft-ietf-netmod-revised-datastores-04.txt=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
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> > 
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

2017-12-19 Thread Martin Bjorklund 
Hi Andy,

Andy Bierman  wrote:
> 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  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  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.

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

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

The text says "nodes supported in a configuration datastore MAY be
omitted from ".  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:

The datastore schema for  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  if a server is not able to accurately report them.

NEW:

The datastore schema for  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  if a server is not
able to accurately report them.


> 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.

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


/martin




> 
> 
> 
> 
> Andy
> 
> 
> On Mon, Dec 4, 2017 at 6:35 AM, Lou Berger  wrote:
> 
> > 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=draft-ietf-netmod-
> > revised-datastores-04.txt=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
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

2017-12-12 Thread Lou Berger 
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

On 12/04/2017 09:35 AM, Lou Berger wrote:
> 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=draft-ietf-netmod-revised-datastores-04.txt=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
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

2017-12-12 Thread Lou Berger 
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:

   The datastore schema for  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  if a server is not able to accurately report them.

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)

On 12/04/2017 09:35 AM, Lou Berger wrote:
> 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=draft-ietf-netmod-revised-datastores-04.txt=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
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

2017-12-08 Thread Andy Bierman 
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  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  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  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  wrote:

> 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=draft-ietf-netmod-
> revised-datastores-04.txt=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
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

2017-12-04 Thread Lou Berger 
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=draft-ietf-netmod-revised-datastores-04.txt=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
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod