Re: [netmod] yang-data-ext issues

[Kent Watsen]

>> The authors of yang-data-ext met today to discuss how to move this
>> draft forward.  After about an hour, we decided that the best course
>> of action is to:
>> 
>>   * clarify RFC 8040 rc:yang-data for the zerotouch use case
>>   - and update the zerotouch draft to use rc:yang-data
>> 
>>   * request this WG for the unadoption of this draft
>>   - the notification-messages draft solution is TBD
>> 
>> Can the working group, especially the chairs and the affected document
>> authors (all CC-ed) please review this proposal?
>
> What about the ability to augment yang-data?  The proposed instance data
> draft also makes use of yang-data-ext, and I have a use case to augment
> some of its MD.  I realize this draft is not a WG item [yet], but I
> wonder what the co-authors thought around the fate of the augments work.

This is what I meant by "TBD" above.  Undoubtedly, the notification-messages
draft will need to see if there is another way to achieve its end and, if
not, we (NETMOD) will be asked to define an "augment-yang-data" draft, which
just defines the "augment" part of this draft on top of RFC 8040 rc:yang-data.

To those who say that we need a new version of YANG to do this properly, it
seems that we're making an argument for starting YANG-next now.


> Joe

Kent // as co-author


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

Re: [netmod] yang-data-ext issues

[Joe Clarke]

On 6/25/18 14:56, Kent Watsen wrote:
> 
> The authors of yang-data-ext met today to discuss how to move this draft 
> forward.  After about an hour, we decided that the best course of action is 
> to:
> 
>   * clarify RFC 8040 rc:yang-data for the zerotouch use case
>   - and update the zerotouch draft to use rc:yang-data
> 
>   * request this WG for the unadoption of this draft
>   - the notification-messages draft solution is TBD
> 
> Can the working group, especially the chairs and the affected document 
> authors (all CC-ed) please review this proposal?

What about the ability to augment yang-data?  The proposed instance data
draft also makes use of yang-data-ext, and I have a use case to augment
some of its MD.  I realize this draft is not a WG item [yet], but I
wonder what the co-authors thought around the fate of the augments work.

Joe

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

Re: [netmod] yang-data-ext issues

[Kent Watsen]

The authors of yang-data-ext met today to discuss how to move this draft 
forward.  After about an hour, we decided that the best course of action is to:

  * clarify RFC 8040 rc:yang-data for the zerotouch use case
  - and update the zerotouch draft to use rc:yang-data

  * request this WG for the unadoption of this draft
  - the notification-messages draft solution is TBD

Can the working group, especially the chairs and the affected document authors 
(all CC-ed) please review this proposal?

Kent (and Andy and Martin) // as co-authors




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

Re: [netmod] yang-data-ext issues

[Ladislav Lhotka]

Juergen Schoenwaelder  writes:

> On Tue, May 29, 2018 at 03:58:33PM +, Kent Watsen wrote:
>> [resurrecting this thread]
>> 
>> Currently the zerotouch draft has a normative reference to this draft.
>> I will this week post an update to the zerotouch draft to resolve the
>> netconf list thread "a couple zerotouch-21 issues".   It would be easy
>> for me to also switch back to using rc:yang-data, but I won't do so if
>> this draft remains an active work-in-progress.
>> 
>> Please see below for more.
>> 
>> 
>> On Wed, 2018-05-02 at 11:36 +0200, Juergen Schoenwaelder wrote:
>> >On Wed, May 02, 2018 at 11:25:06AM +0200, Martin Bjorklund wrote:
>> >> 
>> >> The primary use case is not "generic RPC messages", but standalone
>> >> instance documents, error-info structures, etc.
>> >
>> > The proper solution for rpcs and actions is to define error
>> > information as part of the rpc/action. YANG 1.1 does not support
>> > this but this is where it should be fixed.
>> 
>> Agreed, but note that the subscribed-notifications draft (both the
>> published -12 and unpublished -13) are relying on being able to do
>> just this, and YANG-next is years away...
>
> There is a description statement.
>
>> > Standalone instance documents (not tied to datastores) may have their
>> > use cases as well but it feels odd to create support for standalone
>> > instance documents as extensions and then to create even more
>> > extensions to support augmentation of these instance documents and
>> > whoever knows what comes next.
>> 
>> What feels "odd" about this?  Is it not using the extension statement
>> as it was intended?

It is odd because RFC 7950 uses a lot of text to specify the special
context and then the extension attempts to remove parts of this context
(IMO incompletely). It would be much more logical to have a simple
context-agnostic YANG spec and then use extensions for adding
context-specific stuff.

Somebody who is only interested in this "yang-data" usage of YANG
still has to read all the nice CLRs in 7950 that only make sense for
NETCONF. 

>
> For me, extensions that define new data definition statements are
> borderline. RFC 7950 has this nice statement:

It is no borderline. The exception explicitly redefines YANG semantics
in its description.

>
>o  extension: An extension attaches non-YANG semantics to statements.
>   The "extension" statement defines new statements to express these
>   semantics.
>
> This does not help since we lack a definition for 'non-YANG semantics'
> and yes I know that yang-data is today defined as an extension. But
> for me, this is a hack and instead of creating a slightly more
> generalized version of this hack, I prefer to stick to yang-data in
> favor of a proper solution as part of YANG.
>  
>> > For short-term needs, there is yang-data defined in RFC 8040.
>> 
>> To be clear, the "short-term needs" are:
>> 
>>   a) zerotouch: to define a standalone instance document
>>   b) notification-messages: to define a new notification message
>>   c) subscribed-notifications: to define error-info structures
>> 
>> As I recall, this draft (not RFC 8040) is needed:
>> 
>>   - for (a), because rc:yang-data doesn't support a top-level
>> "choice" statement spanning "container" statements.
>
> So create a container.
>  
>>   - for (b), in order to augment a base yang-data "message" 
>> structure with additional nodes.
>
> So you are creating another augmentation mechanism. I am concerned
> about ending up with a zoo of different mechanisms if we go down this
> path, we may end up with every project or vendor creating their own
> variants.
>
> With NMDA in place, YANG 1.1 is decribing schemas for datastores plus
> operations and notifications. It is not a protocol message description
> language or a standalone file format description language. If this is
> needed, I prefer to create YANG X.Y - and if we manage the complexity
> we have something that is ideally integrated and consistent.
>
>>   - AFAIAA, RFC 8040 is sufficient for (c)
>> 
>> Has anything changed?   I don't think that we can un-adopt this
>> draft with said dependencies, right?
>
> I am just voicing my opinion. It may very well be that the WG prefers
> to go the route of not touching YANG 1.1 and instead patching around
> its limitations with extensions.
>
> My concern is simply driven that some want to patch in via extensions
> support for describing protocol messages and standalone documents,
> others want to patch via extensions and updates a different versioning
> system, and who knows what comes next. In the long run, I am afraid
> this will become a mess. And yes, it is always difficult to predict
> the future - we need crystal balls. Perhaps as an extension. ;-)

And, luckily, vendors probably haven't yet realized the potential of
extensions for creating proprietary YANG silos. This document should be
very instructive for them.

Lada

>
> /js
>
> -- 
> Juergen Schoenwaelder   Jacobs University 

Re: [netmod] yang-data-ext issues

[Juergen Schoenwaelder]

On Tue, May 29, 2018 at 03:58:33PM +, Kent Watsen wrote:
> [resurrecting this thread]
> 
> Currently the zerotouch draft has a normative reference to this draft.
> I will this week post an update to the zerotouch draft to resolve the
> netconf list thread "a couple zerotouch-21 issues".   It would be easy
> for me to also switch back to using rc:yang-data, but I won't do so if
> this draft remains an active work-in-progress.
> 
> Please see below for more.
> 
> 
> On Wed, 2018-05-02 at 11:36 +0200, Juergen Schoenwaelder wrote:
> >On Wed, May 02, 2018 at 11:25:06AM +0200, Martin Bjorklund wrote:
> >> 
> >> The primary use case is not "generic RPC messages", but standalone
> >> instance documents, error-info structures, etc.
> >
> > The proper solution for rpcs and actions is to define error
> > information as part of the rpc/action. YANG 1.1 does not support
> > this but this is where it should be fixed.
> 
> Agreed, but note that the subscribed-notifications draft (both the
> published -12 and unpublished -13) are relying on being able to do
> just this, and YANG-next is years away...

There is a description statement.

> > Standalone instance documents (not tied to datastores) may have their
> > use cases as well but it feels odd to create support for standalone
> > instance documents as extensions and then to create even more
> > extensions to support augmentation of these instance documents and
> > whoever knows what comes next.
> 
> What feels "odd" about this?  Is it not using the extension statement
> as it was intended?

For me, extensions that define new data definition statements are
borderline. RFC 7950 has this nice statement:

   o  extension: An extension attaches non-YANG semantics to statements.
  The "extension" statement defines new statements to express these
  semantics.

This does not help since we lack a definition for 'non-YANG semantics'
and yes I know that yang-data is today defined as an extension. But
for me, this is a hack and instead of creating a slightly more
generalized version of this hack, I prefer to stick to yang-data in
favor of a proper solution as part of YANG.
 
> > For short-term needs, there is yang-data defined in RFC 8040.
> 
> To be clear, the "short-term needs" are:
> 
>   a) zerotouch: to define a standalone instance document
>   b) notification-messages: to define a new notification message
>   c) subscribed-notifications: to define error-info structures
> 
> As I recall, this draft (not RFC 8040) is needed:
> 
>   - for (a), because rc:yang-data doesn't support a top-level
> "choice" statement spanning "container" statements.

So create a container.
 
>   - for (b), in order to augment a base yang-data "message" 
> structure with additional nodes.

So you are creating another augmentation mechanism. I am concerned
about ending up with a zoo of different mechanisms if we go down this
path, we may end up with every project or vendor creating their own
variants.

With NMDA in place, YANG 1.1 is decribing schemas for datastores plus
operations and notifications. It is not a protocol message description
language or a standalone file format description language. If this is
needed, I prefer to create YANG X.Y - and if we manage the complexity
we have something that is ideally integrated and consistent.

>   - AFAIAA, RFC 8040 is sufficient for (c)
> 
> Has anything changed?   I don't think that we can un-adopt this
> draft with said dependencies, right?

I am just voicing my opinion. It may very well be that the WG prefers
to go the route of not touching YANG 1.1 and instead patching around
its limitations with extensions.

My concern is simply driven that some want to patch in via extensions
support for describing protocol messages and standalone documents,
others want to patch via extensions and updates a different versioning
system, and who knows what comes next. In the long run, I am afraid
this will become a mess. And yes, it is always difficult to predict
the future - we need crystal balls. Perhaps as an extension. ;-)

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

[Kent Watsen]

[resurrecting this thread]

Currently the zerotouch draft has a normative reference to this draft.
I will this week post an update to the zerotouch draft to resolve the
netconf list thread "a couple zerotouch-21 issues".   It would be easy
for me to also switch back to using rc:yang-data, but I won't do so if
this draft remains an active work-in-progress.

Please see below for more.


On Wed, 2018-05-02 at 11:36 +0200, Juergen Schoenwaelder wrote:
>On Wed, May 02, 2018 at 11:25:06AM +0200, Martin Bjorklund wrote:
>> 
>> The primary use case is not "generic RPC messages", but standalone
>> instance documents, error-info structures, etc.
>
> The proper solution for rpcs and actions is to define error
> information as part of the rpc/action. YANG 1.1 does not support
> this but this is where it should be fixed.

Agreed, but note that the subscribed-notifications draft (both the
published -12 and unpublished -13) are relying on being able to do
just this, and YANG-next is years away...


> Standalone instance documents (not tied to datastores) may have their
> use cases as well but it feels odd to create support for standalone
> instance documents as extensions and then to create even more
> extensions to support augmentation of these instance documents and
> whoever knows what comes next.

What feels "odd" about this?  Is it not using the extension statement
as it was intended?


> For short-term needs, there is yang-data defined in RFC 8040.

To be clear, the "short-term needs" are:

  a) zerotouch: to define a standalone instance document
  b) notification-messages: to define a new notification message
  c) subscribed-notifications: to define error-info structures


As I recall, this draft (not RFC 8040) is needed:

  - for (a), because rc:yang-data doesn't support a top-level
"choice" statement spanning "container" statements.

  - for (b), in order to augment a base yang-data "message" 
structure with additional nodes.

  - AFAIAA, RFC 8040 is sufficient for (c)


Has anything changed?   I don't think that we can un-adopt this
draft with said dependencies, right?


Kent



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

Re: [netmod] yang-data-ext issues

[Robert Varga]

On 27/04/18 12:03, Martin Bjorklund wrote:
>>> This is true. We used to do this before yang-data was available.
>> If I remember correctly, the stuff was inside groupings that were not used
>> anywhere.
> Which doesn't quite work, since no namespace is attached to the nodes.
> 

True, but that is can boil down to a simple data transplant:

1) treat the nodes declared in a grouping to be defined underneath their
containing grouping identifier
2) recognized when grouping instantiations are data-compatible (i.e.
disregarding namespace)

Unlike an extension, this behavior becomes default-on, not something you
opt into by using an extension -- which would necessitate a revision of
existing modules take advantage of.

Regards,
Robert

P.S.: OpenDaylight Java Bindinds do this to a certain, not perfect, extent.



signature.asc
Description: OpenPGP digital signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] yang-data-ext issues

[Robert Varga]

On 27/04/18 12:03, Martin Bjorklund wrote:
>> It would be great to remove NETCONF specifics from YANG and I'd be willing to
>> contribute to this work.
> This is a different topic though.

+1 and count me in, please.

Thanks,
Robert



signature.asc
Description: OpenPGP digital signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] yang-data-ext issues

[Ladislav Lhotka]

On Wed, 2018-05-02 at 11:36 +0200, Juergen Schoenwaelder wrote:
> On Wed, May 02, 2018 at 11:25:06AM +0200, Martin Bjorklund wrote:
> > 
> > The primary use case is not "generic RPC messages", but standalone
> > instance documents, error-info structures, etc.
> > 
> > > This doesn't seem to be a fundamental change in YANG's scope, or
> > > architecture.
> 
> The proper solution for rpcs and actions is to define error
> information as part of the rpc/action. YANG 1.1 does not support
> this but this is where it should be fixed.
> 
> Standalone instance documents (not tied to datastores) may have their
> use cases as well but it feels odd to create support for standalone
> instance documents as extensions and then to create even more
> extensions to support augmentation of these instance documents and
> whoever knows what comes next. For short-term needs, there is
> yang-data defined in RFC 8040. The longer-term solution should IMHO be
> a proper part of YANG and not an extension.
> 
> And if the current short-term solution requires an additional
> container, then bam go for the additional container. If there is
> serious pressure to use yang-data, then the additional container
> should not stop people that need to use yang-data today.

I agree with all of the above.

Lada

> 
> /js
> 
-- 
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

[Juergen Schoenwaelder]

On Wed, May 02, 2018 at 11:25:06AM +0200, Martin Bjorklund wrote:
> 
> The primary use case is not "generic RPC messages", but standalone
> instance documents, error-info structures, etc.
> 
> > This doesn't seem to be a fundamental change in YANG's scope, or
> > architecture.

The proper solution for rpcs and actions is to define error
information as part of the rpc/action. YANG 1.1 does not support
this but this is where it should be fixed.

Standalone instance documents (not tied to datastores) may have their
use cases as well but it feels odd to create support for standalone
instance documents as extensions and then to create even more
extensions to support augmentation of these instance documents and
whoever knows what comes next. For short-term needs, there is
yang-data defined in RFC 8040. The longer-term solution should IMHO be
a proper part of YANG and not an extension.

And if the current short-term solution requires an additional
container, then bam go for the additional container. If there is
serious pressure to use yang-data, then the additional container
should not stop people that need to use yang-data today.

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

[Martin Bjorklund]

Robert Wilton  wrote:
> 
> 
> On 02/05/2018 08:25, Martin Bjorklund wrote:
> > Andy Bierman  wrote:
> >> On Mon, Apr 30, 2018 at 7:09 AM, Ladislav Lhotka 
> >> wrote:
> >>
> >>> Andy Bierman  writes:
> >>>
>  On Fri, Apr 27, 2018 at 8:13 AM, Ladislav Lhotka 
>  wrote:
> 
> > On Fri, 2018-04-27 at 16:47 +0200, Juergen Schoenwaelder wrote:
> >> On Fri, Apr 27, 2018 at 04:34:38PM +0200, Ladislav Lhotka wrote:
> >>
> >>> [...] define a special datastore for it, such as "error-messages".
> >> This seems worse than using, well, RFC 8040 yang-data. The proper
> > Why it seems worse?
> >
> >
>  Because this is not part of the NMDA.
> >>> NMDA is extensible.
> >>>
> >>
> >> If your only tool is a hammer, then all your problems look like nails.
> >> I fail to see how an "error-messages" datastore fits in with NMDA
> >>
> >>
> >>
>  IMO, the yang-data defined in RFC 8040 has a clear purpose, and it
>  is sufficient for that purpose, which is a YANG representation of
>  an instance document (such as a protocol message or file).
> >>> The same is basically true even without the extension. For example, I
> >>> fail to see any benefit from using yang-data in a module like
> >>> ietf-zerotouch-information.
> >>>
> >>
> >> I don't see the benefit of pretending all data-def-stmts represent
> >> configuration or operational data.
> >>
> >> Wrapping the data-def-stmts in an extension says "this is not
> >> configuration
> >> or operational data".  This is useful for tools that can process YANG
> >> in
> >> other contexts.
> > I fully agree
> 
> YANG already models RPCs, and 7950 makes it clear that the
> input/output parameters of those RPC statements are not configuration
> or state and are not modeled in datastores.  I.e.:
> 
>Since the input tree is not part of any datastore, all "config"
>statements for nodes in the input tree are ignored.
> 
> 
>Since the output tree is not part of any datastore, all "config"
>statements for nodes in the output tree are ignored.
> 
> 
> Isn't the YANG data extension just modelling fragments of YANG to be
> used in generic RPC messages?

The primary use case is not "generic RPC messages", but standalone
instance documents, error-info structures, etc.

> This doesn't seem to be a fundamental change in YANG's scope, or
> architecture.

I agree.


/martin


> 
> Thanks,
> Rob
> 
> 
> >
>  YANG is useful for defining data structures that can be represented in
>  different formats, yet it is independent of any 1 format.
> >>> Of course I see this potential. Unfortunately, YANG spec was
> >>> explicitly
> >>> written for a very specific context. Using an extension for removing
> >>> this specificity is IMO an ugly hack that undermines the architecture.
> >>>
> >>>
> >> I don't see the architecture as fragile or damaged if yang-data is
> >> used.
> >>
> >> People are going to continue to push the boundaries of YANG
> >> capabilities.
> >> This will happen with or without the IETF.
> > Yes, and it already happens.
> >
> >
> > /martin
> >
> >
> >
> >> Maybe this work should remain
> >> proprietary or get moved to an opensource project.
> >>
> >>
> >>
> >>
>  I am in favor if keeping the yang-data in RFC 8040 and not
>  creating a new version of it that is unconstrained.
>  There does not seem to be consensus on how to do this,
>  or even consensus that it is a good idea.
> 
> >>> If the extension is deemed necessary, I would also prefer this
> >>> approach
> >>> to making the extension a Proposed Standard.
> >>>
> >>> Lada
> >>>
> >>
> >> Andy
> >>
> >>
> 
> >> clear solution for RPCs and actions would be to enable the definition
> >> of error details right in the rpc/action definition (input, output,
> >> error).
> > Agreed.
> >
> >> But something like yang-data seems to have uses in other contexts.
> > So other datastores may be defined. I assume that YANG library data
> > can
> >>> be
> > used
> > independently, not just on a NC/RC server, pretty much along the lines
> >>> of
> > draft-
> > lengyel-netmod-yang-instance-data.
> >
> > Lada
> >
>  Andy
> 
> 
> 
> >> /js
> >>
> > --
> > Ladislav Lhotka
> > Head, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
> >
> > ___
> > 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
> > .
> >
> 
___
netmod mailing list
netmod@ietf.org

Re: [netmod] yang-data-ext issues

[Robert Wilton]

On 02/05/2018 08:25, Martin Bjorklund wrote:

Andy Bierman  wrote:

On Mon, Apr 30, 2018 at 7:09 AM, Ladislav Lhotka  wrote:


Andy Bierman  writes:


On Fri, Apr 27, 2018 at 8:13 AM, Ladislav Lhotka  wrote:


On Fri, 2018-04-27 at 16:47 +0200, Juergen Schoenwaelder wrote:

On Fri, Apr 27, 2018 at 04:34:38PM +0200, Ladislav Lhotka wrote:


[...] define a special datastore for it, such as "error-messages".

This seems worse than using, well, RFC 8040 yang-data. The proper

Why it seems worse?



Because this is not part of the NMDA.

NMDA is extensible.



If your only tool is a hammer, then all your problems look like nails.
I fail to see how an "error-messages" datastore fits in with NMDA




IMO, the yang-data defined in RFC 8040 has a clear purpose, and it
is sufficient for that purpose, which is a YANG representation of
an instance document (such as a protocol message or file).

The same is basically true even without the extension. For example, I
fail to see any benefit from using yang-data in a module like
ietf-zerotouch-information.



I don't see the benefit of pretending all data-def-stmts represent
configuration or operational data.

Wrapping the data-def-stmts in an extension says "this is not configuration
or operational data".  This is useful for tools that can process YANG in
other contexts.

I fully agree


YANG already models RPCs, and 7950 makes it clear that the input/output 
parameters of those RPC statements are not configuration or state and 
are not modeled in datastores.  I.e.:


   Since the input tree is not part of any datastore, all "config"
   statements for nodes in the input tree are ignored.


   Since the output tree is not part of any datastore, all "config"
   statements for nodes in the output tree are ignored.


Isn't the YANG data extension just modelling fragments of YANG to be 
used in generic RPC messages?


This doesn't seem to be a fundamental change in YANG's scope, or 
architecture.


Thanks,
Rob





YANG is useful for defining data structures that can be represented in
different formats, yet it is independent of any 1 format.

Of course I see this potential. Unfortunately, YANG spec was explicitly
written for a very specific context. Using an extension for removing
this specificity is IMO an ugly hack that undermines the architecture.



I don't see the architecture as fragile or damaged if yang-data is used.

People are going to continue to push the boundaries of YANG capabilities.
This will happen with or without the IETF.

Yes, and it already happens.


/martin




Maybe this work should remain
proprietary or get moved to an opensource project.





I am in favor if keeping the yang-data in RFC 8040 and not
creating a new version of it that is unconstrained.
There does not seem to be consensus on how to do this,
or even consensus that it is a good idea.


If the extension is deemed necessary, I would also prefer this approach
to making the extension a Proposed Standard.

Lada



Andy





clear solution for RPCs and actions would be to enable the definition
of error details right in the rpc/action definition (input, output,
error).

Agreed.


But something like yang-data seems to have uses in other contexts.

So other datastores may be defined. I assume that YANG library data can

be

used
independently, not just on a NC/RC server, pretty much along the lines

of

draft-
lengyel-netmod-yang-instance-data.

Lada


Andy




/js


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

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



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

Re: [netmod] yang-data-ext issues

[Martin Bjorklund]

Ladislav Lhotka  wrote:
> On Wed, 2018-05-02 at 09:16 +0200, Martin Bjorklund wrote:
> > Ladislav Lhotka  wrote:
> > > On Fri, 2018-04-27 at 12:19 +0100, Robert Wilton wrote:
> > > > 
> > > > On 27/04/2018 12:03, Ladislav Lhotka wrote:
> > > > > On Fri, 2018-04-27 at 11:23 +0100, Robert Wilton wrote:
> > > > > > On 27/04/2018 11:03, Martin Bjorklund wrote:
> > > > > > > Hi,
> > > > > > > 
> > > > > > > Ladislav Lhotka  wrote:
> > > > > > > > On Thu, 2018-04-26 at 17:52 -0700, Andy Bierman wrote:
> > > > > > > > > On Wed, Apr 25, 2018 at 10:53 PM, Ladislav Lhotka 
> > > > > > > > >  > >
> > > > > > > > > wrote:
> > > > > > > > > > Ladislav Lhotka  writes:
> > > > > > > > > > 
> > > > > > > > > > > On Wed, 2018-04-25 at 08:04 -0700, Andy Bierman wrote:
> > > > > > > > > > > > On Wed, Apr 25, 2018 at 7:05 AM, Ladislav Lhotka 
> > > > > > > > > > > >  > ic.c
> > > > > > > > > > > > z>
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > > On Wed, 2018-04-25 at 15:55 +0200, Juergen 
> > > > > > > > > > > > > Schoenwaelder
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > On Tue, Apr 24, 2018 at 04:36:01PM +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
> > > > > > > > > > > > > > > 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?
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > One option is that people use yang-data as defined 
> > > > > > > > > > > > > > in
> > RFC
> > > > > > > > > > > > > > 8040
> > > > > > > > > > > > > > until
> > > > > > > > > > > > > 
> > > > > > > > > > > > > IMO, people should use plain YANG. With the new YANG
> > library
> > > > > > > > > > > > > it
> > > > > > > > > > > > > will be
> > > > > > > > > > > > > possible
> > > > > > > > > > > > > to confine such non-NM schemas in a special datastore 
> > > > > > > > > > > > > so
> > > > > > > > > > > > > that
> > > > > > > > > > > > > the
> > > > > > > > > > 
> > > > > > > > > > intention
> > > > > > > > > > > > > should be clear and multi-module schemas with all the
> > > > > > > > > > > > > additional
> > > > > > > > > > > > > data
> > > > > > > > > > > > > (versions,
> > > > > > > > > > > > >features, deviations) can be used.
> > > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > I don't see how yang-data interferes with "plain YANG" 
> > > > > > > > > > > > at
> > all.
> > > > > > > > > > > > It is for data that is not in scope for plain YANG.
> > > > > > > > > > > 
> > > > > > > > > > > My question is why this extension is needed in the first
> > place.
> > > > > > > > > > 
> > > > > > > > > > For example, RFC 8040 could have used two modules instead of
> > > > > > > > > > "ietf-restconf", one with the contents of grouping "errors"
> > and
> > > > > > > > > > the
> > > > > > > > > > other with the contents of grouping "restconf". No 
> > > > > > > > > > extension.
> > > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > This is true. We used to do this before yang-data was 
> > > > > > > > > available.
> > > > > > > > 
> > > > > > > > If I remember correctly, the stuff was inside groupings that 
> > > > > > > > were
> > not
> > > > > > > > used
> > > > > > > > anywhere.
> > > > > > > 
> > > > > > > Which doesn't quite work, since no namespace is attached to the
> > nodes.
> > > > > 
> > > > > Note that this is not what I was proposing. For RESTCONF errors, the
> > module
> > > > > I
> > > > > had in mind could be like this:
> > > > > 
> > > > > module ietf-restconf-errors {
> > > > > 
> > > > >container errors { // same content as in RFC 8040
> > > > >  ...
> > > > >}
> > > > > 
> > > > >...
> > > > > 
> > > > > }

Re: [netmod] yang-data-ext issues

[Ladislav Lhotka]

On Wed, 2018-05-02 at 09:16 +0200, Martin Bjorklund wrote:
> Ladislav Lhotka  wrote:
> > On Fri, 2018-04-27 at 12:19 +0100, Robert Wilton wrote:
> > > 
> > > On 27/04/2018 12:03, Ladislav Lhotka wrote:
> > > > On Fri, 2018-04-27 at 11:23 +0100, Robert Wilton wrote:
> > > > > On 27/04/2018 11:03, Martin Bjorklund wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > Ladislav Lhotka  wrote:
> > > > > > > On Thu, 2018-04-26 at 17:52 -0700, Andy Bierman wrote:
> > > > > > > > On Wed, Apr 25, 2018 at 10:53 PM, Ladislav Lhotka  >
> > > > > > > > wrote:
> > > > > > > > > Ladislav Lhotka  writes:
> > > > > > > > > 
> > > > > > > > > > On Wed, 2018-04-25 at 08:04 -0700, Andy Bierman wrote:
> > > > > > > > > > > On Wed, Apr 25, 2018 at 7:05 AM, Ladislav Lhotka  ic.c
> > > > > > > > > > > z>
> > > > > > > > > > > wrote:
> > > > > > > > > > > > On Wed, 2018-04-25 at 15:55 +0200, Juergen Schoenwaelder
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > > On Tue, Apr 24, 2018 at 04:36:01PM +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
> > > > > > > > > > > > > > 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?
> > > > > > > > > > > > > 
> > > > > > > > > > > > > One option is that people use yang-data as defined in
> RFC
> > > > > > > > > > > > > 8040
> > > > > > > > > > > > > until
> > > > > > > > > > > > 
> > > > > > > > > > > > IMO, people should use plain YANG. With the new YANG
> library
> > > > > > > > > > > > it
> > > > > > > > > > > > will be
> > > > > > > > > > > > possible
> > > > > > > > > > > > to confine such non-NM schemas in a special datastore so
> > > > > > > > > > > > that
> > > > > > > > > > > > the
> > > > > > > > > 
> > > > > > > > > intention
> > > > > > > > > > > > should be clear and multi-module schemas with all the
> > > > > > > > > > > > additional
> > > > > > > > > > > > data
> > > > > > > > > > > > (versions,
> > > > > > > > > > > >features, deviations) can be used.
> > > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > I don't see how yang-data interferes with "plain YANG" at
> all.
> > > > > > > > > > > It is for data that is not in scope for plain YANG.
> > > > > > > > > > 
> > > > > > > > > > My question is why this extension is needed in the first
> place.
> > > > > > > > > 
> > > > > > > > > For example, RFC 8040 could have used two modules instead of
> > > > > > > > > "ietf-restconf", one with the contents of grouping "errors"
> and
> > > > > > > > > the
> > > > > > > > > other with the contents of grouping "restconf". No extension.
> > > > > > > > > 
> > > > > > > > 
> > > > > > > > This is true. We used to do this before yang-data was available.
> > > > > > > 
> > > > > > > If I remember correctly, the stuff was inside groupings that were
> not
> > > > > > > used
> > > > > > > anywhere.
> > > > > > 
> > > > > > Which doesn't quite work, since no namespace is attached to the
> nodes.
> > > > 
> > > > Note that this is not what I was proposing. For RESTCONF errors, the
> module
> > > > I
> > > > had in mind could be like this:
> > > > 
> > > > module ietf-restconf-errors {
> > > > 
> > > >container errors { // same content as in RFC 8040
> > > >  ...
> > > >}
> > > > 
> > > >...
> > > > 
> > > > }
> > > > 
> > > > Please explain why this cannot serve the given purpose, apart from the
> fact
> > > > that
> > > > it looks like configuration which it isn't - but this can be explained
> in
> > > > the
> > > > module description.
> > > 
> > > It is the "because it looks like configuration" that I don't like.
> > 
> > IMO this won't change even if the same data is inside the "yang-data"
> extension
> > because RFC 7950 says in sec. 7.21.1:
> > 
> >If the top node does not specify a "config" statement, the 

Re: [netmod] yang-data-ext issues

[Martin Bjorklund]

Kent Watsen  wrote:
> 
> Lada writes:
> > Andy writes:
> >>IMO, the yang-data defined in RFC 8040 has a clear purpose, and it
> >>is sufficient for that purpose, which is a YANG representation of
> >>an instance document (such as a protocol message or file).
> >
> > The same is basically true even without the extension. For example, I
> > fail to see any benefit from using yang-data in a module like
> > ietf-zerotouch-information.
> 
> I don't understand this, how else would you propose to define the
> JSON-or-XML encoded payload of the CMS structure?
> 
> 
> >> I am in favor if keeping the yang-data in RFC 8040 and not
> >> creating a new version of it that is unconstrained.
> >> There does not seem to be consensus on how to do this,
> >> or even consensus that it is a good idea.
> >
> > If the extension is deemed necessary, I would also prefer this 
> > approach to making the extension a Proposed Standard.
> 
> I don't understand talk about abandoning this draft.  There is no question
> that it is needed (e.g., anima vouch, zerotouch, tail-f's "structure"),
> and RFC 8040 is unsatisfactory because 1) it doesn't allow a top-level
> 'choice' between two containers and 2) it requires drafts to reference 
> RFC 8040, even though the drafts may have nothing to do with RESTCONF.

and 3) it is not possible to augement 8040's yang-data.

> Sure, maybe we have convinced ourselves that yang-data is not needed
> to model error-info

I don't think there have been any other proposal for how to model
error-info that have any sort of concensus behind it.

> , but that doesn't negate the other use case.
> 
> We need a way to indicate that some data-model represents a stand-alone
> data structure.  It is not configuration, operational state, an RPC, or
> a notification.  It can only appear as a descendent of the 'module'
> statement.  All 'action', 'notification', 'config', and 'if-feature'
> descendent statements are ignored.  For the purpose of 'must' and '
> when' statements, the yang-data structure is its own context root.  It
> has a namespace and a unique local name (unique only to other yang-data
> defined within the same module; it's okay if an RPC, notification, or
> top-level data node has the same name).  Anything else?



/martin

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

Re: [netmod] yang-data-ext issues

[Martin Bjorklund]

Andy Bierman  wrote:
> On Mon, Apr 30, 2018 at 7:09 AM, Ladislav Lhotka  wrote:
> 
> > Andy Bierman  writes:
> >
> > > On Fri, Apr 27, 2018 at 8:13 AM, Ladislav Lhotka  wrote:
> > >
> > >> On Fri, 2018-04-27 at 16:47 +0200, Juergen Schoenwaelder wrote:
> > >> > On Fri, Apr 27, 2018 at 04:34:38PM +0200, Ladislav Lhotka wrote:
> > >> >
> > >> > > [...] define a special datastore for it, such as "error-messages".
> > >> >
> > >> > This seems worse than using, well, RFC 8040 yang-data. The proper
> > >>
> > >> Why it seems worse?
> > >>
> > >>
> > > Because this is not part of the NMDA.
> >
> > NMDA is extensible.
> >
> 
> 
> If your only tool is a hammer, then all your problems look like nails.
> I fail to see how an "error-messages" datastore fits in with NMDA
> 
> 
> 
> >
> > > IMO, the yang-data defined in RFC 8040 has a clear purpose, and it
> > > is sufficient for that purpose, which is a YANG representation of
> > > an instance document (such as a protocol message or file).
> >
> > The same is basically true even without the extension. For example, I
> > fail to see any benefit from using yang-data in a module like
> > ietf-zerotouch-information.
> >
> 
> 
> I don't see the benefit of pretending all data-def-stmts represent
> configuration or operational data.
> 
> Wrapping the data-def-stmts in an extension says "this is not configuration
> or operational data".  This is useful for tools that can process YANG in
> other contexts.

I fully agree

> > > YANG is useful for defining data structures that can be represented in
> > > different formats, yet it is independent of any 1 format.
> >
> > Of course I see this potential. Unfortunately, YANG spec was explicitly
> > written for a very specific context. Using an extension for removing
> > this specificity is IMO an ugly hack that undermines the architecture.
> >
> >
> 
> I don't see the architecture as fragile or damaged if yang-data is used.
> 
> People are going to continue to push the boundaries of YANG capabilities.
> This will happen with or without the IETF.

Yes, and it already happens.


/martin



> Maybe this work should remain
> proprietary or get moved to an opensource project.
> 
> 
> 
> 
> > >
> > > I am in favor if keeping the yang-data in RFC 8040 and not
> > > creating a new version of it that is unconstrained.
> > > There does not seem to be consensus on how to do this,
> > > or even consensus that it is a good idea.
> > >
> >
> > If the extension is deemed necessary, I would also prefer this approach
> > to making the extension a Proposed Standard.
> >
> > Lada
> >
> 
> 
> Andy
> 
> 
> >
> > >
> > >
> > >> > clear solution for RPCs and actions would be to enable the definition
> > >> > of error details right in the rpc/action definition (input, output,
> > >> > error).
> > >>
> > >> Agreed.
> > >>
> > >> >
> > >> > But something like yang-data seems to have uses in other contexts.
> > >>
> > >> So other datastores may be defined. I assume that YANG library data can
> > be
> > >> used
> > >> independently, not just on a NC/RC server, pretty much along the lines
> > of
> > >> draft-
> > >> lengyel-netmod-yang-instance-data.
> > >>
> > >> Lada
> > >>
> > >> >
> > >>
> > >
> > > Andy
> > >
> > >
> > >
> > >> > /js
> > >> >
> > >> --
> > >> Ladislav Lhotka
> > >> Head, CZ.NIC Labs
> > >> PGP Key ID: 0xB8F92B08A9F76C67
> > >>
> > >> ___
> > >> 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

[Juergen Schoenwaelder]

On Tue, May 01, 2018 at 08:33:58PM +, Kent Watsen wrote:
> 
> Juergen writes:
> > Kent writes:
> >> I don't understand talk about abandoning this draft.  There is no question
> >> that it is needed (e.g., anima vouch, zerotouch, tail-f's "structure"),
> >> and RFC 8040 is unsatisfactory because 1) it doesn't allow a top-level
> >> 'choice' between two containers and 2) it requires drafts to reference 
> >> RFC 8040, even though the drafts may have nothing to do with RESTCONF.
> >>
> >
> > Re 1: RFC 8040 says: "It MUST contain data definition statements that
> > result in exactly one container data node definition." So a choice may
> > actually work as long as the result is exactly one container data
> > node. OK, the wording in the RFC 8040 statement is not clear since
> > 'result' and 'definition' do not line up (does 'result' mean the
> > toplevel data node instances that are possible? In this case,
> > 'definition' would be misleading).
> 
> I agree, but Martin did not and he even modified `pyang` to throw an 
> error on the zerotouch draft, thus forcing the current situation.  If
> a new understanding regarding rc:yang-data can be reached, the zerotouch
> draft can go back to using it.

Well, the statement in RFC 8040 is not clear (to me).
 
> > Re 2: It does not really matter whether you import the extension from
> > RFC 8040 or some other module. Why is depending on A better than
> > depending on B? The definition in RFC 8040 is already know by tools.
> >
> > I view the yang-data definition of RFC 8040 as a temporary solution, a
> > proper solution should in my view be part of YANG 1.x.
> 
> What is the "proper solution", and why does it need to wait for YANG 1.x?
> In the discussion regarding moving faster, it's been suggested that YANG 
> 1.x could be a cherry-picking of some number of extension statements 
> produced in other I-Ds.  I was hoping that this was the case here.  True,
> some tools know about A, but if B is the LTS, then I'd hope to move to B
> ASAP.

You will end up with yang-data defined in ietf-restconf, yang-data
defined in ietf-yang-data-ext, and something long-term stable in YANG
1.x. Do people really believe that creating three variants will be
simpler and more effective? The experiment is yang-data in
ietf-restconf - why do we need another experiment?

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

[Kent Watsen]

Juergen writes:
> Kent writes:
>> I don't understand talk about abandoning this draft.  There is no question
>> that it is needed (e.g., anima vouch, zerotouch, tail-f's "structure"),
>> and RFC 8040 is unsatisfactory because 1) it doesn't allow a top-level
>> 'choice' between two containers and 2) it requires drafts to reference 
>> RFC 8040, even though the drafts may have nothing to do with RESTCONF.
>>
>
> Re 1: RFC 8040 says: "It MUST contain data definition statements that
> result in exactly one container data node definition." So a choice may
> actually work as long as the result is exactly one container data
> node. OK, the wording in the RFC 8040 statement is not clear since
> 'result' and 'definition' do not line up (does 'result' mean the
> toplevel data node instances that are possible? In this case,
> 'definition' would be misleading).

I agree, but Martin did not and he even modified `pyang` to throw an 
error on the zerotouch draft, thus forcing the current situation.  If
a new understanding regarding rc:yang-data can be reached, the zerotouch
draft can go back to using it.


> Re 2: It does not really matter whether you import the extension from
> RFC 8040 or some other module. Why is depending on A better than
> depending on B? The definition in RFC 8040 is already know by tools.
>
> I view the yang-data definition of RFC 8040 as a temporary solution, a
> proper solution should in my view be part of YANG 1.x.

What is the "proper solution", and why does it need to wait for YANG 1.x?
In the discussion regarding moving faster, it's been suggested that YANG 
1.x could be a cherry-picking of some number of extension statements 
produced in other I-Ds.  I was hoping that this was the case here.  True,
some tools know about A, but if B is the LTS, then I'd hope to move to B
ASAP.

> Since NMDA essentially binds all data tree definitions to datastores,
> the yang-data construct allows us to define data structures that are
> specifically not bound to any datastore, i.e., data structures that by
> design can't be operated on directly with NMDA NETCONF/RESTCONF.

Yes.


Kent // contributor




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

Re: [netmod] yang-data-ext issues

[Juergen Schoenwaelder]

On Mon, Apr 30, 2018 at 05:57:34PM +, Kent Watsen wrote:
> 
> I don't understand talk about abandoning this draft.  There is no question
> that it is needed (e.g., anima vouch, zerotouch, tail-f's "structure"),
> and RFC 8040 is unsatisfactory because 1) it doesn't allow a top-level
> 'choice' between two containers and 2) it requires drafts to reference 
> RFC 8040, even though the drafts may have nothing to do with RESTCONF.
>

Re 1: RFC 8040 says: "It MUST contain data definition statements that
result in exactly one container data node definition." So a choice may
actually work as long as the result is exactly one container data
node. OK, the wording in the RFC 8040 statement is not clear since
'result' and 'definition' do not line up (does 'result' mean the
toplevel data node instances that are possible? In this case,
'definition' would be misleading).

Re 2: It does not really matter whether you import the extension from
RFC 8040 or some other module. Why is depending on A better than
depending on B? The definition in RFC 8040 is already know by tools.

I view the yang-data definition of RFC 8040 as a temporary solution, a
proper solution should in my view be part of YANG 1.x.

Since NMDA essentially binds all data tree definitions to datastores,
the yang-data construct allows us to define data structures that are
specifically not bound to any datastore, i.e., data structures that by
design can't be operated on directly with NMDA NETCONF/RESTCONF.

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

[Kent Watsen]

Lada writes:
> Andy writes:
>>IMO, the yang-data defined in RFC 8040 has a clear purpose, and it
>>is sufficient for that purpose, which is a YANG representation of
>>an instance document (such as a protocol message or file).
>
> The same is basically true even without the extension. For example, I
> fail to see any benefit from using yang-data in a module like
> ietf-zerotouch-information.

I don't understand this, how else would you propose to define the
JSON-or-XML encoded payload of the CMS structure?


>> I am in favor if keeping the yang-data in RFC 8040 and not
>> creating a new version of it that is unconstrained.
>> There does not seem to be consensus on how to do this,
>> or even consensus that it is a good idea.
>
> If the extension is deemed necessary, I would also prefer this 
> approach to making the extension a Proposed Standard.

I don't understand talk about abandoning this draft.  There is no question
that it is needed (e.g., anima vouch, zerotouch, tail-f's "structure"),
and RFC 8040 is unsatisfactory because 1) it doesn't allow a top-level
'choice' between two containers and 2) it requires drafts to reference 
RFC 8040, even though the drafts may have nothing to do with RESTCONF.

Sure, maybe we have convinced ourselves that yang-data is not needed
to model error-info, but that doesn't negate the other use case.

We need a way to indicate that some data-model represents a stand-alone
data structure.  It is not configuration, operational state, an RPC, or
a notification.  It can only appear as a descendent of the 'module'
statement.  All 'action', 'notification', 'config', and 'if-feature'
descendent statements are ignored.  For the purpose of 'must' and '
when' statements, the yang-data structure is its own context root.  It
has a namespace and a unique local name (unique only to other yang-data
defined within the same module; it's okay if an RPC, notification, or
top-level data node has the same name).  Anything else?


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 30, 2018 at 7:09 AM, Ladislav Lhotka  wrote:

> Andy Bierman  writes:
>
> > On Fri, Apr 27, 2018 at 8:13 AM, Ladislav Lhotka  wrote:
> >
> >> On Fri, 2018-04-27 at 16:47 +0200, Juergen Schoenwaelder wrote:
> >> > On Fri, Apr 27, 2018 at 04:34:38PM +0200, Ladislav Lhotka wrote:
> >> >
> >> > > [...] define a special datastore for it, such as "error-messages".
> >> >
> >> > This seems worse than using, well, RFC 8040 yang-data. The proper
> >>
> >> Why it seems worse?
> >>
> >>
> > Because this is not part of the NMDA.
>
> NMDA is extensible.
>


If your only tool is a hammer, then all your problems look like nails.
I fail to see how an "error-messages" datastore fits in with NMDA



>
> > IMO, the yang-data defined in RFC 8040 has a clear purpose, and it
> > is sufficient for that purpose, which is a YANG representation of
> > an instance document (such as a protocol message or file).
>
> The same is basically true even without the extension. For example, I
> fail to see any benefit from using yang-data in a module like
> ietf-zerotouch-information.
>


I don't see the benefit of pretending all data-def-stmts represent
configuration or operational data.

Wrapping the data-def-stmts in an extension says "this is not configuration
or operational data".  This is useful for tools that can process YANG in
other contexts.



> >
> > YANG is useful for defining data structures that can be represented in
> > different formats, yet it is independent of any 1 format.
>
> Of course I see this potential. Unfortunately, YANG spec was explicitly
> written for a very specific context. Using an extension for removing
> this specificity is IMO an ugly hack that undermines the architecture.
>
>

I don't see the architecture as fragile or damaged if yang-data is used.

People are going to continue to push the boundaries of YANG capabilities.
This will happen with or without the IETF. Maybe this work should remain
proprietary or get moved to an opensource project.




> >
> > I am in favor if keeping the yang-data in RFC 8040 and not
> > creating a new version of it that is unconstrained.
> > There does not seem to be consensus on how to do this,
> > or even consensus that it is a good idea.
> >
>
> If the extension is deemed necessary, I would also prefer this approach
> to making the extension a Proposed Standard.
>
> Lada
>


Andy


>
> >
> >
> >> > clear solution for RPCs and actions would be to enable the definition
> >> > of error details right in the rpc/action definition (input, output,
> >> > error).
> >>
> >> Agreed.
> >>
> >> >
> >> > But something like yang-data seems to have uses in other contexts.
> >>
> >> So other datastores may be defined. I assume that YANG library data can
> be
> >> used
> >> independently, not just on a NC/RC server, pretty much along the lines
> of
> >> draft-
> >> lengyel-netmod-yang-instance-data.
> >>
> >> Lada
> >>
> >> >
> >>
> >
> > Andy
> >
> >
> >
> >> > /js
> >> >
> >> --
> >> Ladislav Lhotka
> >> Head, CZ.NIC Labs
> >> PGP Key ID: 0xB8F92B08A9F76C67
> >>
> >> ___
> >> 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

[Kent Watsen]

>Martin wrote before:
> No I was thinking along the lines of:
>
>  ydx:yang-data my-first-rpc-error-info {
>...
>  }
>
>  rpc my-first-rpc {
>...
>opx:error-info-structure my-first-rpc-error-info;
>  }
>
> I.e., use yang-data to define a structure, and use another statement
> to tie them together.
>
> If we define special statements with inline structures, we probably
> also need special augment statements; with your example:
>
>
>  rpc my-first-rpc {
>...
>opx:error-info-structure my-first-rpc-error-info {
>  ...
>}
>  }
>
>
>  opx:augment-error-info-structure '/m:my-first-rpc'
> + '/m:my-first-rpc-error-info {
>...
>  }
  


Can the definition be inlined, like this?

  module my-module {
...
rpc my-first-rpc {
  input {
 ...
  }
  output {
 ...
  }
  opx:error-info-structure {
leaf error-type {
  type enumeration {
enum error-a;
enum error-b;
enum error-c;
  }
}
choice error-info {
  case error-a {
...
  }
  case error-b {
...
  }
  case error-c {
...
  }
} 
  }
}
  }



Kent // contributor



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

Re: [netmod] yang-data-ext issues

[Ladislav Lhotka]

Andy Bierman  writes:

> On Fri, Apr 27, 2018 at 8:13 AM, Ladislav Lhotka  wrote:
>
>> On Fri, 2018-04-27 at 16:47 +0200, Juergen Schoenwaelder wrote:
>> > On Fri, Apr 27, 2018 at 04:34:38PM +0200, Ladislav Lhotka wrote:
>> >
>> > > [...] define a special datastore for it, such as "error-messages".
>> >
>> > This seems worse than using, well, RFC 8040 yang-data. The proper
>>
>> Why it seems worse?
>>
>>
> Because this is not part of the NMDA.

NMDA is extensible.

> IMO, the yang-data defined in RFC 8040 has a clear purpose, and it
> is sufficient for that purpose, which is a YANG representation of
> an instance document (such as a protocol message or file).

The same is basically true even without the extension. For example, I
fail to see any benefit from using yang-data in a module like
ietf-zerotouch-information.

>
> YANG is useful for defining data structures that can be represented in
> different formats, yet it is independent of any 1 format.

Of course I see this potential. Unfortunately, YANG spec was explicitly
written for a very specific context. Using an extension for removing
this specificity is IMO an ugly hack that undermines the architecture. 

>
> I am in favor if keeping the yang-data in RFC 8040 and not
> creating a new version of it that is unconstrained.
> There does not seem to be consensus on how to do this,
> or even consensus that it is a good idea.
>

If the extension is deemed necessary, I would also prefer this approach
to making the extension a Proposed Standard.

Lada

>
>
>> > clear solution for RPCs and actions would be to enable the definition
>> > of error details right in the rpc/action definition (input, output,
>> > error).
>>
>> Agreed.
>>
>> >
>> > But something like yang-data seems to have uses in other contexts.
>>
>> So other datastores may be defined. I assume that YANG library data can be
>> used
>> independently, not just on a NC/RC server, pretty much along the lines of
>> draft-
>> lengyel-netmod-yang-instance-data.
>>
>> Lada
>>
>> >
>>
>
> Andy
>
>
>
>> > /js
>> >
>> --
>> Ladislav Lhotka
>> Head, CZ.NIC Labs
>> PGP Key ID: 0xB8F92B08A9F76C67
>>
>> ___
>> 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

[Juergen Schoenwaelder]

On Fri, Apr 27, 2018 at 04:34:38PM +0200, Ladislav Lhotka wrote:

> [...] define a special datastore for it, such as "error-messages".

This seems worse than using, well, RFC 8040 yang-data. The proper
clear solution for RPCs and actions would be to enable the definition
of error details right in the rpc/action definition (input, output,
error).

But something like yang-data seems to have uses in other contexts.

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

[Robert Wilton]

On 27/04/2018 12:03, Ladislav Lhotka wrote:

On Fri, 2018-04-27 at 11:23 +0100, Robert Wilton wrote:

On 27/04/2018 11:03, Martin Bjorklund wrote:

Hi,

Ladislav Lhotka  wrote:

On Thu, 2018-04-26 at 17:52 -0700, Andy Bierman wrote:

On Wed, Apr 25, 2018 at 10:53 PM, Ladislav Lhotka  wrote:

Ladislav Lhotka  writes:


On Wed, 2018-04-25 at 08:04 -0700, Andy Bierman wrote:

On Wed, Apr 25, 2018 at 7:05 AM, Ladislav Lhotka 
wrote:

On Wed, 2018-04-25 at 15:55 +0200, Juergen Schoenwaelder wrote:

On Tue, Apr 24, 2018 at 04:36:01PM +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
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?

One option is that people use yang-data as defined in RFC 8040
until

IMO, people should use plain YANG. With the new YANG library it
will be
possible
to confine such non-NM schemas in a special datastore so that
the

intention

should be clear and multi-module schemas with all the additional
data
(versions,
   features, deviations) can be used.


I don't see how yang-data interferes with "plain YANG" at all.
It is for data that is not in scope for plain YANG.

My question is why this extension is needed in the first place.

For example, RFC 8040 could have used two modules instead of
"ietf-restconf", one with the contents of grouping "errors" and the
other with the contents of grouping "restconf". No extension.


This is true. We used to do this before yang-data was available.

If I remember correctly, the stuff was inside groupings that were not used
anywhere.

Which doesn't quite work, since no namespace is attached to the nodes.

Note that this is not what I was proposing. For RESTCONF errors, the module I
had in mind could be like this:

module ietf-restconf-errors {

   container errors { // same content as in RFC 8040
 ...
   }

   ...

}

Please explain why this cannot serve the given purpose, apart from the fact that
it looks like configuration which it isn't - but this can be explained in the
module description.

It is the "because it looks like configuration" that I don't like.

If the server supports and advertises this module then it is reasonable 
to expect that a client should be able to configure the errors 
container, since it is configuration ...


At least marking it as config false would be slightly better.



With this module, one could validate error messages using generic YANG tools
etc.

(I am not proposing to update RFC 8040, just using it as an example.)


OK.  So, using plain groupings doesn't work.

In cases where groupings are being used within a YANG defined RPC, then
presumably they do work OK?

Is the specific problem scenario where the data is external to YANG
defined RPCs, but yet it is still desirable to use a YANG schema and one
of the associated YANG encodings to describe/encode the data?



What would be wrong with this solution? Instead, the reader is
overwhelmed with the complexity of the "yang-data" definition, and
most
tools cannot process the module.

There are tools that can use yang-data.
Not all use-cases involve a server to query for a yang-library.

Sure, but it is not necessary, I meant it just as an option. Such YANG
modules
can be passed straight to tools.


Offline tools need to know about the special data somehow.

Why? Let's say I want the ascii tree, and pyang will be able to generate
it. All
right, there will be "rw" labels that don't apply but it is not a big
deal.


The yang-data extension prevents data-def-stmts from being treated
as if they were configuration or operational data.

This would be a problem if this yang-data is mixed with standard data in
the
same module. IMO this can be avoided, and then for it is essentially
irrelevant
for tools whether it is normal data or not.


I agree with you that unconstrained use of yang-data is questionable
for a standard extension. The bar should be that all tools which choose
to implement the extension should provide the user with the same
behavior.
Declaring that behavior out-of-scope does not help interoperability at
all.

Yes, and so my proposal here is to silently misuse YANG somewhat where
necessary
rather than spend cycles on a Standard Track document that gives a false
impression of a general solution.

I am strongly opposed to this.  IMO it is much better to put such
structures in an extension, which tools that don't understand it will
ignore, than relying on description statements in normal data nodes,
which no tool can understand without hard coding special cases.

I'm also opposed to this.

Stuff 

Re: [netmod] yang-data-ext issues

[Robert Wilton]

On 27/04/2018 11:03, Martin Bjorklund wrote:

Hi,

Ladislav Lhotka  wrote:

On Thu, 2018-04-26 at 17:52 -0700, Andy Bierman wrote:


On Wed, Apr 25, 2018 at 10:53 PM, Ladislav Lhotka  wrote:

Ladislav Lhotka  writes:


On Wed, 2018-04-25 at 08:04 -0700, Andy Bierman wrote:


On Wed, Apr 25, 2018 at 7:05 AM, Ladislav Lhotka  wrote:

On Wed, 2018-04-25 at 15:55 +0200, Juergen Schoenwaelder wrote:

On Tue, Apr 24, 2018 at 04:36:01PM +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
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?

One option is that people use yang-data as defined in RFC 8040 until

IMO, people should use plain YANG. With the new YANG library it will be
possible
to confine such non-NM schemas in a special datastore so that the

intention

should be clear and multi-module schemas with all the additional data
(versions,
  features, deviations) can be used.


I don't see how yang-data interferes with "plain YANG" at all.
It is for data that is not in scope for plain YANG.

My question is why this extension is needed in the first place.

For example, RFC 8040 could have used two modules instead of
"ietf-restconf", one with the contents of grouping "errors" and the
other with the contents of grouping "restconf". No extension.


This is true. We used to do this before yang-data was available.

If I remember correctly, the stuff was inside groupings that were not used
anywhere.

Which doesn't quite work, since no namespace is attached to the nodes.

OK.  So, using plain groupings doesn't work.

In cases where groupings are being used within a YANG defined RPC, then 
presumably they do work OK?


Is the specific problem scenario where the data is external to YANG 
defined RPCs, but yet it is still desirable to use a YANG schema and one 
of the associated YANG encodings to describe/encode the data?






What would be wrong with this solution? Instead, the reader is
overwhelmed with the complexity of the "yang-data" definition, and most
tools cannot process the module.

There are tools that can use yang-data.
Not all use-cases involve a server to query for a yang-library.

Sure, but it is not necessary, I meant it just as an option. Such YANG modules
can be passed straight to tools.


Offline tools need to know about the special data somehow.

Why? Let's say I want the ascii tree, and pyang will be able to generate it. All
right, there will be "rw" labels that don't apply but it is not a big deal.


The yang-data extension prevents data-def-stmts from being treated
as if they were configuration or operational data.

This would be a problem if this yang-data is mixed with standard data in the
same module. IMO this can be avoided, and then for it is essentially irrelevant
for tools whether it is normal data or not.


I agree with you that unconstrained use of yang-data is questionable
for a standard extension. The bar should be that all tools which choose
to implement the extension should provide the user with the same behavior.
Declaring that behavior out-of-scope does not help interoperability at all.

Yes, and so my proposal here is to silently misuse YANG somewhat where necessary
rather than spend cycles on a Standard Track document that gives a false
impression of a general solution.

I am strongly opposed to this.  IMO it is much better to put such
structures in an extension, which tools that don't understand it will
ignore, than relying on description statements in normal data nodes,
which no tool can understand without hard coding special cases.

I'm also opposed to this.

Stuff that looks like configuration should be configuration, and stuff 
that looks like state should be state.  If this data is going to be 
described in YANG then I think that there must be a programmatic way to 
indicate that the resultant schema is not configuration or operational 
state, but something else instead.  An extension seems to achieve this.


Thanks,
Rob






It would be great to remove NETCONF specifics from YANG and I'd be willing to
contribute to this work.

This is a different topic though.


/martin



Lada




Lada


Andy
  

A plain client can ignore yang-data and not affect and RPC, notification,

or

data
definitions in plain YANG.

A plain (NC/RC) client should never see such data even if it is not

protected by

yang-data in YANG. On the other hand, tools will be able to process such

schemas

(generate the ascii tree, convert it to something else, generate sample
instances etc.) without explicitly supporting yang-data.

Lada

  

Re: [netmod] yang-data-ext issues

[Martin Bjorklund]

Hi,

Ladislav Lhotka  wrote:
> On Thu, 2018-04-26 at 17:52 -0700, Andy Bierman wrote:
> > 
> > 
> > On Wed, Apr 25, 2018 at 10:53 PM, Ladislav Lhotka  wrote:
> > > Ladislav Lhotka  writes:
> > > 
> > > > On Wed, 2018-04-25 at 08:04 -0700, Andy Bierman wrote:
> > > >> 
> > > >> 
> > > >> On Wed, Apr 25, 2018 at 7:05 AM, Ladislav Lhotka  wrote:
> > > >> > On Wed, 2018-04-25 at 15:55 +0200, Juergen Schoenwaelder wrote:
> > > >> > > On Tue, Apr 24, 2018 at 04:36:01PM +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
> > > >> > > > 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?
> > > >> > > 
> > > >> > > One option is that people use yang-data as defined in RFC 8040 
> > > >> > > until
> > > >> > 
> > > >> > IMO, people should use plain YANG. With the new YANG library it will 
> > > >> > be
> > > >> > possible
> > > >> > to confine such non-NM schemas in a special datastore so that the
> > > intention
> > > >> > should be clear and multi-module schemas with all the additional data
> > > >> > (versions,
> > > >> >  features, deviations) can be used.
> > > >> > 
> > > >> 
> > > >> I don't see how yang-data interferes with "plain YANG" at all.
> > > >> It is for data that is not in scope for plain YANG.
> > > >
> > > > My question is why this extension is needed in the first place.
> > > 
> > > For example, RFC 8040 could have used two modules instead of
> > > "ietf-restconf", one with the contents of grouping "errors" and the
> > > other with the contents of grouping "restconf". No extension.
> > > 
> > 
> > This is true. We used to do this before yang-data was available.
> 
> If I remember correctly, the stuff was inside groupings that were not used
> anywhere.

Which doesn't quite work, since no namespace is attached to the nodes.

> > > What would be wrong with this solution? Instead, the reader is
> > > overwhelmed with the complexity of the "yang-data" definition, and most
> > > tools cannot process the module.
> > 
> > There are tools that can use yang-data.
> > Not all use-cases involve a server to query for a yang-library.
> 
> Sure, but it is not necessary, I meant it just as an option. Such YANG modules
> can be passed straight to tools.
> 
> > Offline tools need to know about the special data somehow.
> 
> Why? Let's say I want the ascii tree, and pyang will be able to generate it. 
> All
> right, there will be "rw" labels that don't apply but it is not a big deal.
> 
> > The yang-data extension prevents data-def-stmts from being treated
> > as if they were configuration or operational data.
> 
> This would be a problem if this yang-data is mixed with standard data in the
> same module. IMO this can be avoided, and then for it is essentially 
> irrelevant
> for tools whether it is normal data or not.
> 
> > 
> > I agree with you that unconstrained use of yang-data is questionable
> > for a standard extension. The bar should be that all tools which choose
> > to implement the extension should provide the user with the same behavior.
> > Declaring that behavior out-of-scope does not help interoperability at all.
> 
> Yes, and so my proposal here is to silently misuse YANG somewhat where 
> necessary
> rather than spend cycles on a Standard Track document that gives a false
> impression of a general solution.

I am strongly opposed to this.  IMO it is much better to put such
structures in an extension, which tools that don't understand it will
ignore, than relying on description statements in normal data nodes,
which no tool can understand without hard coding special cases.


> It would be great to remove NETCONF specifics from YANG and I'd be willing to
> contribute to this work.

This is a different topic though.


/martin


> 
> Lada
> 
> > 
> > 
> > > Lada
> > > 
> > 
> > Andy
> >  
> > > >
> > > >> A plain client can ignore yang-data and not affect and RPC, 
> > > >> notification,
> > > or
> > > >> data
> > > >> definitions in plain YANG.
> > > >
> > > > A plain (NC/RC) client should never see such data even if it is not
> > > protected by
> > > > yang-data in YANG. On the other hand, tools will be able to process such
> > > schemas
> > > > (generate the ascii tree, convert it to something else, generate sample
> > > > instances etc.) 

Re: [netmod] yang-data-ext issues

[Ladislav Lhotka]

On Thu, 2018-04-26 at 17:52 -0700, Andy Bierman wrote:
> 
> 
> On Wed, Apr 25, 2018 at 10:53 PM, Ladislav Lhotka  wrote:
> > Ladislav Lhotka  writes:
> > 
> > > On Wed, 2018-04-25 at 08:04 -0700, Andy Bierman wrote:
> > >> 
> > >> 
> > >> On Wed, Apr 25, 2018 at 7:05 AM, Ladislav Lhotka  wrote:
> > >> > On Wed, 2018-04-25 at 15:55 +0200, Juergen Schoenwaelder wrote:
> > >> > > On Tue, Apr 24, 2018 at 04:36:01PM +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
> > >> > > > 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?
> > >> > > 
> > >> > > One option is that people use yang-data as defined in RFC 8040 until
> > >> > 
> > >> > IMO, people should use plain YANG. With the new YANG library it will be
> > >> > possible
> > >> > to confine such non-NM schemas in a special datastore so that the
> > intention
> > >> > should be clear and multi-module schemas with all the additional data
> > >> > (versions,
> > >> >  features, deviations) can be used.
> > >> > 
> > >> 
> > >> I don't see how yang-data interferes with "plain YANG" at all.
> > >> It is for data that is not in scope for plain YANG.
> > >
> > > My question is why this extension is needed in the first place.
> > 
> > For example, RFC 8040 could have used two modules instead of
> > "ietf-restconf", one with the contents of grouping "errors" and the
> > other with the contents of grouping "restconf". No extension.
> > 
> 
> This is true. We used to do this before yang-data was available.

If I remember correctly, the stuff was inside groupings that were not used
anywhere.

> 
>  
> > What would be wrong with this solution? Instead, the reader is
> > overwhelmed with the complexity of the "yang-data" definition, and most
> > tools cannot process the module.
> 
> There are tools that can use yang-data.
> Not all use-cases involve a server to query for a yang-library.

Sure, but it is not necessary, I meant it just as an option. Such YANG modules
can be passed straight to tools.

> Offline tools need to know about the special data somehow.

Why? Let's say I want the ascii tree, and pyang will be able to generate it. All
right, there will be "rw" labels that don't apply but it is not a big deal.

> The yang-data extension prevents data-def-stmts from being treated
> as if they were configuration or operational data.

This would be a problem if this yang-data is mixed with standard data in the
same module. IMO this can be avoided, and then for it is essentially irrelevant
for tools whether it is normal data or not.

> 
> I agree with you that unconstrained use of yang-data is questionable
> for a standard extension. The bar should be that all tools which choose
> to implement the extension should provide the user with the same behavior.
> Declaring that behavior out-of-scope does not help interoperability at all.

Yes, and so my proposal here is to silently misuse YANG somewhat where necessary
rather than spend cycles on a Standard Track document that gives a false
impression of a general solution.

It would be great to remove NETCONF specifics from YANG and I'd be willing to
contribute to this work.

Lada

> 
> 
> > Lada
> > 
> 
> Andy
>  
> > >
> > >> A plain client can ignore yang-data and not affect and RPC, notification,
> > or
> > >> data
> > >> definitions in plain YANG.
> > >
> > > A plain (NC/RC) client should never see such data even if it is not
> > protected by
> > > yang-data in YANG. On the other hand, tools will be able to process such
> > schemas
> > > (generate the ascii tree, convert it to something else, generate sample
> > > instances etc.) without explicitly supporting yang-data.
> > >
> > > Lada
> > >
> > >> 
> > >>  
> > >> > Lada
> > >> > 
> > >> 
> > >> Andy
> > >>  
> > >> > > there is a version of YANG that has a proper and complete integrated
> > >> > > solution. (If for example yang-data is used to declare error content
> > >> > > for RPCs, then more extensions are needed or a proper integration
> > into
> > >> > > YANG. Is it really good to introduce augment-yang-data (instead of
> > >> > > making augment work with say 'data' in YANG 1.2)? And then we do
> > >> > > uses-yang-data etc.
> > >> > > 
> > >> > > /js
> > >> > > 
> > >> > -- 
> > >> > Ladislav Lhotka
> > >> > Head, CZ.NIC Labs
> > >> > PGP Key ID: 0xB8F92B08A9F76C67
> > >> > 
> > >> > 

Re: [netmod] yang-data-ext issues

[Ladislav Lhotka]

Ladislav Lhotka  writes:

> On Wed, 2018-04-25 at 08:04 -0700, Andy Bierman wrote:
>> 
>> 
>> On Wed, Apr 25, 2018 at 7:05 AM, Ladislav Lhotka  wrote:
>> > On Wed, 2018-04-25 at 15:55 +0200, Juergen Schoenwaelder wrote:
>> > > On Tue, Apr 24, 2018 at 04:36:01PM +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
>> > > > 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?
>> > > 
>> > > One option is that people use yang-data as defined in RFC 8040 until
>> > 
>> > IMO, people should use plain YANG. With the new YANG library it will be
>> > possible
>> > to confine such non-NM schemas in a special datastore so that the intention
>> > should be clear and multi-module schemas with all the additional data
>> > (versions,
>> >  features, deviations) can be used.
>> > 
>> 
>> I don't see how yang-data interferes with "plain YANG" at all.
>> It is for data that is not in scope for plain YANG.
>
> My question is why this extension is needed in the first place.

For example, RFC 8040 could have used two modules instead of
"ietf-restconf", one with the contents of grouping "errors" and the
other with the contents of grouping "restconf". No extension.

What would be wrong with this solution? Instead, the reader is
overwhelmed with the complexity of the "yang-data" definition, and most
tools cannot process the module.

Lada

>
>> A plain client can ignore yang-data and not affect and RPC, notification, or
>> data
>> definitions in plain YANG.
>
> A plain (NC/RC) client should never see such data even if it is not protected 
> by
> yang-data in YANG. On the other hand, tools will be able to process such 
> schemas
> (generate the ascii tree, convert it to something else, generate sample
> instances etc.) without explicitly supporting yang-data.
>
> Lada
>
>> 
>>  
>> > Lada
>> > 
>> 
>> Andy
>>  
>> > > there is a version of YANG that has a proper and complete integrated
>> > > solution. (If for example yang-data is used to declare error content
>> > > for RPCs, then more extensions are needed or a proper integration into
>> > > YANG. Is it really good to introduce augment-yang-data (instead of
>> > > making augment work with say 'data' in YANG 1.2)? And then we do
>> > > uses-yang-data etc.
>> > > 
>> > > /js
>> > > 
>> > -- 
>> > Ladislav Lhotka
>> > Head, CZ.NIC Labs
>> > PGP Key ID: 0xB8F92B08A9F76C67
>> > 
>> > ___
>> > 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

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

[Andy Bierman]

On Wed, Apr 25, 2018 at 7:05 AM, Ladislav Lhotka  wrote:

> On Wed, 2018-04-25 at 15:55 +0200, Juergen Schoenwaelder wrote:
> > On Tue, Apr 24, 2018 at 04:36:01PM +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
> > > 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?
> >
> > One option is that people use yang-data as defined in RFC 8040 until
>
> IMO, people should use plain YANG. With the new YANG library it will be
> possible
> to confine such non-NM schemas in a special datastore so that the intention
> should be clear and multi-module schemas with all the additional data
> (versions,
>  features, deviations) can be used.
>
>
I don't see how yang-data interferes with "plain YANG" at all.
It is for data that is not in scope for plain YANG.
A plain client can ignore yang-data and not affect and RPC, notification,
or data
definitions in plain YANG.



> Lada
>
>
Andy


> > there is a version of YANG that has a proper and complete integrated
> > solution. (If for example yang-data is used to declare error content
> > for RPCs, then more extensions are needed or a proper integration into
> > YANG. Is it really good to introduce augment-yang-data (instead of
> > making augment work with say 'data' in YANG 1.2)? And then we do
> > uses-yang-data etc.
> >
> > /js
> >
> --
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
>
> ___
> 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] yang-data-ext issues

[Andy Bierman]

On Wed, Apr 25, 2018 at 12:03 AM, Martin Bjorklund  wrote:

> Andy Bierman  wrote:
> > 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.
>
> When the context is different this is not a problem.  Compare w/
> augment:
>
> augment "/if:interfaces/if:interface" {
>   container ipv4 { ... }
> }
>
> augment "/if:interfaces/if:interface-state" {
>   container ipv4 { ... }
> }
>
>

But you are proposing that the target location not be specified,
or specified inside a description-stmt.

No matter what context you pick, DOUBLE augment is not allowed:


augment "/if:interfaces/if:interface" {
  container ipv4 { ... }
}


augment "/if:interfaces/if:interface" {
  container ipv4 { ... }
}


So yang-data cannot define the same node in multiple contexts.
Leaving the context unspecified is not an option.





> These augements define the node "ipv4" in the the "ietf-ip" namespace,
> but 

Re: [netmod] yang-data-ext issues

[Andy Bierman]

On Tue, Apr 24, 2018 at 11:57 PM, Martin Bjorklund  wrote:

> Kent Watsen  wrote:
> >
> > > 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)
>
> I don't think we should use yang-data to model notifications.
> Presumably you meant error-info from rpc or action.
>
> And my point it is that I think that we should make yang-data
> flexible enoough in itself, and not constrain it to the one or two use
> cases we know now.
>
> > 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 {
> >  …
> >}
> >}
>
> No I was thinking along the lines of:
>
>   ydx:yang-data my-first-rpc-error-info {
> ...
>   }
>
>   rpc my-first-rpc {
> ...
> opx:error-info-structure my-first-rpc-error-info;
>   }
>
> I.e., use yang-data to define a structure, and use another statement
> to tie them together.
>
> If we define special statements with inline structures, we probably
> also need special augment statements; with your example:
>
>
>   rpc my-first-rpc {
> ...
> opx:error-info-structure my-first-rpc-error-info {
>   ...
> }
>   }
>
>
>   opx:augment-error-info-structure '/m:my-first-rpc'
>  + '/m:my-first-rpc-error-info {
> ...
>   }
>
>


This could easily be defined to use groupings instead:



  grouping my-first-rpc-error-info {
...
  }

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


 There is no need to reinvent the grouping.



> /martin
>
>

Andy



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

[Martin Bjorklund]

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

When the context is different this is not a problem.  Compare w/
augment:

augment "/if:interfaces/if:interface" {
  container ipv4 { ... }
}

augment "/if:interfaces/if:interface-state" {
  container ipv4 { ... }
}
 
These augements define the node "ipv4" in the the "ietf-ip" namespace,
but b/c the context is different, there is no risk for confusion.

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

See my email to Kent.  I don't understand why this can't be done with
yang-data.  This said, if we were to do a new version of YANG and
address this problem, we would define a new core keyword for this.


/martin




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

Re: [netmod] yang-data-ext issues

[Martin Bjorklund]

Kent Watsen  wrote:
> 
> > 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)

I don't think we should use yang-data to model notifications.
Presumably you meant error-info from rpc or action.

And my point it is that I think that we should make yang-data
flexible enoough in itself, and not constrain it to the one or two use
cases we know now.

> 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 {
>  …
>}
>}

No I was thinking along the lines of:

  ydx:yang-data my-first-rpc-error-info {
...
  }

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

I.e., use yang-data to define a structure, and use another statement
to tie them together.

If we define special statements with inline structures, we probably
also need special augment statements; with your example:


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


  opx:augment-error-info-structure '/m:my-first-rpc'
 + '/m:my-first-rpc-error-info {
...
  }
  

/martin




> 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

[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] 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

Re: [netmod] yang-data-ext issues

[Andy Bierman]

On Mon, Apr 23, 2018 at 10:36 AM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> 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

Re: [netmod] yang-data-ext issues

[Martin Bjorklund]

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



/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

Re: [netmod] yang-data-ext issues

[Andy Bierman]

> 
> >
> > 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.
There are no encoding and parsing rules for instance data
that support this sort of duplicate.

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

[Martin Bjorklund]

Hi,

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


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

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

Re: [netmod] yang-data-ext issues

[Martin Bjorklund]

Andy Bierman  wrote:
> On Mon, Apr 23, 2018 at 4:28 AM, Martin Bjorklund  wrote:
> 
> > Andy Bierman  wrote:
> > > On Sun, Apr 22, 2018 at 11:52 PM, Martin Bjorklund 
> > wrote:
> > >
> > > > Andy Bierman  wrote:
> > > > > On Wed, Apr 18, 2018 at 10:47 AM, Martin Bjorklund 
> > > > wrote:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > Andy Bierman  wrote:
> > > > > > > On Wed, Apr 18, 2018 at 10:26 AM, Kent Watsen <
> > kwat...@juniper.net>
> > > > > > wrote:
> > > > > > >
> > > > > > > > I like Andy's proposal below, for the argument of the
> > 'yang-data'
> > > > > > > > statement to encode some meta-information regarding the
> > > > > > context/namespace
> > > > > > > > in which it's used, but I wonder how it really works.  For
> > > > instance,
> > > > > > would
> > > > > > > > "top" and "error-info" be the only allowed base-path values
> > for the
> > > > > > > > argument? and what is the value of the remainder of the path?
> > are
> > > > we
> > > > > > > > expecting for there to be some kind us 'uses' statement that
> > can
> > > > refer
> > > > > > to
> > > > > > > > just the base-path component to implement substitution-group
> > like
> > > > > > behavior?
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > If we want to avoid defining these contexts, then we could just
> > > > define
> > > > > > root
> > > > > > > vs. nonroot.
> > > > > > >
> > > > > > > e,g:
> > > > > > >
> > > > > > > x:yang-data /mydef1 {
> > > > > > >   container foo;
> > > > > > > }
> > > > > > >
> > > > > > > x:yang-data mydef2 {
> > > > > > >   leaf x;
> > > > > > >   leaf y;
> > > > > > >   container z;
> > > > > > > }
> > > > > > >
> > > > > > >
> > > > > > > Only an argument starting with '/' would be treated as a
> > top-level
> > > > data
> > > > > > > node.
> > > > > > >
> > > > > > > All other yang-data definitions are not allowed to appear as a
> > root
> > > > node.
> > > > > > > The context where this yang-data is used is completely
> > proprietary.
> > > > > > > The mechanism used to expand this yang-data as if it was a
> > grouping
> > > > > > > is completely proprietary.
> > > > > > >
> > > > > > > The augment-yang-data extension only applies to top-level
> > yang-data
> > > > > > > definitions.
> > > > > > >
> > > > > > > However, my preference is to only standardize top-level
> > yang-data.
> > > > > >
> > > > > > What is "top-level" yang-data?
> > > > > >
> > > > > >
> > > > > >
> > > > > It is a data structure that represents an instance document.
> > > >
> > > > So then I assume that you also want to change the current draft -01
> > > > behavior so that a yang-data structure MUST have a single container as
> > > > the child?  Just like in rc:yang-data.
> > > >
> > > >
> > >
> > > A yang-data structure representing an instance document needs to result
> > in
> > > a container.
> >
> > Right, and since you wrote:
> >
> > my preference is to only standardize top-level yang-data.
> >
> > I assume that you want to re-add the CLR about a single container in
> > yang-ext?
> >
> > > > > Since this is the ONLY definition of yang-data we have in the
> > standard,
> > > > > what is a yang-data definition that represents some unspecified
> > usage,
> > > > > other than an instance document?
> > > >
> > > > We want to create a flexible solution for creating structures that can
> > > > be used in other places than just self-contained instance document.
> > > > One example is the error-info data (see subscribed-notifications).
> > > >
> > > > > Why is this any different than a YANG grouping?
> > > >
> > > > ?  We don't have these CLRs for groupings; the following is legal:
> > > >
> > > >   grouping foo {
> > > > leaf a { ... }
> > > > leaf b { ... }
> > > >   }
> > > >
> > > >   grouping bar {
> > > > leaf b { ... }
> > > >   }
> > > >
> > > >
> > > > It is up to the user of the grouping to ensure it is used in a way so
> > > > that the result is legal.  I think yang-data should work the same
> > > > way.
> > > >
> > > >
> > > >
> > >
> > > We don't need yang-data to be another way to define a grouping, because
> > > we already have grouping-stmt.
> >
> > I agree.  At some point someone suggested "uses-yang-data", I think we
> > both agreed that this was a bad idea.
> >
> > > We don't need to re-invent another collection of data-def-stmts that are
> > not
> > > instantiated as data nodes automatically. Any place you could use
> > yang-data
> > > for this purpose, you could use a grouping instead.
> >
> > I'm not sure what you are trying to say.  Are you suggesting that we
> > don't need yang-data at all?
> >
> >
> 
> 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 

Re: [netmod] yang-data-ext issues

[Juergen Schoenwaelder]

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

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

[Robert Varga]

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

Regards,
Robert



signature.asc
Description: OpenPGP digital signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] yang-data-ext issues

[Juergen Schoenwaelder]

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

Re: [netmod] yang-data-ext issues

[Robert Varga]

On 22/04/18 14:56, Ladislav Lhotka wrote:
>> One example: YANG 1.1 was supposed to be a backwards-compatible, yet it
>> introduced multiple-inheritence to a language which was previously
>> strictly single-inheritence. That sort of change is a major revision of
>> the metamodel and certainly does not qualify as backwards-compatible at
>> that level of abstraction.
> I'd defend YANG 1.1 here, I think it was a well managed and conservative 
> update.
> The meaning of backward compatibility was defined in the charter: YANG 1.0
> modules should continue to work in 1.1. Apart from fixing evident bugs, I
> believe this goal was achieved.

I agree and the upgrade process was very smooth, all things considered.

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

Agree, and it's especially the interactions between extensions which are
critical to manage the outcome.

> Regarding your example: from my own experience, implementing validation of
> identityref values with multiple inheritance is not terribly complicated in
> comparison to single inheritance. I have other favorites for the most peculiar
> feature in YANG.

It's not, but it forced us to incompatibly change our Java binding
specifications -- where we used to use abstract classes we have to use
interfaces. Luckily there is no state involved :)

Regards,
Robert



signature.asc
Description: OpenPGP digital signature
___
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 4:28 AM, Martin Bjorklund  wrote:

> Andy Bierman  wrote:
> > On Sun, Apr 22, 2018 at 11:52 PM, Martin Bjorklund 
> wrote:
> >
> > > Andy Bierman  wrote:
> > > > On Wed, Apr 18, 2018 at 10:47 AM, Martin Bjorklund 
> > > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > Andy Bierman  wrote:
> > > > > > On Wed, Apr 18, 2018 at 10:26 AM, Kent Watsen <
> kwat...@juniper.net>
> > > > > wrote:
> > > > > >
> > > > > > > I like Andy's proposal below, for the argument of the
> 'yang-data'
> > > > > > > statement to encode some meta-information regarding the
> > > > > context/namespace
> > > > > > > in which it's used, but I wonder how it really works.  For
> > > instance,
> > > > > would
> > > > > > > "top" and "error-info" be the only allowed base-path values
> for the
> > > > > > > argument? and what is the value of the remainder of the path?
> are
> > > we
> > > > > > > expecting for there to be some kind us 'uses' statement that
> can
> > > refer
> > > > > to
> > > > > > > just the base-path component to implement substitution-group
> like
> > > > > behavior?
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > If we want to avoid defining these contexts, then we could just
> > > define
> > > > > root
> > > > > > vs. nonroot.
> > > > > >
> > > > > > e,g:
> > > > > >
> > > > > > x:yang-data /mydef1 {
> > > > > >   container foo;
> > > > > > }
> > > > > >
> > > > > > x:yang-data mydef2 {
> > > > > >   leaf x;
> > > > > >   leaf y;
> > > > > >   container z;
> > > > > > }
> > > > > >
> > > > > >
> > > > > > Only an argument starting with '/' would be treated as a
> top-level
> > > data
> > > > > > node.
> > > > > >
> > > > > > All other yang-data definitions are not allowed to appear as a
> root
> > > node.
> > > > > > The context where this yang-data is used is completely
> proprietary.
> > > > > > The mechanism used to expand this yang-data as if it was a
> grouping
> > > > > > is completely proprietary.
> > > > > >
> > > > > > The augment-yang-data extension only applies to top-level
> yang-data
> > > > > > definitions.
> > > > > >
> > > > > > However, my preference is to only standardize top-level
> yang-data.
> > > > >
> > > > > What is "top-level" yang-data?
> > > > >
> > > > >
> > > > >
> > > > It is a data structure that represents an instance document.
> > >
> > > So then I assume that you also want to change the current draft -01
> > > behavior so that a yang-data structure MUST have a single container as
> > > the child?  Just like in rc:yang-data.
> > >
> > >
> >
> > A yang-data structure representing an instance document needs to result
> in
> > a container.
>
> Right, and since you wrote:
>
> my preference is to only standardize top-level yang-data.
>
> I assume that you want to re-add the CLR about a single container in
> yang-ext?
>
> > > > Since this is the ONLY definition of yang-data we have in the
> standard,
> > > > what is a yang-data definition that represents some unspecified
> usage,
> > > > other than an instance document?
> > >
> > > We want to create a flexible solution for creating structures that can
> > > be used in other places than just self-contained instance document.
> > > One example is the error-info data (see subscribed-notifications).
> > >
> > > > Why is this any different than a YANG grouping?
> > >
> > > ?  We don't have these CLRs for groupings; the following is legal:
> > >
> > >   grouping foo {
> > > leaf a { ... }
> > > leaf b { ... }
> > >   }
> > >
> > >   grouping bar {
> > > leaf b { ... }
> > >   }
> > >
> > >
> > > It is up to the user of the grouping to ensure it is used in a way so
> > > that the result is legal.  I think yang-data should work the same
> > > way.
> > >
> > >
> > >
> >
> > We don't need yang-data to be another way to define a grouping, because
> > we already have grouping-stmt.
>
> I agree.  At some point someone suggested "uses-yang-data", I think we
> both agreed that this was a bad idea.
>
> > We don't need to re-invent another collection of data-def-stmts that are
> not
> > instantiated as data nodes automatically. Any place you could use
> yang-data
> > for this purpose, you could use a grouping instead.
>
> I'm not sure what you are trying to say.  Are you suggesting that we
> don't need yang-data at all?
>
>

I do not understand the need for a yang-data structure that represents data
that can be instantiated anywhere and everywhere.  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. 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 

Re: [netmod] yang-data-ext issues

[Martin Bjorklund]

Andy Bierman  wrote:
> On Sun, Apr 22, 2018 at 11:52 PM, Martin Bjorklund  wrote:
> 
> > Andy Bierman  wrote:
> > > On Wed, Apr 18, 2018 at 10:47 AM, Martin Bjorklund 
> > wrote:
> > >
> > > > Hi,
> > > >
> > > > Andy Bierman  wrote:
> > > > > On Wed, Apr 18, 2018 at 10:26 AM, Kent Watsen 
> > > > wrote:
> > > > >
> > > > > > I like Andy's proposal below, for the argument of the 'yang-data'
> > > > > > statement to encode some meta-information regarding the
> > > > context/namespace
> > > > > > in which it's used, but I wonder how it really works.  For
> > instance,
> > > > would
> > > > > > "top" and "error-info" be the only allowed base-path values for the
> > > > > > argument? and what is the value of the remainder of the path?  are
> > we
> > > > > > expecting for there to be some kind us 'uses' statement that can
> > refer
> > > > to
> > > > > > just the base-path component to implement substitution-group like
> > > > behavior?
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > If we want to avoid defining these contexts, then we could just
> > define
> > > > root
> > > > > vs. nonroot.
> > > > >
> > > > > e,g:
> > > > >
> > > > > x:yang-data /mydef1 {
> > > > >   container foo;
> > > > > }
> > > > >
> > > > > x:yang-data mydef2 {
> > > > >   leaf x;
> > > > >   leaf y;
> > > > >   container z;
> > > > > }
> > > > >
> > > > >
> > > > > Only an argument starting with '/' would be treated as a top-level
> > data
> > > > > node.
> > > > >
> > > > > All other yang-data definitions are not allowed to appear as a root
> > node.
> > > > > The context where this yang-data is used is completely proprietary.
> > > > > The mechanism used to expand this yang-data as if it was a grouping
> > > > > is completely proprietary.
> > > > >
> > > > > The augment-yang-data extension only applies to top-level yang-data
> > > > > definitions.
> > > > >
> > > > > However, my preference is to only standardize top-level yang-data.
> > > >
> > > > What is "top-level" yang-data?
> > > >
> > > >
> > > >
> > > It is a data structure that represents an instance document.
> >
> > So then I assume that you also want to change the current draft -01
> > behavior so that a yang-data structure MUST have a single container as
> > the child?  Just like in rc:yang-data.
> >
> >
> 
> A yang-data structure representing an instance document needs to result in
> a container.

Right, and since you wrote:

my preference is to only standardize top-level yang-data.

I assume that you want to re-add the CLR about a single container in
yang-ext?

> > > Since this is the ONLY definition of yang-data we have in the standard,
> > > what is a yang-data definition that represents some unspecified usage,
> > > other than an instance document?
> >
> > We want to create a flexible solution for creating structures that can
> > be used in other places than just self-contained instance document.
> > One example is the error-info data (see subscribed-notifications).
> >
> > > Why is this any different than a YANG grouping?
> >
> > ?  We don't have these CLRs for groupings; the following is legal:
> >
> >   grouping foo {
> > leaf a { ... }
> > leaf b { ... }
> >   }
> >
> >   grouping bar {
> > leaf b { ... }
> >   }
> >
> >
> > It is up to the user of the grouping to ensure it is used in a way so
> > that the result is legal.  I think yang-data should work the same
> > way.
> >
> >
> >
> 
> We don't need yang-data to be another way to define a grouping, because
> we already have grouping-stmt.

I agree.  At some point someone suggested "uses-yang-data", I think we
both agreed that this was a bad idea.

> We don't need to re-invent another collection of data-def-stmts that are not
> instantiated as data nodes automatically. Any place you could use yang-data
> for this purpose, you could use a grouping instead.

I'm not sure what you are trying to say.  Are you suggesting that we
don't need yang-data at all?


/martin


> 
> 
> 
> > /martin
> >
> >
> >
> 
> Andy
> 
> 
> 
> >
> > >
> > >
> > >
> > > > /martin
> > > >
> > > >
> > > >
> > > Andy
> > >
> > >
> > >
> > > > > I do not see any need for the other form since all functionality can
> > be
> > > > > achieved with a grouping and a proprietary YANG extension.
> > > > >
> > > > > Kent // contributor
> > > > > >
> > > > >
> > > > > Andy
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 4/16/18, 1:05 PM, "netmod on behalf of Andy Bierman" <
> > > > > > netmod-boun...@ietf.org on behalf of a...@yumaworks.com> wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Mon, Apr 16, 2018 at 9:46 AM, Robert Wilton 
> > > > wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 16/04/2018 17:07, Andy Bierman wrote:
> > > > > >
> > > > > >
> > > > > >

Re: [netmod] yang-data-ext issues

[Andy Bierman]

On Sun, Apr 22, 2018 at 11:52 PM, Martin Bjorklund  wrote:

> Andy Bierman  wrote:
> > On Wed, Apr 18, 2018 at 10:47 AM, Martin Bjorklund 
> wrote:
> >
> > > Hi,
> > >
> > > Andy Bierman  wrote:
> > > > On Wed, Apr 18, 2018 at 10:26 AM, Kent Watsen 
> > > wrote:
> > > >
> > > > > I like Andy's proposal below, for the argument of the 'yang-data'
> > > > > statement to encode some meta-information regarding the
> > > context/namespace
> > > > > in which it's used, but I wonder how it really works.  For
> instance,
> > > would
> > > > > "top" and "error-info" be the only allowed base-path values for the
> > > > > argument? and what is the value of the remainder of the path?  are
> we
> > > > > expecting for there to be some kind us 'uses' statement that can
> refer
> > > to
> > > > > just the base-path component to implement substitution-group like
> > > behavior?
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > > If we want to avoid defining these contexts, then we could just
> define
> > > root
> > > > vs. nonroot.
> > > >
> > > > e,g:
> > > >
> > > > x:yang-data /mydef1 {
> > > >   container foo;
> > > > }
> > > >
> > > > x:yang-data mydef2 {
> > > >   leaf x;
> > > >   leaf y;
> > > >   container z;
> > > > }
> > > >
> > > >
> > > > Only an argument starting with '/' would be treated as a top-level
> data
> > > > node.
> > > >
> > > > All other yang-data definitions are not allowed to appear as a root
> node.
> > > > The context where this yang-data is used is completely proprietary.
> > > > The mechanism used to expand this yang-data as if it was a grouping
> > > > is completely proprietary.
> > > >
> > > > The augment-yang-data extension only applies to top-level yang-data
> > > > definitions.
> > > >
> > > > However, my preference is to only standardize top-level yang-data.
> > >
> > > What is "top-level" yang-data?
> > >
> > >
> > >
> > It is a data structure that represents an instance document.
>
> So then I assume that you also want to change the current draft -01
> behavior so that a yang-data structure MUST have a single container as
> the child?  Just like in rc:yang-data.
>
>

A yang-data structure representing an instance document needs to result in
a container.




>
> > Since this is the ONLY definition of yang-data we have in the standard,
> > what is a yang-data definition that represents some unspecified usage,
> > other than an instance document?
>
> We want to create a flexible solution for creating structures that can
> be used in other places than just self-contained instance document.
> One example is the error-info data (see subscribed-notifications).
>
> > Why is this any different than a YANG grouping?
>
> ?  We don't have these CLRs for groupings; the following is legal:
>
>   grouping foo {
> leaf a { ... }
> leaf b { ... }
>   }
>
>   grouping bar {
> leaf b { ... }
>   }
>
>
> It is up to the user of the grouping to ensure it is used in a way so
> that the result is legal.  I think yang-data should work the same
> way.
>
>
>

We don't need yang-data to be another way to define a grouping, because
we already have grouping-stmt.

We don't need to re-invent another collection of data-def-stmts that are not
instantiated as data nodes automatically. Any place you could use yang-data
for this purpose, you could use a grouping instead.



> /martin
>
>
>

Andy



>
> >
> >
> >
> > > /martin
> > >
> > >
> > >
> > Andy
> >
> >
> >
> > > > I do not see any need for the other form since all functionality can
> be
> > > > achieved with a grouping and a proprietary YANG extension.
> > > >
> > > > Kent // contributor
> > > > >
> > > >
> > > > Andy
> > > >
> > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On 4/16/18, 1:05 PM, "netmod on behalf of Andy Bierman" <
> > > > > netmod-boun...@ietf.org on behalf of a...@yumaworks.com> wrote:
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Mon, Apr 16, 2018 at 9:46 AM, Robert Wilton 
> > > wrote:
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On 16/04/2018 17:07, Andy Bierman wrote:
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Mon, Apr 16, 2018 at 8:44 AM, Robert Wilton 
> > > wrote:
> > > > >
> > > > > Don't groupings have a somewhat similar concern?
> > > > >
> > > > >  E.g. if two groupings define the same data node name and are used
> at
> > > the
> > > > > same point then you would get a namespace clash, but YANG does not
> > > disallow
> > > > > the groupings:
> > > > >
> > > > >
> > > > >  grouping foo_widget {
> > > > >
> > > > >leaf name {
> > > > >
> > > > >  type string;
> > > > >
> > > > >  description "Name of my foo widget";
> > > > >
> > > > >}
> > > > >
> > > > >  }
> > > > >
> > > > >
> > > > >
> > > > >  grouping bar_widget {
> > > > >
> > > > >leaf name {
> > > 

Re: [netmod] yang-data-ext issues

[Martin Bjorklund]

Andy Bierman  wrote:
> On Wed, Apr 18, 2018 at 10:47 AM, Martin Bjorklund  wrote:
> 
> > Hi,
> >
> > Andy Bierman  wrote:
> > > On Wed, Apr 18, 2018 at 10:26 AM, Kent Watsen 
> > wrote:
> > >
> > > > I like Andy's proposal below, for the argument of the 'yang-data'
> > > > statement to encode some meta-information regarding the
> > context/namespace
> > > > in which it's used, but I wonder how it really works.  For instance,
> > would
> > > > "top" and "error-info" be the only allowed base-path values for the
> > > > argument? and what is the value of the remainder of the path?  are we
> > > > expecting for there to be some kind us 'uses' statement that can refer
> > to
> > > > just the base-path component to implement substitution-group like
> > behavior?
> > > >
> > > >
> > > >
> > >
> > >
> > > If we want to avoid defining these contexts, then we could just define
> > root
> > > vs. nonroot.
> > >
> > > e,g:
> > >
> > > x:yang-data /mydef1 {
> > >   container foo;
> > > }
> > >
> > > x:yang-data mydef2 {
> > >   leaf x;
> > >   leaf y;
> > >   container z;
> > > }
> > >
> > >
> > > Only an argument starting with '/' would be treated as a top-level data
> > > node.
> > >
> > > All other yang-data definitions are not allowed to appear as a root node.
> > > The context where this yang-data is used is completely proprietary.
> > > The mechanism used to expand this yang-data as if it was a grouping
> > > is completely proprietary.
> > >
> > > The augment-yang-data extension only applies to top-level yang-data
> > > definitions.
> > >
> > > However, my preference is to only standardize top-level yang-data.
> >
> > What is "top-level" yang-data?
> >
> >
> >
> It is a data structure that represents an instance document.

So then I assume that you also want to change the current draft -01
behavior so that a yang-data structure MUST have a single container as
the child?  Just like in rc:yang-data.


> Since this is the ONLY definition of yang-data we have in the standard,
> what is a yang-data definition that represents some unspecified usage,
> other than an instance document?

We want to create a flexible solution for creating structures that can
be used in other places than just self-contained instance document.
One example is the error-info data (see subscribed-notifications).

> Why is this any different than a YANG grouping?

?  We don't have these CLRs for groupings; the following is legal:

  grouping foo {
leaf a { ... }
leaf b { ... }
  }

  grouping bar {
leaf b { ... }
  }


It is up to the user of the grouping to ensure it is used in a way so
that the result is legal.  I think yang-data should work the same
way.


/martin



> 
> 
> 
> > /martin
> >
> >
> >
> Andy
> 
> 
> 
> > > I do not see any need for the other form since all functionality can be
> > > achieved with a grouping and a proprietary YANG extension.
> > >
> > > Kent // contributor
> > > >
> > >
> > > Andy
> > >
> > >
> > > >
> > > >
> > > >
> > > >
> > > > On 4/16/18, 1:05 PM, "netmod on behalf of Andy Bierman" <
> > > > netmod-boun...@ietf.org on behalf of a...@yumaworks.com> wrote:
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Mon, Apr 16, 2018 at 9:46 AM, Robert Wilton 
> > wrote:
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On 16/04/2018 17:07, Andy Bierman wrote:
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Mon, Apr 16, 2018 at 8:44 AM, Robert Wilton 
> > wrote:
> > > >
> > > > Don't groupings have a somewhat similar concern?
> > > >
> > > >  E.g. if two groupings define the same data node name and are used at
> > the
> > > > same point then you would get a namespace clash, but YANG does not
> > disallow
> > > > the groupings:
> > > >
> > > >
> > > >  grouping foo_widget {
> > > >
> > > >leaf name {
> > > >
> > > >  type string;
> > > >
> > > >  description "Name of my foo widget";
> > > >
> > > >}
> > > >
> > > >  }
> > > >
> > > >
> > > >
> > > >  grouping bar_widget {
> > > >
> > > >leaf name {
> > > >
> > > >  type string;
> > > >
> > > >  description "Name of my bar widget";
> > > >
> > > >}
> > > >
> > > >  }
> > > >
> > > >
> > > >
> > > >  container all_widgets {
> > > >
> > > >uses foo_widget;
> > > >
> > > >uses bar_widget;
> > > >
> > > >  }
> > > >
> > > >
> > > > The principal difference here, is that the compiler can easily check
> > and
> > > > reject the conflict at the uses statements.
> > > >
> > > > Hence I think that it would be good if we could find a solution for
> > > > yang-data-ext that doesn't not require all root yang-data nodes to be
> > > > unique, since that feels somewhat clunky.  I.e. my preference is to
> > keep
> > > > them less restrictive, as Martin has proposed, if this is feasible.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >

Re: [netmod] yang-data-ext issues

[Ladislav Lhotka]

On Sat, 2018-04-21 at 03:16 +0200, Robert Varga wrote:
> On 17/04/18 07:35, Ladislav Lhotka wrote:
> > Hi,
> > 
> > this is a slippery slope. If we want to turn YANG into a general-purpose
> > schema language, it should IMO be done the other way around: design a
> > general-purpose schema language with a sound architecture, and then use
> > it for defining schemas of datastores, protocol messages or whatever.
> > 
> > YANG extensions make changes to the original YANG architecture way too
> > easy, but the result may be a bastard with no architecture at all.
> 
> +1 in general, although I am not convinced we need to start from scratch.

I didn't mean to start from scratch, but the thing is that YANG spec contains
many references to the specific NM context that don't make sense in other
contexts, so these would need to be removed. To begin with, it is the config 
true/false dichotomy.

> 
> The problem is that the metamodel behind YANG is not formally defined,
> which means every implementer has to reverse-engineer it from
> RFC6020/7960 (and 6241, and others). Since there is no metamodel spec,
> it is very hard to reason about how an extension affects it, especially
> in edge cases -- which can (and most probably will) lead to bastardization.

In fact, for the major XML schema languages the metamodel stems from a specific
formal validation algorithm. This article is quite instructive:

http://pike.psu.edu/publications/toit05.pdf

A useful side effect of the YANG-to-DSDL mapping was the evidence that YANG 1.0
was still pretty close to the mainstream of XML schema languages.
  
> 
> One example: YANG 1.1 was supposed to be a backwards-compatible, yet it
> introduced multiple-inheritence to a language which was previously
> strictly single-inheritence. That sort of change is a major revision of
> the metamodel and certainly does not qualify as backwards-compatible at
> that level of abstraction.

I'd defend YANG 1.1 here, I think it was a well managed and conservative update.
The meaning of backward compatibility was defined in the charter: YANG 1.0
modules should continue to work in 1.1. Apart from fixing evident bugs, I
believe this goal was achieved.

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.  

Regarding your example: from my own experience, implementing validation of
identityref values with multiple inheritance is not terribly complicated in
comparison to single inheritance. I have other favorites for the most peculiar
feature in YANG.

> 
> It may not be important for run-of-the-mill NETCONF operations, but
> becomes pivotal when you are mapping YANG to other languages.

You are right, if such a mapping is what you need. I have myself given up
updating the DSDL mapping.

Lada

> 
> Regards,
> Robert
> 
> ___
> 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

[Robert Varga]

On 17/04/18 07:35, Ladislav Lhotka wrote:
> Hi,
> 
> this is a slippery slope. If we want to turn YANG into a general-purpose
> schema language, it should IMO be done the other way around: design a
> general-purpose schema language with a sound architecture, and then use
> it for defining schemas of datastores, protocol messages or whatever.
> 
> YANG extensions make changes to the original YANG architecture way too
> easy, but the result may be a bastard with no architecture at all.

+1 in general, although I am not convinced we need to start from scratch.

The problem is that the metamodel behind YANG is not formally defined,
which means every implementer has to reverse-engineer it from
RFC6020/7960 (and 6241, and others). Since there is no metamodel spec,
it is very hard to reason about how an extension affects it, especially
in edge cases -- which can (and most probably will) lead to bastardization.

One example: YANG 1.1 was supposed to be a backwards-compatible, yet it
introduced multiple-inheritence to a language which was previously
strictly single-inheritence. That sort of change is a major revision of
the metamodel and certainly does not qualify as backwards-compatible at
that level of abstraction.

It may not be important for run-of-the-mill NETCONF operations, but
becomes pivotal when you are mapping YANG to other languages.

Regards,
Robert



signature.asc
Description: OpenPGP digital signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] yang-data-ext issues

[Kent Watsen]

Another and somewhat radical idea is to think of 'yang-data' as defining a data 
node, like a 'container', but not a config or opstate node.  Yes, this is 
different from rc:yang-data, which defines a transparent node, like 'choice', 
but maybe it's okay if we can get the substitution groups part working.  For 
instance:

From draft-ietf-anima-voucher:
OLD:
   rc:yang-data voucher-artifact {
  container voucher {…}
}
NEW:
   yd:yang-data voucher {
  …
}

From draft-ietf-netconf-zerotouch:
OLD
 rc:yang-data "zerotouch-information" {
   choice information-type {
 container redirect-information {…}
 container onboarding-information {…}
   }
 }
NEW
 yd:yang-data "redirect-information" {
 yd:substitution-group zerotouch-information;
 …
 }
 yd:yang-data "onboarding-information" {
 yd:substitution-group zerotouch-information;
 …
 }

And for the error-info use-case:

yd:yang-data "error-info" {
choice error-type {
leaf my-error1 {…}
leaf my-error2 {…}
}
   }


Thoughts?

Kent


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

Re: [netmod] yang-data-ext issues

[Andy Bierman]

On Wed, Apr 18, 2018 at 10:47 AM, Martin Bjorklund  wrote:

> Hi,
>
> Andy Bierman  wrote:
> > On Wed, Apr 18, 2018 at 10:26 AM, Kent Watsen 
> wrote:
> >
> > > I like Andy's proposal below, for the argument of the 'yang-data'
> > > statement to encode some meta-information regarding the
> context/namespace
> > > in which it's used, but I wonder how it really works.  For instance,
> would
> > > "top" and "error-info" be the only allowed base-path values for the
> > > argument? and what is the value of the remainder of the path?  are we
> > > expecting for there to be some kind us 'uses' statement that can refer
> to
> > > just the base-path component to implement substitution-group like
> behavior?
> > >
> > >
> > >
> >
> >
> > If we want to avoid defining these contexts, then we could just define
> root
> > vs. nonroot.
> >
> > e,g:
> >
> > x:yang-data /mydef1 {
> >   container foo;
> > }
> >
> > x:yang-data mydef2 {
> >   leaf x;
> >   leaf y;
> >   container z;
> > }
> >
> >
> > Only an argument starting with '/' would be treated as a top-level data
> > node.
> >
> > All other yang-data definitions are not allowed to appear as a root node.
> > The context where this yang-data is used is completely proprietary.
> > The mechanism used to expand this yang-data as if it was a grouping
> > is completely proprietary.
> >
> > The augment-yang-data extension only applies to top-level yang-data
> > definitions.
> >
> > However, my preference is to only standardize top-level yang-data.
>
> What is "top-level" yang-data?
>
>
>
It is a data structure that represents an instance document.

Since this is the ONLY definition of yang-data we have in the standard,
what is a yang-data definition that represents some unspecified usage,
other than an instance document?

Why is this any different than a YANG grouping?



> /martin
>
>
>
Andy



> > I do not see any need for the other form since all functionality can be
> > achieved with a grouping and a proprietary YANG extension.
> >
> > Kent // contributor
> > >
> >
> > Andy
> >
> >
> > >
> > >
> > >
> > >
> > > On 4/16/18, 1:05 PM, "netmod on behalf of Andy Bierman" <
> > > netmod-boun...@ietf.org on behalf of a...@yumaworks.com> wrote:
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Mon, Apr 16, 2018 at 9:46 AM, Robert Wilton 
> wrote:
> > >
> > >
> > >
> > >
> > >
> > > On 16/04/2018 17:07, Andy Bierman wrote:
> > >
> > >
> > >
> > >
> > >
> > > On Mon, Apr 16, 2018 at 8:44 AM, Robert Wilton 
> wrote:
> > >
> > > Don't groupings have a somewhat similar concern?
> > >
> > >  E.g. if two groupings define the same data node name and are used at
> the
> > > same point then you would get a namespace clash, but YANG does not
> disallow
> > > the groupings:
> > >
> > >
> > >  grouping foo_widget {
> > >
> > >leaf name {
> > >
> > >  type string;
> > >
> > >  description "Name of my foo widget";
> > >
> > >}
> > >
> > >  }
> > >
> > >
> > >
> > >  grouping bar_widget {
> > >
> > >leaf name {
> > >
> > >  type string;
> > >
> > >  description "Name of my bar widget";
> > >
> > >}
> > >
> > >  }
> > >
> > >
> > >
> > >  container all_widgets {
> > >
> > >uses foo_widget;
> > >
> > >uses bar_widget;
> > >
> > >  }
> > >
> > >
> > > The principal difference here, is that the compiler can easily check
> and
> > > reject the conflict at the uses statements.
> > >
> > > Hence I think that it would be good if we could find a solution for
> > > yang-data-ext that doesn't not require all root yang-data nodes to be
> > > unique, since that feels somewhat clunky.  I.e. my preference is to
> keep
> > > them less restrictive, as Martin has proposed, if this is feasible.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > It is not clunky that 2 top-level YANG data nodes in the same module
> > >
> > > have unique names. This is simple and deterministic.
> > >
> > > This restriction has not been a problem so far.
> > >
> > > I agree with the statements above.
> > >
> > > But it is not clear to me that yang-data-ext is really defining new top
> > > level data nodes that are part of the same tree/namespace as the
> > > configuration/state nodes.  In Martin's examples they were used within
> > > RPCs, and it the forcing the names to be unique in that context that I
> > > think would be clunky.  E.g. in Martin's example forcing different
> names
> > > for "reason" and "user-info" doesn't seem to be helpful.
> > >
> > >
> > >
> > >
> > >
> > >
> > > The yang-data statement has to define the context or new abstract
> > > namespace,
> > >
> > > or whatever this hack is called.
> > >
> > > Perhaps.  I think that this depends on how they are used.
> > >
> > >
> > >
> > >
> > >
> > > The yang-data statement has to specify the expansion point, or
> > >
> > > at least specify that it is or is not the 

Re: [netmod] yang-data-ext issues

[Martin Bjorklund]

Hi,

Andy Bierman  wrote:
> On Wed, Apr 18, 2018 at 10:26 AM, Kent Watsen  wrote:
> 
> > I like Andy's proposal below, for the argument of the 'yang-data'
> > statement to encode some meta-information regarding the context/namespace
> > in which it's used, but I wonder how it really works.  For instance, would
> > "top" and "error-info" be the only allowed base-path values for the
> > argument? and what is the value of the remainder of the path?  are we
> > expecting for there to be some kind us 'uses' statement that can refer to
> > just the base-path component to implement substitution-group like behavior?
> >
> >
> >
> 
> 
> If we want to avoid defining these contexts, then we could just define root
> vs. nonroot.
> 
> e,g:
> 
> x:yang-data /mydef1 {
>   container foo;
> }
> 
> x:yang-data mydef2 {
>   leaf x;
>   leaf y;
>   container z;
> }
> 
> 
> Only an argument starting with '/' would be treated as a top-level data
> node.
> 
> All other yang-data definitions are not allowed to appear as a root node.
> The context where this yang-data is used is completely proprietary.
> The mechanism used to expand this yang-data as if it was a grouping
> is completely proprietary.
> 
> The augment-yang-data extension only applies to top-level yang-data
> definitions.
> 
> However, my preference is to only standardize top-level yang-data.

What is "top-level" yang-data?


/martin


> I do not see any need for the other form since all functionality can be
> achieved with a grouping and a proprietary YANG extension.
> 
> Kent // contributor
> >
> 
> Andy
> 
> 
> >
> >
> >
> >
> > On 4/16/18, 1:05 PM, "netmod on behalf of Andy Bierman" <
> > netmod-boun...@ietf.org on behalf of a...@yumaworks.com> wrote:
> >
> >
> >
> >
> >
> >
> >
> > On Mon, Apr 16, 2018 at 9:46 AM, Robert Wilton  wrote:
> >
> >
> >
> >
> >
> > On 16/04/2018 17:07, Andy Bierman wrote:
> >
> >
> >
> >
> >
> > On Mon, Apr 16, 2018 at 8:44 AM, Robert Wilton  wrote:
> >
> > Don't groupings have a somewhat similar concern?
> >
> >  E.g. if two groupings define the same data node name and are used at the
> > same point then you would get a namespace clash, but YANG does not disallow
> > the groupings:
> >
> >
> >  grouping foo_widget {
> >
> >leaf name {
> >
> >  type string;
> >
> >  description "Name of my foo widget";
> >
> >}
> >
> >  }
> >
> >
> >
> >  grouping bar_widget {
> >
> >leaf name {
> >
> >  type string;
> >
> >  description "Name of my bar widget";
> >
> >}
> >
> >  }
> >
> >
> >
> >  container all_widgets {
> >
> >uses foo_widget;
> >
> >uses bar_widget;
> >
> >  }
> >
> >
> > The principal difference here, is that the compiler can easily check and
> > reject the conflict at the uses statements.
> >
> > Hence I think that it would be good if we could find a solution for
> > yang-data-ext that doesn't not require all root yang-data nodes to be
> > unique, since that feels somewhat clunky.  I.e. my preference is to keep
> > them less restrictive, as Martin has proposed, if this is feasible.
> >
> >
> >
> >
> >
> >
> >
> > It is not clunky that 2 top-level YANG data nodes in the same module
> >
> > have unique names. This is simple and deterministic.
> >
> > This restriction has not been a problem so far.
> >
> > I agree with the statements above.
> >
> > But it is not clear to me that yang-data-ext is really defining new top
> > level data nodes that are part of the same tree/namespace as the
> > configuration/state nodes.  In Martin's examples they were used within
> > RPCs, and it the forcing the names to be unique in that context that I
> > think would be clunky.  E.g. in Martin's example forcing different names
> > for "reason" and "user-info" doesn't seem to be helpful.
> >
> >
> >
> >
> >
> >
> > The yang-data statement has to define the context or new abstract
> > namespace,
> >
> > or whatever this hack is called.
> >
> > Perhaps.  I think that this depends on how they are used.
> >
> >
> >
> >
> >
> > The yang-data statement has to specify the expansion point, or
> >
> > at least specify that it is or is not the top-level.
> >
> >
> >
> >   yang-data top/name1 {
> >
> >   container mydata;
> >
> >   }
> >
> >
> >
> > where context is something like "top" or "error-info", etc.
> >
> >
> >
> > It is trivial to use groupings if the same set of nodes needs to be used
> > in different contexts:
> >
> >
> >
> >
> >   yang-data error-info/name1 {
> >
> >   container mydata;
> >
> >   }
> >
> >
> >
> > Only the context named "top" is restricted to a resulting single-container
> >
> > and cannot have duplicate names.
> >
> >
> >
> > This is OK:
> >
> >
> >
> >   x:yang-data error-info/my-error1 {
> >
> >   leaf reason {}
> >
> >   }
> >
> >
> >
> >
> >   x:yang-data error-info/my-error2 {
> >
> >   leaf reason {}
> >
> >   }
> >
> >
> >
> >
> 

Re: [netmod] yang-data-ext issues

[Andy Bierman]

On Wed, Apr 18, 2018 at 10:26 AM, Kent Watsen  wrote:

> I like Andy's proposal below, for the argument of the 'yang-data'
> statement to encode some meta-information regarding the context/namespace
> in which it's used, but I wonder how it really works.  For instance, would
> "top" and "error-info" be the only allowed base-path values for the
> argument? and what is the value of the remainder of the path?  are we
> expecting for there to be some kind us 'uses' statement that can refer to
> just the base-path component to implement substitution-group like behavior?
>
>
>


If we want to avoid defining these contexts, then we could just define root
vs. nonroot.

e,g:

x:yang-data /mydef1 {
  container foo;
}

x:yang-data mydef2 {
  leaf x;
  leaf y;
  container z;
}


Only an argument starting with '/' would be treated as a top-level data
node.

All other yang-data definitions are not allowed to appear as a root node.
The context where this yang-data is used is completely proprietary.
The mechanism used to expand this yang-data as if it was a grouping
is completely proprietary.

The augment-yang-data extension only applies to top-level yang-data
definitions.

However, my preference is to only standardize top-level yang-data.
I do not see any need for the other form since all functionality can be
achieved with a grouping and a proprietary YANG extension.

Kent // contributor
>

Andy


>
>
>
>
> On 4/16/18, 1:05 PM, "netmod on behalf of Andy Bierman" <
> netmod-boun...@ietf.org on behalf of a...@yumaworks.com> wrote:
>
>
>
>
>
>
>
> On Mon, Apr 16, 2018 at 9:46 AM, Robert Wilton  wrote:
>
>
>
>
>
> On 16/04/2018 17:07, Andy Bierman wrote:
>
>
>
>
>
> On Mon, Apr 16, 2018 at 8:44 AM, Robert Wilton  wrote:
>
> Don't groupings have a somewhat similar concern?
>
>  E.g. if two groupings define the same data node name and are used at the
> same point then you would get a namespace clash, but YANG does not disallow
> the groupings:
>
>
>  grouping foo_widget {
>
>leaf name {
>
>  type string;
>
>  description "Name of my foo widget";
>
>}
>
>  }
>
>
>
>  grouping bar_widget {
>
>leaf name {
>
>  type string;
>
>  description "Name of my bar widget";
>
>}
>
>  }
>
>
>
>  container all_widgets {
>
>uses foo_widget;
>
>uses bar_widget;
>
>  }
>
>
> The principal difference here, is that the compiler can easily check and
> reject the conflict at the uses statements.
>
> Hence I think that it would be good if we could find a solution for
> yang-data-ext that doesn't not require all root yang-data nodes to be
> unique, since that feels somewhat clunky.  I.e. my preference is to keep
> them less restrictive, as Martin has proposed, if this is feasible.
>
>
>
>
>
>
>
> It is not clunky that 2 top-level YANG data nodes in the same module
>
> have unique names. This is simple and deterministic.
>
> This restriction has not been a problem so far.
>
> I agree with the statements above.
>
> But it is not clear to me that yang-data-ext is really defining new top
> level data nodes that are part of the same tree/namespace as the
> configuration/state nodes.  In Martin's examples they were used within
> RPCs, and it the forcing the names to be unique in that context that I
> think would be clunky.  E.g. in Martin's example forcing different names
> for "reason" and "user-info" doesn't seem to be helpful.
>
>
>
>
>
>
> The yang-data statement has to define the context or new abstract
> namespace,
>
> or whatever this hack is called.
>
> Perhaps.  I think that this depends on how they are used.
>
>
>
>
>
> The yang-data statement has to specify the expansion point, or
>
> at least specify that it is or is not the top-level.
>
>
>
>   yang-data top/name1 {
>
>   container mydata;
>
>   }
>
>
>
> where context is something like "top" or "error-info", etc.
>
>
>
> It is trivial to use groupings if the same set of nodes needs to be used
> in different contexts:
>
>
>
>
>   yang-data error-info/name1 {
>
>   container mydata;
>
>   }
>
>
>
> Only the context named "top" is restricted to a resulting single-container
>
> and cannot have duplicate names.
>
>
>
> This is OK:
>
>
>
>   x:yang-data error-info/my-error1 {
>
>   leaf reason {}
>
>   }
>
>
>
>
>   x:yang-data error-info/my-error2 {
>
>   leaf reason {}
>
>   }
>
>
>
>
>
>
>
>
> Could a fix for this be something along the lines of:
>  - yang-data names must be unique amongst other top level data nodes
> within the module.
>  - if yang-data extensions are used at the top level then their name must
> be used as a single top level container.
>  - if a yang-data extension is used within another structure then the
> yang-data name is excluded, and the top level nodes defined in the
> yang-data definition are used 
>
>
>   Every tool that implements yang-data has to be able
>
> to interpret a yang-data 

Re: [netmod] yang-data-ext issues

[Martin Bjorklund]

Hi,

[Kent, your email program has messed up the quoting in this thread.
It becomes quite difficult to follow.  And no, please don't invent a
new quoting style in every email thread...]

Kent Watsen  wrote:
> I like Andy's proposal below, for the argument of the 'yang-data'
> statement to encode some meta-information regarding the
> context/namespace in which it's used, but I wonder how it really
> works.

I *think* that what Andy proposes is a way to formally specify the
context in which the yang-data structure will be used.

My proposal was to simply define the context in plain text.  A formal
way of defining the context would of course be useful -- if we can
find agreement on how that would work.  I don't think we should
hard-code a few contexts in this draft; the mechanism must be
extensible.

An alternative syntax could be to introduce a new substatement:

  yd:yang-data foo {
yd:context ...;
description "...";
  }


/martin



> For instance, would "top" and "error-info" be the only allowed
> base-path values for the argument? and what is the value of the
> remainder of the path?  are we expecting for there to be some kind us
> 'uses' statement that can refer to just the base-path component to
> implement substitution-group like behavior?
> 
> Kent // contributor
> 
> 
> On 4/16/18, 1:05 PM, "netmod on behalf of Andy Bierman"
>  on behalf of
> a...@yumaworks.com> wrote:
> 
> 
> 
> On Mon, Apr 16, 2018 at 9:46 AM, Robert Wilton
> > wrote:
> 
> 
> 
> On 16/04/2018 17:07, Andy Bierman wrote:
> 
> 
> On Mon, Apr 16, 2018 at 8:44 AM, Robert Wilton
> > wrote:
> 
> Don't groupings have a somewhat similar concern?
> 
>  E.g. if two groupings define the same data node name and are used at
>  the same point then you would get a namespace clash, but YANG does not
>  disallow the groupings:
> 
> 
> 
>  grouping foo_widget {
> 
>leaf name {
> 
>  type string;
> 
>  description "Name of my foo widget";
> 
>}
> 
>  }
> 
> 
> 
>  grouping bar_widget {
> 
>leaf name {
> 
>  type string;
> 
>  description "Name of my bar widget";
> 
>}
> 
>  }
> 
> 
> 
>  container all_widgets {
> 
>uses foo_widget;
> 
>uses bar_widget;
> 
>  }
> 
> The principal difference here, is that the compiler can easily check
> and reject the conflict at the uses statements.
> 
> Hence I think that it would be good if we could find a solution for
> yang-data-ext that doesn't not require all root yang-data nodes to be
> unique, since that feels somewhat clunky.  I.e. my preference is to
> keep them less restrictive, as Martin has proposed, if this is
> feasible.
> 
> 
> 
> It is not clunky that 2 top-level YANG data nodes in the same module
> have unique names. This is simple and deterministic.
> This restriction has not been a problem so far.
> I agree with the statements above.
> 
> But it is not clear to me that yang-data-ext is really defining new
> top level data nodes that are part of the same tree/namespace as the
> configuration/state nodes.  In Martin's examples they were used within
> RPCs, and it the forcing the names to be unique in that context that I
> think would be clunky.  E.g. in Martin's example forcing different
> names for "reason" and "user-info" doesn't seem to be helpful.
> 
> 
> 
> 
> The yang-data statement has to define the context or new abstract
> namespace,
> or whatever this hack is called.
> Perhaps.  I think that this depends on how they are used.
> 
> 
> The yang-data statement has to specify the expansion point, or
> at least specify that it is or is not the top-level.
> 
>   yang-data top/name1 {
>   container mydata;
>   }
> 
> where context is something like "top" or "error-info", etc.
> 
> It is trivial to use groupings if the same set of nodes needs to be
> used in different contexts:
> 
> 
>   yang-data error-info/name1 {
>   container mydata;
>   }
> 
> Only the context named "top" is restricted to a resulting
> single-container
> and cannot have duplicate names.
> 
> This is OK:
> 
>   x:yang-data error-info/my-error1 {
>   leaf reason {}
>   }
> 
> 
>   x:yang-data error-info/my-error2 {
>   leaf reason {}
>   }
> 
> 
> 
> 
> Could a fix for this be something along the lines of:
>  - yang-data names must be unique amongst other top level data nodes
>  - within the module.
>  - if yang-data extensions are used at the top level then their name must
>  - be used as a single top level container.
>  - if a yang-data extension is used within another structure then the
>  - yang-data name is excluded, and the top level nodes defined in the
>  - yang-data definition are used 
> 
> 
>   Every tool that implements yang-data has to be able
> to interpret a yang-data statement exactly the same 

Re: [netmod] yang-data-ext issues

[Kent Watsen]

I like Andy's proposal below, for the argument of the 'yang-data' statement to 
encode some meta-information regarding the context/namespace in which it's 
used, but I wonder how it really works.  For instance, would "top" and 
"error-info" be the only allowed base-path values for the argument? and what is 
the value of the remainder of the path?  are we expecting for there to be some 
kind us 'uses' statement that can refer to just the base-path component to 
implement substitution-group like behavior?

Kent // contributor


On 4/16/18, 1:05 PM, "netmod on behalf of Andy Bierman" 
 on behalf of 
a...@yumaworks.com> wrote:



On Mon, Apr 16, 2018 at 9:46 AM, Robert Wilton 
> wrote:



On 16/04/2018 17:07, Andy Bierman wrote:


On Mon, Apr 16, 2018 at 8:44 AM, Robert Wilton 
> wrote:

Don't groupings have a somewhat similar concern?

 E.g. if two groupings define the same data node name and are used at the same 
point then you would get a namespace clash, but YANG does not disallow the 
groupings:



 grouping foo_widget {

   leaf name {

 type string;

 description "Name of my foo widget";

   }

 }



 grouping bar_widget {

   leaf name {

 type string;

 description "Name of my bar widget";

   }

 }



 container all_widgets {

   uses foo_widget;

   uses bar_widget;

 }

The principal difference here, is that the compiler can easily check and reject 
the conflict at the uses statements.

Hence I think that it would be good if we could find a solution for 
yang-data-ext that doesn't not require all root yang-data nodes to be unique, 
since that feels somewhat clunky.  I.e. my preference is to keep them less 
restrictive, as Martin has proposed, if this is feasible.



It is not clunky that 2 top-level YANG data nodes in the same module
have unique names. This is simple and deterministic.
This restriction has not been a problem so far.
I agree with the statements above.

But it is not clear to me that yang-data-ext is really defining new top level 
data nodes that are part of the same tree/namespace as the configuration/state 
nodes.  In Martin's examples they were used within RPCs, and it the forcing the 
names to be unique in that context that I think would be clunky.  E.g. in 
Martin's example forcing different names for "reason" and "user-info" doesn't 
seem to be helpful.




The yang-data statement has to define the context or new abstract namespace,
or whatever this hack is called.
Perhaps.  I think that this depends on how they are used.


The yang-data statement has to specify the expansion point, or
at least specify that it is or is not the top-level.

  yang-data top/name1 {
  container mydata;
  }

where context is something like "top" or "error-info", etc.

It is trivial to use groupings if the same set of nodes needs to be used in 
different contexts:


  yang-data error-info/name1 {
  container mydata;
  }

Only the context named "top" is restricted to a resulting single-container
and cannot have duplicate names.

This is OK:

  x:yang-data error-info/my-error1 {
  leaf reason {}
  }


  x:yang-data error-info/my-error2 {
  leaf reason {}
  }




Could a fix for this be something along the lines of:
 - yang-data names must be unique amongst other top level data nodes within the 
module.
 - if yang-data extensions are used at the top level then their name must be 
used as a single top level container.
 - if a yang-data extension is used within another structure then the yang-data 
name is excluded, and the top level nodes defined in the yang-data definition 
are used 


  Every tool that implements yang-data has to be able
to interpret a yang-data statement exactly the same way.

If you want to reinvent XSD substitutionGroup, then do it right.
I'm not familiar with them.  From a quick read, I don't see how they are 
related to the problem that we are trying to solve here.


A substitutionGroup allows a point int the schema to be identified by name.
Different elements can be defined that match this name, which then can be
used (like a YANG choice) at the specified schema point.
(e.g. error-info above is like a substitutionGroup)



Thanks,
Rob

Andy







Thanks,
Rob


Andy


On 16/04/2018 15:36, Andy Bierman wrote:
Hi,

I am strongly opposed to this change because it breaks the rule in YANG 1.1
that there cannot be 2 sibling nodes defined in the same module namespace.

IMO since any yang-data nodes are ALLOWED to be used at the top-level,
then these top-level nodes cannot have conflicting names.

It is very important when parsing an instance document that the instance data
can be associated with the correct schema.  This is not possible if the
same top-level node has multiple yang-data nodes defined.

If one needs to 

Re: [netmod] yang-data-ext issues

[Ladislav Lhotka]

Hi,

this is a slippery slope. If we want to turn YANG into a general-purpose
schema language, it should IMO be done the other way around: design a
general-purpose schema language with a sound architecture, and then use
it for defining schemas of datastores, protocol messages or whatever.

YANG extensions make changes to the original YANG architecture way too
easy, but the result may be a bastard with no architecture at all.

Lada

Martin Bjorklund  writes:

> Hi,
>
> While preparing draft-ietf-netmod-yang-data-ext-02, it turned out that
> it is not clear what, if any, restrictions should be enforced for
> yang-data structures.  Even among the authors we have different ideas
> for how this should work.
>
> Background:
>
> In 8040, the original yang-data extension had a restriction that said
> that a yang-data structure MUST have exactly one container, since it
> wouldn't be possible to have a yang-data structure in an XML instance
> document otherwise.
>
> Since people want to use yang-data structures in other places, this
> restriction was lifted in the new draft:
>
>There is no longer an assumption that a yang data structure can
>only be used as a top-level abstraction, instead of nested within
>some other data structure.
>
>
> With this in mind, here's a use case that I think we ought to support:
>
>   rpc my-first-rpc {
> description
>   "Bla bla...
>If an error occurs,  will contain an instance of
>the yang-data structure 'my-first-rpc-error-info'.";
> ...
>   }
>
>   yang-data my-first-rpc-error-info {
> leaf reason { ... }
> container user-info { ... }
>   }
>
>   rpc my-second-rpc {
> description
>   "Bla bla...
>If an error occurs,  will contain an instance of
>the yang-data structure 'my-second-rpc-error-info'.";
> ...
>   }
>
>   yang-data my-second-rpc-error-info {
> leaf reason { ... }
> leaf important-url { ... }
>   }
>
> (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.)
>
> In the example above, note that the leaf "reason" is present in both
> structures.  IMO this is not a problem, since these structures are
> used in different contexts.
>
> My point is that I think we should impose as few restrictions as
> possible to the yang-data extension.  It should be up to the user of
> yang-data to ensure that the structure is defined in such a way so
> that it can be used properly.  For example, a structure that is
> supposed to describe an XML instance document cannot define two leafs
> at the top level.
>
> If the WG agrees with what I wrote above, we need to change the
> augment-yang-data extension so that you would write for example:
>
>   yx:augment-yang-data /ex:my-first-rpc-error-info/ex:user-info {
> ...
>   }
>
> Comments?
>
>
>
> /martin
>
> ___
> 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

[Andy Bierman]

On Mon, Apr 16, 2018 at 9:46 AM, Robert Wilton  wrote:

>
>
> On 16/04/2018 17:07, Andy Bierman wrote:
>
>
>
> On Mon, Apr 16, 2018 at 8:44 AM, Robert Wilton  wrote:
>
>> Don't groupings have a somewhat similar concern?
>>
>>  E.g. if two groupings define the same data node name and are used at the
>> same point then you would get a namespace clash, but YANG does not disallow
>> the groupings:
>>
>>  grouping foo_widget {
>>leaf name {
>>  type string;
>>  description "Name of my foo widget";
>>}
>>  }
>>
>>  grouping bar_widget {
>>leaf name {
>>  type string;
>>  description "Name of my bar widget";
>>}
>>  }
>>
>>
>>  container all_widgets {
>>uses foo_widget;
>>uses bar_widget;
>>  }
>>
>>
>> The principal difference here, is that the compiler can easily check and
>> reject the conflict at the uses statements.
>>
>> Hence I think that it would be good if we could find a solution for
>> yang-data-ext that doesn't not require all root yang-data nodes to be
>> unique, since that feels somewhat clunky.  I.e. my preference is to keep
>> them less restrictive, as Martin has proposed, if this is feasible.
>>
>>
>
>
> It is not clunky that 2 top-level YANG data nodes in the same module
> have unique names. This is simple and deterministic.
> This restriction has not been a problem so far.
>
> I agree with the statements above.
>
> But it is not clear to me that yang-data-ext is really defining new top
> level data nodes that are part of the same tree/namespace as the
> configuration/state nodes.  In Martin's examples they were used within
> RPCs, and it the forcing the names to be unique in that context that I
> think would be clunky.  E.g. in Martin's example forcing different names
> for "reason" and "user-info" doesn't seem to be helpful.
>
>
>
> The yang-data statement has to define the context or new abstract
> namespace,
> or whatever this hack is called.
>
> Perhaps.  I think that this depends on how they are used.
>


The yang-data statement has to specify the expansion point, or
at least specify that it is or is not the top-level.

  yang-data top/name1 {
  container mydata;
  }

where context is something like "top" or "error-info", etc.

It is trivial to use groupings if the same set of nodes needs to be used in
different contexts:


  yang-data error-info/name1 {
  container mydata;
  }

Only the context named "top" is restricted to a resulting single-container
and cannot have duplicate names.

This is OK:

  x:yang-data error-info/my-error1 {
  leaf reason {}
  }


  x:yang-data error-info/my-error2 {
  leaf reason {}
  }




> Could a fix for this be something along the lines of:
>  - yang-data names must be unique amongst other top level data nodes
> within the module.
>  - if yang-data extensions are used at the top level then their name must
> be used as a single top level container.
>  - if a yang-data extension is used within another structure then the
> yang-data name is excluded, and the top level nodes defined in the
> yang-data definition are used 
>
>   Every tool that implements yang-data has to be able
> to interpret a yang-data statement exactly the same way.
>
> If you want to reinvent XSD substitutionGroup, then do it right.
>
> I'm not familiar with them.  From a quick read, I don't see how they are
> related to the problem that we are trying to solve here.
>
>

A substitutionGroup allows a point int the schema to be identified by name.
Different elements can be defined that match this name, which then can be
used (like a YANG choice) at the specified schema point.
(e.g. error-info above is like a substitutionGroup)




> Thanks,
> Rob
>

Andy


>
>
>
>
>
>
>> Thanks,
>> Rob
>>
>>
>
> Andy
>
>
>>
>> On 16/04/2018 15:36, Andy Bierman wrote:
>>
>> Hi,
>>
>> I am strongly opposed to this change because it breaks the rule in YANG
>> 1.1
>> that there cannot be 2 sibling nodes defined in the same module namespace.
>>
>> IMO since any yang-data nodes are ALLOWED to be used at the top-level,
>> then these top-level nodes cannot have conflicting names.
>>
>> It is very important when parsing an instance document that the instance
>> data
>> can be associated with the correct schema.  This is not possible if the
>> same top-level node has multiple yang-data nodes defined.
>>
>> If one needs to define data that is not top-level, (1) use
>> augment-yang-data
>> or (2) use a different module.
>>
>>
>> Andy
>>
>>
>>
>> On Mon, Apr 16, 2018 at 5:56 AM, Martin Bjorklund  wrote:
>>
>>> Hi,
>>>
>>> While preparing draft-ietf-netmod-yang-data-ext-02, it turned out that
>>> it is not clear what, if any, restrictions should be enforced for
>>> yang-data structures.  Even among the authors we have different ideas
>>> for how this should work.
>>>
>>> Background:
>>>
>>> In 8040, the original yang-data extension had a 

Re: [netmod] yang-data-ext issues

[Robert Wilton]

On 16/04/2018 17:07, Andy Bierman wrote:



On Mon, Apr 16, 2018 at 8:44 AM, Robert Wilton > wrote:


Don't groupings have a somewhat similar concern?

 E.g. if two groupings define the same data node name and are used
at the same point then you would get a namespace clash, but YANG
does not disallow the groupings:

  grouping foo_widget {
leaf name {
  type string;
  description "Name of my foo widget";
    }
  }

  grouping bar_widget {
leaf name {
  type string;
  description "Name of my bar widget";
    }
  }

  container all_widgets {
uses foo_widget;
uses bar_widget;
  }


The principal difference here, is that the compiler can easily
check and reject the conflict at the uses statements.

Hence I think that it would be good if we could find a solution
for yang-data-ext that doesn't not require all root yang-data
nodes to be unique, since that feels somewhat clunky.  I.e. my
preference is to keep them less restrictive, as Martin has
proposed, if this is feasible.




It is not clunky that 2 top-level YANG data nodes in the same module
have unique names. This is simple and deterministic.
This restriction has not been a problem so far.

I agree with the statements above.

But it is not clear to me that yang-data-ext is really defining new top 
level data nodes that are part of the same tree/namespace as the 
configuration/state nodes.  In Martin's examples they were used within 
RPCs, and it the forcing the names to be unique in that context that I 
think would be clunky.  E.g. in Martin's example forcing different names 
for "reason" and "user-info" doesn't seem to be helpful.





The yang-data statement has to define the context or new abstract 
namespace,

or whatever this hack is called.

Perhaps.  I think that this depends on how they are used.

Could a fix for this be something along the lines of:
 - yang-data names must be unique amongst other top level data nodes 
within the module.
 - if yang-data extensions are used at the top level then their name 
must be used as a single top level container.
 - if a yang-data extension is used within another structure then the 
yang-data name is excluded, and the top level nodes defined in the 
yang-data definition are used 



  Every tool that implements yang-data has to be able
to interpret a yang-data statement exactly the same way.

If you want to reinvent XSD substitutionGroup, then do it right.
I'm not familiar with them.  From a quick read, I don't see how they are 
related to the problem that we are trying to solve here.


Thanks,
Rob





Thanks,
Rob



Andy


On 16/04/2018 15:36, Andy Bierman wrote:

Hi,

I am strongly opposed to this change because it breaks the rule
in YANG 1.1
that there cannot be 2 sibling nodes defined in the same module
namespace.

IMO since any yang-data nodes are ALLOWED to be used at the
top-level,
then these top-level nodes cannot have conflicting names.

It is very important when parsing an instance document that the
instance data
can be associated with the correct schema. This is not possible
if the
same top-level node has multiple yang-data nodes defined.

If one needs to define data that is not top-level, (1) use
augment-yang-data
or (2) use a different module.


Andy



On Mon, Apr 16, 2018 at 5:56 AM, Martin Bjorklund > wrote:

Hi,

While preparing draft-ietf-netmod-yang-data-ext-02, it turned
out that
it is not clear what, if any, restrictions should be enforced for
yang-data structures.  Even among the authors we have
different ideas
for how this should work.

Background:

In 8040, the original yang-data extension had a restriction
that said
that a yang-data structure MUST have exactly one container,
since it
wouldn't be possible to have a yang-data structure in an XML
instance
document otherwise.

Since people want to use yang-data structures in other
places, this
restriction was lifted in the new draft:

   There is no longer an assumption that a yang data
structure can
   only be used as a top-level abstraction, instead of nested
within
   some other data structure.


With this in mind, here's a use case that I think we ought to
support:

  rpc my-first-rpc {
    description
      "Bla bla...
       If an error occurs,  will contain an
instance of
       the yang-data structure 'my-first-rpc-error-info'.";
    ...
  }

  yang-data my-first-rpc-error-info {
  

Re: [netmod] yang-data-ext issues

[Martin Bjorklund]

Andy Bierman  wrote:
> On Mon, Apr 16, 2018 at 8:44 AM, Robert Wilton  wrote:
> 
> > Don't groupings have a somewhat similar concern?
> >
> >  E.g. if two groupings define the same data node name and are used at the
> > same point then you would get a namespace clash, but YANG does not disallow
> > the groupings:
> >
> >  grouping foo_widget {
> >leaf name {
> >  type string;
> >  description "Name of my foo widget";
> >}
> >  }
> >
> >  grouping bar_widget {
> >leaf name {
> >  type string;
> >  description "Name of my bar widget";
> >}
> >  }
> >
> >
> >  container all_widgets {
> >uses foo_widget;
> >uses bar_widget;
> >  }
> >
> >
> > The principal difference here, is that the compiler can easily check and
> > reject the conflict at the uses statements.
> >
> > Hence I think that it would be good if we could find a solution for
> > yang-data-ext that doesn't not require all root yang-data nodes to be
> > unique, since that feels somewhat clunky.  I.e. my preference is to keep
> > them less restrictive, as Martin has proposed, if this is feasible.
> >
> >
> 
> 
> It is not clunky that 2 top-level YANG data nodes in the same module
> have unique names.

If the yang-data structure is used nested within some other node, it
does not define a top-level node.  In this case it doesn't have to
have uniquely named nodes, and it doesn't have to define a single
container.

> This is simple and deterministic.
> This restriction has not been a problem so far.

yang-data is a new construct.  A more restrictive version was defined
in RFC 8040, and these restrictions *were* problematic.  I don't want
to make the same mistake again.

> The yang-data statement has to define the context or new abstract namespace,

Yes, agreed.  Regardless of the outcome of this thread, the yang-data
statement has to define where the structure being defined is supposed
to be used.

> or whatever this hack is called.  Every tool that implements yang-data has
> to be able
> to interpret a yang-data statement exactly the same way.
> 
> If you want to reinvent XSD substitutionGroup, then do it right.

This is not a new substitutionGroup.


/martin


> 
> 
> 
> 
> > Thanks,
> > Rob
> >
> >
> 
> Andy
> 
> 
> >
> > On 16/04/2018 15:36, Andy Bierman wrote:
> >
> > Hi,
> >
> > I am strongly opposed to this change because it breaks the rule in YANG 1.1
> > that there cannot be 2 sibling nodes defined in the same module namespace.
> >
> > IMO since any yang-data nodes are ALLOWED to be used at the top-level,
> > then these top-level nodes cannot have conflicting names.
> >
> > It is very important when parsing an instance document that the instance
> > data
> > can be associated with the correct schema.  This is not possible if the
> > same top-level node has multiple yang-data nodes defined.
> >
> > If one needs to define data that is not top-level, (1) use
> > augment-yang-data
> > or (2) use a different module.
> >
> >
> > Andy
> >
> >
> >
> > On Mon, Apr 16, 2018 at 5:56 AM, Martin Bjorklund  wrote:
> >
> >> Hi,
> >>
> >> While preparing draft-ietf-netmod-yang-data-ext-02, it turned out that
> >> it is not clear what, if any, restrictions should be enforced for
> >> yang-data structures.  Even among the authors we have different ideas
> >> for how this should work.
> >>
> >> Background:
> >>
> >> In 8040, the original yang-data extension had a restriction that said
> >> that a yang-data structure MUST have exactly one container, since it
> >> wouldn't be possible to have a yang-data structure in an XML instance
> >> document otherwise.
> >>
> >> Since people want to use yang-data structures in other places, this
> >> restriction was lifted in the new draft:
> >>
> >>There is no longer an assumption that a yang data structure can
> >>only be used as a top-level abstraction, instead of nested within
> >>some other data structure.
> >>
> >>
> >> With this in mind, here's a use case that I think we ought to support:
> >>
> >>   rpc my-first-rpc {
> >> description
> >>   "Bla bla...
> >>If an error occurs,  will contain an instance of
> >>the yang-data structure 'my-first-rpc-error-info'.";
> >> ...
> >>   }
> >>
> >>   yang-data my-first-rpc-error-info {
> >> leaf reason { ... }
> >> container user-info { ... }
> >>   }
> >>
> >>   rpc my-second-rpc {
> >> description
> >>   "Bla bla...
> >>If an error occurs,  will contain an instance of
> >>the yang-data structure 'my-second-rpc-error-info'.";
> >> ...
> >>   }
> >>
> >>   yang-data my-second-rpc-error-info {
> >> leaf reason { ... }
> >> leaf important-url { ... }
> >>   }
> >>
> >> (maybe in the future we could even have a YANG extension statement to
> >> formalize the description:
> >>
> >>rpc my-first-rpc {
> >>  ...
> >>  

Re: [netmod] yang-data-ext issues

[Andy Bierman]

On Mon, Apr 16, 2018 at 8:44 AM, Robert Wilton  wrote:

> Don't groupings have a somewhat similar concern?
>
>  E.g. if two groupings define the same data node name and are used at the
> same point then you would get a namespace clash, but YANG does not disallow
> the groupings:
>
>  grouping foo_widget {
>leaf name {
>  type string;
>  description "Name of my foo widget";
>}
>  }
>
>  grouping bar_widget {
>leaf name {
>  type string;
>  description "Name of my bar widget";
>}
>  }
>
>
>  container all_widgets {
>uses foo_widget;
>uses bar_widget;
>  }
>
>
> The principal difference here, is that the compiler can easily check and
> reject the conflict at the uses statements.
>
> Hence I think that it would be good if we could find a solution for
> yang-data-ext that doesn't not require all root yang-data nodes to be
> unique, since that feels somewhat clunky.  I.e. my preference is to keep
> them less restrictive, as Martin has proposed, if this is feasible.
>
>


It is not clunky that 2 top-level YANG data nodes in the same module
have unique names. This is simple and deterministic.
This restriction has not been a problem so far.


The yang-data statement has to define the context or new abstract namespace,
or whatever this hack is called.  Every tool that implements yang-data has
to be able
to interpret a yang-data statement exactly the same way.

If you want to reinvent XSD substitutionGroup, then do it right.




> Thanks,
> Rob
>
>

Andy


>
> On 16/04/2018 15:36, Andy Bierman wrote:
>
> Hi,
>
> I am strongly opposed to this change because it breaks the rule in YANG 1.1
> that there cannot be 2 sibling nodes defined in the same module namespace.
>
> IMO since any yang-data nodes are ALLOWED to be used at the top-level,
> then these top-level nodes cannot have conflicting names.
>
> It is very important when parsing an instance document that the instance
> data
> can be associated with the correct schema.  This is not possible if the
> same top-level node has multiple yang-data nodes defined.
>
> If one needs to define data that is not top-level, (1) use
> augment-yang-data
> or (2) use a different module.
>
>
> Andy
>
>
>
> On Mon, Apr 16, 2018 at 5:56 AM, Martin Bjorklund  wrote:
>
>> Hi,
>>
>> While preparing draft-ietf-netmod-yang-data-ext-02, it turned out that
>> it is not clear what, if any, restrictions should be enforced for
>> yang-data structures.  Even among the authors we have different ideas
>> for how this should work.
>>
>> Background:
>>
>> In 8040, the original yang-data extension had a restriction that said
>> that a yang-data structure MUST have exactly one container, since it
>> wouldn't be possible to have a yang-data structure in an XML instance
>> document otherwise.
>>
>> Since people want to use yang-data structures in other places, this
>> restriction was lifted in the new draft:
>>
>>There is no longer an assumption that a yang data structure can
>>only be used as a top-level abstraction, instead of nested within
>>some other data structure.
>>
>>
>> With this in mind, here's a use case that I think we ought to support:
>>
>>   rpc my-first-rpc {
>> description
>>   "Bla bla...
>>If an error occurs,  will contain an instance of
>>the yang-data structure 'my-first-rpc-error-info'.";
>> ...
>>   }
>>
>>   yang-data my-first-rpc-error-info {
>> leaf reason { ... }
>> container user-info { ... }
>>   }
>>
>>   rpc my-second-rpc {
>> description
>>   "Bla bla...
>>If an error occurs,  will contain an instance of
>>the yang-data structure 'my-second-rpc-error-info'.";
>> ...
>>   }
>>
>>   yang-data my-second-rpc-error-info {
>> leaf reason { ... }
>> leaf important-url { ... }
>>   }
>>
>> (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 see no reason to reinvent the grouping-stmt.
You could easily say opx:error-info-structure argument is a grouping name
as it is a yang-data name.



>
>> In the example above, note that the leaf "reason" is present in both
>> structures.  IMO this is not a problem, since these structures are
>> used in different contexts.
>>
>> My point is that I think we should impose as few restrictions as
>> possible to the yang-data extension.  It should be up to the user of
>> yang-data to ensure that the structure is defined in such a way so
>> that it can be used properly.  For example, a structure that is
>> supposed to describe an XML instance document cannot define two leafs
>> at the top level.
>>
>> If the WG agrees with what I wrote above, we need to change the
>> augment-yang-data extension so that you would write for example:
>>

Re: [netmod] yang-data-ext issues

[Robert Wilton]

Don't groupings have a somewhat similar concern?

 E.g. if two groupings define the same data node name and are used at 
the same point then you would get a namespace clash, but YANG does not 
disallow the groupings:


 grouping foo_widget {
   leaf name {
 type string;
 description "Name of my foo widget";
   }
 }

 grouping bar_widget {
   leaf name {
 type string;
 description "Name of my bar widget";
   }
 }

 container all_widgets {
   uses foo_widget;
   uses bar_widget;
 }


The principal difference here, is that the compiler can easily check and 
reject the conflict at the uses statements.


Hence I think that it would be good if we could find a solution for 
yang-data-ext that doesn't not require all root yang-data nodes to be 
unique, since that feels somewhat clunky.  I.e. my preference is to keep 
them less restrictive, as Martin has proposed, if this is feasible.


Thanks,
Rob


On 16/04/2018 15:36, Andy Bierman wrote:

Hi,

I am strongly opposed to this change because it breaks the rule in 
YANG 1.1

that there cannot be 2 sibling nodes defined in the same module namespace.

IMO since any yang-data nodes are ALLOWED to be used at the top-level,
then these top-level nodes cannot have conflicting names.

It is very important when parsing an instance document that the 
instance data

can be associated with the correct schema.  This is not possible if the
same top-level node has multiple yang-data nodes defined.

If one needs to define data that is not top-level, (1) use 
augment-yang-data

or (2) use a different module.


Andy



On Mon, Apr 16, 2018 at 5:56 AM, Martin Bjorklund > wrote:


Hi,

While preparing draft-ietf-netmod-yang-data-ext-02, it turned out that
it is not clear what, if any, restrictions should be enforced for
yang-data structures.  Even among the authors we have different ideas
for how this should work.

Background:

In 8040, the original yang-data extension had a restriction that said
that a yang-data structure MUST have exactly one container, since it
wouldn't be possible to have a yang-data structure in an XML instance
document otherwise.

Since people want to use yang-data structures in other places, this
restriction was lifted in the new draft:

   There is no longer an assumption that a yang data structure can
   only be used as a top-level abstraction, instead of nested within
   some other data structure.


With this in mind, here's a use case that I think we ought to support:

  rpc my-first-rpc {
    description
      "Bla bla...
       If an error occurs,  will contain an instance of
       the yang-data structure 'my-first-rpc-error-info'.";
    ...
  }

  yang-data my-first-rpc-error-info {
    leaf reason { ... }
    container user-info { ... }
  }

  rpc my-second-rpc {
    description
      "Bla bla...
       If an error occurs,  will contain an instance of
       the yang-data structure 'my-second-rpc-error-info'.";
    ...
  }

  yang-data my-second-rpc-error-info {
    leaf reason { ... }
    leaf important-url { ... }
  }

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

In the example above, note that the leaf "reason" is present in both
structures.  IMO this is not a problem, since these structures are
used in different contexts.

My point is that I think we should impose as few restrictions as
possible to the yang-data extension.  It should be up to the user of
yang-data to ensure that the structure is defined in such a way so
that it can be used properly.  For example, a structure that is
supposed to describe an XML instance document cannot define two leafs
at the top level.

If the WG agrees with what I wrote above, we need to change the
augment-yang-data extension so that you would write for example:

  yx:augment-yang-data /ex:my-first-rpc-error-info/ex:user-info {
    ...
  }

Comments?



/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


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

Re: [netmod] yang-data-ext issues

[Martin Bjorklund]

Hi,

Andy Bierman  wrote:
> On Mon, Apr 16, 2018 at 6:33 AM, Joe Clarke  wrote:
> 
> > On 4/16/18 08:56, Martin Bjorklund wrote:
> > > Hi,
> > >
> > > While preparing draft-ietf-netmod-yang-data-ext-02, it turned out that
> > > it is not clear what, if any, restrictions should be enforced for
> > > yang-data structures.  Even among the authors we have different ideas
> > > for how this should work.
> > >
> > > Background:
> > >
> > > In 8040, the original yang-data extension had a restriction that said
> > > that a yang-data structure MUST have exactly one container, since it
> > > wouldn't be possible to have a yang-data structure in an XML instance
> > > document otherwise.
> > >
> > > Since people want to use yang-data structures in other places, this
> > > restriction was lifted in the new draft:
> > >
> > >There is no longer an assumption that a yang data structure can
> > >only be used as a top-level abstraction, instead of nested within
> > >some other data structure.
> > >
> > >
> > > With this in mind, here's a use case that I think we ought to support:
> > >
> > >   rpc my-first-rpc {
> > > description
> > >   "Bla bla...
> > >If an error occurs,  will contain an instance of
> > >the yang-data structure 'my-first-rpc-error-info'.";
> > > ...
> > >   }
> > >
> > >   yang-data my-first-rpc-error-info {
> > > leaf reason { ... }
> > > container user-info { ... }
> > >   }
> > >
> > >   rpc my-second-rpc {
> > > description
> > >   "Bla bla...
> > >If an error occurs,  will contain an instance of
> > >the yang-data structure 'my-second-rpc-error-info'.";
> > > ...
> > >   }
> > >
> > >   yang-data my-second-rpc-error-info {
> > > leaf reason { ... }
> > > leaf important-url { ... }
> > >   }
> > >
> > > (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.)
> > >
> > > In the example above, note that the leaf "reason" is present in both
> > > structures.  IMO this is not a problem, since these structures are
> > > used in different contexts.
> > >
> > > My point is that I think we should impose as few restrictions as
> > > possible to the yang-data extension.  It should be up to the user of
> > > yang-data to ensure that the structure is defined in such a way so
> > > that it can be used properly.  For example, a structure that is
> > > supposed to describe an XML instance document cannot define two leafs
> > > at the top level.
> > >
> > > If the WG agrees with what I wrote above, we need to change the
> > > augment-yang-data extension so that you would write for example:
> > >
> > >   yx:augment-yang-data /ex:my-first-rpc-error-info/ex:user-info {
> > > ...
> > >   }
> > >
> > > Comments?
> >
> > I found the "single container only" policy to be too restricting.  I was
> > modeling data that would [typically] be serialized to something other
> > than XML, and this just made me jump through more hoops than I wanted to
> > use rc:yang-data.
> >
> > I agree with your laissez-faire proposal here.  I think there should be
> > some text to the same effect about how it is up to the author of the
> > yd:yang-data elements to make sure the modeled data can be encoded as
> > they require.
> >
> >
> 
> How will your tool handle this?
> 
> 
> module foo {
>x:yang-data fake-namespace1 {
>   container top { ... }
>}
> 
>x:yang-data fake-namespace2 {
>   container top { ... }
>}
> 
>container top { ... }
> 
> }
> 
> 
> You parse an artifact file:
> 
> 
> ... 
> 

If the yang-data structures are supposed be used in instance documents
w/ no additional context information, then the designer should not use
two nodes with the same name in different strcuctures, just like he
wouldn't use two top-level containers.

But as my original email demonstrated, there are cases where the
context provides the information which structure to use.n

> Current YANG says that the  node can only be defined once.
> This makes it possible for a parser to pick the correct schema.
> If 2 or or more yang-data definitions have this name (foo:top)
> then how does your tool pick the right one.?
> 
> This existing restriction in YANG serves a useful purpose.
> Removing it would be unwise.
> 
> There is no restriction to limit the yang-data to a container.
> This has already been removed.
> 
> 
> My counter-proposal is to remove the argument for yang-data
> since it servers no purpose:
> 
> 
>   x:yang-data  {
>  container top { ... }
>   }
> 
>   x:yang-data {
>   list bar { ... }
>}

I think this would be a mistake.  It wouldn't even be possible to talk
about the different structures in a module.  For example, the
subscribed notification draft has this:


   These are 

Re: [netmod] yang-data-ext issues

[Andy Bierman]

On Mon, Apr 16, 2018 at 6:33 AM, Joe Clarke  wrote:

> On 4/16/18 08:56, Martin Bjorklund wrote:
> > Hi,
> >
> > While preparing draft-ietf-netmod-yang-data-ext-02, it turned out that
> > it is not clear what, if any, restrictions should be enforced for
> > yang-data structures.  Even among the authors we have different ideas
> > for how this should work.
> >
> > Background:
> >
> > In 8040, the original yang-data extension had a restriction that said
> > that a yang-data structure MUST have exactly one container, since it
> > wouldn't be possible to have a yang-data structure in an XML instance
> > document otherwise.
> >
> > Since people want to use yang-data structures in other places, this
> > restriction was lifted in the new draft:
> >
> >There is no longer an assumption that a yang data structure can
> >only be used as a top-level abstraction, instead of nested within
> >some other data structure.
> >
> >
> > With this in mind, here's a use case that I think we ought to support:
> >
> >   rpc my-first-rpc {
> > description
> >   "Bla bla...
> >If an error occurs,  will contain an instance of
> >the yang-data structure 'my-first-rpc-error-info'.";
> > ...
> >   }
> >
> >   yang-data my-first-rpc-error-info {
> > leaf reason { ... }
> > container user-info { ... }
> >   }
> >
> >   rpc my-second-rpc {
> > description
> >   "Bla bla...
> >If an error occurs,  will contain an instance of
> >the yang-data structure 'my-second-rpc-error-info'.";
> > ...
> >   }
> >
> >   yang-data my-second-rpc-error-info {
> > leaf reason { ... }
> > leaf important-url { ... }
> >   }
> >
> > (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.)
> >
> > In the example above, note that the leaf "reason" is present in both
> > structures.  IMO this is not a problem, since these structures are
> > used in different contexts.
> >
> > My point is that I think we should impose as few restrictions as
> > possible to the yang-data extension.  It should be up to the user of
> > yang-data to ensure that the structure is defined in such a way so
> > that it can be used properly.  For example, a structure that is
> > supposed to describe an XML instance document cannot define two leafs
> > at the top level.
> >
> > If the WG agrees with what I wrote above, we need to change the
> > augment-yang-data extension so that you would write for example:
> >
> >   yx:augment-yang-data /ex:my-first-rpc-error-info/ex:user-info {
> > ...
> >   }
> >
> > Comments?
>
> I found the "single container only" policy to be too restricting.  I was
> modeling data that would [typically] be serialized to something other
> than XML, and this just made me jump through more hoops than I wanted to
> use rc:yang-data.
>
> I agree with your laissez-faire proposal here.  I think there should be
> some text to the same effect about how it is up to the author of the
> yd:yang-data elements to make sure the modeled data can be encoded as
> they require.
>
>

How will your tool handle this?


module foo {
   x:yang-data fake-namespace1 {
  container top { ... }
   }

   x:yang-data fake-namespace2 {
  container top { ... }
   }

   container top { ... }

}


You parse an artifact file:


... 


Current YANG says that the  node can only be defined once.
This makes it possible for a parser to pick the correct schema.
If 2 or or more yang-data definitions have this name (foo:top)
then how does your tool pick the right one.?

This existing restriction in YANG serves a useful purpose.
Removing it would be unwise.

There is no restriction to limit the yang-data to a container.
This has already been removed.


My counter-proposal is to remove the argument for yang-data
since it servers no purpose:


  x:yang-data  {
 container top { ... }
  }

  x:yang-data {
  list bar { ... }
   }

Joe
>
>

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

Re: [netmod] yang-data-ext issues

[Martin Bjorklund]

Hi,

Andy Bierman  wrote:
> Hi,
> 
> I am strongly opposed to this change because it breaks the rule in YANG 1.1
> that there cannot be 2 sibling nodes defined in the same module namespace.
> 
> IMO since any yang-data nodes are ALLOWED to be used at the top-level,
> then these top-level nodes cannot have conflicting names.

What do you mean with "used at the top-level"?  Do you mean that they
are allowed to be used e.g. in an XML instance document?  If so, we
should not allow more than one container either.

> It is very important when parsing an instance document that the instance
> data
> can be associated with the correct schema.  This is not possible if the
> same top-level node has multiple yang-data nodes defined.

Correct.  And a structure with more than one node is also not possible
to use in an instance document, but we still allow it.

There is no requirement that a yang-data structure MUST be used as a
single instance document.

My point is that it should be up to the designer that define a
yang-data structure to ensure the structure can be used properly.  In
some cases it means that the designer uses a single container, in some
cases it means that two different strcutures have unique nodes, and in
other cases it might mean that all lists have keys.  We should ensure
that all these use cases are supported.


/martin



> If one needs to define data that is not top-level, (1) use augment-yang-data
> or (2) use a different module.
> 
> 
> Andy
> 
> 
> 
> On Mon, Apr 16, 2018 at 5:56 AM, Martin Bjorklund  wrote:
> 
> > Hi,
> >
> > While preparing draft-ietf-netmod-yang-data-ext-02, it turned out that
> > it is not clear what, if any, restrictions should be enforced for
> > yang-data structures.  Even among the authors we have different ideas
> > for how this should work.
> >
> > Background:
> >
> > In 8040, the original yang-data extension had a restriction that said
> > that a yang-data structure MUST have exactly one container, since it
> > wouldn't be possible to have a yang-data structure in an XML instance
> > document otherwise.
> >
> > Since people want to use yang-data structures in other places, this
> > restriction was lifted in the new draft:
> >
> >There is no longer an assumption that a yang data structure can
> >only be used as a top-level abstraction, instead of nested within
> >some other data structure.
> >
> >
> > With this in mind, here's a use case that I think we ought to support:
> >
> >   rpc my-first-rpc {
> > description
> >   "Bla bla...
> >If an error occurs,  will contain an instance of
> >the yang-data structure 'my-first-rpc-error-info'.";
> > ...
> >   }
> >
> >   yang-data my-first-rpc-error-info {
> > leaf reason { ... }
> > container user-info { ... }
> >   }
> >
> >   rpc my-second-rpc {
> > description
> >   "Bla bla...
> >If an error occurs,  will contain an instance of
> >the yang-data structure 'my-second-rpc-error-info'.";
> > ...
> >   }
> >
> >   yang-data my-second-rpc-error-info {
> > leaf reason { ... }
> > leaf important-url { ... }
> >   }
> >
> > (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.)
> >
> > In the example above, note that the leaf "reason" is present in both
> > structures.  IMO this is not a problem, since these structures are
> > used in different contexts.
> >
> > My point is that I think we should impose as few restrictions as
> > possible to the yang-data extension.  It should be up to the user of
> > yang-data to ensure that the structure is defined in such a way so
> > that it can be used properly.  For example, a structure that is
> > supposed to describe an XML instance document cannot define two leafs
> > at the top level.
> >
> > If the WG agrees with what I wrote above, we need to change the
> > augment-yang-data extension so that you would write for example:
> >
> >   yx:augment-yang-data /ex:my-first-rpc-error-info/ex:user-info {
> > ...
> >   }
> >
> > Comments?
> >
> >
> >
> > /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] yang-data-ext issues

[Andy Bierman]

Hi,

I am strongly opposed to this change because it breaks the rule in YANG 1.1
that there cannot be 2 sibling nodes defined in the same module namespace.

IMO since any yang-data nodes are ALLOWED to be used at the top-level,
then these top-level nodes cannot have conflicting names.

It is very important when parsing an instance document that the instance
data
can be associated with the correct schema.  This is not possible if the
same top-level node has multiple yang-data nodes defined.

If one needs to define data that is not top-level, (1) use augment-yang-data
or (2) use a different module.


Andy



On Mon, Apr 16, 2018 at 5:56 AM, Martin Bjorklund  wrote:

> Hi,
>
> While preparing draft-ietf-netmod-yang-data-ext-02, it turned out that
> it is not clear what, if any, restrictions should be enforced for
> yang-data structures.  Even among the authors we have different ideas
> for how this should work.
>
> Background:
>
> In 8040, the original yang-data extension had a restriction that said
> that a yang-data structure MUST have exactly one container, since it
> wouldn't be possible to have a yang-data structure in an XML instance
> document otherwise.
>
> Since people want to use yang-data structures in other places, this
> restriction was lifted in the new draft:
>
>There is no longer an assumption that a yang data structure can
>only be used as a top-level abstraction, instead of nested within
>some other data structure.
>
>
> With this in mind, here's a use case that I think we ought to support:
>
>   rpc my-first-rpc {
> description
>   "Bla bla...
>If an error occurs,  will contain an instance of
>the yang-data structure 'my-first-rpc-error-info'.";
> ...
>   }
>
>   yang-data my-first-rpc-error-info {
> leaf reason { ... }
> container user-info { ... }
>   }
>
>   rpc my-second-rpc {
> description
>   "Bla bla...
>If an error occurs,  will contain an instance of
>the yang-data structure 'my-second-rpc-error-info'.";
> ...
>   }
>
>   yang-data my-second-rpc-error-info {
> leaf reason { ... }
> leaf important-url { ... }
>   }
>
> (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.)
>
> In the example above, note that the leaf "reason" is present in both
> structures.  IMO this is not a problem, since these structures are
> used in different contexts.
>
> My point is that I think we should impose as few restrictions as
> possible to the yang-data extension.  It should be up to the user of
> yang-data to ensure that the structure is defined in such a way so
> that it can be used properly.  For example, a structure that is
> supposed to describe an XML instance document cannot define two leafs
> at the top level.
>
> If the WG agrees with what I wrote above, we need to change the
> augment-yang-data extension so that you would write for example:
>
>   yx:augment-yang-data /ex:my-first-rpc-error-info/ex:user-info {
> ...
>   }
>
> Comments?
>
>
>
> /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] yang-data-ext issues

[Joe Clarke]

On 4/16/18 08:56, Martin Bjorklund wrote:
> Hi,
> 
> While preparing draft-ietf-netmod-yang-data-ext-02, it turned out that
> it is not clear what, if any, restrictions should be enforced for
> yang-data structures.  Even among the authors we have different ideas
> for how this should work.
> 
> Background:
> 
> In 8040, the original yang-data extension had a restriction that said
> that a yang-data structure MUST have exactly one container, since it
> wouldn't be possible to have a yang-data structure in an XML instance
> document otherwise.
> 
> Since people want to use yang-data structures in other places, this
> restriction was lifted in the new draft:
> 
>There is no longer an assumption that a yang data structure can
>only be used as a top-level abstraction, instead of nested within
>some other data structure.
> 
> 
> With this in mind, here's a use case that I think we ought to support:
> 
>   rpc my-first-rpc {
> description
>   "Bla bla...
>If an error occurs,  will contain an instance of
>the yang-data structure 'my-first-rpc-error-info'.";
> ...
>   }
> 
>   yang-data my-first-rpc-error-info {
> leaf reason { ... }
> container user-info { ... }
>   }
> 
>   rpc my-second-rpc {
> description
>   "Bla bla...
>If an error occurs,  will contain an instance of
>the yang-data structure 'my-second-rpc-error-info'.";
> ...
>   }
> 
>   yang-data my-second-rpc-error-info {
> leaf reason { ... }
> leaf important-url { ... }
>   }
> 
> (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.)
> 
> In the example above, note that the leaf "reason" is present in both
> structures.  IMO this is not a problem, since these structures are
> used in different contexts.
> 
> My point is that I think we should impose as few restrictions as
> possible to the yang-data extension.  It should be up to the user of
> yang-data to ensure that the structure is defined in such a way so
> that it can be used properly.  For example, a structure that is
> supposed to describe an XML instance document cannot define two leafs
> at the top level.
> 
> If the WG agrees with what I wrote above, we need to change the
> augment-yang-data extension so that you would write for example:
> 
>   yx:augment-yang-data /ex:my-first-rpc-error-info/ex:user-info {
> ...
>   }
> 
> Comments?

I found the "single container only" policy to be too restricting.  I was
modeling data that would [typically] be serialized to something other
than XML, and this just made me jump through more hoops than I wanted to
use rc:yang-data.

I agree with your laissez-faire proposal here.  I think there should be
some text to the same effect about how it is up to the author of the
yd:yang-data elements to make sure the modeled data can be encoded as
they require.

Joe

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

[netmod] yang-data-ext issues

[Martin Bjorklund]

Hi,

While preparing draft-ietf-netmod-yang-data-ext-02, it turned out that
it is not clear what, if any, restrictions should be enforced for
yang-data structures.  Even among the authors we have different ideas
for how this should work.

Background:

In 8040, the original yang-data extension had a restriction that said
that a yang-data structure MUST have exactly one container, since it
wouldn't be possible to have a yang-data structure in an XML instance
document otherwise.

Since people want to use yang-data structures in other places, this
restriction was lifted in the new draft:

   There is no longer an assumption that a yang data structure can
   only be used as a top-level abstraction, instead of nested within
   some other data structure.


With this in mind, here's a use case that I think we ought to support:

  rpc my-first-rpc {
description
  "Bla bla...
   If an error occurs,  will contain an instance of
   the yang-data structure 'my-first-rpc-error-info'.";
...
  }

  yang-data my-first-rpc-error-info {
leaf reason { ... }
container user-info { ... }
  }

  rpc my-second-rpc {
description
  "Bla bla...
   If an error occurs,  will contain an instance of
   the yang-data structure 'my-second-rpc-error-info'.";
...
  }

  yang-data my-second-rpc-error-info {
leaf reason { ... }
leaf important-url { ... }
  }

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

In the example above, note that the leaf "reason" is present in both
structures.  IMO this is not a problem, since these structures are
used in different contexts.

My point is that I think we should impose as few restrictions as
possible to the yang-data extension.  It should be up to the user of
yang-data to ensure that the structure is defined in such a way so
that it can be used properly.  For example, a structure that is
supposed to describe an XML instance document cannot define two leafs
at the top level.

If the WG agrees with what I wrote above, we need to change the
augment-yang-data extension so that you would write for example:

  yx:augment-yang-data /ex:my-first-rpc-error-info/ex:user-info {
...
  }

Comments?



/martin

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