Re: [netmod] [netconf] Comments on draft-ietf-netconf-nmda-netconf-05

[Rohit R Ranade]

Hi All,

I plan to implement this draft and hence had some implementation related 
clarifications.


1.   I feel that there should be more text added about "origin" filtering 
mechanism. I am not clear about some aspects of origin filtering.

RFC 8342 : NMDA RFC provides the below example


   
 lo0
 loopback
 127.0.0.1
 ::1
   
 
If user provides  as "system" ONLY, then he will NOT get this 
record in output. Because the keys have originated from "intended" . Right ?
So, If user wants to get the system originated data, he MUST give all the 
origins in the  where the keys of the system data have 
originated from. Can you please confirm whether this is OK.


Another example given in RFC 8342 is as below:
 
   
 lo0
 127.0.0.1
 ::1
   
 

?  Here keys are originated from "system", but it is under container of 
"intended". So if user gives "system" for "origin-filter", the output will 
still NOT have this instance output ?

?  Also the container is not defined as "presence" in C.3.  Interface Example, 
but still it has origin whether that is Ok ?

With Regards,
Rohit R Ranade

From: Rohit R Ranade
Sent: 24 April 2018 18:39
To: 'netmod@ietf.org' 
Subject: [netmod] Comments on draft-ietf-netconf-nmda-netconf-05

Hi All,

Please find some comments for the draft.


1.   If "config-filter" leaf is not given for  whether we can add 
explicit text that both config=true and config=false nodes will be selected.

2.   In the YANG module description for "config-filter" , also it is not 
clear about what happens if the leaf is not given in filter. I feel better we 
keep the style like RESTCONF RFC 8040 Section 4.8.1 , with "content" having  
config/nonconfig/all

3.   Regarding the "max-depth" parameter, I feel we should take the text 
about how "depth" is calculated for each node from RESTCONF RFC from Section 
4.8.2 and add it to this draft. What will be depth of parent keys which are 
auto-selected when selecting on child nodes. Maybe some example regarding using 
of "max-depth" will be helpful.

4.   For the  filter mechanism, since there are 4 filters 
(filter-spec and config-filter and max-depth and with-defaults), whether we can 
mention that all these filters are AND'ed. Also whether there is a suggested 
order to apply filter ? I think "max-depth" filter has to be applied last. 
Others maybe any order is OK.

5.   negated-origin-filter : Regarding this I feel we can add a sentence as 
to when user should use "negated-origin-filter" , as "origin-filter" also can 
be used for this purpose.

With Regards,
Rohit R Ranade


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

Re: [netmod] yang-data-ext issues

[Kent Watsen]

> People want to use YANG to define the schema for an XML or JSON
> representation of a stand-alone document.

Agreed


> The only data needed must be module + local-name.

Or maybe: module + local-name + context, where context is one of:

  - data nodes
  - RPC/actions
  - notifications
  - standalone artifacts (files)

At least, it seems that these are different things.

[Note: RESTCONF places some of the context into the URL; two different data 
node resources can have identical module + local-name.]

It would be bad if two stand-alone artifacts had the same module+local-name 
(foo:bar).   However, it's okay to have a matching top-level data node called 
"foo:bar", since it is used in a different context.  Just like yang-data cannot 
be accessed as data via a protocol like NC or RC, so it is that 
traditionally-defined data nodes cannot be accessed as a stand-alone artifact 
(unless you’re a draft-author and need an instance document for an example).


> Defining an extension that maps error-info data for a specific RPC might be
> something worth standardizing.  It should not be done with yang-data,
> but rather a different extension just for this purpose.

Martin wrote before:

(maybe in the future we could even have a YANG extension statement 
to
formalize the description:

   rpc my-first-rpc {
 ...
 opx:error-info-structure my-first-rpc-error-info;
   }

but this is not point now.)

I imagined that he was hoping to limit what's needed to get 
draft-ietf-netconf-notification-messages out the door now, but I think another 
I-D should be proposed to augment the 'rpc' and 'action' statements with an 
anydata called "error-info-structure" so the YANG would be more like this:

   rpc my-first-rpc {
 ...
 opx:error-info-structure my-first-rpc-error-info {
 …
   }
   }

That is, to your point, with no reference to a yang-data data structure.


> Andy

Kent // contributor

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

Re: [netmod] yang-data-ext issues

[Andy Bierman]

On Mon, Apr 23, 2018 at 1:08 PM, Martin Bjorklund  wrote:

> Andy Bierman  wrote:
> > > 
> > > >
> > > > I do not understand the need for a yang-data structure that
> represents
> > > data
> > > > that can be instantiated anywhere and everywhere.
> > >
> > > AFAIK noone is proposing that.
> > >
> > > > I do not want to break
> > > > existing tools that expect sibling data nodes in the same module
> > > namespace
> > > > to
> > > > be unique local-names.
> > > >
> > > > I would rather stick with the yang-data in RFC 8040 than introduce a
> new
> > > > extension
> > > > with no restrictions.  Standard YANG extensions should be
> interoperable
> > > and
> > > > have
> > > > a clear purpose.
> > >
> > > Of course.
> > >
> > > > If we do not need to define what a YANG extension does in
> > > > a way that can be observed somehow, then it does not need to be a
> > > standard.
> > >
> > > Agreed.
> > >
> > > Not sure how any of this helps with the original issue though.
> > >
> > >
> >
> > You proposed that duplicate nodes were OK:
> >
> > module X {
> > prefix x;
> >
> > x:yang-data A {
> >list foo { ... }
> > }
> >
> > x:yang-data B {
> >   container foo { ... }
> > }
> >
> > }
> >
> >
> > I do not want to allow any duplicates.
>
> Yes, I got that.
>
> > There are no encoding and parsing rules for instance data
> > that support this sort of duplicate.
>
> This is not correct, as I have demonstrated earlier, and I think you
> also accepted; if different structures are defined for different rpcs'
> error-infos, then these structures can have the same child node names.
>
> I think that we have to agree on the basics before disussing
> solutions:
>
>   1)  Should we do anything at all?
>
>   (i.e., keep using yang-data in RFC 8040)
>
>   2)  Should we define structures that only can be used in
>   standalone instance documents?
>
>   (i.e., *more* restrictive than yang-data in RFC 8040)
>
>   3)  Should we define structures that can be used in standalone
>   instance documents, error-info contents, and other places that
>   we might not know right now?
>
>   (i.e., *less* restrictive than yang-data in RFC 8040)
>
>
> Since the current draft says:
>
>The "yang-data" extension statement from RFC
>8040 [RFC8040] is defined for this purpose, however it is limited in
>its functionality.
>
>The intended use of the "yang-data" extension is to model all or part
>of a protocol message, such as the "errors" definition in ietf-
>restconf.yang [RFC8040], or the contents of a file.  However,
>protocols are often layered such that the header or payload portions
>of the message can be extended by external documents.  The YANG
>statements that model a protocol need to support this extensibility
>that is already found in that protocol.
>
>
> I thought we are doing (3).
>
>
>
The use-case that has come up several times is (1).
People want to use YANG to define the schema for an XML or JSON
representation of a stand-alone document.

Item (3) needs to be machine-readable and deterministic for it to be even
remotely
feasible as a standard. There is no way a tool should have to match 
to
the correct schema, based on the description-stmt inside some
yang-data-stmt.
The only data needed must be module + local-name.

The example you gave of different definitions of the  leaf is a
really bad idea.
We should never try to define different schema for the same instance data,
where the module-name and local-name are the same, but the contents are
different.

Defining an extension that maps error-info data for a specific RPC might be
something worth standardizing.  It should not be done with yang-data,
but rather a different extension just for this purpose.



> /martin
>

Andy


>
>
>
> > yang-data definitions define conceptual data nodes (e.g, /x:foo)
> > Only one data-def-stmt (in yang-data or otherwise) can define a data node
> > /x:foo.
> > The descriptive names for the yang-data (A or B) do not define
> namespaces.
> >
> >
> >
> > > /martin
> > >
> > >
> > Andy
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] yang-data-ext issues

[Ladislav Lhotka]

On Tue, 2018-04-24 at 16:36 +0200, Martin Bjorklund wrote:
> Ladislav Lhotka  wrote:
> > Martin Bjorklund  writes:
> > 
> > > Hi,
> > >
> > > I am not sure what this statement tells us re. the issue in this email
> > > thread.
> > 
> > It tells us that, in my view, the approach taken in this document is a
> > bad idea.
> 
> Do you mean that the WG shoud drop this document?  And people that

Yes. Doing it properly would amount to rewriting many parts of RFC 7950 for use
inside "yang-data".

> need yang-data should continue to use the version in 8040?  Or that

Preferably not.

> people that need yang-data do not have a valid use case and they
> should do something else?

They may have a valid use case but YANG (in the current form) is not suitable
for it.

Lada


> 
> 
> /martin
> 
> 
> 
> > 
> > Lada
> > 
> > >
> > >
> > > /martin
> > >
> > >
> > > Juergen Schoenwaelder  wrote:
> > >> On Sun, Apr 22, 2018 at 02:56:51PM +0200, Ladislav Lhotka wrote:
> > >> 
> > >> > I am much more concerned with some of the post-1.1 features, also
> > >> > because YANG is now being updated in several directions without a
> > >> > clear vision. And another big problem is that YANG extensions are
> > >> > used for these changes, so we will probably end up with several
> > >> > different versions of YANG, although formally everything will be
> > >> > 1.1.
> > >> 
> > >> I tend to agree. Ideally, we would carefully remove things from YANG
> > >> that did not meet the cost/benefit target (e.g., submodules),
> > >> reorganize definitions whenever possible (some NETCONF specific stuff
> > >> in the YANG specification should not be there, XML encoding may be
> > >> factored out) and incorporate new features (like yang-data) after we
> > >> have sufficient _experience_ to know that such new features will be
> > >> useful (which seems to be the case for yang-data).
> > >> 
> > >> Yes, such iterations likely take 2 years at IETF speed but this kind
> > >> of maintenance cost/effort is likely the price to be paied for
> > >> something that is being used at a larger scale.
> > >> 
> > >> Some people will say that the cost of a new language version is high.
> > >> (Well, when we did 1.1, some people said it will never be deployed.)
> > >> Anyway, not bumping the YANG version number but having instead several
> > >> (optional) language extensions is just hiding the version number
> > >> change under the carpet.
> > >> 
> > >> /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
> > >> 
> > 
> > -- 
> > Ladislav Lhotka
> > Head, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
> > 
-- 
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] yang-data-ext issues

[Martin Bjorklund]

Robert Wilton  wrote:
> 
> 
> On 23/04/2018 21:08, Martin Bjorklund wrote:
> > Andy Bierman  wrote:
> >>> 
>  I do not understand the need for a yang-data structure that represents
> >>> data
>  that can be instantiated anywhere and everywhere.
> >>> AFAIK noone is proposing that.
> >>>
>  I do not want to break
>  existing tools that expect sibling data nodes in the same module
> >>> namespace
>  to
>  be unique local-names.
> 
>  I would rather stick with the yang-data in RFC 8040 than introduce a
>  new
>  extension
>  with no restrictions.  Standard YANG extensions should be
>  interoperable
> >>> and
>  have
>  a clear purpose.
> >>> Of course.
> >>>
>  If we do not need to define what a YANG extension does in
>  a way that can be observed somehow, then it does not need to be a
> >>> standard.
> >>>
> >>> Agreed.
> >>>
> >>> Not sure how any of this helps with the original issue though.
> >>>
> >>>
> >> You proposed that duplicate nodes were OK:
> >>
> >> module X {
> >> prefix x;
> >>
> >> x:yang-data A {
> >> list foo { ... }
> >> }
> >>
> >> x:yang-data B {
> >>container foo { ... }
> >> }
> >>
> >> }
> >>
> >>
> >> I do not want to allow any duplicates.
> > Yes, I got that.
> >
> >> There are no encoding and parsing rules for instance data
> >> that support this sort of duplicate.
> > This is not correct, as I have demonstrated earlier, and I think you
> > also accepted; if different structures are defined for different rpcs'
> > error-infos, then these structures can have the same child node names.
> >
> > I think that we have to agree on the basics before disussing
> > solutions:
> >
> >1)  Should we do anything at all?
> >
> >(i.e., keep using yang-data in RFC 8040)
> There is also an option 1(b) which is to move the current yang-data
> definition on RFC 8040 into it's own document, just to fix the
> references issue.

Sure, but I don't think it is worth the effort.

> >2)  Should we define structures that only can be used in
> >standalone instance documents?
> >
> >(i.e., *more* restrictive than yang-data in RFC 8040)
> I don't think that we should define something more restrictive that
> yang-data in RFC 8040.

I agree.

> >3)  Should we define structures that can be used in standalone
> >instance documents, error-info contents, and other places that
> >we might not know right now?
> >
> >(i.e., *less* restrictive than yang-data in RFC 8040)
> I don't know about this one because I'm not sure that I understand the
> problem space well enough.
> 
> For some of the categories above would a choice statement + groupings
> works just as well as a yang-data extension?

Not sure what you mean, but before we had yang-data in 8040, people
used something like this:

  module my-module {

container foo {
  description
"This is not really a real data node that is supposed to be
 instantiated in any datastore.  Instead it is supposed to be
 the top-level node in an instance document that
 describes...";
}
  }

By this is really a mis-use of YANG statements.  Wrapping it in an
extension solves that problem.

> A different thought, one that has probably been considered before:
>  - Could all yang data definitions be defined using groupings
> instead.  I.e. a grouping without any associated uses statements.
>  - Perhaps an extra statement under the grouping could be used to
> indicate whether the grouping represents a yang data definition.

Nodes in a grouping do not belong to any namespace.  Forcing such a
namespace binding with a substatement to "grouping" feels worse than
having a YANG extension with the nodes defined (which of course can be
done with "uses").


/martin


> 
> Thanks,
> Rob
> 
> 
> >
> >
> > Since the current draft says:
> >
> > The "yang-data" extension statement from RFC
> > 8040 [RFC8040] is defined for this purpose, however it is limited in
> > its functionality.
> >
> > The intended use of the "yang-data" extension is to model all or part
> > of a protocol message, such as the "errors" definition in ietf-
> > restconf.yang [RFC8040], or the contents of a file.  However,
> > protocols are often layered such that the header or payload portions
> > of the message can be extended by external documents.  The YANG
> > statements that model a protocol need to support this extensibility
> > that is already found in that protocol.
> >
> >
> > I thought we are doing (3).
> >
> >
> >
> > /martin
> >
> >
> >
> >> yang-data definitions define conceptual data nodes (e.g, /x:foo)
> >> Only one data-def-stmt (in yang-data or otherwise) can define a data
> >> node
> >> /x:foo.
> >> The descriptive names for the yang-data (A or B) do not define
> >> namespaces.
> >>
> >>
> >>
> >>> /martin
> >>>
> >>>
> >> Andy
> > 

Re: [netmod] yang-data-ext issues

[Martin Bjorklund]

Ladislav Lhotka  wrote:
> Robert Varga  writes:
> 
> > On 23/04/18 18:51, Juergen Schoenwaelder wrote:
> >> Some people will say that the cost of a new language version is high.
> >> (Well, when we did 1.1, some people said it will never be deployed.)
> >> Anyway, not bumping the YANG version number but having instead several
> >> (optional) language extensions is just hiding the version number
> >> change under the carpet.
> >
> > Not quite, as extensions allow for modular/incremental evolution, as an
> > implementer I do not have to go through a long development cycle where I
> > need to rewire language aspects just to get the features my users need
> > for their models...
> 
> But what prevents you from forking YANG, indicating it in the
> "yang-version" string and implementing your new statements as built-ins?
> 
> It is tempting to think about extensions as a magic for adding modular
> extensions but it breaks down as soon as such extensions interfere with
> the YANG core (with and each other, or both).

Sure, nothing new here.  This is how the extension mechanism is
designed.  Do you feel that there are so many standard extensions that
interfere with each other that we actually have a problem?  I strongly
agree that we need to be careful with standard extensions, and I
strongly encourage vendors to not define extensions that interfere
with YANG core (been there, done that, bad idea).

In the case of yang-data, the fact is that it *is* used in standard
models (in ways not originally anticipated), and vendors have similar
proprietary extensions (we have a tailf:structure, and I think others
have reported similar things).



/martin

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

Re: [netmod] yang-data-ext issues

[Martin Bjorklund]

Ladislav Lhotka  wrote:
> Martin Bjorklund  writes:
> 
> > Hi,
> >
> > I am not sure what this statement tells us re. the issue in this email
> > thread.
> 
> It tells us that, in my view, the approach taken in this document is a
> bad idea.

Do you mean that the WG shoud drop this document?  And people that
need yang-data should continue to use the version in 8040?  Or that
people that need yang-data do not have a valid use case and they
should do something else?


/martin



> 
> Lada
> 
> >
> >
> > /martin
> >
> >
> > Juergen Schoenwaelder  wrote:
> >> On Sun, Apr 22, 2018 at 02:56:51PM +0200, Ladislav Lhotka wrote:
> >> 
> >> > I am much more concerned with some of the post-1.1 features, also
> >> > because YANG is now being updated in several directions without a
> >> > clear vision. And another big problem is that YANG extensions are
> >> > used for these changes, so we will probably end up with several
> >> > different versions of YANG, although formally everything will be
> >> > 1.1.
> >> 
> >> I tend to agree. Ideally, we would carefully remove things from YANG
> >> that did not meet the cost/benefit target (e.g., submodules),
> >> reorganize definitions whenever possible (some NETCONF specific stuff
> >> in the YANG specification should not be there, XML encoding may be
> >> factored out) and incorporate new features (like yang-data) after we
> >> have sufficient _experience_ to know that such new features will be
> >> useful (which seems to be the case for yang-data).
> >> 
> >> Yes, such iterations likely take 2 years at IETF speed but this kind
> >> of maintenance cost/effort is likely the price to be paied for
> >> something that is being used at a larger scale.
> >> 
> >> Some people will say that the cost of a new language version is high.
> >> (Well, when we did 1.1, some people said it will never be deployed.)
> >> Anyway, not bumping the YANG version number but having instead several
> >> (optional) language extensions is just hiding the version number
> >> change under the carpet.
> >> 
> >> /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
> >> 
> 
> -- 
> 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] yang-data-ext issues

[Ladislav Lhotka]

Martin Bjorklund  writes:

> Hi,
>
> I am not sure what this statement tells us re. the issue in this email
> thread.

It tells us that, in my view, the approach taken in this document is a
bad idea.

Lada

>
>
> /martin
>
>
> Juergen Schoenwaelder  wrote:
>> On Sun, Apr 22, 2018 at 02:56:51PM +0200, Ladislav Lhotka wrote:
>> 
>> > I am much more concerned with some of the post-1.1 features, also
>> > because YANG is now being updated in several directions without a
>> > clear vision. And another big problem is that YANG extensions are
>> > used for these changes, so we will probably end up with several
>> > different versions of YANG, although formally everything will be
>> > 1.1.
>> 
>> I tend to agree. Ideally, we would carefully remove things from YANG
>> that did not meet the cost/benefit target (e.g., submodules),
>> reorganize definitions whenever possible (some NETCONF specific stuff
>> in the YANG specification should not be there, XML encoding may be
>> factored out) and incorporate new features (like yang-data) after we
>> have sufficient _experience_ to know that such new features will be
>> useful (which seems to be the case for yang-data).
>> 
>> Yes, such iterations likely take 2 years at IETF speed but this kind
>> of maintenance cost/effort is likely the price to be paied for
>> something that is being used at a larger scale.
>> 
>> Some people will say that the cost of a new language version is high.
>> (Well, when we did 1.1, some people said it will never be deployed.)
>> Anyway, not bumping the YANG version number but having instead several
>> (optional) language extensions is just hiding the version number
>> change under the carpet.
>> 
>> /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
>> 

-- 
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] yang-data-ext issues

[Ladislav Lhotka]

Robert Varga  writes:

> On 23/04/18 18:51, Juergen Schoenwaelder wrote:
>> Some people will say that the cost of a new language version is high.
>> (Well, when we did 1.1, some people said it will never be deployed.)
>> Anyway, not bumping the YANG version number but having instead several
>> (optional) language extensions is just hiding the version number
>> change under the carpet.
>
> Not quite, as extensions allow for modular/incremental evolution, as an
> implementer I do not have to go through a long development cycle where I
> need to rewire language aspects just to get the features my users need
> for their models...

But what prevents you from forking YANG, indicating it in the
"yang-version" string and implementing your new statements as built-ins?

It is tempting to think about extensions as a magic for adding modular
extensions but it breaks down as soon as such extensions interfere with
the YANG core (with and each other, or both).

Lada

>
> Regards,
> Robert
>

-- 
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] Extensions vs new YANG versions [was Re: yang-data-ext issues]

[Ladislav Lhotka]

Robert Wilton  writes:

> [Renaming the thread because this doesn't seem to be directly applicable 
> to the yang-data extension.]
>
> I think that extensions are great in the sense that they allow YANG to 
> evolve more quickly without requiring a fork lift version upgrade that 
> may take a long time to produce.

This is of course a double-edged sword. In my view, extensions must not
influence the resulting data model, and I thought the last paragraph in
sec. 6.3.1 of RFC 6020 had been intended to mean exactly this.

I would prefer to indicate experimental versions of YANG in the version
string (e.g. as a topical branch), and use YANG extensions only for
stuff that's outside the realm of data modelling. For example, the
extension in NACM is perfectly OK because it is a hint for protocol
operation and doesn't affect the schema in any way.

>
> I agree that all standard defined extensions should cleanly 
> inter-operate with each other.
>
> I also think that it is useful to periodically define new versions of 
> YANG that fold back in all the extensions that have been successfully 
> and are widely deployed.  And also to deprecate/obsolete stuff that 
> hasn't worked well.

Without a metamodel, it is difficult to avoid YANG becoming a kitchen
sink.

And what about extensions that won't make it into the new official
version?  For example, imagine that "openconfig:pattern" won't be
accepted - would it really matter? The forked versions will continue to
exist but they could still claim adherence to the IETF standard (which
is what marketing departments love).

Lada

>
> For me, the interesting question is about namespaces when those 
> extensions are incorporated back into a new version of YANG:
> - Does it just keep the extension prefix that the extension module was 
> originally defined in?
> - Or does the extension get folded into core of the YANG language and no 
> extension prefix is used any more?
> - Or does the extension get supported both with/without the extension 
> namespace prefix?
>
> Thanks,
> Rob
>
>
> On 23/04/2018 21:58, Andy Bierman wrote:
>>
>>
>> On Mon, Apr 23, 2018 at 10:36 AM, Juergen Schoenwaelder 
>> > > wrote:
>>
>> On Mon, Apr 23, 2018 at 07:18:38PM +0200, Robert Varga wrote:
>> > On 23/04/18 18:51, Juergen Schoenwaelder wrote:
>> > > Some people will say that the cost of a new language version
>> is high.
>> > > (Well, when we did 1.1, some people said it will never be
>> deployed.)
>> > > Anyway, not bumping the YANG version number but having instead
>> several
>> > > (optional) language extensions is just hiding the version number
>> > > change under the carpet.
>> >
>> > Not quite, as extensions allow for modular/incremental
>> evolution, as an
>> > implementer I do not have to go through a long development cycle
>> where I
>> > need to rewire language aspects just to get the features my
>> users need
>> > for their models...
>>
>> Once we standardize extensions (and this is what I am talking about),
>> we better make sure that the whole stays consistent. Otherwise, we
>> will end up with patchwork where all the patches may work in isolation
>> but sooner or later they will fall apart when you look at all the
>> possible combinations.
>>
>> I am in favour of managing a clean definition of the core of the YANG
>> language instead of creating patchwork. It is great if people create
>> and prototype new extensions but once such extensions are considered
>> to be ready for general use, we should roll them into the core (and
>> remove any cruft from the core at the same time).
>>
>>
>> I agree with your concerns.
>> If the intent is that a YANG extension is optional, then its semantics 
>> have
>> to be well-scoped so that tools really can skip over the extension 
>> without any problems.
>> If we create standard extensions that standard YANG 1.1 modules use, 
>> then this can
>> become an unofficial add-on to YANG 1.1. (e.g. annotation could 
>> already be considered as such)
>>
>>
>>
>> /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
>> 
>>
>>
>>
>>
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>

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

Re: [netmod] yang-data-ext issues

[Robert Wilton]

On 23/04/2018 21:08, Martin Bjorklund wrote:

Andy Bierman  wrote:



I do not understand the need for a yang-data structure that represents

data

that can be instantiated anywhere and everywhere.

AFAIK noone is proposing that.


I do not want to break
existing tools that expect sibling data nodes in the same module

namespace

to
be unique local-names.

I would rather stick with the yang-data in RFC 8040 than introduce a new
extension
with no restrictions.  Standard YANG extensions should be interoperable

and

have
a clear purpose.

Of course.


If we do not need to define what a YANG extension does in
a way that can be observed somehow, then it does not need to be a

standard.

Agreed.

Not sure how any of this helps with the original issue though.



You proposed that duplicate nodes were OK:

module X {
prefix x;

x:yang-data A {
list foo { ... }
}

x:yang-data B {
   container foo { ... }
}

}


I do not want to allow any duplicates.

Yes, I got that.


There are no encoding and parsing rules for instance data
that support this sort of duplicate.

This is not correct, as I have demonstrated earlier, and I think you
also accepted; if different structures are defined for different rpcs'
error-infos, then these structures can have the same child node names.

I think that we have to agree on the basics before disussing
solutions:

   1)  Should we do anything at all?

   (i.e., keep using yang-data in RFC 8040)
There is also an option 1(b) which is to move the current yang-data 
definition on RFC 8040 into it's own document, just to fix the 
references issue.




   2)  Should we define structures that only can be used in
   standalone instance documents?

   (i.e., *more* restrictive than yang-data in RFC 8040)
I don't think that we should define something more restrictive that 
yang-data in RFC 8040.




   3)  Should we define structures that can be used in standalone
   instance documents, error-info contents, and other places that
   we might not know right now?

   (i.e., *less* restrictive than yang-data in RFC 8040)
I don't know about this one because I'm not sure that I understand the 
problem space well enough.


For some of the categories above would a choice statement + groupings 
works just as well as a yang-data extension?


A different thought, one that has probably been considered before:
 - Could all yang data definitions be defined using groupings instead.  
I.e. a grouping without any associated uses statements.
 - Perhaps an extra statement under the grouping could be used to 
indicate whether the grouping represents a yang data definition.


Thanks,
Rob





Since the current draft says:

The "yang-data" extension statement from RFC
8040 [RFC8040] is defined for this purpose, however it is limited in
its functionality.

The intended use of the "yang-data" extension is to model all or part
of a protocol message, such as the "errors" definition in ietf-
restconf.yang [RFC8040], or the contents of a file.  However,
protocols are often layered such that the header or payload portions
of the message can be extended by external documents.  The YANG
statements that model a protocol need to support this extensibility
that is already found in that protocol.


I thought we are doing (3).



/martin




yang-data definitions define conceptual data nodes (e.g, /x:foo)
Only one data-def-stmt (in yang-data or otherwise) can define a data node
/x:foo.
The descriptive names for the yang-data (A or B) do not define namespaces.




/martin



Andy

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



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

[netmod] Extensions vs new YANG versions [was Re: yang-data-ext issues]

[Robert Wilton]

[Renaming the thread because this doesn't seem to be directly applicable 
to the yang-data extension.]


I think that extensions are great in the sense that they allow YANG to 
evolve more quickly without requiring a fork lift version upgrade that 
may take a long time to produce.


I agree that all standard defined extensions should cleanly 
inter-operate with each other.


I also think that it is useful to periodically define new versions of 
YANG that fold back in all the extensions that have been successfully 
and are widely deployed.  And also to deprecate/obsolete stuff that 
hasn't worked well.


For me, the interesting question is about namespaces when those 
extensions are incorporated back into a new version of YANG:
- Does it just keep the extension prefix that the extension module was 
originally defined in?
- Or does the extension get folded into core of the YANG language and no 
extension prefix is used any more?
- Or does the extension get supported both with/without the extension 
namespace prefix?


Thanks,
Rob


On 23/04/2018 21:58, Andy Bierman wrote:



On Mon, Apr 23, 2018 at 10:36 AM, Juergen Schoenwaelder 
> wrote:


On Mon, Apr 23, 2018 at 07:18:38PM +0200, Robert Varga wrote:
> On 23/04/18 18:51, Juergen Schoenwaelder wrote:
> > Some people will say that the cost of a new language version
is high.
> > (Well, when we did 1.1, some people said it will never be
deployed.)
> > Anyway, not bumping the YANG version number but having instead
several
> > (optional) language extensions is just hiding the version number
> > change under the carpet.
>
> Not quite, as extensions allow for modular/incremental
evolution, as an
> implementer I do not have to go through a long development cycle
where I
> need to rewire language aspects just to get the features my
users need
> for their models...

Once we standardize extensions (and this is what I am talking about),
we better make sure that the whole stays consistent. Otherwise, we
will end up with patchwork where all the patches may work in isolation
but sooner or later they will fall apart when you look at all the
possible combinations.

I am in favour of managing a clean definition of the core of the YANG
language instead of creating patchwork. It is great if people create
and prototype new extensions but once such extensions are considered
to be ready for general use, we should roll them into the core (and
remove any cruft from the core at the same time).


I agree with your concerns.
If the intent is that a YANG extension is optional, then its semantics 
have
to be well-scoped so that tools really can skip over the extension 
without any problems.
If we create standard extensions that standard YANG 1.1 modules use, 
then this can
become an unofficial add-on to YANG 1.1. (e.g. annotation could 
already be considered as such)




/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





___
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