Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied)

[Kent Watsen]

Rob,

Can you take all the comments from this thread to update the proposed 
definitions for "synchronous server" and "asynchronous server" terms?

Thanks,
Kent

From: Robert Wilton mailto:rwil...@cisco.com>>
Date: Thursday, October 1, 2015 at 5:50 AM
To: Mahesh Jethanandani 
mailto:mjethanand...@gmail.com>>
Cc: Kent Watsen mailto:kwat...@juniper.net>>, 
"netmod@ietf.org" 
mailto:netmod@ietf.org>>
Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs 
asynchronous (esp. wrt intended and applied)



On 01/10/2015 00:55, Mahesh Jethanandani wrote:
One comment.

On Sep 30, 2015, at 8:02 AM, Robert Wilton 
mailto:rwil...@cisco.com>> wrote:

Hi Kent,

Just some quick comments inline ...

On 30/09/2015 15:31, Kent Watsen wrote:
[As a contributor]


I find that the term "system" is a bit ambiguous in this context.  It is 
talking about the NMS, the server, or both together?

[KENT] I believe that we're talking about the NETCONF/RESTCONF/ server, 
specifically in how it processes update requests.


Anyway, I've tried to define them relative to the configuration operations 
being performed.

[KENT] Perhaps these could be collapsed if we use the terms "a/synchronous 
server" ?

Personally, I think that defining the operations is arguably more useful 
because it is feasible that you could have a server that supports both sync and 
async operations and allows the client to choose which semantics should be used 
for a particular request.




Synchronous configuration operation - A configuration request that the server 
applies synchronously with respect to the client request.  Before the server 
replies back to the client indicating the success or failure of the operation 
it MUST semantically validate the contents of the request and update the 
intended configuration of the target datastore.  If the request is to the 
running datastore then the configuration change MUST also be applied in the 
system before the server replies back to the client.  The reply to the client 
indicates whether there are any semantic errors or system errors from applying 
the configuration change.


[KENT]  This generally matches my understanding, but here are some thoughts to 
improve it:

1. I think the language "semantically validate" would exclude an ephemeral 
datastore.  We could put a qualifier on it, but I think it can be removed 
entirely as each datastore already has its own semantics around how it 
processes update requests.

My aim here is potentially tied to the definition of intended config, were I am 
suggesting that the system has to at least have been checked that the request 
is well formed and any YANG constraints in the data model have been met, before 
it is accepted as intended config, otherwise it would be rejected.



2. I like how you call out the running datastore, but it is somewhat 
NETCONF-specific.  How about something like "If the request impacts the 
intended configuration (see term), then..."

Yes your text is better and I agree that we should avoid making the description 
NETCONF specific at all.


3. "applied in the system" seems too open ended, how about this:  "...MUST also 
be propagated to and processed by the operational components of the server 
before..." ???

So my aim here was to tie it back to the definition of "applied configuration", 
but this could probably be expressed in a more direct way, e.g. perhaps " 
MUST update the applied configuration in the system before the server replies …"

If I understand this correctly, we are still talking about “applied 
configuration” as configuration that has been written to 
datastore/hardware/line card etc. It does not imply that anything has come out 
of it, including whether the configuration is usable. That operating 
configuration (and I just introduced another term) will be reflected by derived 
state.

Is that true?
Yes.

Rather than operating configuration I would perhaps say the "observable system 
behaviour is reflected by derived state".

E.g. if you were to change the MTU of an interface to a different value (that 
was say incompatible with a peer device) then the "applied configuration" for 
the MTU leaf would only tell you whether or not that MTU was actively being 
used by the system.   It wouldn't tell you that an ISIS session on that 
interface had gone down due to the MTU incompatibility.  That could only be 
observed by the changing of the derived state representing the status of the 
ISIS session (or an alarm).

Thanks,
Rob

___
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 mailto:a...@yumaworks.com>>
Date: Saturday, October 3, 2015 at 11:38 AM
To: Robert Wilton mailto:rwil...@cisco.com>>
Cc: Randy Presuhn 
mailto:randy_pres...@mindspring.com>>, 
"netmod@ietf.org" 
mailto: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 
mailto:rwil...@cisco.com>> 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





Andy

On Fri, Oct 2, 2015 at 10:44 AM, Sterne, Jason (Jason) 
<jason.

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

[Martin Bjorklund]

"Alexander Clemm (alex)"  wrote:
> Thanks, Martin, this is very clear. 
> 
> (Too bad actually - I could see applications for this.) 

As you noted, this would require the server to know the data models.
Do you have some use case in mind where this would be useful?


/martin


> 
> --- 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] 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] anydata interaction with yang-patch and edit config

[Martin Bjorklund]

"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

[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

[netmod] Interim Meetings info.

[Andrew McLachlan (amclachl)]

Dear All

A quick update on the format for NETMOD interim meetings, including the 
frequency and meeting management.

Cheers

Andrew, Benoit, Kent and Tom


Frequency of meetings

Fortnightly / bi-weekly on Thursday's at 7am PST for 2 hours.
Please note, if there is no requirement for us to meet then we don't. No 
meetings for the sake of a meetings.
Meetings do not have to run for the full 2 hours.

Agenda Publishing

Agenda to be posted to the mailing list 7days before the next interim meeting.

Meeting method / Note Taking

Currently we are using webex, which seems to work, so lets leave that as is 
unless there is major objection which would also need to be accompanied by a 
replacement solution.

Note taking - Etherpad also seems to work, so as with webex, unless there is an 
objection coupled with solution we should continue.

Minutes

As interim meetings increase overhead, we need to keep admin to a minimum and 
use modern tools/methods.

It is therefore suggested that the minutes are keep as summaries of the 
discussion for each point discussed, rather than an entire back and forth of 
the conversation. In the notes we should indicate the time we discussed each 
point, so this can be used to fast-forward to a point in a webex recording.

Summary

Since the goal of having interim meetings is to speed things up in the WG, we 
need to ensure these meetings are focused and responsive.





Upcoming Meetings (next few months schedule)

Oct 15
- 1st bi-weekly meeting
Oct 29
- 2nd bi-weekly meeting (maybe cancelled due to travel needs)
Nov --
- two meetings at conference
Nov 12
- 3rd bi-weekly meeting
Nov 26
- cancelled (Thanksgiving holiday in US)
Dec 10
- 4th bi-weekly meeting
Dec 24
- cancelled (Christmas eve)
Jan 7
- 5th bi-weekly meeting
Jan 21
- 6th bi-weekly meeting

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

Re: [netmod] Choice corner Cases -1

[Ladislav Lhotka]

> On 05 Oct 2015, at 17:35, Balazs Lengyel  wrote:
> 
> 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?

In the first place, it should be an error because of colliding names - all the 
leaves defined in sub-cases have the same parent. However, pyang doesn't flag 
it as an error.

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

Yes, it is quite complicated. Normally, such embedded choices shouldn't be 
needed but they can happen if, e.g. the internal choices are defined in 
groupings.

> As the very least we SHOULD prohibit mandatory/default on the inside choice.

I think it would be better to ignore them (and tools may issue a warning).

Lada 

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

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




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

Re: [netmod] Choice corner Cases -1

[Andy Bierman]

Hi,

It looks like neither 'mandatory' or 'default' has any effect in
this situation.  If the nested choices had sibling nodes
then these statements would be relevant.  Then selecting the
sibling would cause the mandatory or default choice to have meaning.


Andy


On Mon, Oct 5, 2015 at 8:35 AM, Balazs Lengyel 
wrote:

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

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

Re: [netmod] 6020bis - anydata

[Juergen Schoenwaelder]

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

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

[Juergen Schoenwaelder]

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

___
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] Y26 again, sorry

[Robert Wilton]

Thanks. Yes.

I had missed that.

Rob


On 05/10/2015 10:32, Juergen Schoenwaelder wrote:

Robert,

I think this is listed as the first issue in our list of last call
comments.

/js

On Mon, Oct 05, 2015 at 10:16:33AM +0100, Robert Wilton wrote:

Hi Juergen,

Did you get a chance to consider this proposed text for mandatory nodes
at all?

Thanks,
Rob


On 23/09/2015 14:50, Robert Wilton wrote:

Hi Juergen,

On 21/09/2015 09:26, Juergen Schoenwaelder wrote:

On Tue, Sep 15, 2015 at 10:00:46AM +0200, Ladislav Lhotka wrote:

Juergen Schoenwaelder  writes:


Still some text needs to be written explaining that breaking old
clients by adding new mandatory nodes is a no go. I did not ask to
enumerate all situations where it is allowed, I am looking for text
that clearly says what people have to look out for if they add
mandatory nodes.

Would it be sufficient to just change the MUST NOT to SHOULD NOT and
then reference section 5.17.2 of draft-ietf-netmod-rfc6087bis which
seems to provide the explanation that you are requesting?

E.g. something like:

draft-ietf-netmod-rfc6020bis, section 7.17.  The augment Statement

From:

If the target node is in another module, then nodes added by the
augmentation MUST NOT be mandatory nodes (see Section 3.1).

To:

If the target node is in another module, then nodes added by the
augmentation SHOULD NOT be mandatory nodes (see Section 3.1).  The
safe scenarios to augment with mandatory nodes are described in
[draft-ietf-netmod-rfc6087bis] section 5.17.2.


For reference, I've also reproduced the text for
draft-ietf-netmod-rfc6087bis-04] section 5.17.2 below:

5.17.  Augment Statements

   The YANG "augment" statement is used to define a set of data
   definition statements that will be added as child nodes of a target
   data node.  The module namespace for these data nodes will be the
   augmenting module, not the augmented module.

   A top-level "augment" statement SHOULD NOT be used if the target data
   node is in the same module or submodule as the evaluated "augment"
   statement.  The data definition statements SHOULD be added inline
   instead.

5.17.1.  Conditional Augment Statements

   The "augment" statement is often used together with the "when"
   statement and/or "if-feature" statement to make the augmentation
   conditional on some portion of the data model.

   The following example from [RFC7223] shows how a conditional
   container called "ethernet" is added to the "interface" list only for
   entries of the type "ethernetCsmacd".

augment "/if:interfaces/if:interface" {
when "if:type = 'ianaift:ethernetCsmacd'";

container ethernet {
leaf duplex {
...
}
}
}

5.17.2.  Conditionally Mandatory Data Definition Statements

   YANG has very specific rules about how configuration data can be
   updated in new releases of a module.  These rules allow an "old
   client" to continue interoperating with a "new server".

   If data nodes are added to an existing entry, the old client MUST NOT
   be required to provide any mandatory parameters that were not in the
   original module definition.

   It is possible to add conditional augment statements such that the
   old client would not know about the new condition, and would not
   specify the new condition.  The conditional augment statement can
   contain mandatory objects only if the condition is false unless
   explicitly requested by the client.

   Only a conditional augment statement that uses the "when" statement
   form of condition can be used in this manner.  The YANG features
   enabled on the server cannot be controlled by the client in any way,
   so it is not safe to add mandatory augmenting data nodes based on the
   "if-feature" statement.

   The XPath "when" statement condition MUST NOT reference data outside
   of target data node because the client does not have any control over
   this external data.

   In the following dummy example, it is OK to augment the "interface"
   entry with "mandatory-leaf" because the augmentation depends on
   support for "some-new-iftype".  The old client does not know about
   this type so it would never select this type, and therefore not be
   adding a mandatory data node.

 module my-module {
   ...

   identity some-new-iftype {
  base iana:iana-interface-type;
   }

   augment "/if:interfaces/if:interface" {
  when "if:type = 'mymod:some-new-iftype'";

  leaf mandatory-leaf {
 mandatory true;
 ...
  }
   }
 }

   Note that this practice is safe only for creating data resources.  It
   is not safe for replacing or modifying resources if the client does
   not know about the new condition.  The YANG data model MUST be
   packaged in a way that requires the client to be aware of the
   mandatory data nodes if it is aware of the condition for this data.
   In the example above,

Re: [netmod] Y26 again, sorry

[Juergen Schoenwaelder]

Robert,

I think this is listed as the first issue in our list of last call
comments.

/js

On Mon, Oct 05, 2015 at 10:16:33AM +0100, Robert Wilton wrote:
> Hi Juergen,
> 
> Did you get a chance to consider this proposed text for mandatory nodes 
> at all?
> 
> Thanks,
> Rob
> 
> 
> On 23/09/2015 14:50, Robert Wilton wrote:
> >Hi Juergen,
> >
> >On 21/09/2015 09:26, Juergen Schoenwaelder wrote:
> >>On Tue, Sep 15, 2015 at 10:00:46AM +0200, Ladislav Lhotka wrote:
> >>>Juergen Schoenwaelder  writes:
> >>>
> >>Still some text needs to be written explaining that breaking old
> >>clients by adding new mandatory nodes is a no go. I did not ask to
> >>enumerate all situations where it is allowed, I am looking for text
> >>that clearly says what people have to look out for if they add
> >>mandatory nodes.
> >Would it be sufficient to just change the MUST NOT to SHOULD NOT and 
> >then reference section 5.17.2 of draft-ietf-netmod-rfc6087bis which 
> >seems to provide the explanation that you are requesting?
> >
> >E.g. something like:
> >
> >draft-ietf-netmod-rfc6020bis, section 7.17.  The augment Statement
> >
> >From:
> >
> >If the target node is in another module, then nodes added by the
> >augmentation MUST NOT be mandatory nodes (see Section 3.1).
> >
> >To:
> >
> >If the target node is in another module, then nodes added by the
> >augmentation SHOULD NOT be mandatory nodes (see Section 3.1).  The
> >safe scenarios to augment with mandatory nodes are described in
> >[draft-ietf-netmod-rfc6087bis] section 5.17.2.
> >
> >
> >For reference, I've also reproduced the text for 
> >draft-ietf-netmod-rfc6087bis-04] section 5.17.2 below:
> >
> >5.17.  Augment Statements
> >
> >   The YANG "augment" statement is used to define a set of data
> >   definition statements that will be added as child nodes of a target
> >   data node.  The module namespace for these data nodes will be the
> >   augmenting module, not the augmented module.
> >
> >   A top-level "augment" statement SHOULD NOT be used if the target data
> >   node is in the same module or submodule as the evaluated "augment"
> >   statement.  The data definition statements SHOULD be added inline
> >   instead.
> >
> >5.17.1.  Conditional Augment Statements
> >
> >   The "augment" statement is often used together with the "when"
> >   statement and/or "if-feature" statement to make the augmentation
> >   conditional on some portion of the data model.
> >
> >   The following example from [RFC7223] shows how a conditional
> >   container called "ethernet" is added to the "interface" list only for
> >   entries of the type "ethernetCsmacd".
> >
> >augment "/if:interfaces/if:interface" {
> >when "if:type = 'ianaift:ethernetCsmacd'";
> >
> >container ethernet {
> >leaf duplex {
> >...
> >}
> >}
> >}
> >
> >5.17.2.  Conditionally Mandatory Data Definition Statements
> >
> >   YANG has very specific rules about how configuration data can be
> >   updated in new releases of a module.  These rules allow an "old
> >   client" to continue interoperating with a "new server".
> >
> >   If data nodes are added to an existing entry, the old client MUST NOT
> >   be required to provide any mandatory parameters that were not in the
> >   original module definition.
> >
> >   It is possible to add conditional augment statements such that the
> >   old client would not know about the new condition, and would not
> >   specify the new condition.  The conditional augment statement can
> >   contain mandatory objects only if the condition is false unless
> >   explicitly requested by the client.
> >
> >   Only a conditional augment statement that uses the "when" statement
> >   form of condition can be used in this manner.  The YANG features
> >   enabled on the server cannot be controlled by the client in any way,
> >   so it is not safe to add mandatory augmenting data nodes based on the
> >   "if-feature" statement.
> >
> >   The XPath "when" statement condition MUST NOT reference data outside
> >   of target data node because the client does not have any control over
> >   this external data.
> >
> >   In the following dummy example, it is OK to augment the "interface"
> >   entry with "mandatory-leaf" because the augmentation depends on
> >   support for "some-new-iftype".  The old client does not know about
> >   this type so it would never select this type, and therefore not be
> >   adding a mandatory data node.
> >
> > module my-module {
> >   ...
> >
> >   identity some-new-iftype {
> >  base iana:iana-interface-type;
> >   }
> >
> >   augment "/if:interfaces/if:interface" {
> >  when "if:type = 'mymod:some-new-iftype'";
> >
> >  leaf mandatory-leaf {
> > mandatory true;
> > ...
> >  }
> >   }
> > }
> >
> >   Note that this practice is safe only for creating data resources.  It
> >   is n

Re: [netmod] Y26 again, sorry

[Robert Wilton]

Hi Juergen,

Did you get a chance to consider this proposed text for mandatory nodes 
at all?


Thanks,
Rob


On 23/09/2015 14:50, Robert Wilton wrote:

Hi Juergen,

On 21/09/2015 09:26, Juergen Schoenwaelder wrote:

On Tue, Sep 15, 2015 at 10:00:46AM +0200, Ladislav Lhotka wrote:

Juergen Schoenwaelder  writes:


Still some text needs to be written explaining that breaking old
clients by adding new mandatory nodes is a no go. I did not ask to
enumerate all situations where it is allowed, I am looking for text
that clearly says what people have to look out for if they add
mandatory nodes.
Would it be sufficient to just change the MUST NOT to SHOULD NOT and 
then reference section 5.17.2 of draft-ietf-netmod-rfc6087bis which 
seems to provide the explanation that you are requesting?


E.g. something like:

draft-ietf-netmod-rfc6020bis, section 7.17.  The augment Statement

From:

If the target node is in another module, then nodes added by the
augmentation MUST NOT be mandatory nodes (see Section 3.1).

To:

If the target node is in another module, then nodes added by the
augmentation SHOULD NOT be mandatory nodes (see Section 3.1).  The
safe scenarios to augment with mandatory nodes are described in
[draft-ietf-netmod-rfc6087bis] section 5.17.2.


For reference, I've also reproduced the text for 
draft-ietf-netmod-rfc6087bis-04] section 5.17.2 below:


5.17.  Augment Statements

   The YANG "augment" statement is used to define a set of data
   definition statements that will be added as child nodes of a target
   data node.  The module namespace for these data nodes will be the
   augmenting module, not the augmented module.

   A top-level "augment" statement SHOULD NOT be used if the target data
   node is in the same module or submodule as the evaluated "augment"
   statement.  The data definition statements SHOULD be added inline
   instead.

5.17.1.  Conditional Augment Statements

   The "augment" statement is often used together with the "when"
   statement and/or "if-feature" statement to make the augmentation
   conditional on some portion of the data model.

   The following example from [RFC7223] shows how a conditional
   container called "ethernet" is added to the "interface" list only for
   entries of the type "ethernetCsmacd".

augment "/if:interfaces/if:interface" {
when "if:type = 'ianaift:ethernetCsmacd'";

container ethernet {
leaf duplex {
...
}
}
}

5.17.2.  Conditionally Mandatory Data Definition Statements

   YANG has very specific rules about how configuration data can be
   updated in new releases of a module.  These rules allow an "old
   client" to continue interoperating with a "new server".

   If data nodes are added to an existing entry, the old client MUST NOT
   be required to provide any mandatory parameters that were not in the
   original module definition.

   It is possible to add conditional augment statements such that the
   old client would not know about the new condition, and would not
   specify the new condition.  The conditional augment statement can
   contain mandatory objects only if the condition is false unless
   explicitly requested by the client.

   Only a conditional augment statement that uses the "when" statement
   form of condition can be used in this manner.  The YANG features
   enabled on the server cannot be controlled by the client in any way,
   so it is not safe to add mandatory augmenting data nodes based on the
   "if-feature" statement.

   The XPath "when" statement condition MUST NOT reference data outside
   of target data node because the client does not have any control over
   this external data.

   In the following dummy example, it is OK to augment the "interface"
   entry with "mandatory-leaf" because the augmentation depends on
   support for "some-new-iftype".  The old client does not know about
   this type so it would never select this type, and therefore not be
   adding a mandatory data node.

 module my-module {
   ...

   identity some-new-iftype {
  base iana:iana-interface-type;
   }

   augment "/if:interfaces/if:interface" {
  when "if:type = 'mymod:some-new-iftype'";

  leaf mandatory-leaf {
 mandatory true;
 ...
  }
   }
 }

   Note that this practice is safe only for creating data resources.  It
   is not safe for replacing or modifying resources if the client does
   not know about the new condition.  The YANG data model MUST be
   packaged in a way that requires the client to be aware of the
   mandatory data nodes if it is aware of the condition for this data.
   In the example above, the "some-new-iftype" identity is defined in
   the same module as the "mandatory-leaf" data definition statement.

   This practice is not safe for identities defined in a common module
   such as "iana-if-type" because the client is not r

[netmod] today's (2015-10-05) virtual interim on YANG 1.1 cancelled

[Juergen Schoenwaelder]

Hi,

I decided to cancel today's YANG 1.1 virtual interim meeting. Note
that the YANG 1.1 specification

  https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-07

is in WG last call until Monday October 12, 2015 at 13:00 CEST. You
are encouraged to spent the hour gained today to review the document.
We will likely use the YANG 1.1 virtual interim meeting on October
12 to go through the non-editorial issues that we track here:

  https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/last-call-comments.html

/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