[netmod] anydata interaction with yang-patch and edit config (RE: 6020bis - anydata)

[Alexander Clemm (alex)]

Hi,

I have two quick questions with regards to anydata - related to the topic of 
the thread, but concerning a separate topic.  

(1) How does yang-patch interact with anydata?  In particular, could you apply 
a yang-patch edit to a data node within the anydata?  (While the module may not 
have been known at design time, it will be known at run time - so presume yes.)

(2) How about edit-config?  Can you use edit config to apply operations to 
nodes within the anydata, or just to the blob as a whole?  (Again, I would 
assume you can, as the nodes will be known at run time.)  

Thanks
--- Alex

-Original Message-
From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Juergen Schoenwaelder
Sent: Wednesday, September 30, 2015 6:52 AM
To: Ladislav Lhotka 
Cc: Randy Presuhn ; netmod@ietf.org
Subject: Re: [netmod] 6020bis - anydata

On Wed, Sep 30, 2015 at 01:01:36PM +0200, Ladislav Lhotka wrote:
> Hi Randy,
> 
> thanks for the comments and proposed edits. Please see inline.
> 
> Randy Presuhn  writes:
> 
> > Hi -
> >
> >>From: Ladislav Lhotka 
> >>Sent: Sep 29, 2015 7:07 AM
> >>To: netmod@ietf.org
> >>Subject: [netmod] 6020bis - anydata
> >>
> >>Hi,
> >>
> >>I propose to expand the text in Sec. 7.10 as follows:
> >>
> >>OLD
> >>
> >>   The "anydata" statement is used to represent an unknown set of nodes
> >>   that can be modelled with YANG.  An example of where this can be
> >>   useful is a list of received notifications, where the exact
> >>   notifications are not known as design time.
> >>
> >>NEW
> >>
> >>   The "anydata" statement is used to represent an unknown set of nodes
> >>   that can be modelled with YANG but for which the data model doesn't
> >>   exist at module design time.
> >
> > "doesn't exist" would not be appropriate for the example you provide 
> > below.  It would be incorrect if some of the notifications in your 
> > example had already been defined, even though "anydata" would still 
> > be necessary to handle others not yet defined.
> 
> Would "doesn't exist or cannot be determined at module design time" be better?
>

What about this:

  The "anydata" statement is used to represent a set of nodes that can
  be modelled with YANG but for which the data model is not known at
  module design 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

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

Re: [netmod] 6020bis - anydata

[Ladislav Lhotka]

Randy Presuhn  writes:

> Hi -
>
>>From: Ladislav Lhotka 
>>Sent: Oct 1, 2015 12:24 AM
>>To: Juergen Schoenwaelder 
>>Cc: Randy Presuhn , netmod@ietf.org
>>Subject: Re: [netmod] 6020bis - anydata
> ...
>>Fine by me. So here is an updated proposal:
>>
>>OLD
>>
>>   The "anydata" statement is used to represent an unknown set of nodes
>>   that can be modelled with YANG.  An example of where this can be
>>   useful is a list of received notifications, where the exact
>>   notifications are not known as design time.
>>
>>NEW
>>
>>   The "anydata" statement is used to represent an unknown set of nodes
>>   that can be modelled with YANG but for which the data model is not
>>   known at module design time. It is possible, though not required, for
>
> s/know/known/
>
>>   the data model for "anydata" content to become known through protocol
>>   signalling or other means that are outside the scope of this
>>   document, as is the server and client behaviour.
>
> I'd end the sentence at "document." The rest of the sentence doesn't
> really add anything.
>
> There's still a big lump under the carpet, but no one else appears
> concerned about it, so I'll desist from further comment.

I am certainly concerned. The current definition of "anydata" ("an
unknown set of nodes that can be modelled with YANG") is IMO
insufficient because, for one, it doesn't even eliminate mixed content
in XML, which can be modelled with YANG's "anyxml" statement.

In my view, the idea behind "anydata" was that it would be possible to
build a regular data (sub)tree from schema-less data. However, this
seems to be difficult, at least on a server supporting both XML and
JSON, and so benefits of "anydata" over "anyxml" are really
questionable.

Lada

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

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

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

Re: [netmod] anydata interaction with yang-patch and edit config

[Alexander Clemm (alex)]

Thanks, Martin, this is very clear. 

(Too bad actually - I could see applications for this.) 

--- Alex

-Original Message-
From: Martin Bjorklund [mailto:m...@tail-f.com] 
Sent: Monday, October 05, 2015 2:21 PM
To: Alexander Clemm (alex) 
Cc: j.schoenwael...@jacobs-university.de; lho...@nic.cz; 
randy_pres...@mindspring.com; netmod@ietf.org
Subject: Re: [netmod] anydata interaction with yang-patch and edit config

"Alexander Clemm (alex)"  wrote:
> Hi,
> 
> I have two quick questions with regards to anydata - related to the 
> topic of the thread, but concerning a separate topic.
> 
> (1) How does yang-patch interact with anydata?  In particular, could 
> you apply a yang-patch edit to a data node within the anydata?  (While 
> the module may not have been known at design time, it will be known at 
> run time - so presume yes.)
> 
> (2) How about edit-config?  Can you use edit config to apply 
> operations to nodes within the anydata, or just to the blob as a 
> whole?  (Again, I would assume you can, as the nodes will be known at 
> run time.)

The current text says:

  An anydata node is treated as an opaque chunk of data.  This data
  can be modified in its entirety only.


So the answer to both questions are "no".

I don't think that the module necessarily must be known at run-time.


/martin

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

Re: [netmod] opstate-reqs issue #1 - Define/Clarify "fully synchronized" in "Requirement 1.D"

[Kent Watsen]

This issue appears to have become more like issue #5 – should we mark this one 
a duplicate of the other?

As for this, what does it mean?

> >   - templates: the intended data model and applied data model are disjoint
>
> This came up towards the end of the interim, and my understanding is that it
> acceptable for any templating solution to have to adhere to that constraint 
> above.

Specifically, would this imply that the flattening of the template would have 
to now take place at each operational component in the system – as opposed to 
being flattened by a centralized component (e.g., in the control plane).   If 
so, then I think it might add significant costs to the servers, as then *all* 
downstream components would have to know how to flatten templates.

Related to this, how do we handle the case where the downstream component's 
native data model is different.  For instance, imagine a mixed IP/optical 
router that has subtended ROADM and optical amplifiers attached.  So, when the 
control plane sends the config to the ROADM, it first converts it to the 
ROADM's native data model.  For this case, in order to present the applied 
config with the same data model, would the control plane have to perform the 
reverse mapping?


Kent   // as a contributor




From: Andy Bierman >
Date: Saturday, October 3, 2015 at 11:38 AM
To: Robert Wilton >
Cc: Randy Presuhn 
>, 
"netmod@ietf.org" 
>
Subject: Re: [netmod] opstate-reqs issue #1 - Define/Clarify "fully 
synchronized" in "Requirement 1.D"

Hi,

So the applied leaf is being used as a complicated boolean?

IMO your draft (using attributes similar to with-defaults=report-all-tagged,
not containers) is the best compromise because:

   - the data models are not touched
   - no datastores are required
   - the same string is used to identify the data node no matter what
 state needs to be checked
   - client has to request the metadata somehow so no impact
 on clients that do not care about this issue
   - a single boolean attribute applied="true" is all that is really needed



Andy



On Fri, Oct 2, 2015 at 1:16 PM, Robert Wilton 
> wrote:
Hi Andy,

It was clarified by Rob Shakir in the meeting that the applied-cfg leaf is only 
used to indicate whether the configuration represented by the intended-cfg leaf 
has been applied.

But it appears that my proposed text for 1D may have caused some confusion.  
Please see inline ...

On 02/10/2015 19:11, Andy Bierman wrote:
Hi,

What about the data models that do not follow 1D?

  - templates: the intended data model and applied data model are disjoint

This came up towards the end of the interim, and my understanding is that it 
acceptable for any templating solution to have to adhere to that constraint 
above.


  - 'auto-duplex' corner-case: the intended and applied leaf are the same, but 
they
will never have the same value
The intention is:
  - intended-cfg duplex leaf = "auto" (i.e. operator wants duplex to be 
determined by auto-negotiation)
  - applied-cfg duplex leaf = "auto" (i.e. device will determine duplex by 
auto-negotiation)
  - related derived-state duplex-state leaf = "full" or "half" or "unknown" 
(always represents the actual duplex setting of the interface)

  - 'use-dhcp' corner-case: intended config just enables specific derived state
 to be used; disjoint data models
Similarly:
  - intended-cfg use-dhcp leaf = "true" (i.e. operator wants DHCP assigned IP 
addresses)
  - applied-cfg use-dhcp leaf = "true" (i.e. system is using DHCP to assign IP 
addresses)
  - related derived-state IP address leaf = A.B.C.D (Primary IP address in use 
for the interface - if any).



Somebody asked an important question at the interim:
Is the intent of this group to limit all YANG data models such that
they conform to 1D? (IMO that is a non-starter)
It is not my intention that my proposed 1D text makes are constraint on the 
structure of YANG data models.


IMO requirement 1D presume that the solution involves separate
objects in the YANG data model for intended and applied states,
and therefore it is an invalid requirement.

That is not the intention of my phrasing, perhaps it needs further refinement?

The intention is that a config node has two notional states in the data store, 
intended and applied.  The aim is to tightly relate those two notional states 
as to when they are allowed to be the same or different.


Only the 2 protocol-based solutions address this issue by using
the same object identifier no matter which state is being queried.
I don't think that this requirement excludes any of the three solutions that 
have been proposed (or the use of attribute to return intended vs applied state 
metadata).

Thanks,
Rob

Re: [netmod] 6020bis - anydata

[Ladislav Lhotka]

> On 05 Oct 2015, at 11:57, Juergen Schoenwaelder 
>  wrote:
> 
> On Mon, Oct 05, 2015 at 11:48:10AM +0200, Ladislav Lhotka wrote:
> 
>> I am certainly concerned. The current definition of "anydata" ("an
>> unknown set of nodes that can be modelled with YANG") is IMO
>> insufficient because, for one, it doesn't even eliminate mixed content
>> in XML, which can be modelled with YANG's "anyxml" statement.
> 
> Good point. I think we should clarify that anyxml is excluded.

Then YANG extensions probably need to be excluded, too.

> 
>> In my view, the idea behind "anydata" was that it would be possible to
>> build a regular data (sub)tree from schema-less data. However, this
>> seems to be difficult, at least on a server supporting both XML and
>> JSON, and so benefits of "anydata" over "anyxml" are really
>> questionable.
> 
> I do not think anydata was driven by the idea to build a regular data
> (sub)tree from schema-less data.
> 
> I think anydata works fine with both JSON and XML as long as the
> encoder has the data model, which seems to be a reasonable assumption

If it is so,  then what we really need is a standard mechanism that allows for 
signalling the data model at run time. Without that, as Randy pointed out, 
there is no way to make sure that the server and client use the same data model 
for a particular “anydata” node, and then the difference between “anydata” and 
“anyxml” is no more interesting. All external means (or descriptions) that may 
potentially provide “late binding” of the data model are applicable to “anyxml” 
as well.

Lada

> for servers and perhaps also for data-model driven clients. The
> problem are any generic components in between clients and servers but
> that can also be seen as a problem of the encodings and not of
> anydata itself.
> 
> /js
> 
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




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

Re: [netmod] 6020bis - anydata

[Ladislav Lhotka]

> On 05 Oct 2015, at 13:44, Juergen Schoenwaelder 
>  wrote:
> 
> On Mon, Oct 05, 2015 at 01:32:46PM +0200, Ladislav Lhotka wrote:
>> 
>>> On 05 Oct 2015, at 11:57, Juergen Schoenwaelder 
>>>  wrote:
>>> 
>>> On Mon, Oct 05, 2015 at 11:48:10AM +0200, Ladislav Lhotka wrote:
>>> 
 I am certainly concerned. The current definition of "anydata" ("an
 unknown set of nodes that can be modelled with YANG") is IMO
 insufficient because, for one, it doesn't even eliminate mixed content
 in XML, which can be modelled with YANG's "anyxml" statement.
>>> 
>>> Good point. I think we should clarify that anyxml is excluded.
>> 
>> Then YANG extensions probably need to be excluded, too.
>> 
>>> 
 In my view, the idea behind "anydata" was that it would be possible to
 build a regular data (sub)tree from schema-less data. However, this
 seems to be difficult, at least on a server supporting both XML and
 JSON, and so benefits of "anydata" over "anyxml" are really
 questionable.
>>> 
>>> I do not think anydata was driven by the idea to build a regular data
>>> (sub)tree from schema-less data.
>>> 
>>> I think anydata works fine with both JSON and XML as long as the
>>> encoder has the data model, which seems to be a reasonable assumption
>> 
>> If it is so,  then what we really need is a standard mechanism that allows 
>> for signalling the data model at run time. Without that, as Randy pointed 
>> out, there is no way to make sure that the server and client use the same 
>> data model for a particular “anydata” node, and then the difference between 
>> “anydata” and “anyxml” is no more interesting. All external means (or 
>> descriptions) that may potentially provide “late binding” of the data model 
>> are applicable to “anyxml” as well.
>> 
> 
> XML uses namespace URIs to identify the data model, JSON uses module

Sorry, this is not true: A data model is identified by a set of YANG modules 
with their exact revisions + features (+ deviations). A URI or module name by 
itself doesn’t help if you don’t have the rest.

> names to identify the data model. The only discussion point here is
> the level of uniqueness (and of course why we use two different data
> model identifiers - but it seems nobody except me or perhaps Randy
> cares).
> 
> And no, anyxml was defined to be 'any XML' and anydata has been
> defined to be 'any data modeled in YANG' (without anyxml). This really
> has been settled, please read the archives if you are still unsure
> what the difference is.

But the exclusion of anyxml wasn’t part of that discussion, was it? And since 
you didn’t answer my comment about extensions, let me put it differently: Are 
XML attributes allowed in XML-encoded anydata contents?

Randy talks about “a big lump under the carpet”, so maybe I am not alone in 
thinking that the concept of anydata needs to be clarified or reconsidered - 
and WGLC is the last chance to do it.

I tried to formulate a clarification but it turned out to be unacceptable, and 
its relaxed form useless, as you rightly pointed out. So can somebody propose a 
better definition of anydata?  

Lada 

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

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




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

[netmod] Choice corner Cases -1

[Balazs Lengyel]

Hello,
What do the mandatory statements mean in the following model ?

   choice scen8 {  // Embedded choices with multiple mandatory 
cases; invalid scenario

   case A {
   choice subChoiceA {
   mandatory true;
   case A {
   leaf scen8-num1 { type uint8; }
   }
   case B {
   leaf scen8-num2 { type uint8; }
   }
   }
   }
   case B {
   choice subChoiceB {
   mandatory true;
   case A {
   leaf scen8-num1 { type uint8; }
   }
   case B {
   leaf scen8-num2 { type uint8; }
   }
   }
   }
   }

Answers:
A1) They mean nothing because the case around subChoiceA/B might not 
exist, in which case its underlying statements are not valid.
A2) They mean that one case from both subChoiceA AND subchoiceB must 
exist leading to two cases in choice scen8 which is not allowed, hence 
this is an invalid model?


Generally I find choices embedded in choices to be so complicated that 
IMHO they SHOULD be immediately prohibited. If you think about all the 
variants of embedded choices with mandatory and default placed on some 
or a bunch of them, even understanding what they mean becomes a 
headache. BAD  In the beginning YANG was about easy-understanding. 
However these combinations are unclear even after repeatedly reading the 
RFC :-(
 As the very least we SHOULD prohibit mandatory/default on the inside 
choice.


regards Balazs

--
Balazs Lengyel   Ericsson Hungary Ltd.
Senior Specialist
ECN: 831 7320
Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com

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