Re: [netmod] IPR call on draft-ietf-netmod-acl-model-18

[Lisa Huang]

Hi Kent,

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

Regards,
Lisa


On Tue, May 1, 2018 at 1:03 PM, Kent Watsen  wrote:

> Thank you, Mahesh and Sonal.
>
> I'm still waiting to hear from Lisa and Dana.  Neither have been heard
> from since the pen moved a couple years ago.  Is anyone aware of Lisa or
> Dana's current email?
>
> Let's give it a few days but, if we don't hear back from them shortly, I
> recommend moving their names from authors to contributors so we can unblock
> the publishing process.
>
> Thanks,
> Kent // shepherd
>
>
> = original message =
>
> Authors, Contributors, WG,
>
> As part of Shepherd write-up for the acl-model draft, we need to ensure
> that all IPR has been declared.  There was an IPR-call before, when there
> was a different set of authors involved, but not since, so it seems prudent
> to do another call now.
>
> Are you aware of any IPR that applies to draft identified above?
>
>
> Please state either:
> "No, I'm not aware of any IPR that applies to this draft"
>   or
> "Yes, I'm aware of IPR that applies to this draft"
>
>
> If yes, has this IPR been disclosed in compliance with IETF IPR rules
> (see RFCs 3979, 4879, 3669 and 5378 for more details)? Please state
> either:
> "Yes, the IPR has been disclosed in compliance with IETF IPR rules"
>   or
> "No, the IPR has not been disclosed"
>
> If no, please provide any additional details you think appropriate.
>
>
> If you are listed as a document author or contributor, please answer the
> above by responding to this email regardless of whether or not you are
> aware of any relevant IPR. This document will not advance to the next
> stage until a response has been received from each author and listed
> contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S
> TO LINES.
>
>
> If you are on the WG email list or attend WG meetings but are not listed
> as an author or contributor, we remind you of your obligations under the
> IETF IPR rules which encourages you to notify the IETF if you are aware
> of IPR of others on an IETF contribution, or to refrain from participating
> in any contribution or discussion related to your undisclosed IPR. For
> more information, please see the RFCs listed above and
> https://urldefense.proofpoint.com/v2/url?u=http-3A__trac.
> tools.ietf.org_group_iesg_trac_wiki_IntellectualProperty=DwICAg&
> c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=
> 9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=yj0hQ9S_
> xraeKbiSv7McZY1diBVVR4EU78hnklrI24I=xX-ih-MpZ1qkXhYls1UQDAK7WuTJnOc29n7Z
> p4nk_Gc=.
>
> Thank you,
>
> Kent // document shepherd and co-chair
>
>
> PS: Please include all listed in the headers of this message in your
> response.
>
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.
> ietf.org_mailman_listinfo_netmod=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=yj0hQ9S_
> xraeKbiSv7McZY1diBVVR4EU78hnklrI24I=m-pbImTlMIVO07ILC0SphA-b3D-
> 3urMSOPR3YSWwQXk=
>
>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Abusing YANG extensions

[Andy Bierman]

Hi,

The discussion about yang-data is stuck because the NETMOD WG does not
understand or does not agree on what it means to abuse a YANG extension
and use it improperly.

If a tool implementing a standard cannot do so without implementing
certain extensions, then those extensions are not optional,
but rather they are mandatory, and therefore violating YANG 1.1.

The NACM extensions are OK because they can be safely ignored
unless the implementation supports NACM, These extensions
are only implemented by the server, so the client is not impacted.

The  element is a use-case where YANG fails completely.
According to YANG, the  element should only contain child nodes
if they are defined directly or defined with the augment-stmt.
YANG says absolutely nothing about nested data nodes that contain
top-level data nodes.

The "mount-point" extension in YANG Schema Mount also violates
YANG 1.1 in this way. A plain client that does not support schema-mount
will find container and list elements that contain undefined child nodes.
If the server chooses to support schema-mount, the client
is forced to support it, and this is a violation of YANG 1.1.

However, the yang-data extension cannot possibly interfere with standard
YANG 1.1 statements because it is used to specify data structures
that are outside the plain data nodes, instead of over-riding the
definitions of the plain data nodes.


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

[netmod] NETCONF server handling of 'when' statements

[Sterne, Jason (Nokia - CA/Ottawa)]

Hi all,

I've seen some older threads about 'when' handling and they ended up creating a 
lot of debate about behavior & intentions (and about how well the text is 
written in the specs).

I'm hoping that the community out there is in agreement on yes vs no for the 
questions below.

Given the following module:

module test {
   namespace "http://test.com;;
   prefix "test";

   container foo {
 leaf foo-type {
   type enumeration {
 enum "green";
 enum "red";
   }
 }
 leaf green-value {
   when "../foo-type = 'green'";
   type uint32;
 }
 leaf red-value {
   when "../foo-type = 'red'";
   type uint32;
 }
   }
}


(A) Assume the candidate is empty initially.  Does the following edit-config to 
the candidate return "OK" ?  (only showing the content of the  
section):

http://dummy.com>
  23
  red


Does the candidate contain the following after the edit-config ?
 foo-type = red
 red-value = 23

Is the result the same if the red-value and foo-type leafs were reversed in the 
XML above ?

(B) Assume the candidate is empty initially.  Does the following edit-config to 
the candidate return an error ?

http://dummy.com>
  23
  green


Does it also return an error if the red-value and foo-type leafs were reversed 
in the XML above ?

(C) Does the presence of 'when' in a YANG model ever create the need for a 
NETCONF client to specifically order nodes within a single edit-config to 
achieve some desired behavior ?

Or do 'when' statements purely put the onus on the server to build a dependency 
tree with the scope of a single edit-config (to ensure that the input leafs to 
a 'when' statement are processed before the when statement itself is evaluated, 
i.e. evaluate the when statements at the end) ?

Rgds,
Jason








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

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

[Juergen Schoenwaelder]

On Wed, May 02, 2018 at 11:28:42AM +, Rohit R Ranade wrote:
> Hi Juergen,
> 
> Some thoughts in-lined.
> 
> With Regards,
> Rohit R Ranade
> 
> -Original Message-
> From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de] 
> Sent: 25 April 2018 16:12
> To: Rohit R Ranade 
> Cc: netc...@ietf.org; netmod@ietf.org
> Subject: Re: [Netconf] [netconf] Comments on 
> draft-ietf-netconf-nmda-netconf-05
> 
> On Wed, Apr 25, 2018 at 04:22:24AM +, Rohit R Ranade wrote:
> > Hi All,
> > 
> > I plan to implement this draft and hence had some implementation related 
> > clarifications.
> > 
> > 
> > 1.   I feel that there should be more text added about "origin" 
> > filtering mechanism. I am not clear about some aspects of origin filtering.
> > 
> > RFC 8342 : NMDA RFC provides the below example
> > 
> >  >  or:origin="or:intended">
> >
> >  lo0
> >  loopback
> >  127.0.0.1
> >  ::1
> >
> >  
> > If user provides  as "system" ONLY, then he will NOT get 
> > this record in output. Because the keys have originated from "intended" . 
> > Right ?
> > So, If user wants to get the system originated data, he MUST give all the 
> > origins in the  where the keys of the system data have 
> > originated from. Can you please confirm whether this is OK.
> 
> I would expect that or:system would select the 
> ip-address tagged with or:origin="or:system" and that the system would return 
> any necessary container or list elements and the necessary key elements 
> (since otherwise the value returned is just useless). So the result would be:
> 
>  or:origin="or:intended">
> 
>   lo0
>   127.0.0.1
> 
>   
> 
> [Rohit R Ranade] While this looks OK for the origin filter, for the 
> negated-origin-filter, for the same example given above, if 
>  or:intended is given, then it 
> will give the "system" related nodes even if it encountered the "intended" 
> node first, which the user definitely dint want included in the output ? Can 
> you please confirm whether this is OK.

I think the leafs matter. Origin values on container and list nodes
are used for compactness. I think I wrote this already.

>Can you please clarify whether the negated filter has higher priority than 
> the selected filter ?

There are no priorities.

> > Another example given in RFC 8342 is as below:
> >   >  or:origin="or:intended">
> >
> >  lo0
> >  127.0.0.1
> >  ::1
> >
> >  
> > 
> > ?  Here keys are originated from "system", but it is under container of 
> > "intended". So if user gives "system" for "origin-filter", the output will 
> > still NOT have this instance output ?
> 
> We allow origin values on containers or lists in order to inherit them, i.e., 
> to achieve a more compact encoding. Anyway, if a leaf node matches, then I 
> think any encompassing containers and list should be included in the result 
> so that the matching leaf can be reported. So you would return
> 
>  or:origin="or:intended">
> 
>   lo0
>   127.0.0.1
>   ::1
> 
>   
> 
> instead of not returning anything at all.
> 
> > ?  Also the container is not defined as "presence" in C.3.  Interface 
> > Example, but still it has origin whether that is Ok ?
> 
> Why not?
> [Rohit R Ranade] RFC 8342 Section 5.3.4
> " The origin applies to all configuration nodes except non-presence 
> containers.  "
>

There are origin attributes that apply to the data node where the
attribute is present and there are origin attributes that exist in
order to inherit them to other data nodes. A node that is not carrying
a configuration value and is not a presence container may have an
origin attribute for inheritance purposes.

/js

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

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

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

[Rohit R Ranade]

Hi Juergen,

Some thoughts in-lined.

With Regards,
Rohit R Ranade

-Original Message-
From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de] 
Sent: 25 April 2018 16:12
To: Rohit R Ranade 
Cc: netc...@ietf.org; netmod@ietf.org
Subject: Re: [Netconf] [netconf] Comments on draft-ietf-netconf-nmda-netconf-05

On Wed, Apr 25, 2018 at 04:22:24AM +, Rohit R Ranade wrote:
> Hi All,
> 
> I plan to implement this draft and hence had some implementation related 
> clarifications.
> 
> 
> 1.   I feel that there should be more text added about "origin" filtering 
> mechanism. I am not clear about some aspects of origin filtering.
> 
> RFC 8342 : NMDA RFC provides the below example
> 
>   or:origin="or:intended">
>
>  lo0
>  loopback
>  127.0.0.1
>  ::1
>
>  
> If user provides  as "system" ONLY, then he will NOT get this 
> record in output. Because the keys have originated from "intended" . Right ?
> So, If user wants to get the system originated data, he MUST give all the 
> origins in the  where the keys of the system data have 
> originated from. Can you please confirm whether this is OK.

I would expect that or:system would select the 
ip-address tagged with or:origin="or:system" and that the system would return 
any necessary container or list elements and the necessary key elements (since 
otherwise the value returned is just useless). So the result would be:

  

  lo0
  127.0.0.1

  

[Rohit R Ranade] While this looks OK for the origin filter, for the 
negated-origin-filter, for the same example given above, if 
 or:intended is given, then it 
will give the "system" related nodes even if it encountered the "intended" node 
first, which the user definitely dint want included in the output ? Can you 
please confirm whether this is OK.
   Can you please clarify whether the negated filter has higher priority than 
the selected filter ?

> Another example given in RFC 8342 is as below:
>or:origin="or:intended">
>
>  lo0
>  127.0.0.1
>  ::1
>
>  
> 
> ?  Here keys are originated from "system", but it is under container of 
> "intended". So if user gives "system" for "origin-filter", the output will 
> still NOT have this instance output ?

We allow origin values on containers or lists in order to inherit them, i.e., 
to achieve a more compact encoding. Anyway, if a leaf node matches, then I 
think any encompassing containers and list should be included in the result so 
that the matching leaf can be reported. So you would return

  

  lo0
  127.0.0.1
  ::1

  

instead of not returning anything at all.

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

Why not?
[Rohit R Ranade] RFC 8342 Section 5.3.4
" The origin applies to all configuration nodes except non-presence containers. 
 "



/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

[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