Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts

[Andy Bierman]

On Thu, Feb 8, 2018 at 11:00 AM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> On Thu, Feb 08, 2018 at 10:55:53AM -0800, Andy Bierman wrote:
> > On Thu, Feb 8, 2018 at 10:44 AM, Juergen Schoenwaelder <
> > j.schoenwael...@jacobs-university.de> wrote:
> >
> > > On Thu, Feb 08, 2018 at 09:11:58AM -0800, Andy Bierman wrote:
> > > > >
> > > > Then remove the text that says an error is sent if with-defaults
> > > attempted
> > > > on .
> > > > None of this new text needs to go into NMDA. It can be a
> vendor-specific
> > > > mystery what gets set as origin=default.  Implementors can read RFC
> 6243
> > > > and figure it out on their own.
> > >
> > > As I said, I am absolutely fine with the option of being silent about
> > > with-defaults and if needed someone can spin an update of RFC 6243.
> >
> > This is not needed.
> >
> >
> >If the "with-defaults" parameter
> >is present in a request to such a datastore, then the server MUST
> >
> >   return an error, as specified in "ietf-netconf-nmda" (see Section 4
> >  netconf-03#section-4>).
> >
> >
> >  The 'with-defaults' parameter does not apply to operational
> >  datastores. If the 'with-defaults' parameter is present in a
> >  request to an operational datastore, then the server MUST
> >  return an  element with an  value of
> >  'invalid-value'.";
> >
> >
> >
> > There are 2 places in the draft that say MUST send an error.
> > You need to add detailed text explaining what "harm to the Internet"
> > is caused if this parameter is accepted. You cannot use MUST
> > unless interoperability is harmed by allowing a server to
> > omit response data containing the YANG default value.
> > Please explain all the problems solved by this MUST constraint.
> >
> >
> > Please explain in detail in the draft WHY
> >
> >  The 'with-defaults' parameter does not apply to operational
> >  datastores.
> >
> > This assertion is false.
>
> I don't get your message. Trying again: I am fine to remove all text
> that talks about with-default and if needed someone can spin an update
> of RFC 6243 to use with-default.
>


It is now clear that the current "trim" and "report-all-tagged" enums apply
to .
These retrieval options apply to config=false nodes for .
It is not clear why  is removing this functionality for
config=false nodes.



>
> /js
>


Andy



>
> --
> 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] [Netconf] LC of NDMA NETCONF/RESTCONF drafts

[Martin Bjorklund]

Andy Bierman  wrote:
> > 
> > Who needs all this to manage a network?
> >
> >
> 
> I sometimes get comments from people about NETCONF defaults, like
> "You think this is a standard? Why does a vendor get to decide what
> is a default leaf?"
> 
> CoMI has taken a different approach.
> Every server MUST implement "trim" mode and nothing else.
> NETCONF should do the same (but won't)

Since we're now defining a new datastore, , we have the
opportunity to define one single behavour that all servers MUST
implement.  That's why the draft says that defaults are injected as
data flows into , and that all values that are in use
(including defaults), are present in  and always
returned.


/martin

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

Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts

[Juergen Schoenwaelder]

On Thu, Feb 08, 2018 at 10:55:53AM -0800, Andy Bierman wrote:
> On Thu, Feb 8, 2018 at 10:44 AM, Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de> wrote:
> 
> > On Thu, Feb 08, 2018 at 09:11:58AM -0800, Andy Bierman wrote:
> > > >
> > > Then remove the text that says an error is sent if with-defaults
> > attempted
> > > on .
> > > None of this new text needs to go into NMDA. It can be a vendor-specific
> > > mystery what gets set as origin=default.  Implementors can read RFC 6243
> > > and figure it out on their own.
> >
> > As I said, I am absolutely fine with the option of being silent about
> > with-defaults and if needed someone can spin an update of RFC 6243.
> 
> This is not needed.
> 
> 
>If the "with-defaults" parameter
>is present in a request to such a datastore, then the server MUST
> 
>   return an error, as specified in "ietf-netconf-nmda" (see Section 4
> ).
> 
> 
>  The 'with-defaults' parameter does not apply to operational
>  datastores. If the 'with-defaults' parameter is present in a
>  request to an operational datastore, then the server MUST
>  return an  element with an  value of
>  'invalid-value'.";
> 
> 
> 
> There are 2 places in the draft that say MUST send an error.
> You need to add detailed text explaining what "harm to the Internet"
> is caused if this parameter is accepted. You cannot use MUST
> unless interoperability is harmed by allowing a server to
> omit response data containing the YANG default value.
> Please explain all the problems solved by this MUST constraint.
> 
> 
> Please explain in detail in the draft WHY
> 
>  The 'with-defaults' parameter does not apply to operational
>  datastores.
> 
> This assertion is false.

I don't get your message. Trying again: I am fine to remove all text
that talks about with-default and if needed someone can spin an update
of RFC 6243 to use with-default.

/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] [Netconf] LC of NDMA NETCONF/RESTCONF drafts

[Andy Bierman]

On Thu, Feb 8, 2018 at 10:44 AM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> On Thu, Feb 08, 2018 at 09:11:58AM -0800, Andy Bierman wrote:
> > >
> > Then remove the text that says an error is sent if with-defaults
> attempted
> > on .
> > None of this new text needs to go into NMDA. It can be a vendor-specific
> > mystery what gets set as origin=default.  Implementors can read RFC 6243
> > and figure it out on their own.
>
> As I said, I am absolutely fine with the option of being silent about
> with-defaults and if needed someone can spin an update of RFC 6243.
>
>

This is not needed.


   If the "with-defaults" parameter
   is present in a request to such a datastore, then the server MUST

  return an error, as specified in "ietf-netconf-nmda" (see Section 4
).


 The 'with-defaults' parameter does not apply to operational
 datastores. If the 'with-defaults' parameter is present in a
 request to an operational datastore, then the server MUST
 return an  element with an  value of
 'invalid-value'.";



There are 2 places in the draft that say MUST send an error.
You need to add detailed text explaining what "harm to the Internet"
is caused if this parameter is accepted. You cannot use MUST
unless interoperability is harmed by allowing a server to
omit response data containing the YANG default value.
Please explain all the problems solved by this MUST constraint.


Please explain in detail in the draft WHY



 The 'with-defaults' parameter does not apply to operational
 datastores.


This assertion is false.






> /js
>

Andy



>
> --
> 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] [Netconf] LC of NDMA NETCONF/RESTCONF drafts

[Juergen Schoenwaelder]

On Thu, Feb 08, 2018 at 09:11:58AM -0800, Andy Bierman wrote:
> >
> Then remove the text that says an error is sent if with-defaults attempted
> on .
> None of this new text needs to go into NMDA. It can be a vendor-specific
> mystery what gets set as origin=default.  Implementors can read RFC 6243
> and figure it out on their own.

As I said, I am absolutely fine with the option of being silent about
with-defaults and if needed someone can spin an update of RFC 6243.

/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] [Netconf] LC of NDMA NETCONF/RESTCONF drafts

[Martin Bjorklund]

Hi,

Juergen Schoenwaelder  wrote:
> What we may consider, though, is to have a way to negate origin-filter
> so that we can exclude specific origins - right now to emulate this
> one has to (a) know all possible origins and then (b) list all origins
> except the one not wanted.

  leaf-list include-origin-filter { ... }
  leaf-list exclude-origin-filter { ... }

Or we have a single leaf origin-filter which is a boolean expression
with origin values.  Just like if-feature.

  (not default) and (not learned)

but maybe this is overkill...


/martin

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

Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts

[Martin Bjorklund]

Andy Bierman  wrote:

> It should be clear in some draft how basic-mode applies to origin=default
> within .
> 
> Applying sec 2 of 6243...
> 
> config=true:
> 
> If basic-mode=report-all then origin=default will never be present

Note that origin=default can be used for more than just static YANG
"default" statement defaults.  But then RFC 6243 talks about "schema
defaults", and presumably this includes dynamic defaults, even if they
are defined in prose in a description statement.

So I think your statement above is correct, since the default value is
present even in  and .

> If basic-mode=trim then origin=default is only possible if the value-in-use
> is the YANG default

Yes, for the same reason as above.

> If basic-mode=explicit then origin=default is only possible if the
> configured value was not
> explicitly set by a client.

Yes.

> Sec 2.3.1 is not clear if the YANG default
> value is relevant or not.
> It could be that if the configured value not explicitly set, then any
> value-in-use (not just the
> YANG default) could be tagged origin=default.

Yes I think so, as per above.

> config=false:

Note that the origin annotation is not present on config false nodes.

> report-all: default ignored, no nodes treated as default

Yes.

> trim: node removed if value=YANG default

Yes.

> explicit: all config=false nodes are set by the server, so no nodes treated
> as default

Yes.

> This draft makes with-defaults mandatory-to-implement.
> It is a SHOULD implement now.  (I approve!).

But is this what the WG wants?  (side note; it would be good with a
"if-module-implemented" statement, similar to if-feature.  as it is
today, if we want with-defaults to be optional we'd have to define an
additional feature, which really is unnecessary)

> The with-defaults capability MUST be advertised by the NMDA server,
> including
> the basic-mode parameter. The also-supported parameter MAY be included.
> 
> Is it possible for report-all-tagged to apply to nodes that are learned
> (i.e., not origin=default)?

No, I think that if report-all-tagged is requested, you'd get both the
"default" attribute and origin=default together.



/martin

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

Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts

[Phil Shafer]

Juergen Schoenwaelder writes:
>Frankly, carrying the different basic modes over to 
>sounds like a mistake. Complexity for no real value.

+1

Thanks,
 Phil

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

Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts

[Andy Bierman]

> 
> Who needs all this to manage a network?
>
>

I sometimes get comments from people about NETCONF defaults, like
"You think this is a standard? Why does a vendor get to decide what
is a default leaf?"

CoMI has taken a different approach.
Every server MUST implement "trim" mode and nothing else.
NETCONF should do the same (but won't)


Andy



> > This draft makes with-defaults mandatory-to-implement.
> > It is a SHOULD implement now.  (I approve!).
> >
> > The with-defaults capability MUST be advertised by the NMDA server,
> > including
> > the basic-mode parameter. The also-supported parameter MAY be included.
> >
> > Is it possible for report-all-tagged to apply to nodes that are learned
> > (i.e., not origin=default)?
>
> So here is an alternate proposal: The NMDA documents are silent about
> with-defaults and if someone wants to use with-defaults with
> datastores then an update of RFC 6243 needs to be written. This way,
> implementations can choose to not do any of the with-defaults magic.
>
> What we may consider, though, is to have a way to negate origin-filter
> so that we can exclude specific origins - right now to emulate this
> one has to (a) know all possible origins and then (b) list all origins
> except the one not wanted.
>
> /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] [Netconf] LC of NDMA NETCONF/RESTCONF drafts

[Andy Bierman]

On Wed, Feb 7, 2018 at 11:36 PM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> On Wed, Feb 07, 2018 at 03:03:49PM -0800, Andy Bierman wrote:
> > >
> > > > 2) The  operation returns all values in use.
> > > > The only way to suppress defaults is to use 
> > > > (e.g., request all origins except 'default')
> > >
> > > Or use with-defaults = trim.
> >
> > Yes -- because the definition in RFC 6243 is worded to exclude nodes.
> >
> > It should be clear in some draft how basic-mode applies to origin=default
> > within .
>
> Frankly, carrying the different basic modes over to 
> sounds like a mistake. Complexity for no real value.
>
>

API consistency is never a mistake.
Special case treatment of 1 datastore sounds like a mistake.


> > Applying sec 2 of 6243...
> >
> > config=true:
> >
> > If basic-mode=report-all then origin=default will never be present
> >
> > If basic-mode=trim then origin=default is only possible if the
> value-in-use
> > is the YANG default
> >
> > If basic-mode=explicit then origin=default is only possible if the
> > configured value was not
> > explicitly set by a client.  Sec 2.3.1 is not clear if the YANG default
> > value is relevant or not.
> > It could be that if the configured value not explicitly set, then any
> > value-in-use (not just the
> > YANG default) could be tagged origin=default.
> >
> >
> > config=false:
> >
> > report-all: default ignored, no nodes treated as default
> > trim: node removed if value=YANG default
> > explicit: all config=false nodes are set by the server, so no nodes
> treated
> > as default
>
> Who needs all this to manage a network?



>
>
> This draft makes with-defaults mandatory-to-implement.
> > It is a SHOULD implement now.  (I approve!).
> >
> > The with-defaults capability MUST be advertised by the NMDA server,
> > including
> > the basic-mode parameter. The also-supported parameter MAY be included.
> >
> > Is it possible for report-all-tagged to apply to nodes that are learned
> > (i.e., not origin=default)?
>
> So here is an alternate proposal: The NMDA documents are silent about
> with-defaults and if someone wants to use with-defaults with
> datastores then an update of RFC 6243 needs to be written. This way,
> implementations can choose to not do any of the with-defaults magic.
>
> What we may consider, though, is to have a way to negate origin-filter
> so that we can exclude specific origins - right now to emulate this
> one has to (a) know all possible origins and then (b) list all origins
> except the one not wanted.
>
>
Then remove the text that says an error is sent if with-defaults attempted
on .
None of this new text needs to go into NMDA. It can be a vendor-specific
mystery what gets set as origin=default.  Implementors can read RFC 6243
and figure it out on their own.

Sometimes default leafs might take up 50% or more of the retrieval response.
Insisting that all clients always want this extra data seems overly
simplistic.
Assuming all networks are fast enough to ignore a 2X increase in data size
for no benefit
is not a good idea either.





> /js
>


Andy


>
> --
> 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] [Netconf] LC of NDMA NETCONF/RESTCONF drafts

[Juergen Schoenwaelder]

On Wed, Feb 07, 2018 at 03:03:49PM -0800, Andy Bierman wrote:
> >
> > > 2) The  operation returns all values in use.
> > > The only way to suppress defaults is to use 
> > > (e.g., request all origins except 'default')
> >
> > Or use with-defaults = trim.
> 
> Yes -- because the definition in RFC 6243 is worded to exclude nodes.
> 
> It should be clear in some draft how basic-mode applies to origin=default
> within .

Frankly, carrying the different basic modes over to 
sounds like a mistake. Complexity for no real value.
 
> Applying sec 2 of 6243...
> 
> config=true:
> 
> If basic-mode=report-all then origin=default will never be present
> 
> If basic-mode=trim then origin=default is only possible if the value-in-use
> is the YANG default
> 
> If basic-mode=explicit then origin=default is only possible if the
> configured value was not
> explicitly set by a client.  Sec 2.3.1 is not clear if the YANG default
> value is relevant or not.
> It could be that if the configured value not explicitly set, then any
> value-in-use (not just the
> YANG default) could be tagged origin=default.
> 
> 
> config=false:
> 
> report-all: default ignored, no nodes treated as default
> trim: node removed if value=YANG default
> explicit: all config=false nodes are set by the server, so no nodes treated
> as default

Who needs all this to manage a network?
 
> This draft makes with-defaults mandatory-to-implement.
> It is a SHOULD implement now.  (I approve!).
>
> The with-defaults capability MUST be advertised by the NMDA server,
> including
> the basic-mode parameter. The also-supported parameter MAY be included.
> 
> Is it possible for report-all-tagged to apply to nodes that are learned
> (i.e., not origin=default)?

So here is an alternate proposal: The NMDA documents are silent about
with-defaults and if someone wants to use with-defaults with
datastores then an update of RFC 6243 needs to be written. This way,
implementations can choose to not do any of the with-defaults magic.

What we may consider, though, is to have a way to negate origin-filter
so that we can exclude specific origins - right now to emulate this
one has to (a) know all possible origins and then (b) list all origins
except the one not wanted.

/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] [Netconf] LC of NDMA NETCONF/RESTCONF drafts

[Andy Bierman]

On Wed, Feb 7, 2018 at 10:28 AM, Martin Bjorklund  wrote:

> Andy Bierman  wrote:
> > On Wed, Feb 7, 2018 at 8:11 AM, Robert Wilton  wrote:
> >
> > >
> > >
> > > On 07/02/2018 14:23, Andy Bierman wrote:
> > >
> > >
> > >
> > > On Wed, Feb 7, 2018 at 3:14 AM, Robert Wilton 
> wrote:
> > >
> > >> Hi Andy,
> > >>
> > >> On 07/02/2018 02:33, Andy Bierman wrote:
> > >>
> > >>
> > >>
> > >> On Mon, Feb 5, 2018 at 1:33 PM, Mahesh Jethanandani <
> > >> mjethanand...@gmail.com> wrote:
> > >>
> > >>> For folks that provided comments as part of LC, please verify that
> your
> > >>> comments have been adequately addressed by -03 version of the draft.
> > >>>
> > >>>
> > >>
> > >> Most comments have been addressed.
> > >>
> > >>
> > >> The "with-defaults" parameter does not apply when interacting
> with an
> > >>
> > >> operational datastore.
> > >>
> > >>
> > >> There is no explanation of why the with-defaults parameter does not
> apply
> > >> to .
> > >> This is confusing. The solution that has been a standard for years
> still
> > >> applies to
> > >> all datastores, except a completely different mechanism
> (origin-filter)
> > >> is used instead
> > >> for 1 datastore.
> > >>
> > >> If the server code can identify a default so it can be tagged
> > >> origin=or:default, then it can
> > >> also support with-defaults.
> > >>
> > >> I prefer the sentence above be changed, so that a server MAY implement
> > >> with-defaults
> > >> for .  If the client sends  it should be
> OK
> > >> to honor it instead
> > >> of returning an error.
> > >>
> > >> I have two concerns with changing this to a MAY:
> > >>
> > >> (1) The most useful "with-defaults" behavior differs for
>  vs
> > >> the configuration datastores, but with-defaults only allows a single
> > >> standard behavior to be specified.
> > >>
> > >> E.g. for configuration datastores the most appropriate semantics (if
> the
> > >> client doesn't explicitly ask for something else) is "explicit". i.e.
> you
> > >> give back exactly what was put in.
> > >>
> > >> But, for operational, the most appropriate semantics (if the client
> > >> doesn't explicitly ask for something else) is something like
> "report-all",
> > >> i.e. the device reports the precise current state including any
> defaults.
> > >> However, we felt that this would return too much unnecessary data,
> hence
> > >> why the datastore architecture defines "in-use" data, allowing the
> server
> > >> to prune out any data that is clearly irrelevant.
> > >>
> > >> (2)  is a new datastore.  I personally don't want each
> > >> server choosing how the data is returned, which requires that clients
> must
> > >> handle all variants.  It would be better for the draft to specify the
> > >> standard semantics to use unless a client has explicitly requested
> > >> something else.
> > >>
> > >> I'm not opposed to a "with-defaults-bis", or a new draft covering
> > >> "with-defaults" for ", but I think that:
> > >> (i) We shouldn't delay the NMDA protocol drafts for this, this can be
> > >> done as separate draft adding extra optional functionality.
> > >> (ii) The semantics for retrieving data from operational (or
> > >> notifications) should be as defined by "in-use" in the NMDA
> architecture,
> > >> unless a client has explicitly specified, or configured, a different
> > >> behavior.
> > >> (iii) Probably the only existing option defined in "with-defaults"
> that
> > >> makes sense for  is a variant of "trim" that is
> specified to
> > >> return what is defined as returning the "in-use" values, but also
> excluding
> > >> any values that match a default value specified in the schema.
> > >>
> > >>
> > >
> > > I think your approach violates the Postel Principle.
> > > "Be liberal in what you accept" is about robustness.
> > > Rejecting parameters for no good reason is about fragility.
> > >
> > > I never said change the behavior for  if no
> 
> > > is present.
> > > If the parameter is provided it is trivial for the server to honor it.
> > > The most useful value (report-all) is the default, not leave out all
> > > defaults, like .
> > >
> > > OK, so one option is to allow the "with-defaults" parameter for the
> > >  datastore, but specify in both the NETCONF NMDA and
> RESTCONF
> > > NMDA drafts how "with-defaults" semantics apply to any operational
> > > datastore:
> > >
> > > 1) Regardless of what is reported in the "basic-mode" capability
> > > parameter, the default behavior for  is "report-all", with
> > > semantics as described below:
> > > 2) "report-all" for operational datastores is defined as returning all
> "in
> > > use" values (i.e. as specified in section 5.3 of the NMDA
> architecture, so
> > > default values that are not "in use" are not returned).
> > > 3) "trim" for operational datastores is defined as returning all
> "in-use"
> > > values (... as 5.3) except that values that match the value specified
> in
> > > the 

Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts

[Andy Bierman]

On Wed, Feb 7, 2018 at 1:58 PM, Mahesh Jethanandani  wrote:

> It appears that there is some consensus around the issue of
> “with-defaults” for operational datastore. Andy, would you agree with what
> has been suggested?
>
>
Yes.



> It also appears that text needs to be added to explain the behavior w.r.t.
> operational datastore. If everyone agrees, authors, can you propose the
> text that needs to be updated.
>
> Thanks.
>
>
Andy


> On Feb 7, 2018, at 10:28 AM, Martin Bjorklund  wrote:
>
> Andy Bierman  wrote:
>
> On Wed, Feb 7, 2018 at 8:11 AM, Robert Wilton  wrote:
>
>
>
> On 07/02/2018 14:23, Andy Bierman wrote:
>
>
>
> On Wed, Feb 7, 2018 at 3:14 AM, Robert Wilton  wrote:
>
> Hi Andy,
>
> On 07/02/2018 02:33, Andy Bierman wrote:
>
>
>
> On Mon, Feb 5, 2018 at 1:33 PM, Mahesh Jethanandani <
> mjethanand...@gmail.com> wrote:
>
> For folks that provided comments as part of LC, please verify that your
> comments have been adequately addressed by -03 version of the draft.
>
>
>
> Most comments have been addressed.
>
>
>The "with-defaults" parameter does not apply when interacting with an
>
>operational datastore.
>
>
> There is no explanation of why the with-defaults parameter does not apply
> to .
> This is confusing. The solution that has been a standard for years still
> applies to
> all datastores, except a completely different mechanism (origin-filter)
> is used instead
> for 1 datastore.
>
> If the server code can identify a default so it can be tagged
> origin=or:default, then it can
> also support with-defaults.
>
> I prefer the sentence above be changed, so that a server MAY implement
> with-defaults
> for .  If the client sends  it should be OK
> to honor it instead
> of returning an error.
>
> I have two concerns with changing this to a MAY:
>
> (1) The most useful "with-defaults" behavior differs for  vs
> the configuration datastores, but with-defaults only allows a single
> standard behavior to be specified.
>
> E.g. for configuration datastores the most appropriate semantics (if the
> client doesn't explicitly ask for something else) is "explicit". i.e. you
> give back exactly what was put in.
>
> But, for operational, the most appropriate semantics (if the client
> doesn't explicitly ask for something else) is something like "report-all",
> i.e. the device reports the precise current state including any defaults.
> However, we felt that this would return too much unnecessary data, hence
> why the datastore architecture defines "in-use" data, allowing the server
> to prune out any data that is clearly irrelevant.
>
> (2)  is a new datastore.  I personally don't want each
> server choosing how the data is returned, which requires that clients must
> handle all variants.  It would be better for the draft to specify the
> standard semantics to use unless a client has explicitly requested
> something else.
>
> I'm not opposed to a "with-defaults-bis", or a new draft covering
> "with-defaults" for ", but I think that:
> (i) We shouldn't delay the NMDA protocol drafts for this, this can be
> done as separate draft adding extra optional functionality.
> (ii) The semantics for retrieving data from operational (or
> notifications) should be as defined by "in-use" in the NMDA architecture,
> unless a client has explicitly specified, or configured, a different
> behavior.
> (iii) Probably the only existing option defined in "with-defaults" that
> makes sense for  is a variant of "trim" that is specified to
> return what is defined as returning the "in-use" values, but also excluding
> any values that match a default value specified in the schema.
>
>
>
> I think your approach violates the Postel Principle.
> "Be liberal in what you accept" is about robustness.
> Rejecting parameters for no good reason is about fragility.
>
> I never said change the behavior for  if no 
> is present.
> If the parameter is provided it is trivial for the server to honor it.
> The most useful value (report-all) is the default, not leave out all
> defaults, like .
>
> OK, so one option is to allow the "with-defaults" parameter for the
>  datastore, but specify in both the NETCONF NMDA and RESTCONF
> NMDA drafts how "with-defaults" semantics apply to any operational
> datastore:
>
> 1) Regardless of what is reported in the "basic-mode" capability
> parameter, the default behavior for  is "report-all", with
> semantics as described below:
> 2) "report-all" for operational datastores is defined as returning all "in
> use" values (i.e. as specified in section 5.3 of the NMDA architecture, so
> default values that are not "in use" are not returned).
> 3) "trim" for operational datastores is defined as returning all "in-use"
> values (... as 5.3) except that values that match the value specified in
> the schema "default" statement are omitted.  Note, clients cannot
> distinguish between a value that is omitted 

Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts

[Mahesh Jethanandani]

It appears that there is some consensus around the issue of “with-defaults” for 
operational datastore. Andy, would you agree with what has been suggested?

It also appears that text needs to be added to explain the behavior w.r.t. 
operational datastore. If everyone agrees, authors, can you propose the text 
that needs to be updated.

Thanks.

> On Feb 7, 2018, at 10:28 AM, Martin Bjorklund  wrote:
> 
> Andy Bierman > wrote:
>> On Wed, Feb 7, 2018 at 8:11 AM, Robert Wilton  wrote:
>> 
>>> 
>>> 
>>> On 07/02/2018 14:23, Andy Bierman wrote:
>>> 
>>> 
>>> 
>>> On Wed, Feb 7, 2018 at 3:14 AM, Robert Wilton  wrote:
>>> 
 Hi Andy,
 
 On 07/02/2018 02:33, Andy Bierman wrote:
 
 
 
 On Mon, Feb 5, 2018 at 1:33 PM, Mahesh Jethanandani <
 mjethanand...@gmail.com> wrote:
 
> For folks that provided comments as part of LC, please verify that your
> comments have been adequately addressed by -03 version of the draft.
> 
> 
 
 Most comments have been addressed.
 
 
The "with-defaults" parameter does not apply when interacting with an
 
operational datastore.
 
 
 There is no explanation of why the with-defaults parameter does not apply
 to .
 This is confusing. The solution that has been a standard for years still
 applies to
 all datastores, except a completely different mechanism (origin-filter)
 is used instead
 for 1 datastore.
 
 If the server code can identify a default so it can be tagged
 origin=or:default, then it can
 also support with-defaults.
 
 I prefer the sentence above be changed, so that a server MAY implement
 with-defaults
 for .  If the client sends  it should be OK
 to honor it instead
 of returning an error.
 
 I have two concerns with changing this to a MAY:
 
 (1) The most useful "with-defaults" behavior differs for  vs
 the configuration datastores, but with-defaults only allows a single
 standard behavior to be specified.
 
 E.g. for configuration datastores the most appropriate semantics (if the
 client doesn't explicitly ask for something else) is "explicit". i.e. you
 give back exactly what was put in.
 
 But, for operational, the most appropriate semantics (if the client
 doesn't explicitly ask for something else) is something like "report-all",
 i.e. the device reports the precise current state including any defaults.
 However, we felt that this would return too much unnecessary data, hence
 why the datastore architecture defines "in-use" data, allowing the server
 to prune out any data that is clearly irrelevant.
 
 (2)  is a new datastore.  I personally don't want each
 server choosing how the data is returned, which requires that clients must
 handle all variants.  It would be better for the draft to specify the
 standard semantics to use unless a client has explicitly requested
 something else.
 
 I'm not opposed to a "with-defaults-bis", or a new draft covering
 "with-defaults" for ", but I think that:
 (i) We shouldn't delay the NMDA protocol drafts for this, this can be
 done as separate draft adding extra optional functionality.
 (ii) The semantics for retrieving data from operational (or
 notifications) should be as defined by "in-use" in the NMDA architecture,
 unless a client has explicitly specified, or configured, a different
 behavior.
 (iii) Probably the only existing option defined in "with-defaults" that
 makes sense for  is a variant of "trim" that is specified to
 return what is defined as returning the "in-use" values, but also excluding
 any values that match a default value specified in the schema.
 
 
>>> 
>>> I think your approach violates the Postel Principle.
>>> "Be liberal in what you accept" is about robustness.
>>> Rejecting parameters for no good reason is about fragility.
>>> 
>>> I never said change the behavior for  if no 
>>> is present.
>>> If the parameter is provided it is trivial for the server to honor it.
>>> The most useful value (report-all) is the default, not leave out all
>>> defaults, like .
>>> 
>>> OK, so one option is to allow the "with-defaults" parameter for the
>>>  datastore, but specify in both the NETCONF NMDA and RESTCONF
>>> NMDA drafts how "with-defaults" semantics apply to any operational
>>> datastore:
>>> 
>>> 1) Regardless of what is reported in the "basic-mode" capability
>>> parameter, the default behavior for  is "report-all", with
>>> semantics as described below:
>>> 2) "report-all" for operational datastores is defined as returning all "in
>>> use" values (i.e. as specified in section 5.3 of the NMDA architecture, so
>>> default values that are not "in use" are not returned).
>>> 3) "trim" for operational 

Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts

[Martin Bjorklund]

Andy Bierman  wrote:
> On Wed, Feb 7, 2018 at 8:11 AM, Robert Wilton  wrote:
> 
> >
> >
> > On 07/02/2018 14:23, Andy Bierman wrote:
> >
> >
> >
> > On Wed, Feb 7, 2018 at 3:14 AM, Robert Wilton  wrote:
> >
> >> Hi Andy,
> >>
> >> On 07/02/2018 02:33, Andy Bierman wrote:
> >>
> >>
> >>
> >> On Mon, Feb 5, 2018 at 1:33 PM, Mahesh Jethanandani <
> >> mjethanand...@gmail.com> wrote:
> >>
> >>> For folks that provided comments as part of LC, please verify that your
> >>> comments have been adequately addressed by -03 version of the draft.
> >>>
> >>>
> >>
> >> Most comments have been addressed.
> >>
> >>
> >> The "with-defaults" parameter does not apply when interacting with an
> >>
> >> operational datastore.
> >>
> >>
> >> There is no explanation of why the with-defaults parameter does not apply
> >> to .
> >> This is confusing. The solution that has been a standard for years still
> >> applies to
> >> all datastores, except a completely different mechanism (origin-filter)
> >> is used instead
> >> for 1 datastore.
> >>
> >> If the server code can identify a default so it can be tagged
> >> origin=or:default, then it can
> >> also support with-defaults.
> >>
> >> I prefer the sentence above be changed, so that a server MAY implement
> >> with-defaults
> >> for .  If the client sends  it should be OK
> >> to honor it instead
> >> of returning an error.
> >>
> >> I have two concerns with changing this to a MAY:
> >>
> >> (1) The most useful "with-defaults" behavior differs for  vs
> >> the configuration datastores, but with-defaults only allows a single
> >> standard behavior to be specified.
> >>
> >> E.g. for configuration datastores the most appropriate semantics (if the
> >> client doesn't explicitly ask for something else) is "explicit". i.e. you
> >> give back exactly what was put in.
> >>
> >> But, for operational, the most appropriate semantics (if the client
> >> doesn't explicitly ask for something else) is something like "report-all",
> >> i.e. the device reports the precise current state including any defaults.
> >> However, we felt that this would return too much unnecessary data, hence
> >> why the datastore architecture defines "in-use" data, allowing the server
> >> to prune out any data that is clearly irrelevant.
> >>
> >> (2)  is a new datastore.  I personally don't want each
> >> server choosing how the data is returned, which requires that clients must
> >> handle all variants.  It would be better for the draft to specify the
> >> standard semantics to use unless a client has explicitly requested
> >> something else.
> >>
> >> I'm not opposed to a "with-defaults-bis", or a new draft covering
> >> "with-defaults" for ", but I think that:
> >> (i) We shouldn't delay the NMDA protocol drafts for this, this can be
> >> done as separate draft adding extra optional functionality.
> >> (ii) The semantics for retrieving data from operational (or
> >> notifications) should be as defined by "in-use" in the NMDA architecture,
> >> unless a client has explicitly specified, or configured, a different
> >> behavior.
> >> (iii) Probably the only existing option defined in "with-defaults" that
> >> makes sense for  is a variant of "trim" that is specified to
> >> return what is defined as returning the "in-use" values, but also excluding
> >> any values that match a default value specified in the schema.
> >>
> >>
> >
> > I think your approach violates the Postel Principle.
> > "Be liberal in what you accept" is about robustness.
> > Rejecting parameters for no good reason is about fragility.
> >
> > I never said change the behavior for  if no 
> > is present.
> > If the parameter is provided it is trivial for the server to honor it.
> > The most useful value (report-all) is the default, not leave out all
> > defaults, like .
> >
> > OK, so one option is to allow the "with-defaults" parameter for the
> >  datastore, but specify in both the NETCONF NMDA and RESTCONF
> > NMDA drafts how "with-defaults" semantics apply to any operational
> > datastore:
> >
> > 1) Regardless of what is reported in the "basic-mode" capability
> > parameter, the default behavior for  is "report-all", with
> > semantics as described below:
> > 2) "report-all" for operational datastores is defined as returning all "in
> > use" values (i.e. as specified in section 5.3 of the NMDA architecture, so
> > default values that are not "in use" are not returned).
> > 3) "trim" for operational datastores is defined as returning all "in-use"
> > values (... as 5.3) except that values that match the value specified in
> > the schema "default" statement are omitted.  Note, clients cannot
> > distinguish between a value that is omitted because it is not in use, vs a
> > value that is omitted because it matches the schema default.
> > 4) "explicit" for operational datastores is defined as returning the same
> > as "report-all", defined above.
> > 5) "report-all-tagged" for 

Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts

[Andy Bierman]

On Wed, Feb 7, 2018 at 8:11 AM, Robert Wilton  wrote:

>
>
> On 07/02/2018 14:23, Andy Bierman wrote:
>
>
>
> On Wed, Feb 7, 2018 at 3:14 AM, Robert Wilton  wrote:
>
>> Hi Andy,
>>
>> On 07/02/2018 02:33, Andy Bierman wrote:
>>
>>
>>
>> On Mon, Feb 5, 2018 at 1:33 PM, Mahesh Jethanandani <
>> mjethanand...@gmail.com> wrote:
>>
>>> For folks that provided comments as part of LC, please verify that your
>>> comments have been adequately addressed by -03 version of the draft.
>>>
>>>
>>
>> Most comments have been addressed.
>>
>>
>> The "with-defaults" parameter does not apply when interacting with an
>>
>> operational datastore.
>>
>>
>> There is no explanation of why the with-defaults parameter does not apply
>> to .
>> This is confusing. The solution that has been a standard for years still
>> applies to
>> all datastores, except a completely different mechanism (origin-filter)
>> is used instead
>> for 1 datastore.
>>
>> If the server code can identify a default so it can be tagged
>> origin=or:default, then it can
>> also support with-defaults.
>>
>> I prefer the sentence above be changed, so that a server MAY implement
>> with-defaults
>> for .  If the client sends  it should be OK
>> to honor it instead
>> of returning an error.
>>
>> I have two concerns with changing this to a MAY:
>>
>> (1) The most useful "with-defaults" behavior differs for  vs
>> the configuration datastores, but with-defaults only allows a single
>> standard behavior to be specified.
>>
>> E.g. for configuration datastores the most appropriate semantics (if the
>> client doesn't explicitly ask for something else) is "explicit". i.e. you
>> give back exactly what was put in.
>>
>> But, for operational, the most appropriate semantics (if the client
>> doesn't explicitly ask for something else) is something like "report-all",
>> i.e. the device reports the precise current state including any defaults.
>> However, we felt that this would return too much unnecessary data, hence
>> why the datastore architecture defines "in-use" data, allowing the server
>> to prune out any data that is clearly irrelevant.
>>
>> (2)  is a new datastore.  I personally don't want each
>> server choosing how the data is returned, which requires that clients must
>> handle all variants.  It would be better for the draft to specify the
>> standard semantics to use unless a client has explicitly requested
>> something else.
>>
>> I'm not opposed to a "with-defaults-bis", or a new draft covering
>> "with-defaults" for ", but I think that:
>> (i) We shouldn't delay the NMDA protocol drafts for this, this can be
>> done as separate draft adding extra optional functionality.
>> (ii) The semantics for retrieving data from operational (or
>> notifications) should be as defined by "in-use" in the NMDA architecture,
>> unless a client has explicitly specified, or configured, a different
>> behavior.
>> (iii) Probably the only existing option defined in "with-defaults" that
>> makes sense for  is a variant of "trim" that is specified to
>> return what is defined as returning the "in-use" values, but also excluding
>> any values that match a default value specified in the schema.
>>
>>
>
> I think your approach violates the Postel Principle.
> "Be liberal in what you accept" is about robustness.
> Rejecting parameters for no good reason is about fragility.
>
> I never said change the behavior for  if no 
> is present.
> If the parameter is provided it is trivial for the server to honor it.
> The most useful value (report-all) is the default, not leave out all
> defaults, like .
>
> OK, so one option is to allow the "with-defaults" parameter for the
>  datastore, but specify in both the NETCONF NMDA and RESTCONF
> NMDA drafts how "with-defaults" semantics apply to any operational
> datastore:
>
> 1) Regardless of what is reported in the "basic-mode" capability
> parameter, the default behavior for  is "report-all", with
> semantics as described below:
> 2) "report-all" for operational datastores is defined as returning all "in
> use" values (i.e. as specified in section 5.3 of the NMDA architecture, so
> default values that are not "in use" are not returned).
> 3) "trim" for operational datastores is defined as returning all "in-use"
> values (... as 5.3) except that values that match the value specified in
> the schema "default" statement are omitted.  Note, clients cannot
> distinguish between a value that is omitted because it is not in use, vs a
> value that is omitted because it matches the schema default.
> 4) "explicit" for operational datastores is defined as returning the same
> as "report-all", defined above.
> 5) "report-all-tagged" for operational datastores is defined as returning
> the same as "report-all", except that all values that match the values
> specified in the schema "default" statement are tagged, as described in
> with-defaults (RFC 5243).
>
> Also note - there is no change in semantics or 

Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts

[Robert Wilton]

On 07/02/2018 14:23, Andy Bierman wrote:



On Wed, Feb 7, 2018 at 3:14 AM, Robert Wilton > wrote:


Hi Andy,


On 07/02/2018 02:33, Andy Bierman wrote:



On Mon, Feb 5, 2018 at 1:33 PM, Mahesh Jethanandani
> wrote:

For folks that provided comments as part of LC, please verify
that your comments have been adequately addressed by -03
version of the draft.



Most comments have been addressed.


 The "with-defaults" parameter does not apply when interacting with an
      operational datastore.


There is no explanation of why the with-defaults parameter does
not apply to .
This is confusing. The solution that has been a standard for
years still applies to
all datastores, except a completely different mechanism
(origin-filter) is used instead
for 1 datastore.

If the server code can identify a default so it can be tagged
origin=or:default, then it can
also support with-defaults.

I prefer the sentence above be changed, so that a server MAY
implement with-defaults
for .  If the client sends  it should
be OK to honor it instead
of returning an error.

I have two concerns with changing this to a MAY:

(1) The most useful "with-defaults" behavior differs for
 vs the configuration datastores, but with-defaults
only allows a single standard behavior to be specified.

E.g. for configuration datastores the most appropriate semantics
(if the client doesn't explicitly ask for something else) is
"explicit". i.e. you give back exactly what was put in.

But, for operational, the most appropriate semantics (if the
client doesn't explicitly ask for something else) is something
like "report-all", i.e. the device reports the precise current
state including any defaults.  However, we felt that this would
return too much unnecessary data, hence why the datastore
architecture defines "in-use" data, allowing the server to prune
out any data that is clearly irrelevant.

(2)  is a new datastore.  I personally don't want
each server choosing how the data is returned, which requires that
clients must handle all variants.  It would be better for the
draft to specify the standard semantics to use unless a client has
explicitly requested something else.

I'm not opposed to a "with-defaults-bis", or a new draft covering
"with-defaults" for ", but I think that:
(i) We shouldn't delay the NMDA protocol drafts for this, this can
be done as separate draft adding extra optional functionality.
(ii) The semantics for retrieving data from operational (or
notifications) should be as defined by "in-use" in the NMDA
architecture, unless a client has explicitly specified, or
configured, a different behavior.
(iii) Probably the only existing option defined in "with-defaults"
that makes sense for  is a variant of "trim" that is
specified to return what is defined as returning the "in-use"
values, but also excluding any values that match a default value
specified in the schema.



I think your approach violates the Postel Principle.
"Be liberal in what you accept" is about robustness.
Rejecting parameters for no good reason is about fragility.

I never said change the behavior for  if no 
 is present.

If the parameter is provided it is trivial for the server to honor it.
The most useful value (report-all) is the default, not leave out all 
defaults, like .
OK, so one option is to allow the "with-defaults" parameter for the 
 datastore, but specify in both the NETCONF NMDA and 
RESTCONF NMDA drafts how "with-defaults" semantics apply to any 
operational datastore:


1) Regardless of what is reported in the "basic-mode" capability 
parameter, the default behavior for  is "report-all", with 
semantics as described below:
2) "report-all" for operational datastores is defined as returning all 
"in use" values (i.e. as specified in section 5.3 of the NMDA 
architecture, so default values that are not "in use" are not returned).
3) "trim" for operational datastores is defined as returning all 
"in-use" values (... as 5.3) except that values that match the value 
specified in the schema "default" statement are omitted.  Note, clients 
cannot distinguish between a value that is omitted because it is not in 
use, vs a value that is omitted because it matches the schema default.
4) "explicit" for operational datastores is defined as returning the 
same as "report-all", defined above.
5) "report-all-tagged" for operational datastores is defined as 
returning the same as "report-all", except that all values that match 
the values specified in the schema "default" statement are tagged, as 
described in with-defaults (RFC 5243).


Also note - there is no change in semantics or behavior to how 
"with-defaults" works for 

Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts

[Andy Bierman]

On Wed, Feb 7, 2018 at 3:14 AM, Robert Wilton  wrote:

> Hi Andy,
>
> On 07/02/2018 02:33, Andy Bierman wrote:
>
>
>
> On Mon, Feb 5, 2018 at 1:33 PM, Mahesh Jethanandani <
> mjethanand...@gmail.com> wrote:
>
>> For folks that provided comments as part of LC, please verify that your
>> comments have been adequately addressed by -03 version of the draft.
>>
>>
>
> Most comments have been addressed.
>
>
> The "with-defaults" parameter does not apply when interacting with an
>
> operational datastore.
>
>
> There is no explanation of why the with-defaults parameter does not apply
> to .
> This is confusing. The solution that has been a standard for years still
> applies to
> all datastores, except a completely different mechanism (origin-filter) is
> used instead
> for 1 datastore.
>
> If the server code can identify a default so it can be tagged
> origin=or:default, then it can
> also support with-defaults.
>
> I prefer the sentence above be changed, so that a server MAY implement
> with-defaults
> for .  If the client sends  it should be OK to
> honor it instead
> of returning an error.
>
> I have two concerns with changing this to a MAY:
>
> (1) The most useful "with-defaults" behavior differs for  vs
> the configuration datastores, but with-defaults only allows a single
> standard behavior to be specified.
>
> E.g. for configuration datastores the most appropriate semantics (if the
> client doesn't explicitly ask for something else) is "explicit". i.e. you
> give back exactly what was put in.
>
> But, for operational, the most appropriate semantics (if the client
> doesn't explicitly ask for something else) is something like "report-all",
> i.e. the device reports the precise current state including any defaults.
> However, we felt that this would return too much unnecessary data, hence
> why the datastore architecture defines "in-use" data, allowing the server
> to prune out any data that is clearly irrelevant.
>
> (2)  is a new datastore.  I personally don't want each server
> choosing how the data is returned, which requires that clients must handle
> all variants.  It would be better for the draft to specify the standard
> semantics to use unless a client has explicitly requested something else.
>
> I'm not opposed to a "with-defaults-bis", or a new draft covering
> "with-defaults" for ", but I think that:
> (i) We shouldn't delay the NMDA protocol drafts for this, this can be done
> as separate draft adding extra optional functionality.
> (ii) The semantics for retrieving data from operational (or notifications)
> should be as defined by "in-use" in the NMDA architecture, unless a client
> has explicitly specified, or configured, a different behavior.
> (iii) Probably the only existing option defined in "with-defaults" that
> makes sense for  is a variant of "trim" that is specified to
> return what is defined as returning the "in-use" values, but also excluding
> any values that match a default value specified in the schema.
>
>

I think your approach violates the Postel Principle.
"Be liberal in what you accept" is about robustness.
Rejecting parameters for no good reason is about fragility.

I never said change the behavior for  if no  is
present.
If the parameter is provided it is trivial for the server to honor it.
The most useful value (report-all) is the default, not leave out all
defaults, like .



> Thanks,
> Rob
>
>
>
Andy


>
>
> Andy
>
>
>
>
>> Thanks
>>
>> Mahesh Jethanandani
>> mjethanand...@gmail.com
>>
>> > On Feb 5, 2018, at 9:43 AM, Martin Bjorklund  wrote:
>> >
>> > Hi,
>> >
>> > Mahesh Jethanandani  wrote:
>> >> This closes the LC for the two NDMA drafts for NETCONF and RESTCONF.
>> >>
>> >> As part of the LC, there were a couple of comments/questions
>> >> raised. In particular
>> >>
>> >> - Vladmir reported an error, which Martin said is fixed in his local
>> copy.
>> >
>> > Fixed.
>> >
>> >> - Robert suggested that “/yang-library/checksum” should be a
>> >>  reference. Juergen supported that comment, so I am assuming that
>> >>  that will be incorporated into the draft.
>> >
>> > Yes, fixed.
>> >
>> >> - Andy had questions around datastore set to “conventional”
>> >
>> > Fixed.
>> >
>> >>  , about origin filter limited to 1 source
>> >
>> > Fixed.
>> >
>> >>  and the behavior of with-defaults.
>> >
>> > There were no additional changes to the document from the discussion
>> > about this.
>> >
>> >>  I see some discussion around it with the authors
>> >>  agreeing that some of them need some text clarifying the
>> >>  position. Can the authors please post the suggested text/additions
>> >>  for the WG to review.
>> >> - Anything else??
>> >>
>> >> Once an updated draft has been posted, I will do a writeup on the
>> >> drafts and send it to IESG.
>> >
>> > The issues above are now addressed, in
>> > draft-ietf-netconf-nmda-netconf-03.
>> >
>> > There were no additional comments on
>> > 

Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts

[Robert Wilton]

Hi Andy,


On 07/02/2018 02:33, Andy Bierman wrote:



On Mon, Feb 5, 2018 at 1:33 PM, Mahesh Jethanandani 
> wrote:


For folks that provided comments as part of LC, please verify that
your comments have been adequately addressed by -03 version of the
draft.



Most comments have been addressed.


 The "with-defaults" parameter does not apply when interacting with an
    operational datastore.


There is no explanation of why the with-defaults parameter does not 
apply to .
This is confusing. The solution that has been a standard for years 
still applies to
all datastores, except a completely different mechanism 
(origin-filter) is used instead

for 1 datastore.

If the server code can identify a default so it can be tagged 
origin=or:default, then it can

also support with-defaults.

I prefer the sentence above be changed, so that a server MAY implement 
with-defaults
for .  If the client sends  it should be 
OK to honor it instead

of returning an error.

I have two concerns with changing this to a MAY:

(1) The most useful "with-defaults" behavior differs for  
vs the configuration datastores, but with-defaults only allows a single 
standard behavior to be specified.


E.g. for configuration datastores the most appropriate semantics (if the 
client doesn't explicitly ask for something else) is "explicit". i.e. 
you give back exactly what was put in.


But, for operational, the most appropriate semantics (if the client 
doesn't explicitly ask for something else) is something like 
"report-all", i.e. the device reports the precise current state 
including any defaults.  However, we felt that this would return too 
much unnecessary data, hence why the datastore architecture defines 
"in-use" data, allowing the server to prune out any data that is clearly 
irrelevant.


(2)  is a new datastore.  I personally don't want each 
server choosing how the data is returned, which requires that clients 
must handle all variants.  It would be better for the draft to specify 
the standard semantics to use unless a client has explicitly requested 
something else.


I'm not opposed to a "with-defaults-bis", or a new draft covering 
"with-defaults" for ", but I think that:
(i) We shouldn't delay the NMDA protocol drafts for this, this can be 
done as separate draft adding extra optional functionality.
(ii) The semantics for retrieving data from operational (or 
notifications) should be as defined by "in-use" in the NMDA 
architecture, unless a client has explicitly specified, or configured, a 
different behavior.
(iii) Probably the only existing option defined in "with-defaults" that 
makes sense for  is a variant of "trim" that is specified 
to return what is defined as returning the "in-use" values, but also 
excluding any values that match a default value specified in the schema.


Thanks,
Rob





Andy


Thanks

Mahesh Jethanandani
mjethanand...@gmail.com 

> On Feb 5, 2018, at 9:43 AM, Martin Bjorklund > wrote:
>
> Hi,
>
> Mahesh Jethanandani > wrote:
>> This closes the LC for the two NDMA drafts for NETCONF and
RESTCONF.
>>
>> As part of the LC, there were a couple of comments/questions
>> raised. In particular
>>
>> - Vladmir reported an error, which Martin said is fixed in his
local copy.
>
> Fixed.
>
>> - Robert suggested that “/yang-library/checksum” should be a
>>  reference. Juergen supported that comment, so I am assuming that
>>  that will be incorporated into the draft.
>
> Yes, fixed.
>
>> - Andy had questions around datastore set to “conventional”
>
> Fixed.
>
>>  , about origin filter limited to 1 source
>
> Fixed.
>
>>  and the behavior of with-defaults.
>
> There were no additional changes to the document from the discussion
> about this.
>
>>  I see some discussion around it with the authors
>>  agreeing that some of them need some text clarifying the
>>  position. Can the authors please post the suggested text/additions
>>  for the WG to review.
>> - Anything else??
>>
>> Once an updated draft has been posted, I will do a writeup on the
>> drafts and send it to IESG.
>
> The issues above are now addressed, in
> draft-ietf-netconf-nmda-netconf-03.
>
> There were no additional comments on
> draft-ietf-netconf-nmda-restconf-02, so I believe this version is
> ready.
>
>
> /martin
>
>
>>
>> Thanks.
>>
>>> On Jan 31, 2018, at 10:16 AM, Juergen Schoenwaelder
> wrote:
>>>
>>> On Wed, Jan 31, 2018 at 04:53:48PM +, Eric Voit (evoit) wrote:

Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts

[Andy Bierman]

On Mon, Feb 5, 2018 at 1:33 PM, Mahesh Jethanandani  wrote:

> For folks that provided comments as part of LC, please verify that your
> comments have been adequately addressed by -03 version of the draft.
>
>

Most comments have been addressed.


The "with-defaults" parameter does not apply when interacting with an

operational datastore.


There is no explanation of why the with-defaults parameter does not apply
to .
This is confusing. The solution that has been a standard for years still
applies to
all datastores, except a completely different mechanism (origin-filter) is
used instead
for 1 datastore.

If the server code can identify a default so it can be tagged
origin=or:default, then it can
also support with-defaults.

I prefer the sentence above be changed, so that a server MAY implement
with-defaults
for .  If the client sends  it should be OK to
honor it instead
of returning an error.


Andy




> Thanks
>
> Mahesh Jethanandani
> mjethanand...@gmail.com
>
> > On Feb 5, 2018, at 9:43 AM, Martin Bjorklund  wrote:
> >
> > Hi,
> >
> > Mahesh Jethanandani  wrote:
> >> This closes the LC for the two NDMA drafts for NETCONF and RESTCONF.
> >>
> >> As part of the LC, there were a couple of comments/questions
> >> raised. In particular
> >>
> >> - Vladmir reported an error, which Martin said is fixed in his local
> copy.
> >
> > Fixed.
> >
> >> - Robert suggested that “/yang-library/checksum” should be a
> >>  reference. Juergen supported that comment, so I am assuming that
> >>  that will be incorporated into the draft.
> >
> > Yes, fixed.
> >
> >> - Andy had questions around datastore set to “conventional”
> >
> > Fixed.
> >
> >>  , about origin filter limited to 1 source
> >
> > Fixed.
> >
> >>  and the behavior of with-defaults.
> >
> > There were no additional changes to the document from the discussion
> > about this.
> >
> >>  I see some discussion around it with the authors
> >>  agreeing that some of them need some text clarifying the
> >>  position. Can the authors please post the suggested text/additions
> >>  for the WG to review.
> >> - Anything else??
> >>
> >> Once an updated draft has been posted, I will do a writeup on the
> >> drafts and send it to IESG.
> >
> > The issues above are now addressed, in
> > draft-ietf-netconf-nmda-netconf-03.
> >
> > There were no additional comments on
> > draft-ietf-netconf-nmda-restconf-02, so I believe this version is
> > ready.
> >
> >
> > /martin
> >
> >
> >>
> >> Thanks.
> >>
> >>> On Jan 31, 2018, at 10:16 AM, Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de> wrote:
> >>>
> >>> On Wed, Jan 31, 2018 at 04:53:48PM +, Eric Voit (evoit) wrote:
> 
>  I do have one additional thought below on 
>  draft-ietf-netmod-revised-datastores
> section 5.3 default handling process.  See in-line...
> 
> >>>
> >>> Well, this document is with the RFC editor now. I do not think it needs
> >>> clarification. It already has text in 5.3 such as:
> >>>
> >>>  Requests to retrieve nodes from  always return the value
> >>>  in use if the node exists, regardless of any default value specified
> >>>  in the YANG module.  If no value is returned for a given node, then
> >>>  this implies that the node is not used by the device.
> >>>
> >>> /js
> >>>
>  From: Robert Wilton -X, January 31, 2018 6:31 AM
> 
> 
>  Hi Andy,
> 
>  On 31/01/2018 09:22, Andy Bierman wrote:
> 
> 
>  On Wed, Jan 31, 2018 at 12:11 AM, Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de  jacobs-university.de>>> wrote:
> > On Tue, Jan 30, 2018 at 12:35:33PM -0800, Andy Bierman wrote:
> > Hi,
> >
> > I have some questions about these drafts.
> >
> > 1) what if datastore set to "conventional"?
> >   There are many places where a datastore-ref type is used.
> >   However, "conventional" is valid for base "datastore", even though
> >   it is ambiguous as a datastore selector.
> 
>  We can add explicit text that an identity that does not resolve to a
>  datastore implemented by the server results in an invalid value error.
> 
> 
>  OK
> 
> 
> > 2) origin filter is limited to 1 source
> >  This filtering seems rather limited.  A client must retrieve
> >  and check
> >   all the values in use, then make repeated requests for each source
> as a
> > different
> >leaf
> 
>  If the client does , then it has all origin information
>  and it can filter locally. That said, we could make origin-filter a
>  leaf-list which is logically ORed so that one can retrieve
>  origin-filter=or:system or origin-filter=or:learned in one request.
> 
> 
>  OK
> 
> > 3) with-defaults broken
> >   The operational datastore does not 

Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts

[Robert Wilton]

Yes, my comment on the YANG library checksum reference has been 
adequately addressed by the -03 version of the draft.


Thanks,
Rob


On 05/02/2018 21:33, Mahesh Jethanandani wrote:

For folks that provided comments as part of LC, please verify that your 
comments have been adequately addressed by -03 version of the draft.

Thanks

Mahesh Jethanandani
mjethanand...@gmail.com


On Feb 5, 2018, at 9:43 AM, Martin Bjorklund  wrote:

Hi,

Mahesh Jethanandani  wrote:

This closes the LC for the two NDMA drafts for NETCONF and RESTCONF.

As part of the LC, there were a couple of comments/questions
raised. In particular

- Vladmir reported an error, which Martin said is fixed in his local copy.

Fixed.


- Robert suggested that “/yang-library/checksum” should be a
  reference. Juergen supported that comment, so I am assuming that
  that will be incorporated into the draft.

Yes, fixed.


- Andy had questions around datastore set to “conventional”

Fixed.


  , about origin filter limited to 1 source

Fixed.


  and the behavior of with-defaults.

There were no additional changes to the document from the discussion
about this.


  I see some discussion around it with the authors
  agreeing that some of them need some text clarifying the
  position. Can the authors please post the suggested text/additions
  for the WG to review.
- Anything else??

Once an updated draft has been posted, I will do a writeup on the
drafts and send it to IESG.

The issues above are now addressed, in
draft-ietf-netconf-nmda-netconf-03.

There were no additional comments on
draft-ietf-netconf-nmda-restconf-02, so I believe this version is
ready.


/martin



Thanks.


On Jan 31, 2018, at 10:16 AM, Juergen Schoenwaelder 
 wrote:

On Wed, Jan 31, 2018 at 04:53:48PM +, Eric Voit (evoit) wrote:

I do have one additional thought below on draft-ietf-netmod-revised-datastores 
section 5.3 default handling process.  See in-line...


Well, this document is with the RFC editor now. I do not think it needs
clarification. It already has text in 5.3 such as:

  Requests to retrieve nodes from  always return the value
  in use if the node exists, regardless of any default value specified
  in the YANG module.  If no value is returned for a given node, then
  this implies that the node is not used by the device.

/js


From: Robert Wilton -X, January 31, 2018 6:31 AM


Hi Andy,

On 31/01/2018 09:22, Andy Bierman wrote:


On Wed, Jan 31, 2018 at 12:11 AM, Juergen Schoenwaelder >> wrote:

On Tue, Jan 30, 2018 at 12:35:33PM -0800, Andy Bierman wrote:
Hi,

I have some questions about these drafts.

1) what if datastore set to "conventional"?
   There are many places where a datastore-ref type is used.
   However, "conventional" is valid for base "datastore", even though
   it is ambiguous as a datastore selector.

We can add explicit text that an identity that does not resolve to a
datastore implemented by the server results in an invalid value error.


OK



2) origin filter is limited to 1 source
  This filtering seems rather limited.  A client must retrieve
 and check
   all the values in use, then make repeated requests for each source as a
different
leaf

If the client does , then it has all origin information
and it can filter locally. That said, we could make origin-filter a
leaf-list which is logically ORed so that one can retrieve
origin-filter=or:system or origin-filter=or:learned in one request.


OK


3) with-defaults broken
   The operational datastore does not support with-defaults.
Instead, the client must use origin-filter=or:default or with-origin
and check all the origin attributes.  Since a client needs to use
with-defaults for other datastores, this special handling of

seems unhelpful.

I think the with-defaults semantics for conventional configuration
datastores are much more complicated than necessary for the
operational state datastore. Note that that the operational state
datastore reports in-use values not really defaults:

foo

This reports that the value 'foo' is in use and that it originates
from a default value. Note that this could also be

foo

in case the intended configuration datastore configured the value
'foo' (despite this value matching the default). The with-defaults
solution is pretty complex because it tries to handle how different
systems deal with configuration defaults. The idea is to not carry
this complexity over to in-use values in the operational state
datastore.


Before NMDA, the client could decide if it wanted to retrieve default nodes or 
not.
This client-choice has been removed from NMDA, which is a problem.
We tried to reach a sensible compromise on the data returned from operational 
(defined in section 5.3 of the NMDA 

Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts

[Mahesh Jethanandani]

For folks that provided comments as part of LC, please verify that your 
comments have been adequately addressed by -03 version of the draft. 

Thanks 

Mahesh Jethanandani 
mjethanand...@gmail.com

> On Feb 5, 2018, at 9:43 AM, Martin Bjorklund  wrote:
> 
> Hi,
> 
> Mahesh Jethanandani  wrote:
>> This closes the LC for the two NDMA drafts for NETCONF and RESTCONF.
>> 
>> As part of the LC, there were a couple of comments/questions
>> raised. In particular 
>> 
>> - Vladmir reported an error, which Martin said is fixed in his local copy.
> 
> Fixed.
> 
>> - Robert suggested that “/yang-library/checksum” should be a
>>  reference. Juergen supported that comment, so I am assuming that
>>  that will be incorporated into the draft.
> 
> Yes, fixed.
> 
>> - Andy had questions around datastore set to “conventional”
> 
> Fixed.
> 
>>  , about origin filter limited to 1 source
> 
> Fixed.
> 
>>  and the behavior of with-defaults.
> 
> There were no additional changes to the document from the discussion
> about this.
> 
>>  I see some discussion around it with the authors
>>  agreeing that some of them need some text clarifying the
>>  position. Can the authors please post the suggested text/additions
>>  for the WG to review. 
>> - Anything else??
>> 
>> Once an updated draft has been posted, I will do a writeup on the
>> drafts and send it to IESG.  
> 
> The issues above are now addressed, in
> draft-ietf-netconf-nmda-netconf-03.
> 
> There were no additional comments on
> draft-ietf-netconf-nmda-restconf-02, so I believe this version is
> ready.
> 
> 
> /martin
> 
> 
>> 
>> Thanks.
>> 
>>> On Jan 31, 2018, at 10:16 AM, Juergen Schoenwaelder 
>>>  wrote:
>>> 
>>> On Wed, Jan 31, 2018 at 04:53:48PM +, Eric Voit (evoit) wrote:
 
 I do have one additional thought below on 
 draft-ietf-netmod-revised-datastores section 5.3 default handling process. 
  See in-line...
 
>>> 
>>> Well, this document is with the RFC editor now. I do not think it needs
>>> clarification. It already has text in 5.3 such as:
>>> 
>>>  Requests to retrieve nodes from  always return the value
>>>  in use if the node exists, regardless of any default value specified
>>>  in the YANG module.  If no value is returned for a given node, then
>>>  this implies that the node is not used by the device.
>>> 
>>> /js
>>> 
 From: Robert Wilton -X, January 31, 2018 6:31 AM
 
 
 Hi Andy,
 
 On 31/01/2018 09:22, Andy Bierman wrote:
 
 
 On Wed, Jan 31, 2018 at 12:11 AM, Juergen Schoenwaelder 
 >> wrote:
> On Tue, Jan 30, 2018 at 12:35:33PM -0800, Andy Bierman wrote:
> Hi,
> 
> I have some questions about these drafts.
> 
> 1) what if datastore set to "conventional"?
>   There are many places where a datastore-ref type is used.
>   However, "conventional" is valid for base "datastore", even though
>   it is ambiguous as a datastore selector.
 
 We can add explicit text that an identity that does not resolve to a
 datastore implemented by the server results in an invalid value error.
 
 
 OK
 
 
> 2) origin filter is limited to 1 source
>  This filtering seems rather limited.  A client must retrieve
>  and check
>   all the values in use, then make repeated requests for each source as a
> different
>leaf
 
 If the client does , then it has all origin information
 and it can filter locally. That said, we could make origin-filter a
 leaf-list which is logically ORed so that one can retrieve
 origin-filter=or:system or origin-filter=or:learned in one request.
 
 
 OK
 
> 3) with-defaults broken
>   The operational datastore does not support with-defaults.
>Instead, the client must use origin-filter=or:default or with-origin
>and check all the origin attributes.  Since a client needs to use
>with-defaults for other datastores, this special handling of
> 
>seems unhelpful.
 
 I think the with-defaults semantics for conventional configuration
 datastores are much more complicated than necessary for the
 operational state datastore. Note that that the operational state
 datastore reports in-use values not really defaults:
 
 foo
 
 This reports that the value 'foo' is in use and that it originates
 from a default value. Note that this could also be
 
 foo
 
 in case the intended configuration datastore configured the value
 'foo' (despite this value matching the default). The with-defaults
 solution is pretty complex because it tries to handle how different
 systems deal with configuration defaults. 

Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts

[Martin Bjorklund]

Hi,

Mahesh Jethanandani  wrote:
> This closes the LC for the two NDMA drafts for NETCONF and RESTCONF.
> 
> As part of the LC, there were a couple of comments/questions
> raised. In particular 
> 
> - Vladmir reported an error, which Martin said is fixed in his local copy.

Fixed.

> - Robert suggested that “/yang-library/checksum” should be a
>   reference. Juergen supported that comment, so I am assuming that
>   that will be incorporated into the draft.

Yes, fixed.

> - Andy had questions around datastore set to “conventional”

Fixed.

>   , about origin filter limited to 1 source

Fixed.

>   and the behavior of with-defaults.

There were no additional changes to the document from the discussion
about this.

>   I see some discussion around it with the authors
>   agreeing that some of them need some text clarifying the
>   position. Can the authors please post the suggested text/additions
>   for the WG to review. 
> - Anything else??
> 
> Once an updated draft has been posted, I will do a writeup on the
> drafts and send it to IESG.  

The issues above are now addressed, in
draft-ietf-netconf-nmda-netconf-03.

There were no additional comments on
draft-ietf-netconf-nmda-restconf-02, so I believe this version is
ready.


/martin


> 
> Thanks.
> 
> > On Jan 31, 2018, at 10:16 AM, Juergen Schoenwaelder 
> >  wrote:
> > 
> > On Wed, Jan 31, 2018 at 04:53:48PM +, Eric Voit (evoit) wrote:
> >> 
> >> I do have one additional thought below on 
> >> draft-ietf-netmod-revised-datastores section 5.3 default handling process. 
> >>  See in-line...
> >> 
> > 
> > Well, this document is with the RFC editor now. I do not think it needs
> > clarification. It already has text in 5.3 such as:
> > 
> >   Requests to retrieve nodes from  always return the value
> >   in use if the node exists, regardless of any default value specified
> >   in the YANG module.  If no value is returned for a given node, then
> >   this implies that the node is not used by the device.
> > 
> > /js
> > 
> >> From: Robert Wilton -X, January 31, 2018 6:31 AM
> >> 
> >> 
> >> Hi Andy,
> >> 
> >> On 31/01/2018 09:22, Andy Bierman wrote:
> >> 
> >> 
> >> On Wed, Jan 31, 2018 at 12:11 AM, Juergen Schoenwaelder 
> >>  >>  >>  >> wrote:
> >> On Tue, Jan 30, 2018 at 12:35:33PM -0800, Andy Bierman wrote:
> >>> Hi,
> >>> 
> >>> I have some questions about these drafts.
> >>> 
> >>> 1) what if datastore set to "conventional"?
> >>>There are many places where a datastore-ref type is used.
> >>>However, "conventional" is valid for base "datastore", even though
> >>>it is ambiguous as a datastore selector.
> >> 
> >> We can add explicit text that an identity that does not resolve to a
> >> datastore implemented by the server results in an invalid value error.
> >> 
> >> 
> >> OK
> >> 
> >> 
> >>> 2) origin filter is limited to 1 source
> >>>   This filtering seems rather limited.  A client must retrieve
> >>>  and check
> >>>all the values in use, then make repeated requests for each source as a
> >>> different
> >>> leaf
> >> 
> >> If the client does , then it has all origin information
> >> and it can filter locally. That said, we could make origin-filter a
> >> leaf-list which is logically ORed so that one can retrieve
> >> origin-filter=or:system or origin-filter=or:learned in one request.
> >> 
> >> 
> >> OK
> >> 
> >>> 3) with-defaults broken
> >>>The operational datastore does not support with-defaults.
> >>> Instead, the client must use origin-filter=or:default or with-origin
> >>> and check all the origin attributes.  Since a client needs to use
> >>> with-defaults for other datastores, this special handling of
> >>> 
> >>> seems unhelpful.
> >> 
> >> I think the with-defaults semantics for conventional configuration
> >> datastores are much more complicated than necessary for the
> >> operational state datastore. Note that that the operational state
> >> datastore reports in-use values not really defaults:
> >> 
> >>  foo
> >> 
> >> This reports that the value 'foo' is in use and that it originates
> >> from a default value. Note that this could also be
> >> 
> >>  foo
> >> 
> >> in case the intended configuration datastore configured the value
> >> 'foo' (despite this value matching the default). The with-defaults
> >> solution is pretty complex because it tries to handle how different
> >> systems deal with configuration defaults. The idea is to not carry
> >> this complexity over to in-use values in the operational state
> >> datastore.
> >> 
> >> 
> >> Before NMDA, the client could decide if it wanted to retrieve default 
> >> nodes or not.
> >> This client-choice has been removed from NMDA, which is a problem.
> >> We tried to reach a sensible compromise on 

Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts

[Mahesh Jethanandani]

This closes the LC for the two NDMA drafts for NETCONF and RESTCONF.

As part of the LC, there were a couple of comments/questions raised. In 
particular

- Vladmir reported an error, which Martin said is fixed in his local copy.
- Robert suggested that “/yang-library/checksum” should be a reference. Juergen 
supported that comment, so I am assuming that that will be incorporated into 
the draft.
- Andy had questions around datastore set to “conventional”, about origin 
filter limited to 1 source and the behavior of with-defaults. I see some 
discussion around it with the authors agreeing that some of them need some text 
clarifying the position. Can the authors please post the suggested 
text/additions for the WG to review.
- Anything else??

Once an updated draft has been posted, I will do a writeup on the drafts and 
send it to IESG. 

Thanks.

> On Jan 31, 2018, at 10:16 AM, Juergen Schoenwaelder 
>  wrote:
> 
> On Wed, Jan 31, 2018 at 04:53:48PM +, Eric Voit (evoit) wrote:
>> 
>> I do have one additional thought below on 
>> draft-ietf-netmod-revised-datastores section 5.3 default handling process.  
>> See in-line...
>> 
> 
> Well, this document is with the RFC editor now. I do not think it needs
> clarification. It already has text in 5.3 such as:
> 
>   Requests to retrieve nodes from  always return the value
>   in use if the node exists, regardless of any default value specified
>   in the YANG module.  If no value is returned for a given node, then
>   this implies that the node is not used by the device.
> 
> /js
> 
>> From: Robert Wilton -X, January 31, 2018 6:31 AM
>> 
>> 
>> Hi Andy,
>> 
>> On 31/01/2018 09:22, Andy Bierman wrote:
>> 
>> 
>> On Wed, Jan 31, 2018 at 12:11 AM, Juergen Schoenwaelder 
>> > >  >> wrote:
>> On Tue, Jan 30, 2018 at 12:35:33PM -0800, Andy Bierman wrote:
>>> Hi,
>>> 
>>> I have some questions about these drafts.
>>> 
>>> 1) what if datastore set to "conventional"?
>>>There are many places where a datastore-ref type is used.
>>>However, "conventional" is valid for base "datastore", even though
>>>it is ambiguous as a datastore selector.
>> 
>> We can add explicit text that an identity that does not resolve to a
>> datastore implemented by the server results in an invalid value error.
>> 
>> 
>> OK
>> 
>> 
>>> 2) origin filter is limited to 1 source
>>>   This filtering seems rather limited.  A client must retrieve
>>>  and check
>>>all the values in use, then make repeated requests for each source as a
>>> different
>>> leaf
>> 
>> If the client does , then it has all origin information
>> and it can filter locally. That said, we could make origin-filter a
>> leaf-list which is logically ORed so that one can retrieve
>> origin-filter=or:system or origin-filter=or:learned in one request.
>> 
>> 
>> OK
>> 
>>> 3) with-defaults broken
>>>The operational datastore does not support with-defaults.
>>> Instead, the client must use origin-filter=or:default or with-origin
>>> and check all the origin attributes.  Since a client needs to use
>>> with-defaults for other datastores, this special handling of
>>> 
>>> seems unhelpful.
>> 
>> I think the with-defaults semantics for conventional configuration
>> datastores are much more complicated than necessary for the
>> operational state datastore. Note that that the operational state
>> datastore reports in-use values not really defaults:
>> 
>>  foo
>> 
>> This reports that the value 'foo' is in use and that it originates
>> from a default value. Note that this could also be
>> 
>>  foo
>> 
>> in case the intended configuration datastore configured the value
>> 'foo' (despite this value matching the default). The with-defaults
>> solution is pretty complex because it tries to handle how different
>> systems deal with configuration defaults. The idea is to not carry
>> this complexity over to in-use values in the operational state
>> datastore.
>> 
>> 
>> Before NMDA, the client could decide if it wanted to retrieve default nodes 
>> or not.
>> This client-choice has been removed from NMDA, which is a problem.
>> We tried to reach a sensible compromise on the data returned from 
>> operational (defined in section 5.3 of the NMDA architecture):
>> - it should return explicit values for everything that is affecting the 
>> actual running state of the device (regardless of whether the operational 
>> value matches a schema default value).
>> - it does not need to, and should not, return operational values for stuff 
>> that isn't actually in use, i.e. don't return needless and unwanted data.
>> 
>> In particular, if no value is returned from a particular data node in 
>>  then, barring mgmt protocol errors, a client can assume that 
>> any functionality associated with that 

Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts

[Eric Voit (evoit)]

From: Robert Wilton, January 31, 2018 12:24 PM

Hi Eric,

On 31/01/2018 16:53, Eric Voit (evoit) wrote:

I have read and support these two drafts going forward.



I do have one additional thought below on draft-ietf-netmod-revised-datastores 
section 5.3 default handling process.  See in-line...


From: Robert Wilton -X, January 31, 2018 6:31 AM



Hi Andy,

On 31/01/2018 09:22, Andy Bierman wrote:


On Wed, Jan 31, 2018 at 12:11 AM, Juergen Schoenwaelder 
>
 wrote:
On Tue, Jan 30, 2018 at 12:35:33PM -0800, Andy Bierman wrote:
> Hi,
>
> I have some questions about these drafts.
>
> 1) what if datastore set to "conventional"?
> There are many places where a datastore-ref type is used.
> However, "conventional" is valid for base "datastore", even though
> it is ambiguous as a datastore selector.

We can add explicit text that an identity that does not resolve to a
datastore implemented by the server results in an invalid value error.


OK


> 2) origin filter is limited to 1 source
>This filtering seems rather limited.  A client must retrieve
>  and check
> all the values in use, then make repeated requests for each source as a
> different
>  leaf

If the client does , then it has all origin information
and it can filter locally. That said, we could make origin-filter a
leaf-list which is logically ORed so that one can retrieve
origin-filter=or:system or origin-filter=or:learned in one request.


OK

> 3) with-defaults broken
> The operational datastore does not support with-defaults.
>  Instead, the client must use origin-filter=or:default or with-origin
>  and check all the origin attributes.  Since a client needs to use
>  with-defaults for other datastores, this special handling of
> 
>  seems unhelpful.

I think the with-defaults semantics for conventional configuration
datastores are much more complicated than necessary for the
operational state datastore. Note that that the operational state
datastore reports in-use values not really defaults:

  foo

This reports that the value 'foo' is in use and that it originates
from a default value. Note that this could also be

  foo

in case the intended configuration datastore configured the value
'foo' (despite this value matching the default). The with-defaults
solution is pretty complex because it tries to handle how different
systems deal with configuration defaults. The idea is to not carry
this complexity over to in-use values in the operational state
datastore.


Before NMDA, the client could decide if it wanted to retrieve default nodes or 
not.
This client-choice has been removed from NMDA, which is a problem.
We tried to reach a sensible compromise on the data returned from operational 
(defined in section 5.3 of the NMDA architecture):
 - it should return explicit values for everything that is affecting the actual 
running state of the device (regardless of whether the operational value 
matches a schema default value).
 - it does not need to, and should not, return operational values for stuff 
that isn't actually in use, i.e. don't return needless and unwanted data.

In particular, if no value is returned from a particular data node in 
 then, barring mgmt protocol errors, a client can assume that any 
functionality associated with that data node is off (i.e. not in use).

Some examples to illustrate the behavior:

(i) If a protocol, e.g. OSPF,  is not enabled/running then  does 
not need to return any data for it.  It would be reasonable to return a flag to 
indicate that OSPF is not enabled/running.

(ii) If you have some funky widget on an interface that defaults to being off 
and isn't being used then  don't need to return any data for it.

(iii) But, if you have some funky widget on an interface that defaults to being 
on, then the server should return data for it.  If it is actually enabled, then 
it would indicate that it is on and return any associated values with its 
operational state, or if it is disabled then it should explicitly report that 
it is off.

(iv) I would regard that all applied configuration is "in use" by the system, 
even if it matches the default value, and hence it should be reported.


This behavior for  is obviously slightly different from the 
existing with-default handling that is supported for configuration datastores.  
As I recall, there were a couple of reasons that we decided to have a different 
behavior for :
(a) to have consistent semantics for all servers, rather than different servers 
supporting different with-defaults behaviors (which makes life harder for 
clients because they must cope with all variants).
(b) to remove any potential ambiguity if data isn't returned.  I.e. with the 
existing with-defaults semantics it is not clear to me that servers will always 
return an explicit value to indicate that a particular widget is off if the 
schema defines that the default it 

Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts

[Juergen Schoenwaelder]

On Wed, Jan 31, 2018 at 04:53:48PM +, Eric Voit (evoit) wrote:
> 
> I do have one additional thought below on 
> draft-ietf-netmod-revised-datastores section 5.3 default handling process.  
> See in-line...
>

Well, this document is with the RFC editor now. I do not think it needs
clarification. It already has text in 5.3 such as:

   Requests to retrieve nodes from  always return the value
   in use if the node exists, regardless of any default value specified
   in the YANG module.  If no value is returned for a given node, then
   this implies that the node is not used by the device.

/js
 
> From: Robert Wilton -X, January 31, 2018 6:31 AM
> 
> 
> Hi Andy,
> 
> On 31/01/2018 09:22, Andy Bierman wrote:
> 
> 
> On Wed, Jan 31, 2018 at 12:11 AM, Juergen Schoenwaelder 
> >
>  wrote:
> On Tue, Jan 30, 2018 at 12:35:33PM -0800, Andy Bierman wrote:
> > Hi,
> >
> > I have some questions about these drafts.
> >
> > 1) what if datastore set to "conventional"?
> > There are many places where a datastore-ref type is used.
> > However, "conventional" is valid for base "datastore", even though
> > it is ambiguous as a datastore selector.
> 
> We can add explicit text that an identity that does not resolve to a
> datastore implemented by the server results in an invalid value error.
> 
> 
> OK
> 
> 
> > 2) origin filter is limited to 1 source
> >This filtering seems rather limited.  A client must retrieve
> >  and check
> > all the values in use, then make repeated requests for each source as a
> > different
> >  leaf
> 
> If the client does , then it has all origin information
> and it can filter locally. That said, we could make origin-filter a
> leaf-list which is logically ORed so that one can retrieve
> origin-filter=or:system or origin-filter=or:learned in one request.
> 
> 
> OK
> 
> > 3) with-defaults broken
> > The operational datastore does not support with-defaults.
> >  Instead, the client must use origin-filter=or:default or with-origin
> >  and check all the origin attributes.  Since a client needs to use
> >  with-defaults for other datastores, this special handling of
> > 
> >  seems unhelpful.
> 
> I think the with-defaults semantics for conventional configuration
> datastores are much more complicated than necessary for the
> operational state datastore. Note that that the operational state
> datastore reports in-use values not really defaults:
> 
>   foo
> 
> This reports that the value 'foo' is in use and that it originates
> from a default value. Note that this could also be
> 
>   foo
> 
> in case the intended configuration datastore configured the value
> 'foo' (despite this value matching the default). The with-defaults
> solution is pretty complex because it tries to handle how different
> systems deal with configuration defaults. The idea is to not carry
> this complexity over to in-use values in the operational state
> datastore.
> 
> 
> Before NMDA, the client could decide if it wanted to retrieve default nodes 
> or not.
> This client-choice has been removed from NMDA, which is a problem.
> We tried to reach a sensible compromise on the data returned from operational 
> (defined in section 5.3 of the NMDA architecture):
>  - it should return explicit values for everything that is affecting the 
> actual running state of the device (regardless of whether the operational 
> value matches a schema default value).
>  - it does not need to, and should not, return operational values for stuff 
> that isn't actually in use, i.e. don't return needless and unwanted data.
> 
> In particular, if no value is returned from a particular data node in 
>  then, barring mgmt protocol errors, a client can assume that 
> any functionality associated with that data node is off (i.e. not in use).
> 
> Some examples to illustrate the behavior:
> 
> (i) If a protocol, e.g. OSPF,  is not enabled/running then  does 
> not need to return any data for it.  It would be reasonable to return a flag 
> to indicate that OSPF is not enabled/running.
> 
> (ii) If you have some funky widget on an interface that defaults to being off 
> and isn't being used then  don't need to return any data for it.
> 
> (iii) But, if you have some funky widget on an interface that defaults to 
> being on, then the server should return data for it.  If it is actually 
> enabled, then it would indicate that it is on and return any associated 
> values with its operational state, or if it is disabled then it should 
> explicitly report that it is off.
> 
> (iv) I would regard that all applied configuration is "in use" by the system, 
> even if it matches the default value, and hence it should be reported.
> 
> 
> This behavior for  is obviously slightly different from the 
> existing with-default handling that is supported for configuration 
> datastores.  As I recall, there were a couple of reasons that we 

Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts

[Robert Wilton]

Hi Eric,


On 31/01/2018 16:53, Eric Voit (evoit) wrote:


I have read and support these two drafts going forward.

I do have one additional thought below on 
draft-ietf-netmod-revised-datastores section 5.3 default handling 
process.  See in-line...


*From:*Robert Wilton -X, January 31, 2018 6:31 AM

Hi Andy,

On 31/01/2018 09:22, Andy Bierman wrote:

On Wed, Jan 31, 2018 at 12:11 AM, Juergen Schoenwaelder
> wrote:

On Tue, Jan 30, 2018 at 12:35:33PM -0800, Andy Bierman wrote:
> Hi,
>
> I have some questions about these drafts.
>
> 1) what if datastore set to "conventional"?
>     There are many places where a datastore-ref type is used.
>     However, "conventional" is valid for base "datastore",
even though
>     it is ambiguous as a datastore selector.

We can add explicit text that an identity that does not
resolve to a
datastore implemented by the server results in an invalid
value error.

OK

> 2) origin filter is limited to 1 source
>    This filtering seems rather limited.  A client must retrieve
>  and check
>     all the values in use, then make repeated requests for
each source as a
> different
>      leaf

If the client does , then it has all origin
information
and it can filter locally. That said, we could make
origin-filter a
leaf-list which is logically ORed so that one can retrieve
origin-filter=or:system or origin-filter=or:learned in one
request.

OK

> 3) with-defaults broken
>     The operational datastore does not support with-defaults.
>      Instead, the client must use origin-filter=or:default
or with-origin
>      and check all the origin attributes. Since a client
needs to use
>      with-defaults for other datastores, this special
handling of
> 
>      seems unhelpful.

I think the with-defaults semantics for conventional configuration
datastores are much more complicated than necessary for the
operational state datastore. Note that that the operational state
datastore reports in-use values not really defaults:

  foo

This reports that the value 'foo' is in use and that it originates
from a default value. Note that this could also be

  foo

in case the intended configuration datastore configured the value
'foo' (despite this value matching the default). The with-defaults
solution is pretty complex because it tries to handle how
different
systems deal with configuration defaults. The idea is to not carry
this complexity over to in-use values in the operational state
datastore.

Before NMDA, the client could decide if it wanted to retrieve
default nodes or not.

This client-choice has been removed from NMDA, which is a problem.

We tried to reach a sensible compromise on the data returned from 
operational (defined in section 5.3 of the NMDA architecture):
 - it should return explicit values for everything that is affecting 
the actual running state of the device (regardless of whether the 
operational value matches a schema default value).
 - it does not need to, and should not, return operational values for 
stuff that isn't actually in use, i.e. don't return needless and 
unwanted data.


In particular, if no value is returned from a particular data node in 
 then, barring mgmt protocol errors, a client can assume 
that any functionality associated with that data node is off (i.e. not 
in use).


Some examples to illustrate the behavior:

(i) If a protocol, e.g. OSPF,  is not enabled/running then 
 does not need to return any data for it.  It would be 
reasonable to return a flag to indicate that OSPF is not enabled/running.


(ii) If you have some funky widget on an interface that defaults to 
being off and isn't being used then  don't need to return 
any data for it.


(iii) But, if you have some funky widget on an interface that defaults 
to being on, then the server should return data for it.  If it is 
actually enabled, then it would indicate that it is on and return any 
associated values with its operational state, or if it is disabled 
then it should explicitly report that it is off.


(iv) I would regard that all applied configuration is "in use" by the 
system, even if it matches the default value, and hence it should be 
reported.



This behavior for  is obviously slightly different from 
the existing with-default handling that is supported for configuration 
datastores.  As I recall, there were a couple of reasons that we 
decided to have a different behavior for :
(a) to have consistent semantics for all servers, rather than 

Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts

[Eric Voit (evoit)]

I have read and support these two drafts going forward.



I do have one additional thought below on draft-ietf-netmod-revised-datastores 
section 5.3 default handling process.  See in-line...


From: Robert Wilton -X, January 31, 2018 6:31 AM


Hi Andy,

On 31/01/2018 09:22, Andy Bierman wrote:


On Wed, Jan 31, 2018 at 12:11 AM, Juergen Schoenwaelder 
>
 wrote:
On Tue, Jan 30, 2018 at 12:35:33PM -0800, Andy Bierman wrote:
> Hi,
>
> I have some questions about these drafts.
>
> 1) what if datastore set to "conventional"?
> There are many places where a datastore-ref type is used.
> However, "conventional" is valid for base "datastore", even though
> it is ambiguous as a datastore selector.

We can add explicit text that an identity that does not resolve to a
datastore implemented by the server results in an invalid value error.


OK


> 2) origin filter is limited to 1 source
>This filtering seems rather limited.  A client must retrieve
>  and check
> all the values in use, then make repeated requests for each source as a
> different
>  leaf

If the client does , then it has all origin information
and it can filter locally. That said, we could make origin-filter a
leaf-list which is logically ORed so that one can retrieve
origin-filter=or:system or origin-filter=or:learned in one request.


OK

> 3) with-defaults broken
> The operational datastore does not support with-defaults.
>  Instead, the client must use origin-filter=or:default or with-origin
>  and check all the origin attributes.  Since a client needs to use
>  with-defaults for other datastores, this special handling of
> 
>  seems unhelpful.

I think the with-defaults semantics for conventional configuration
datastores are much more complicated than necessary for the
operational state datastore. Note that that the operational state
datastore reports in-use values not really defaults:

  foo

This reports that the value 'foo' is in use and that it originates
from a default value. Note that this could also be

  foo

in case the intended configuration datastore configured the value
'foo' (despite this value matching the default). The with-defaults
solution is pretty complex because it tries to handle how different
systems deal with configuration defaults. The idea is to not carry
this complexity over to in-use values in the operational state
datastore.


Before NMDA, the client could decide if it wanted to retrieve default nodes or 
not.
This client-choice has been removed from NMDA, which is a problem.
We tried to reach a sensible compromise on the data returned from operational 
(defined in section 5.3 of the NMDA architecture):
 - it should return explicit values for everything that is affecting the actual 
running state of the device (regardless of whether the operational value 
matches a schema default value).
 - it does not need to, and should not, return operational values for stuff 
that isn't actually in use, i.e. don't return needless and unwanted data.

In particular, if no value is returned from a particular data node in 
 then, barring mgmt protocol errors, a client can assume that any 
functionality associated with that data node is off (i.e. not in use).

Some examples to illustrate the behavior:

(i) If a protocol, e.g. OSPF,  is not enabled/running then  does 
not need to return any data for it.  It would be reasonable to return a flag to 
indicate that OSPF is not enabled/running.

(ii) If you have some funky widget on an interface that defaults to being off 
and isn't being used then  don't need to return any data for it.

(iii) But, if you have some funky widget on an interface that defaults to being 
on, then the server should return data for it.  If it is actually enabled, then 
it would indicate that it is on and return any associated values with its 
operational state, or if it is disabled then it should explicitly report that 
it is off.

(iv) I would regard that all applied configuration is "in use" by the system, 
even if it matches the default value, and hence it should be reported.


This behavior for  is obviously slightly different from the 
existing with-default handling that is supported for configuration datastores.  
As I recall, there were a couple of reasons that we decided to have a different 
behavior for :
(a) to have consistent semantics for all servers, rather than different servers 
supporting different with-defaults behaviors (which makes life harder for 
clients because they must cope with all variants).
(b) to remove any potential ambiguity if data isn't returned.  I.e. with the 
existing with-defaults semantics it is not clear to me that servers will always 
return an explicit value to indicate that a particular widget is off if the 
schema defines that the default it that is enabled.  If the server doesn't 
support a given widget at all, it is quite plausible that it will 

Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts

[Ladislav Lhotka]

Hi,

I read the draft draft-ietf-netconf-nmda-restconf-02, I believe it is
important and ready to be published. We plan an implementation.

Thanks for this work,

Lada

Mahesh Jethanandani  writes:

> Authors and WG,
>
> We have not received any explicit support for this LC on this email thread. 
> If you believe these drafts are important and should proceed, please state 
> your support by responding to this email thread.
>
> Thanks.
>
>> On Jan 17, 2018, at 10:39 AM, Mahesh Jethanandani  
>> wrote:
>> 
>> The authors of draft-ietf-netconf-nmda-netconf and 
>> draft-ietf-netconf-nmda-restconf have posted updates to their drafts, and 
>> believe that the documents are ready for LC.
>> 
>> This starts a 2 week LC on the two drafts that will end on January 31. 
>> Please send your comments on this thread. Comments like “I have reviewed the 
>> documents and believe they are ready for publication”, or “I have concerns 
>> about the document because …” are welcome and useful for the authors.
>> 
>> Authors please indicate whether you are aware of any IPR for either of the 
>> drafts.
>> 
>> Thanks.
>> 
>> Mahesh & Kent
>> 
>
> Mahesh & Kent
>
> ___
> Netconf mailing list
> netc...@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf

-- 
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] [Netconf] LC of NDMA NETCONF/RESTCONF drafts

[Robert Wilton]

Hi Andy,


On 31/01/2018 09:22, Andy Bierman wrote:



On Wed, Jan 31, 2018 at 12:11 AM, Juergen Schoenwaelder 
> wrote:


On Tue, Jan 30, 2018 at 12:35:33PM -0800, Andy Bierman wrote:
> Hi,
>
> I have some questions about these drafts.
>
> 1) what if datastore set to "conventional"?
>     There are many places where a datastore-ref type is used.
>     However, "conventional" is valid for base "datastore", even
though
>     it is ambiguous as a datastore selector.

We can add explicit text that an identity that does not resolve to a
datastore implemented by the server results in an invalid value error.



OK

> 2) origin filter is limited to 1 source
>    This filtering seems rather limited.  A client must retrieve
>  and check
>     all the values in use, then make repeated requests for each
source as a
> different
>      leaf

If the client does , then it has all origin information
and it can filter locally. That said, we could make origin-filter a
leaf-list which is logically ORed so that one can retrieve
origin-filter=or:system or origin-filter=or:learned in one request.



OK

> 3) with-defaults broken
>     The operational datastore does not support with-defaults.
>      Instead, the client must use origin-filter=or:default or
with-origin
>      and check all the origin attributes.  Since a client needs
to use
>      with-defaults for other datastores, this special handling of
> 
>      seems unhelpful.

I think the with-defaults semantics for conventional configuration
datastores are much more complicated than necessary for the
operational state datastore. Note that that the operational state
datastore reports in-use values not really defaults:

  foo

This reports that the value 'foo' is in use and that it originates
from a default value. Note that this could also be

  foo

in case the intended configuration datastore configured the value
'foo' (despite this value matching the default). The with-defaults
solution is pretty complex because it tries to handle how different
systems deal with configuration defaults. The idea is to not carry
this complexity over to in-use values in the operational state
datastore.



Before NMDA, the client could decide if it wanted to retrieve default 
nodes or not.

This client-choice has been removed from NMDA, which is a problem.
We tried to reach a sensible compromise on the data returned from 
operational (defined in section 5.3 of the NMDA architecture):
 - it should return explicit values for everything that is affecting 
the actual running state of the device (regardless of whether the 
operational value matches a schema default value).
 - it does not need to, and should not, return operational values for 
stuff that isn't actually in use, i.e. don't return needless and 
unwanted data.


In particular, if no value is returned from a particular data node in 
 then, barring mgmt protocol errors, a client can assume 
that any functionality associated with that data node is off (i.e. not 
in use).


Some examples to illustrate the behavior:

(i) If a protocol, e.g. OSPF,  is not enabled/running then  
does not need to return any data for it.  It would be reasonable to 
return a flag to indicate that OSPF is not enabled/running.


(ii) If you have some funky widget on an interface that defaults to 
being off and isn't being used then  don't need to return 
any data for it.


(iii) But, if you have some funky widget on an interface that defaults 
to being on, then the server should return data for it.  If it is 
actually enabled, then it would indicate that it is on and return any 
associated values with its operational state, or if it is disabled then 
it should explicitly report that it is off.


(iv) I would regard that all applied configuration is "in use" by the 
system, even if it matches the default value, and hence it should be 
reported.



This behavior for  is obviously slightly different from the 
existing with-default handling that is supported for configuration 
datastores.  As I recall, there were a couple of reasons that we decided 
to have a different behavior for :
(a) to have consistent semantics for all servers, rather than different 
servers supporting different with-defaults behaviors (which makes life 
harder for clients because they must cope with all variants).
(b) to remove any potential ambiguity if data isn't returned.  I.e. with 
the existing with-defaults semantics it is not clear to me that servers 
will always return an explicit value to indicate that a particular 
widget is off if the schema defines that the default it that is 
enabled.  If the server doesn't support a given widget at all, it is 
quite plausible that it will just return no data for it. In theory 

Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts

[Robert Wilton]

As co-author, I have read and support both drafts for advancement.

In fact, I think that it is important that we get these drafts (and 
YL-bis) completed and standardized quickly, since the YANG models that 
IETF is standardizing rely on the NMDA.


Thanks,
Rob


On 30/01/2018 19:33, Juergen Schoenwaelder wrote:

Same here.

/js

On Tue, Jan 30, 2018 at 06:55:32PM +, Kent Watsen wrote:

I have read and support both drafts for advancement.

Kent // co-author


= original message =

Authors and WG,

We have not received any explicit support for this LC on this email thread. If 
you believe these drafts are important and should proceed, please state your 
support by responding to this email thread.

Thanks.


On Jan 17, 2018, at 10:39 AM, Mahesh Jethanandani  
wrote:

The authors of draft-ietf-netconf-nmda-netconf and 
draft-ietf-netconf-nmda-restconf have posted updates to their drafts, and 
believe that the documents are ready for LC.

This starts a 2 week LC on the two drafts that will end on January 31. Please 
send your comments on this thread. Comments like “I have reviewed the documents 
and believe they are ready for publication”, or “I have concerns about the 
document because …” are welcome and useful for the authors.

Authors please indicate whether you are aware of any IPR for either of the 
drafts.

Thanks.

Mahesh & Kent


Mahesh & Kent

___
Netconf mailing list
netc...@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf=DwIGaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=chxZG5ZrBnHC_vO0f9kYhGnMwAUeF2ALqnpqjt2FOwI=cLxPvaw3wBK8KfUx0ZKNPyqPPhC17Yx-o9SJQ_q4AWE=


___
Netconf mailing list
netc...@ietf.org
https://www.ietf.org/mailman/listinfo/netconf


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

Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts

[Andy Bierman]

On Wed, Jan 31, 2018 at 12:11 AM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> On Tue, Jan 30, 2018 at 12:35:33PM -0800, Andy Bierman wrote:
> > Hi,
> >
> > I have some questions about these drafts.
> >
> > 1) what if datastore set to "conventional"?
> > There are many places where a datastore-ref type is used.
> > However, "conventional" is valid for base "datastore", even though
> > it is ambiguous as a datastore selector.
>
> We can add explicit text that an identity that does not resolve to a
> datastore implemented by the server results in an invalid value error.
>
>

OK



> > 2) origin filter is limited to 1 source
> >This filtering seems rather limited.  A client must retrieve
> >  and check
> > all the values in use, then make repeated requests for each source
> as a
> > different
> >  leaf
>
> If the client does , then it has all origin information
> and it can filter locally. That said, we could make origin-filter a
> leaf-list which is logically ORed so that one can retrieve
> origin-filter=or:system or origin-filter=or:learned in one request.
>
>

OK


> > 3) with-defaults broken
> > The operational datastore does not support with-defaults.
> >  Instead, the client must use origin-filter=or:default or with-origin
> >  and check all the origin attributes.  Since a client needs to use
> >  with-defaults for other datastores, this special handling of
> > 
> >  seems unhelpful.
>
> I think the with-defaults semantics for conventional configuration
> datastores are much more complicated than necessary for the
> operational state datastore. Note that that the operational state
> datastore reports in-use values not really defaults:
>
>   foo
>
> This reports that the value 'foo' is in use and that it originates
> from a default value. Note that this could also be
>
>   foo
>
> in case the intended configuration datastore configured the value
> 'foo' (despite this value matching the default). The with-defaults
> solution is pretty complex because it tries to handle how different
> systems deal with configuration defaults. The idea is to not carry
> this complexity over to in-use values in the operational state
> datastore.
>
>

Before NMDA, the client could decide if it wanted to retrieve default nodes
or not.
This client-choice has been removed from NMDA, which is a problem.




> /js
>
>
Andy


> --
> 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] [Netconf] LC of NDMA NETCONF/RESTCONF drafts

[Martin Bjorklund]

Hi,

Andy Bierman  wrote:
> Hi,
> 
> I have some questions about these drafts.
> 
> 1) what if datastore set to "conventional"?
> There are many places where a datastore-ref type is used.
> However, "conventional" is valid for base "datastore", even though
> it is ambiguous as a datastore selector.

For edit-data, the text says:

leaf datastore {
  type ds:datastore-ref;
  description
"Datastore which is the target of the edit-data operation.

 If the target datastore is not writable, then the server
 MUST return an  element with an 
 value of 'invalid-value'";

So from this it follows that if the client sends "conventional", the
server will reply with an 'invalid-value' error.

Maybe we can even clarify:

 If the target datastore is not writable, or is not
 supported on the server, then the server
 MUST return an  element with an 


There is similar text for lock/unlock/validate.



But for get-data, the text just says:

leaf datastore {
  type ds:datastore-ref;
  ...
  description
"Datastore from which to retrieve data.";

I think we should add text:

  If the datastore is not supported on the server, , then the server
  MUST return an  element with an  value of
  'invalid-value'.


> 2) origin filter is limited to 1 source
>This filtering seems rather limited.  A client must retrieve
>  and check
> all the values in use, then make repeated requests for each source as a
> different
>  leaf

Since "AND" of origins doesn't really make any sense, I think we can
make this a leaf-list and explain that these values are OR:ed.  Do you
think this would be a good idea?

> 3) with-defaults broken
> The operational datastore does not support with-defaults.
>  Instead, the client must use origin-filter=or:default or with-origin
>  and check all the origin attributes.  Since a client needs to use
>  with-defaults for other datastores, this special handling of
> 
>  seems unhelpful.

The "with-defaults" feature is mostly useful in configuration
datastores, where the client needs to understand how the server treats
defaults.  When the server starts to operationally use config data, it
will also take default values into account and use these values, just
as if they had been explicitly configured.  default values are "in
use" and thus present in the operational state datastore (which by
definition contains all values that are in use).  Since these values
are present in the datastore, they are always returned.  If for some
reason a default value is NOT used, the leaf will not be present in
, and it will not be reported.



/martin



> 
> 
> Andy
> 
> 
> On Tue, Jan 30, 2018 at 10:27 AM, Mahesh Jethanandani <
> mjethanand...@gmail.com> wrote:
> 
> > Authors and WG,
> >
> > We have not received any explicit support for this LC on this email
> > thread. If you believe these drafts are important and should proceed,
> > please state your support by responding to this email thread.
> >
> > Thanks.
> >
> > > On Jan 17, 2018, at 10:39 AM, Mahesh Jethanandani <
> > mjethanand...@gmail.com> wrote:
> > >
> > > The authors of draft-ietf-netconf-nmda-netconf and
> > draft-ietf-netconf-nmda-restconf have posted updates to their drafts, and
> > believe that the documents are ready for LC.
> > >
> > > This starts a 2 week LC on the two drafts that will end on January 31.
> > Please send your comments on this thread. Comments like “I have reviewed
> > the documents and believe they are ready for publication”, or “I have
> > concerns about the document because …” are welcome and useful for the
> > authors.
> > >
> > > Authors please indicate whether you are aware of any IPR for either of
> > the drafts.
> > >
> > > Thanks.
> > >
> > > Mahesh & Kent
> > >
> >
> > Mahesh & Kent
> >
> > ___
> > 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] [Netconf] LC of NDMA NETCONF/RESTCONF drafts

[Juergen Schoenwaelder]

On Tue, Jan 30, 2018 at 12:35:33PM -0800, Andy Bierman wrote:
> Hi,
> 
> I have some questions about these drafts.
> 
> 1) what if datastore set to "conventional"?
> There are many places where a datastore-ref type is used.
> However, "conventional" is valid for base "datastore", even though
> it is ambiguous as a datastore selector.

We can add explicit text that an identity that does not resolve to a
datastore implemented by the server results in an invalid value error.
 
> 2) origin filter is limited to 1 source
>This filtering seems rather limited.  A client must retrieve
>  and check
> all the values in use, then make repeated requests for each source as a
> different
>  leaf

If the client does , then it has all origin information
and it can filter locally. That said, we could make origin-filter a
leaf-list which is logically ORed so that one can retrieve
origin-filter=or:system or origin-filter=or:learned in one request.

> 3) with-defaults broken
> The operational datastore does not support with-defaults.
>  Instead, the client must use origin-filter=or:default or with-origin
>  and check all the origin attributes.  Since a client needs to use
>  with-defaults for other datastores, this special handling of
> 
>  seems unhelpful.

I think the with-defaults semantics for conventional configuration
datastores are much more complicated than necessary for the
operational state datastore. Note that that the operational state
datastore reports in-use values not really defaults:

  foo

This reports that the value 'foo' is in use and that it originates
from a default value. Note that this could also be

  foo

in case the intended configuration datastore configured the value
'foo' (despite this value matching the default). The with-defaults
solution is pretty complex because it tries to handle how different
systems deal with configuration defaults. The idea is to not carry
this complexity over to in-use values in the operational state
datastore.

/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] [Netconf] LC of NDMA NETCONF/RESTCONF drafts

[Martin Bjorklund]

Juergen Schoenwaelder  wrote:
> Same here.

And same here.


/martin


> 
> /js
> 
> On Tue, Jan 30, 2018 at 06:55:32PM +, Kent Watsen wrote:
> > 
> > I have read and support both drafts for advancement.
> > 
> > Kent // co-author
> > 
> > 
> > = original message =
> > 
> > Authors and WG,
> > 
> > We have not received any explicit support for this LC on this email thread. 
> > If you believe these drafts are important and should proceed, please state 
> > your support by responding to this email thread.
> > 
> > Thanks.
> > 
> > > On Jan 17, 2018, at 10:39 AM, Mahesh Jethanandani 
> > >  wrote:
> > > 
> > > The authors of draft-ietf-netconf-nmda-netconf and 
> > > draft-ietf-netconf-nmda-restconf have posted updates to their drafts, and 
> > > believe that the documents are ready for LC.
> > > 
> > > This starts a 2 week LC on the two drafts that will end on January 31. 
> > > Please send your comments on this thread. Comments like “I have reviewed 
> > > the documents and believe they are ready for publication”, or “I have 
> > > concerns about the document because …” are welcome and useful for the 
> > > authors.
> > > 
> > > Authors please indicate whether you are aware of any IPR for either of 
> > > the drafts.
> > > 
> > > Thanks.
> > > 
> > > Mahesh & Kent
> > > 
> > 
> > Mahesh & Kent
> > 
> > ___
> > Netconf mailing list
> > netc...@ietf.org
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf=DwIGaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=chxZG5ZrBnHC_vO0f9kYhGnMwAUeF2ALqnpqjt2FOwI=cLxPvaw3wBK8KfUx0ZKNPyqPPhC17Yx-o9SJQ_q4AWE=
> > 
> > 
> > ___
> > Netconf mailing list
> > netc...@ietf.org
> > https://www.ietf.org/mailman/listinfo/netconf
> 
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
> 
> ___
> Netconf mailing list
> netc...@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts

[Juergen Schoenwaelder]

Same here.

/js

On Tue, Jan 30, 2018 at 06:55:32PM +, Kent Watsen wrote:
> 
> I have read and support both drafts for advancement.
> 
> Kent // co-author
> 
> 
> = original message =
> 
> Authors and WG,
> 
> We have not received any explicit support for this LC on this email thread. 
> If you believe these drafts are important and should proceed, please state 
> your support by responding to this email thread.
> 
> Thanks.
> 
> > On Jan 17, 2018, at 10:39 AM, Mahesh Jethanandani  
> > wrote:
> > 
> > The authors of draft-ietf-netconf-nmda-netconf and 
> > draft-ietf-netconf-nmda-restconf have posted updates to their drafts, and 
> > believe that the documents are ready for LC.
> > 
> > This starts a 2 week LC on the two drafts that will end on January 31. 
> > Please send your comments on this thread. Comments like “I have reviewed 
> > the documents and believe they are ready for publication”, or “I have 
> > concerns about the document because …” are welcome and useful for the 
> > authors.
> > 
> > Authors please indicate whether you are aware of any IPR for either of the 
> > drafts.
> > 
> > Thanks.
> > 
> > Mahesh & Kent
> > 
> 
> Mahesh & Kent
> 
> ___
> Netconf mailing list
> netc...@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf=DwIGaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=chxZG5ZrBnHC_vO0f9kYhGnMwAUeF2ALqnpqjt2FOwI=cLxPvaw3wBK8KfUx0ZKNPyqPPhC17Yx-o9SJQ_q4AWE=
> 
> 
> ___
> Netconf mailing list
> netc...@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf

-- 
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] [Netconf] LC of NDMA NETCONF/RESTCONF drafts

[Kent Watsen]

I have read and support both drafts for advancement.

Kent // co-author


= original message =

Authors and WG,

We have not received any explicit support for this LC on this email thread. If 
you believe these drafts are important and should proceed, please state your 
support by responding to this email thread.

Thanks.

> On Jan 17, 2018, at 10:39 AM, Mahesh Jethanandani  
> wrote:
> 
> The authors of draft-ietf-netconf-nmda-netconf and 
> draft-ietf-netconf-nmda-restconf have posted updates to their drafts, and 
> believe that the documents are ready for LC.
> 
> This starts a 2 week LC on the two drafts that will end on January 31. Please 
> send your comments on this thread. Comments like “I have reviewed the 
> documents and believe they are ready for publication”, or “I have concerns 
> about the document because …” are welcome and useful for the authors.
> 
> Authors please indicate whether you are aware of any IPR for either of the 
> drafts.
> 
> Thanks.
> 
> Mahesh & Kent
> 

Mahesh & Kent

___
Netconf mailing list
netc...@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf=DwIGaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=chxZG5ZrBnHC_vO0f9kYhGnMwAUeF2ALqnpqjt2FOwI=cLxPvaw3wBK8KfUx0ZKNPyqPPhC17Yx-o9SJQ_q4AWE=


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

Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts

[Vladimir Vassilev]

Hello,

There is a YANG error in ietf-netconf-n...@2018-01-17.yang:

Error: XPath expression 'derived-from-or-self(../datastore, 
"or:operational")' with invalid identity param 'or:operational'

ietf-netconf-nmda.yang:148.63: error(348): invalid XPath expression syntax

Error: XPath expression 'derived-from-or-self(../datastore, 
"or:operational")' with invalid identity param 'or:operational'

ietf-netconf-nmda.yang:178.63: error(348): invalid XPath expression syntax

The correct datastore identity is ds:operational. The same error was 
reported for the previous version of the draft.



 Forwarded Message 
Subject: [netmod] validation of draft-ietf-netconf-nmda-netconf-01
Date: Mon, 13 Nov 2017 19:48:49 +0100
From: Vladimir Vassilev 
To: netmod@ietf.org 

Hello,

There is a validation error reported for
ietf-netconf-datasto...@2017-08-24.yang:

Error: XPath expression 'derived-from-or-self(../datastore,
"or:operational")' with invalid identity param 'or:operational'
ietf-netconf-datasto...@2017-08-24.yang:140.63: error(348): invalid
XPath expression syntax


Vladimir

On 01/17/2018 07:39 PM, Mahesh Jethanandani wrote:

The authors of draft-ietf-netconf-nmda-netconf and 
draft-ietf-netconf-nmda-restconf have posted updates to their drafts, and 
believe that the documents are ready for LC.

This starts a 2 week LC on the two drafts that will end on January 31. Please 
send your comments on this thread. Comments like “I have reviewed the documents 
and believe they are ready for publication”, or “I have concerns about the 
document because …” are welcome and useful for the authors.

Authors please indicate whether you are aware of any IPR for either of the 
drafts.

Thanks.

Mahesh & Kent

___
Netconf mailing list
netc...@ietf.org
https://www.ietf.org/mailman/listinfo/netconf


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

Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts

[Robert Wilton]

I'm not aware of any IPR impacting either of these two drafts.

Rob


On 17/01/2018 19:02, Kent Watsen wrote:

I'm not aware of any IPR impacting either of these two drafts.

Kent // as co-author


= original message =

The authors of draft-ietf-netconf-nmda-netconf and 
draft-ietf-netconf-nmda-restconf have posted updates to their drafts, and 
believe that the documents are ready for LC.

This starts a 2 week LC on the two drafts that will end on January 31. Please 
send your comments on this thread. Comments like “I have reviewed the documents 
and believe they are ready for publication”, or “I have concerns about the 
document because …” are welcome and useful for the authors.

Authors please indicate whether you are aware of any IPR for either of the 
drafts.

Thanks.

Mahesh & Kent

___
Netconf mailing list
netc...@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf=DwIGaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=YD0IXtUkMMI3qIK63vNpsDmumHSc_7n1T6esiz6Nzhc=5dIbx4-7CM-5NmbIyhGS16He41fyV_CoCuTLBV0mDLw=


___
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] [Netconf] LC of NDMA NETCONF/RESTCONF drafts

[Kent Watsen]

I'm not aware of any IPR impacting either of these two drafts.

Kent // as co-author


= original message =

The authors of draft-ietf-netconf-nmda-netconf and 
draft-ietf-netconf-nmda-restconf have posted updates to their drafts, and 
believe that the documents are ready for LC.

This starts a 2 week LC on the two drafts that will end on January 31. Please 
send your comments on this thread. Comments like “I have reviewed the documents 
and believe they are ready for publication”, or “I have concerns about the 
document because …” are welcome and useful for the authors.

Authors please indicate whether you are aware of any IPR for either of the 
drafts.

Thanks.

Mahesh & Kent

___
Netconf mailing list
netc...@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf=DwIGaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=YD0IXtUkMMI3qIK63vNpsDmumHSc_7n1T6esiz6Nzhc=5dIbx4-7CM-5NmbIyhGS16He41fyV_CoCuTLBV0mDLw=


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