[netmod] 6991bis - Any plans to add more URI Syntax components?

[Mahesh Jethanandani]

Hi Juergen,

Is there a plan to add more URI syntax components in rfc6991bis? I know there 
is a typedef for uri, but I was looking specifically for the following that are 
defined in RFC 3986.
Scheme
Authority field including
User information
Path
Query
Fragment

Thanks.

Mahesh Jethanandani
mjethanand...@gmail.com



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

Re: [netmod] What's the problem with NMDA? was Re: 答复: 答复: Please clarify implementation about ‘when’

[Andy Bierman]

On Fri, Sep 27, 2019 at 3:40 AM Rob Wilton (rwilton) 
wrote:

> Hi,
>
> > -Original Message-
> > From: netmod  On Behalf Of Schönwälder, Jürgen
> > Sent: 26 September 2019 19:35
> > To: Andy Bierman 
> > Cc: netmod@ietf.org
> > Subject: Re: [netmod] What's the problem with NMDA? was Re: 答复: 答复:
> > Please clarify implementation about ‘when’
> >
> > On Thu, Sep 26, 2019 at 10:44:01AM -0700, Andy Bierman wrote:
> >
> > > The IETF has completely punted the problem of converting data for a
> > > configuration datastore to the schema tree for .
> >
> > I am not sure. The  model consists of the applied
> > configuration plus any config false extras. NMDA simplifies things since
> > there is now a single tree structure instead of two if you have to handle
> > models where applied configuration can be different than intended config.
> > If I configure /foo/bar in , I can check /foo/bar in
> >  whether it exists and matches what I configured.
> >
> > > Deviations may be different.  A leaf may be string in 1 tree and
> > > decimal64 in the other. There is an incorrect assumption that software
> > > developers will deal with these corner-cases (correctly and
> > > consistently).
> >
> > Not really true for applied config. And with non NMDA, there is no
> > guarantee either that /foo/bar and /foo-state/bar use the same type and
> > semantics.
>
> Indeed.  For non-NMDA, even if /foo/bar and /foo-state/bar are the same
> type in the published model, there is no guarantee that a server won't
> deviate the /foo-state/bar leaf to change its type to differ from /foo/bar,
> and this is allowed.
>
> But NMDA is aiming to be better than this.  One of the fundamental aims is
> that the config and operational values should be comparable, on the same
> relative datastore path and have the same type.
>
> That is why RFC 8342 does not allow a server to change the type of a data
> node in operational, they are only allowed to remove it to indicate that it
> is not supported.
>
> RFC 8342, section 5.3 The Operational State Datastore(operational):
>
>The datastore schema for  MUST be a superset of the
>combined datastore schema used in all configuration datastores,
>except that configuration data nodes supported in a configuration
>datastore MAY be omitted from  if a server is not able
>to accurately report them.
>
> The intention here is:
>  - If a server does a deviate "add|replace|delete" deviation on a config
> data node then that same deviation MUST be applied to all datastores that
> contain that data node in their schema (or otherwise operational cannot be
> a superset).
>  - A server MAY have operational datastore specific deviate
> "not-supported" deviations.  The purpose of this is meant to help
> migration, ideally servers would not have these deviations.
>
> Hence, a client/server can construct a single "superset" schema for the
> device, and then the schema for each individual datastore must be a subset
> of that "superset" schema (with the added requirement that there is only a
> single schema for all conventional datastores).
>
>
IMO the new YANG library is the most disruptive and complex way possible to
express
a simple capability "operational value for configuration object foo
supported or not".
I prefer the capabilities module approach in
https://tools.ietf.org/html/draft-ietf-netconf-notification-capabilities-04
Deprecating the YANG library and starting over is kind of a
bull-in-the-china-shop
approach to advertising some server capabilities.


I appreciate that the new YANG library structurally allows invalid schemas
> to be defined, but then so does the old YANG library as well.  E.g. there
> is nothing in the old YANG library structure to prevent a server from
> reporting that it implements two different revisions of the same YANG 1.1
> module.
>
> Thanks,
> Rob
>
>

Andy


>
> >
> > > The other big problem is an untested NMDA transition strategy that is
> > > not well understood by vendors.
> > > Should non-NMDA (/foo-state) be visible to  or just ?
> >
> > Perhaps there is more explanation necessary. The idea here is that an
> NMDA
> > client should not bother to search for /foo-state, it should send a 
> > for /foo/state in operational.
> >
> > Yes, NMDA requires updates to clients. Whether these are visible or in
> > which form they are visible to application logic likely depends on the
> > client design. But yes, NMDA is not for free for clients. But once you
> > have updated, we believe NMDA actually makes things simpler and more
> > consistent.
> >
> > > Using the YANG library to separate the modules relies on the
> > > assumption that the client is capable of managing each datastore
> > > independently (instead of
> > > 1 schema tree per server).
> >
> > Yes, YANG library can express pretty complex server model organizations..
> > This does not mean that all server have to use server model
> organizations.
> > I assume that also many clients will not be interested to 

Re: [netmod] IPR check draft-ietf-netmod-yang-data-ext-04

[Dmytro Shytyi]

Hello,

​

No, I'm not aware of any IPR that applies to this draft


__
Dmytro SHYTYI



 On Fri, 27 Sep 2019 14:57:50 +0200 Andy Bierman  wrote 






On Thu, Sep 26, 2019 at 10:35 PM Joel Jaeggli  wrote:

Authors, Contributors, WG,

As part of WG Last Call for  draft-ietf-netmod-yang-data-ext-04

Are you aware of any IPR that applies to drafts identified above?

Please state either:







 "No, I'm not aware of any IPR that applies to this draft"



Andy



"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate.

If you are listed as a document author or contributor please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR. This document will not advance to the next
stage until a response has been received from each author and listed
contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S
TO LINES.

If you are on the WG email list or attend WG meetings but are not listed
as an author or contributor, we remind you of your obligations under
the IETF IPR rules which encourages you to notify the IETF if you are
aware of IPR of others on an IETF contribution, or to refrain from
participating in any contribution or discussion related to your
undisclosed IPR. For more information, please see the RFCs listed above
and
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.

Thank you,
NetMod WG Chairs

PS Please include all listed in the headers of this message in your
response.





___
netmod mailing list 
mailto: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] IPR check draft-ietf-netmod-yang-data-ext-04

[Andy Bierman]

On Thu, Sep 26, 2019 at 10:35 PM Joel Jaeggli  wrote:

> Authors, Contributors, WG,
>
> As part of WG Last Call for  draft-ietf-netmod-yang-data-ext-04
>
> Are you aware of any IPR that applies to drafts identified above?
>
> Please state either:
>
>

 "No, I'm not aware of any IPR that applies to this draft"

Andy

"No, I'm not aware of any IPR that applies to this draft"
> or
> "Yes, I'm aware of IPR that applies to this draft"
>
> If so, has this IPR been disclosed in compliance with IETF IPR rules
> (see RFCs 3669, 5378 and 8179 for more details)?
>
> If yes to the above, please state either:
>
> "Yes, the IPR has been disclosed in compliance with IETF IPR rules"
> or
> "No, the IPR has not been disclosed"
>
> If you answer no, please provide any additional details you think
> appropriate.
>
> If you are listed as a document author or contributor please answer the
> above by responding to this email regardless of whether or not you are
> aware of any relevant IPR. This document will not advance to the next
> stage until a response has been received from each author and listed
> contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S
> TO LINES.
>
> If you are on the WG email list or attend WG meetings but are not listed
> as an author or contributor, we remind you of your obligations under
> the IETF IPR rules which encourages you to notify the IETF if you are
> aware of IPR of others on an IETF contribution, or to refrain from
> participating in any contribution or discussion related to your
> undisclosed IPR. For more information, please see the RFCs listed above
> and
> http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.
>
> Thank you,
> NetMod WG Chairs
>
> PS Please include all listed in the headers of this message in your
> response.
>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] IPR check draft-ietf-netmod-yang-data-ext-04

[Kent Watsen]

No, I'm not aware of any IPR that applies to this draft. 

Kent // as co-author 



> On Sep 27, 2019, at 1:35 AM, Joel Jaeggli  wrote:
> 
> Authors, Contributors, WG,
> 
> As part of WG Last Call for  draft-ietf-netmod-yang-data-ext-04
> 
> Are you aware of any IPR that applies to drafts identified above?
> 
> Please state either:
> 
> "No, I'm not aware of any IPR that applies to this draft"
> or
> "Yes, I'm aware of IPR that applies to this draft"
> 
> If so, has this IPR been disclosed in compliance with IETF IPR rules
> (see RFCs 3669, 5378 and 8179 for more details)?
> 
> If yes to the above, please state either:
> 
> "Yes, the IPR has been disclosed in compliance with IETF IPR rules"
> or
> "No, the IPR has not been disclosed"
> 
> If you answer no, please provide any additional details you think
> appropriate.
> 
> If you are listed as a document author or contributor please answer the
> above by responding to this email regardless of whether or not you are
> aware of any relevant IPR. This document will not advance to the next
> stage until a response has been received from each author and listed
> contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S
> TO LINES.
> 
> If you are on the WG email list or attend WG meetings but are not listed
> as an author or contributor, we remind you of your obligations under
> the IETF IPR rules which encourages you to notify the IETF if you are
> aware of IPR of others on an IETF contribution, or to refrain from
> participating in any contribution or discussion related to your
> undisclosed IPR. For more information, please see the RFCs listed above
> and
> http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.
> 
> Thank you,
> NetMod WG Chairs
> 
> PS Please include all listed in the headers of this message in your
> response.
> 
> ___
> 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] What's the problem with NMDA? was Re: 答复: 答复: Please clarify implementation about ‘when’

[Rob Wilton (rwilton)]

Hi,

> -Original Message-
> From: netmod  On Behalf Of Schönwälder, Jürgen
> Sent: 26 September 2019 19:35
> To: Andy Bierman 
> Cc: netmod@ietf.org
> Subject: Re: [netmod] What's the problem with NMDA? was Re: 答复: 答复:
> Please clarify implementation about ‘when’
> 
> On Thu, Sep 26, 2019 at 10:44:01AM -0700, Andy Bierman wrote:
> 
> > The IETF has completely punted the problem of converting data for a
> > configuration datastore to the schema tree for .
> 
> I am not sure. The  model consists of the applied
> configuration plus any config false extras. NMDA simplifies things since
> there is now a single tree structure instead of two if you have to handle
> models where applied configuration can be different than intended config.
> If I configure /foo/bar in , I can check /foo/bar in
>  whether it exists and matches what I configured.
> 
> > Deviations may be different.  A leaf may be string in 1 tree and
> > decimal64 in the other. There is an incorrect assumption that software
> > developers will deal with these corner-cases (correctly and
> > consistently).
> 
> Not really true for applied config. And with non NMDA, there is no
> guarantee either that /foo/bar and /foo-state/bar use the same type and
> semantics.

Indeed.  For non-NMDA, even if /foo/bar and /foo-state/bar are the same type in 
the published model, there is no guarantee that a server won't deviate the 
/foo-state/bar leaf to change its type to differ from /foo/bar, and this is 
allowed.

But NMDA is aiming to be better than this.  One of the fundamental aims is that 
the config and operational values should be comparable, on the same relative 
datastore path and have the same type.

That is why RFC 8342 does not allow a server to change the type of a data node 
in operational, they are only allowed to remove it to indicate that it is not 
supported.

RFC 8342, section 5.3 The Operational State Datastore(operational):

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

The intention here is:
 - If a server does a deviate "add|replace|delete" deviation on a config data 
node then that same deviation MUST be applied to all datastores that contain 
that data node in their schema (or otherwise operational cannot be a superset).
 - A server MAY have operational datastore specific deviate "not-supported" 
deviations.  The purpose of this is meant to help migration, ideally servers 
would not have these deviations.

Hence, a client/server can construct a single "superset" schema for the device, 
and then the schema for each individual datastore must be a subset of that 
"superset" schema (with the added requirement that there is only a single 
schema for all conventional datastores).

I appreciate that the new YANG library structurally allows invalid schemas to 
be defined, but then so does the old YANG library as well.  E.g. there is 
nothing in the old YANG library structure to prevent a server from reporting 
that it implements two different revisions of the same YANG 1.1 module.

Thanks,
Rob


> 
> > The other big problem is an untested NMDA transition strategy that is
> > not well understood by vendors.
> > Should non-NMDA (/foo-state) be visible to  or just ?
> 
> Perhaps there is more explanation necessary. The idea here is that an NMDA
> client should not bother to search for /foo-state, it should send a 
> for /foo/state in operational.
> 
> Yes, NMDA requires updates to clients. Whether these are visible or in
> which form they are visible to application logic likely depends on the
> client design. But yes, NMDA is not for free for clients. But once you
> have updated, we believe NMDA actually makes things simpler and more
> consistent.
> 
> > Using the YANG library to separate the modules relies on the
> > assumption that the client is capable of managing each datastore
> > independently (instead of
> > 1 schema tree per server).
> 
> Yes, YANG library can express pretty complex server model organizations.
> This does not mean that all server have to use server model organizations.
> I assume that also many clients will not be interested to understand the
> entire server model, they likely want to check the existance of only those
> pieces that they care about.
> 
> /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
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] What's the problem with NMDA? was Re: 答复: 答复: Please clarify implementation about ‘when’

[tom petch]

Andy

Thanks for the explanation - makes sense to me.

Tom Petch


- Original Message -
From: "Andy Bierman" 
To: "tom petch" 
Cc: 
Sent: Thursday, September 26, 2019 6:44 PM


Hi,


On Thu, Sep 26, 2019 at 9:14 AM tom petch  wrote:

> Inline
>
> Tom Petch
>
> - Original Message -
> From: "Andy Bierman" 
> To: "Rob Wilton (rwilton)" 
> Cc: ; 
> Sent: Thursday, September 26, 2019 3:33 PM
>
> On Thu, Sep 26, 2019 at 3:32 AM Rob Wilton (rwilton)

> wrote:
>
> >
> >
> > > -Original Message-
> > > From: netmod  On Behalf Of Martin
Bjorklund
> > > Sent: 26 September 2019 08:45
> > > To: lho...@nic.cz
> > > Cc: yang...@huawei.com; netmod@ietf.org
> > > Subject: Re: [netmod] 答复: 答复: Please clarify implementation about
> > > ‘when’
> > >
> > > > >
> > > > > It also says in 8.2:
> > > > >
> > > > >o  If a request modifies a configuration data node such
that
> any
> > > > >   node's "when" expression becomes false, then the node in
> the
> > > data
> > > > >   tree with the "when" expression is deleted by the
server.
> > > >
> > > > Right. But the request won't modify a configuration data node
> because
> > > > it is rejected. So the premise of the above implication doesn't
> hold,
> > > > and the conclusion doesn't apply.
> > >
> > > With the same logic you can claim conformance if you reject a
> request to
> > > create nodes under a case if another case is active.  I think it
is
> quite
> > > clear that this auto-deletion is part of the spec, and something
> clients
> > > can rely on.  If the intention had been that this was optional to
> > > implement, it would have been clearly stated, and there would have
> been
> > > mechanism present for clients to detect this.
> > >
> > I don't like the 'when' behaviour, I would have rather that clients
> were
> > forced to delete the configuration explicitly (or pass an option for
> an
> > implicit delete).
>
> I hear the opposite from customers.
> They insist that the server implement every last detail of the
> machine-readable YANG,
> especially when-stmt auto-deletion. The auto-cleanup is seen as a
> feature.
>
> > However, I do agree with Martin & Juergen, that the intent of the
spec
> is
> > that servers perform the 'when' auto-delete behaviour, and clients
> must be
> > able to rely on compliant servers behaving this way.
> >
>
> agreed.
> It is hard to argue against consistent, predicable server behavior
> for datastore editing.  (NP containers and NMDA are also causing
> problems,
> and should be fixed in yang-next if that ever happens).
>
> 
>
> Andy
>
> This caught my eye.  What is the problem with NMDA? Anything specific?
>
> My own problem is that it is different to what has been proposed as
> suitable for the previous 12 years but I doubt if many customers would
> think that.
>
>
My comments are in the context of operator expectations for consistent
implementations.

The first problem with NMDA is the new YANG library.
There is an assumption that the client can and will change from an
architecture
where there is 1 schema tree per server to an architecture where there
can
be a completely
different schema tree for configuration vs operational datastores.
There
is no such desire
or willingness on the client side to properly address this complexity.
IMO
NMDA is going to
need to function without this complexity. The benefits of 
are
not hindered
at all (in a properly implemented server) if /yang-library is left out.

The IETF has completely punted the problem of converting data for a
configuration datastore
to the schema tree for . Deviations may be different.  A
leaf
may
be string in 1 tree and decimal64 in the other. There is an incorrect
assumption
that software developers will deal with these corner-cases (correctly
and
consistently).

The other big problem is an untested NMDA transition strategy that is
not
well understood by vendors.
Should non-NMDA (/foo-state) be visible to  or just ?
Using the YANG library to separate the modules relies on the assumption
that
the client is capable of managing each datastore independently (instead
of
1 schema tree per server).



> Tom Petch
>
>
Andy


> Thanks,
> > Rob
> >
> >
>
> Andy
>
>
> >
> > >
> > > /martin
> > > ___
> > > 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] IPR check draft-ietf-netmod-yang-data-ext-04

[Martin Bjorklund]

Joel Jaeggli  wrote:
> Authors, Contributors, WG,
> 
> As part of WG Last Call for  draft-ietf-netmod-yang-data-ext-04
> 
> Are you aware of any IPR that applies to drafts identified above?

No, I'm not aware of any IPR that applies to this draft


/martin


> 
> Please state either:
> 
> "No, I'm not aware of any IPR that applies to this draft"
> or
> "Yes, I'm aware of IPR that applies to this draft"
> 
> If so, has this IPR been disclosed in compliance with IETF IPR rules
> (see RFCs 3669, 5378 and 8179 for more details)?
> 
> If yes to the above, please state either:
> 
> "Yes, the IPR has been disclosed in compliance with IETF IPR rules"
> or
> "No, the IPR has not been disclosed"
> 
> If you answer no, please provide any additional details you think
> appropriate.
> 
> If you are listed as a document author or contributor please answer the
> above by responding to this email regardless of whether or not you are
> aware of any relevant IPR. This document will not advance to the next
> stage until a response has been received from each author and listed
> contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S
> TO LINES.
> 
> If you are on the WG email list or attend WG meetings but are not listed
> as an author or contributor, we remind you of your obligations under
> the IETF IPR rules which encourages you to notify the IETF if you are
> aware of IPR of others on an IETF contribution, or to refrain from
> participating in any contribution or discussion related to your
> undisclosed IPR. For more information, please see the RFCs listed above
> and
> http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty 
> .
> 
> Thank you,
> NetMod WG Chairs
> 
> PS Please include all listed in the headers of this message in your
> response.
> 

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