Re: [netmod] AD review: draft-ietf-netmod-yang-json-07

[Ladislav Lhotka]

Andy Bierman  writes:

> Hi,
>
> I entered a new 6087bis issue:
> https://github.com/netmod-wg/rfc6087bis/issues/27
>
> I agree the conventions need to be spelled out.
> IMO there are many problematic examples in 6020bis.
> The convention "..." is used and some newbie could think
> it was some valid YANG syntax.  There are also example
> modules that use prefixes although no prefix-stmt or import-stmt
> is shown to match up the prefix.
>
> This is a bigger problem than automated tools extracting modules.
> People learn from examples (more than we would like) so it needs
> to be clear in every YANG draft whether a YANG example
> is complete vs. trimmed for readability and not meant to be compiled.
>
> Let's not use 'example' as a hack to indicate 1 or the other.
> Compiler writers want deterministic syntax, not ad-hoc conventions.
>
> There are 3 scenarios:
>
> 1) normative: has  and complete YANG module
>
>
> 2) example: no  but complete YANG module,
> intended to be compiled
>
> 3) snippet: no  and not complete, not intended to be compiled
>
>
> So we cannot tell the difference between (2) and (3).

I think the "example-" prefix could be such a discriminator, to be used
at I-D author's discretion. It's better than nothing.

Lada

>
> IMO we should have  for (2) so it can be
> extracted automatically and distinguished from (3).
>
>
> Andy
>
>
> On Wed, Feb 3, 2016 at 1:38 PM, Mahesh Jethanandani > wrote:
>
>>
>> On Feb 3, 2016, at 2:49 AM, Juergen Schoenwaelder <
>> j.schoenwael...@jacobs-university.de> wrote:
>>
>> On Wed, Feb 03, 2016 at 11:19:33AM +0100, Benoit Claise wrote:
>>
>>  module foomod {
>>
>> namespace"http://example.com/foomod";;
>>
>> prefix "foo";
>>
>> container top {
>>   leaf foo {
>> type uint8;
>>   }
>> }
>>   }
>>
>> Use "example-" in the module name, as mentioned
>> inhttps://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-05:
>>
>>   Example modules are non-normative, and SHOULD be named with the
>>   prefix "example-".
>>
>> Same remark for module barmod (and btw, pay attention to the "import
>> foomod") and module exmod
>>
>>
>> I still believe the text in draft-ietf-netmod-rfc6087bis-05 needs
>> fixing to distinguish between examples that should be subject to
>> validation and examples that are just there for documentation purposes
>> and which are typically designed to be incomplete in order to aid the
>> reader.
>>
>>
>> I agree. Currently there is no way to distinguish between models that are
>> examples, meant to be extracted and validated, and what I call snippets of
>> an example that are designed to incomplete and for demonstrating a point.
>>
>> Should there be a stipulation in 6087bis that incomplete examples should
>> NOT use the prefix example-?
>>
>>
>> /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
>>
>>
>> Mahesh Jethanandani
>> mjethanand...@gmail.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

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

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

Re: [netmod] Yang mount / ysdl example use case

[Lou Berger]

Alex,


On February 3, 2016 8:35:54 PM "Alexander Clemm (alex)"  wrote:


Hi Kent,

I do think that we should have a slot for that draft as well.  The 
structural mount case is a variation of the alias mount case;


Insofar as much that Structural mount and YSDL both have a model that is 
used to control their mount functions there is similarity, but there is a 
fundamental difference that the other documents  cover a schema being 
mounted not a datastore. Scheme mount is really a better term than 
structural mount...


Also for our use case we don't want to use a different/ additional model.

That said covering alias and remote mount if there is time in the interim 
would be fine with me, but not at the expense of identifying a preferred 
approach of enabling the same amount that we are making use of in our draft.


Lou

it is certainly possible to have a continuum of solutions that allows to 
incorporate structural mount as well as alias mount and peer mount (the 
latter possibly at a later point).


At the core in each case is the “mountpoint” construct / YANG extension, 
which was first introduced in the peer-mount draft and which also appears 
in the structured-mount draft.  In peer-mount, we also introduced two 
additional arguments/ extension in addition:  the subtree (used for alias 
mount), and the target (for peer mount – building on top, for when it is 
required).  In the discussions since, it became clear that there is also a 
use case where you don’t need an alias, where it is sufficient to just 
mount a module and instantiate it right under the mount point.  This is the 
case that Martin put in his draft.  So, there is really a continuum: a case 
of a mountpoint with no argument (structural mount - the new draft), with 
one argument (alias),  and with two (peer) (the earlier draft).


--- Alex


-Original Message-
From: Kent Watsen [mailto:kwat...@juniper.net]
Sent: Wednesday, February 03, 2016 11:27 AM
To: Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco) 
Cc: Lou Berger ; netmod WG ; Alexander 
Clemm (alex) ; Eric Voit (evoit) 

Subject: Re: [netmod] Yang mount / ysdl example use case


I was led to believe that the current set of drafts subsume 
draft-clemm-netmod-mount.  If that’s not true, then absolutely there should 
be a slot for that draft to be discussed as well.  Please advise.


Kent






On 2/3/16, 9:07 AM, "Robert Wilton"  wrote:


Hi Kent,

There is also another Yang Mount related draft:
draft-clemm-netmod-mount-03

Now, this draft doesn't directly address the RTG DT Arch team use-case,
and seems to cover two more complex problem scenarios (remote mount and
alias mount), but these do appear to be a valid mount use cases (e.g. I
think that it is used by OpenDaylight SDN controller), and I know that
there is at least one implementation of this draft.

So, I want to echo Eric Voit's comments that it would be good if
whatever basic YANG mount draft we converge on is able to be cleanly
extended to cover the more complex mount scenarios.

As such, if Alex Clemm or Eric Voit are willing, I think that it would
be useful if one of them could comment on how feasible it is to extend
either netmod-structual-mount or netmod-ysdl to cover the remote mount
and alias mount scenarios described in draft-clemm-netmod-mount-03.
Hence, if they agree, do you think that you would be able to add a 15
min slot to the agenda to cover this please?

Thanks,
Rob


On 03/02/2016 02:24, Kent Watsen wrote:

[Chair hat on]

Given the number of competing/complementing drafts involved, and the 
general lack of discussion on any of them, a virtual interim meeting might 
be an expedient way to proceed.  In fairness, we know that there has been 
some discussion, but it hasn’t been picked up yet in a big way, and now Lou 
has an updated draft.


The chairs discussed maybe scheduling one for a couple weeks from now, 
perhaps Thursday Feb 18 starting at 10am EST?   I'm thinking about this 
slot only since it worked for us for previously.  Is this a good time slot? 
 I assume to schedule for 2 hours, with a plan to end early if needed - 
makes sense? We also need to put together a proper agenda, perhaps the 
following?


   10 min: RTG DT YANG Arch team use-case summary
   20 min: draft-rtgyangdt-rtgwg-device-model
   20 min: draft-lhotka-netmod-ysdl
   20 min: draft-bjorklund-netmod-structural-mount
   50 min: general discussion or end early


We hope to schedule the meeting itself tomorrow or the next day, so please 
respond quickly to this email if possible.


Thanks,
Kent and Tom




On 2/2/16, 2:04 PM, "netmod on behalf of Lou Berger" 
 wrote:



I thought it would be worth summarizing what we're looking for in
our draft, draft-rtgyangdt-rtgwg-device-model-02 (note new version
in case you missed it) with respect to the draft-lhotka-netmod-ysdl
and draft-bjorklund-netmod-structural-mount drafts. This is just my
view, so my co-authors may wish to chime in and correct me.

I'd be interested in hearin

Re: [netmod] Yang mount / ysdl example use case

[Alexander Clemm (alex)]

Hi Kent,

I do think that we should have a slot for that draft as well.  The structural 
mount case is a variation of the alias mount case; it is certainly possible to 
have a continuum of solutions that allows to incorporate structural mount as 
well as alias mount and peer mount (the latter possibly at a later point).  

At the core in each case is the “mountpoint” construct / YANG extension, which 
was first introduced in the peer-mount draft and which also appears in the 
structured-mount draft.  In peer-mount, we also introduced two additional 
arguments/ extension in addition:  the subtree (used for alias mount), and the 
target (for peer mount – building on top, for when it is required).  In the 
discussions since, it became clear that there is also a use case where you 
don’t need an alias, where it is sufficient to just mount a module and 
instantiate it right under the mount point.  This is the case that Martin put 
in his draft.  So, there is really a continuum: a case of a mountpoint with no 
argument (structural mount - the new draft), with one argument (alias),  and 
with two (peer) (the earlier draft).  

--- Alex


-Original Message-
From: Kent Watsen [mailto:kwat...@juniper.net] 
Sent: Wednesday, February 03, 2016 11:27 AM
To: Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco) 
Cc: Lou Berger ; netmod WG ; Alexander Clemm 
(alex) ; Eric Voit (evoit) 
Subject: Re: [netmod] Yang mount / ysdl example use case


I was led to believe that the current set of drafts subsume 
draft-clemm-netmod-mount.  If that’s not true, then absolutely there should be 
a slot for that draft to be discussed as well.  Please advise.

Kent






On 2/3/16, 9:07 AM, "Robert Wilton"  wrote:

>Hi Kent,
>
>There is also another Yang Mount related draft: 
>draft-clemm-netmod-mount-03
>
>Now, this draft doesn't directly address the RTG DT Arch team use-case, 
>and seems to cover two more complex problem scenarios (remote mount and 
>alias mount), but these do appear to be a valid mount use cases (e.g. I 
>think that it is used by OpenDaylight SDN controller), and I know that 
>there is at least one implementation of this draft.
>
>So, I want to echo Eric Voit's comments that it would be good if 
>whatever basic YANG mount draft we converge on is able to be cleanly 
>extended to cover the more complex mount scenarios.
>
>As such, if Alex Clemm or Eric Voit are willing, I think that it would 
>be useful if one of them could comment on how feasible it is to extend 
>either netmod-structual-mount or netmod-ysdl to cover the remote mount 
>and alias mount scenarios described in draft-clemm-netmod-mount-03.
>Hence, if they agree, do you think that you would be able to add a 15 
>min slot to the agenda to cover this please?
>
>Thanks,
>Rob
>
>
>On 03/02/2016 02:24, Kent Watsen wrote:
>> [Chair hat on]
>>
>> Given the number of competing/complementing drafts involved, and the general 
>> lack of discussion on any of them, a virtual interim meeting might be an 
>> expedient way to proceed.  In fairness, we know that there has been some 
>> discussion, but it hasn’t been picked up yet in a big way, and now Lou has 
>> an updated draft.
>>
>> The chairs discussed maybe scheduling one for a couple weeks from now, 
>> perhaps Thursday Feb 18 starting at 10am EST?   I'm thinking about this slot 
>> only since it worked for us for previously.  Is this a good time slot?  I 
>> assume to schedule for 2 hours, with a plan to end early if needed - makes 
>> sense? We also need to put together a proper agenda, perhaps the 
>> following?
>>
>>10 min: RTG DT YANG Arch team use-case summary
>>20 min: draft-rtgyangdt-rtgwg-device-model
>>20 min: draft-lhotka-netmod-ysdl
>>20 min: draft-bjorklund-netmod-structural-mount
>>50 min: general discussion or end early
>>
>>
>> We hope to schedule the meeting itself tomorrow or the next day, so please 
>> respond quickly to this email if possible.
>>
>> Thanks,
>> Kent and Tom
>>
>>
>>
>>
>> On 2/2/16, 2:04 PM, "netmod on behalf of Lou Berger" 
>>  wrote:
>>
>>> I thought it would be worth summarizing what we're looking for in 
>>> our draft, draft-rtgyangdt-rtgwg-device-model-02 (note new version 
>>> in case you missed it) with respect to the draft-lhotka-netmod-ysdl 
>>> and draft-bjorklund-netmod-structural-mount drafts. This is just my 
>>> view, so my co-authors may wish to chime in and correct me.
>>>
>>> I'd be interested in hearing from the authors of YSDL and 
>>> structural-mount, or anyone else for that matter, on how they see to 
>>> best meet these needs.
>>>
>>> Here's what I think our draft needs:
>>>
>>> 1. that there be a mechanism that allows the incorporation (or
>>>'mounting') of the data model defined by one top-level module
>>>within another module.
>>>
>>>The implication here is that when information is instantiated
>>>for the parent model it is also instantiated for the
>>>incorporated/mounted model. In our case we expect to 

Re: [netmod] AD review: draft-ietf-netmod-yang-json-07

[Andy Bierman]

Hi,

I entered a new 6087bis issue:
https://github.com/netmod-wg/rfc6087bis/issues/27

I agree the conventions need to be spelled out.
IMO there are many problematic examples in 6020bis.
The convention "..." is used and some newbie could think
it was some valid YANG syntax.  There are also example
modules that use prefixes although no prefix-stmt or import-stmt
is shown to match up the prefix.

This is a bigger problem than automated tools extracting modules.
People learn from examples (more than we would like) so it needs
to be clear in every YANG draft whether a YANG example
is complete vs. trimmed for readability and not meant to be compiled.

Let's not use 'example' as a hack to indicate 1 or the other.
Compiler writers want deterministic syntax, not ad-hoc conventions.

There are 3 scenarios:

1) normative: has  and complete YANG module


2) example: no  but complete YANG module,
intended to be compiled

3) snippet: no  and not complete, not intended to be compiled


So we cannot tell the difference between (2) and (3).

IMO we should have  for (2) so it can be
extracted automatically and distinguished from (3).


Andy


On Wed, Feb 3, 2016 at 1:38 PM, Mahesh Jethanandani  wrote:

>
> On Feb 3, 2016, at 2:49 AM, Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de> wrote:
>
> On Wed, Feb 03, 2016 at 11:19:33AM +0100, Benoit Claise wrote:
>
>  module foomod {
>
> namespace"http://example.com/foomod";;
>
> prefix "foo";
>
> container top {
>   leaf foo {
> type uint8;
>   }
> }
>   }
>
> Use "example-" in the module name, as mentioned
> inhttps://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-05:
>
>   Example modules are non-normative, and SHOULD be named with the
>   prefix "example-".
>
> Same remark for module barmod (and btw, pay attention to the "import
> foomod") and module exmod
>
>
> I still believe the text in draft-ietf-netmod-rfc6087bis-05 needs
> fixing to distinguish between examples that should be subject to
> validation and examples that are just there for documentation purposes
> and which are typically designed to be incomplete in order to aid the
> reader.
>
>
> I agree. Currently there is no way to distinguish between models that are
> examples, meant to be extracted and validated, and what I call snippets of
> an example that are designed to incomplete and for demonstrating a point.
>
> Should there be a stipulation in 6087bis that incomplete examples should
> NOT use the prefix example-?
>
>
> /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
>
>
> Mahesh Jethanandani
> mjethanand...@gmail.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

Re: [netmod] AD review: draft-ietf-netmod-yang-json-07

[Mahesh Jethanandani]

> On Feb 3, 2016, at 2:49 AM, Juergen Schoenwaelder 
>  wrote:
> 
> On Wed, Feb 03, 2016 at 11:19:33AM +0100, Benoit Claise wrote:
> 
>>  module foomod {
>> 
>> namespace"http://example.com/foomod";;
>> 
>> prefix "foo";
>> 
>> container top {
>>   leaf foo {
>> type uint8;
>>   }
>> }
>>   }
>> 
>> Use "example-" in the module name, as mentioned 
>> inhttps://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-05:
>> 
>>   Example modules are non-normative, and SHOULD be named with the
>>   prefix "example-".
>> 
>> Same remark for module barmod (and btw, pay attention to the "import 
>> foomod") and module exmod
> 
> I still believe the text in draft-ietf-netmod-rfc6087bis-05 needs
> fixing to distinguish between examples that should be subject to
> validation and examples that are just there for documentation purposes
> and which are typically designed to be incomplete in order to aid the
> reader.

I agree. Currently there is no way to distinguish between models that are 
examples, meant to be extracted and validated, and what I call snippets of an 
example that are designed to incomplete and for demonstrating a point. 

Should there be a stipulation in 6087bis that incomplete examples should NOT 
use the prefix example-?

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

Mahesh Jethanandani
mjethanand...@gmail.com





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

Re: [netmod] AD review: draft-ietf-netmod-yang-json-07

[Ladislav Lhotka]

> On 03 Feb 2016, at 17:33, Martin Bjorklund  wrote:
> 
> Ladislav Lhotka  wrote:
>> 
>>> On 03 Feb 2016, at 14:37, Benoit Claise  wrote:
>>> 
>>> Hi Lada,
 
>> I agree with Juergen that 6087bis should distinguish between complete
>> example modules and short module snippets that are used for explaining a
>> certain YANG language or encoding issue. If you look at this particular
>> example, then changing the JSON document on p. 6 to
>> 
>>   {
>> "example-foomod:top": {
>>   "foo": 54,
>>   "example-barmod:bar": true
>> }
>>   }
>> 
>> would IMO just add noise and blur the message the example is supposed to
>> convey.
> So please fix the text in 6087bis.
> Until it's done, I'll stick to the current rule.
 I don't want to be excessively bureaucratic but, strictly
>> speaking, current rules are those of RFC 6087 that contains no such
>> requirement, so we should be OK for now. And I think there is enough
>> consensus
>>> so Jürgen and you?
>> 
>> I guess Martin as well, given that 6020bis doesn't follow that rule.
> 
> I agree that not all modules must compile, e.g. we have things like:
> 
>  module example-foo {
> ...
> container bar { ... }
>  }
> 
> Having said that, in the upcoming version of 6020bis, I have changed
> things like "module acme-system" to "module example-system".

OK, so I will also add the "example-" prefix in yang-json.

Lada

> 
> 
> 
> /martin
> 
> 
> 
>> 
>> Lada
>> 
 to change the corresponding 6087bis text - after all, 6020bis also has 
 example modules whose names don't start with "example-".
>>> I'll still have to review it and that will be one of my comments, for sure. 
>>> Consistency first.
>>> 
>>> Regards ,Benoit
>>> 
>> 
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>> 
>> 
>> 
>> 
>> ___
>> 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] Yang mount / ysdl example use case

[Martin Bjorklund]

Hi,

Kent Watsen  wrote:
> 
> I was led to believe that the current set of drafts subsume
> draft-clemm-netmod-mount.

The mechanism in draft-clemm-netmod-mount primarily mounts remote
datastores into a datastore.

Structural mount focuses on combining *schemas*.  This approach can
support different implementation strategies, where remote mounting
could be one.  However, the structural mount draft does not specify
any such implementation strategies; the idea was that such strategies
could be defined in separate documents (that would reference the
structural mount doc).


/martin
 
> If that’s not true, then absolutely there
> should be a slot for that draft to be discussed as well.  Please
> advise.
> 
> Kent
> 
> 
> 
> 
> 
> 
> On 2/3/16, 9:07 AM, "Robert Wilton"  wrote:
> 
> >Hi Kent,
> >
> >There is also another Yang Mount related draft:
> >draft-clemm-netmod-mount-03
> >
> >Now, this draft doesn't directly address the RTG DT Arch team
> >use-case,
> >and seems to cover two more complex problem scenarios (remote mount
> >and
> >alias mount), but these do appear to be a valid mount use cases
> >(e.g. I
> >think that it is used by OpenDaylight SDN controller), and I know that
> >there is at least one implementation of this draft.
> >
> >So, I want to echo Eric Voit's comments that it would be good if 
> >whatever basic YANG mount draft we converge on is able to be cleanly 
> >extended to cover the more complex mount scenarios.
> >
> >As such, if Alex Clemm or Eric Voit are willing, I think that it would
> >be useful if one of them could comment on how feasible it is to extend
> >either netmod-structual-mount or netmod-ysdl to cover the remote mount
> >and alias mount scenarios described in draft-clemm-netmod-mount-03.  
> >Hence, if they agree, do you think that you would be able to add a 15 
> >min slot to the agenda to cover this please?
> >
> >Thanks,
> >Rob
> >
> >
> >On 03/02/2016 02:24, Kent Watsen wrote:
> >> [Chair hat on]
> >>
> >> Given the number of competing/complementing drafts involved, and the
> >> general lack of discussion on any of them, a virtual interim meeting
> >> might be an expedient way to proceed.  In fairness, we know that there
> >> has been some discussion, but it hasn’t been picked up yet in a big
> >> way, and now Lou has an updated draft.
> >>
> >> The chairs discussed maybe scheduling one for a couple weeks from now,
> >> perhaps Thursday Feb 18 starting at 10am EST?  I'm thinking about this
> >> slot only since it worked for us for previously.  Is this a good time
> >> slot?  I assume to schedule for 2 hours, with a plan to end early if
> >> needed - makes sense?  We also need to put together a proper agenda,
> >> perhaps the following?
> >>
> >>10 min: RTG DT YANG Arch team use-case summary
> >>20 min: draft-rtgyangdt-rtgwg-device-model
> >>20 min: draft-lhotka-netmod-ysdl
> >>20 min: draft-bjorklund-netmod-structural-mount
> >>50 min: general discussion or end early
> >>
> >>
> >> We hope to schedule the meeting itself tomorrow or the next day, so
> >> please respond quickly to this email if possible.
> >>
> >> Thanks,
> >> Kent and Tom
> >>
> >>
> >>
> >>
> >> On 2/2/16, 2:04 PM, "netmod on behalf of Lou Berger"
> >>  wrote:
> >>
> >>> I thought it would be worth summarizing what we're looking for in our
> >>> draft, draft-rtgyangdt-rtgwg-device-model-02 (note new version in case
> >>> you missed it) with respect to the draft-lhotka-netmod-ysdl and
> >>> draft-bjorklund-netmod-structural-mount drafts. This is just my view,
> >>> so
> >>> my co-authors may wish to chime in and correct me.
> >>>
> >>> I'd be interested in hearing from the authors of YSDL and
> >>> structural-mount, or anyone else for that matter, on how they see to
> >>> best meet these needs.
> >>>
> >>> Here's what I think our draft needs:
> >>>
> >>> 1. that there be a mechanism that allows the incorporation (or
> >>>'mounting') of the data model defined by one top-level module
> >>>within another module.
> >>>
> >>>The implication here is that when information is instantiated
> >>>for the parent model it is also instantiated for the
> >>>incorporated/mounted model. In our case we expect to do this on
> >>>list element creation. Both solutions drafts cover the path
> >>>implications, so these are not repeated here.
> >>>
> >>> 2. that this mechanism allow identification of specific modules to
> >>>be incorporated/mounted at time of module definition, i.e. that
> >>>no additional module is needed to support 1. This doesn't
> >>>preclude definition of such a module.
> >>>
> >>> 3. that this mechanism allow for a server to control (and
> >>>identify) which modules are incorporated/mounted. (see Section
> >>>3 LNE in our draft for an envisioned usage.)
> >>>
> >>> 4. that all capabilities that exist with the mounted module are
> >>>available e.g. RPC operations and notifications.
> >>>
> >>> 5. while our primary requirement is for 'mo

Re: [netmod] Yang mount / ysdl example use case

[Lou Berger]

I don't see how draft Clemm addresses our draft's use case.  That said, if 
alex thinks it does - let's hear about it.


Alex,

Can you look at the mail I sent the other day about our planned usage and 
see what you think - and let us know what you find?


Thanks,
Lou


On February 3, 2016 2:27:44 PM Kent Watsen  wrote:



I was led to believe that the current set of drafts subsume 
draft-clemm-netmod-mount.  If that’s not true, then absolutely there should 
be a slot for that draft to be discussed as well.  Please advise.


Kent






On 2/3/16, 9:07 AM, "Robert Wilton"  wrote:


Hi Kent,

There is also another Yang Mount related draft: draft-clemm-netmod-mount-03

Now, this draft doesn't directly address the RTG DT Arch team use-case,
and seems to cover two more complex problem scenarios (remote mount and
alias mount), but these do appear to be a valid mount use cases (e.g. I
think that it is used by OpenDaylight SDN controller), and I know that
there is at least one implementation of this draft.

So, I want to echo Eric Voit's comments that it would be good if
whatever basic YANG mount draft we converge on is able to be cleanly
extended to cover the more complex mount scenarios.

As such, if Alex Clemm or Eric Voit are willing, I think that it would
be useful if one of them could comment on how feasible it is to extend
either netmod-structual-mount or netmod-ysdl to cover the remote mount
and alias mount scenarios described in draft-clemm-netmod-mount-03.
Hence, if they agree, do you think that you would be able to add a 15
min slot to the agenda to cover this please?

Thanks,
Rob


On 03/02/2016 02:24, Kent Watsen wrote:

[Chair hat on]

Given the number of competing/complementing drafts involved, and the 
general lack of discussion on any of them, a virtual interim meeting might 
be an expedient way to proceed.  In fairness, we know that there has been 
some discussion, but it hasn’t been picked up yet in a big way, and now Lou 
has an updated draft.


The chairs discussed maybe scheduling one for a couple weeks from now, 
perhaps Thursday Feb 18 starting at 10am EST?   I'm thinking about this 
slot only since it worked for us for previously.  Is this a good time slot? 
 I assume to schedule for 2 hours, with a plan to end early if needed - 
makes sense? We also need to put together a proper agenda, perhaps the 
following?


   10 min: RTG DT YANG Arch team use-case summary
   20 min: draft-rtgyangdt-rtgwg-device-model
   20 min: draft-lhotka-netmod-ysdl
   20 min: draft-bjorklund-netmod-structural-mount
   50 min: general discussion or end early


We hope to schedule the meeting itself tomorrow or the next day, so please 
respond quickly to this email if possible.


Thanks,
Kent and Tom




On 2/2/16, 2:04 PM, "netmod on behalf of Lou Berger" 
 wrote:



I thought it would be worth summarizing what we're looking for in our
draft, draft-rtgyangdt-rtgwg-device-model-02 (note new version in case
you missed it) with respect to the draft-lhotka-netmod-ysdl and
draft-bjorklund-netmod-structural-mount drafts. This is just my view, so
my co-authors may wish to chime in and correct me.

I'd be interested in hearing from the authors of YSDL and
structural-mount, or anyone else for that matter, on how they see to
best meet these needs.

Here's what I think our draft needs:

1. that there be a mechanism that allows the incorporation (or
   'mounting') of the data model defined by one top-level module
   within another module.

   The implication here is that when information is instantiated
   for the parent model it is also instantiated for the
   incorporated/mounted model. In our case we expect to do this on
   list element creation. Both solutions drafts cover the path
   implications, so these are not repeated here.

2. that this mechanism allow identification of specific modules to
   be incorporated/mounted at time of module definition, i.e. that
   no additional module is needed to support 1. This doesn't
   preclude definition of such a module.

3. that this mechanism allow for a server to control (and
   identify) which modules are incorporated/mounted. (see Section
   3 LNE in our draft for an envisioned usage.)

4. that all capabilities that exist with the mounted module are
   available e.g. RPC operations and notifications.

5. while our primary requirement is for 'mounting' of top level
   modules, mounting of submodules may also be useful. (DT not draft
   driven.)

We make use of the above in sections 3 and 4 of rtgwg-device-model.  We
see having a solution as critical for the simplifications/flexibility
represented in the -02 version of our draft vs the -03 rev.  We don't
see wither solution draft as significantly different and just hope for a
standard solution as soon as possible.  (a draft-ietf-netmod solutions
draft on the topic by BA would be fantastic given the impact on routing
area -- even if it had to document two variations / alternative solutions.)

Again, this is just my opinion 

Re: [netmod] Yang mount / ysdl example use case

[Kent Watsen]

I was led to believe that the current set of drafts subsume 
draft-clemm-netmod-mount.  If that’s not true, then absolutely there should be 
a slot for that draft to be discussed as well.  Please advise.

Kent






On 2/3/16, 9:07 AM, "Robert Wilton"  wrote:

>Hi Kent,
>
>There is also another Yang Mount related draft: draft-clemm-netmod-mount-03
>
>Now, this draft doesn't directly address the RTG DT Arch team use-case, 
>and seems to cover two more complex problem scenarios (remote mount and 
>alias mount), but these do appear to be a valid mount use cases (e.g. I 
>think that it is used by OpenDaylight SDN controller), and I know that 
>there is at least one implementation of this draft.
>
>So, I want to echo Eric Voit's comments that it would be good if 
>whatever basic YANG mount draft we converge on is able to be cleanly 
>extended to cover the more complex mount scenarios.
>
>As such, if Alex Clemm or Eric Voit are willing, I think that it would 
>be useful if one of them could comment on how feasible it is to extend 
>either netmod-structual-mount or netmod-ysdl to cover the remote mount 
>and alias mount scenarios described in draft-clemm-netmod-mount-03.  
>Hence, if they agree, do you think that you would be able to add a 15 
>min slot to the agenda to cover this please?
>
>Thanks,
>Rob
>
>
>On 03/02/2016 02:24, Kent Watsen wrote:
>> [Chair hat on]
>>
>> Given the number of competing/complementing drafts involved, and the general 
>> lack of discussion on any of them, a virtual interim meeting might be an 
>> expedient way to proceed.  In fairness, we know that there has been some 
>> discussion, but it hasn’t been picked up yet in a big way, and now Lou has 
>> an updated draft.
>>
>> The chairs discussed maybe scheduling one for a couple weeks from now, 
>> perhaps Thursday Feb 18 starting at 10am EST?   I'm thinking about this slot 
>> only since it worked for us for previously.  Is this a good time slot?  I 
>> assume to schedule for 2 hours, with a plan to end early if needed - makes 
>> sense? We also need to put together a proper agenda, perhaps the 
>> following?
>>
>>10 min: RTG DT YANG Arch team use-case summary
>>20 min: draft-rtgyangdt-rtgwg-device-model
>>20 min: draft-lhotka-netmod-ysdl
>>20 min: draft-bjorklund-netmod-structural-mount
>>50 min: general discussion or end early
>>
>>
>> We hope to schedule the meeting itself tomorrow or the next day, so please 
>> respond quickly to this email if possible.
>>
>> Thanks,
>> Kent and Tom
>>
>>
>>
>>
>> On 2/2/16, 2:04 PM, "netmod on behalf of Lou Berger" 
>>  wrote:
>>
>>> I thought it would be worth summarizing what we're looking for in our
>>> draft, draft-rtgyangdt-rtgwg-device-model-02 (note new version in case
>>> you missed it) with respect to the draft-lhotka-netmod-ysdl and
>>> draft-bjorklund-netmod-structural-mount drafts. This is just my view, so
>>> my co-authors may wish to chime in and correct me.
>>>
>>> I'd be interested in hearing from the authors of YSDL and
>>> structural-mount, or anyone else for that matter, on how they see to
>>> best meet these needs.
>>>
>>> Here's what I think our draft needs:
>>>
>>> 1. that there be a mechanism that allows the incorporation (or
>>>'mounting') of the data model defined by one top-level module
>>>within another module.
>>>
>>>The implication here is that when information is instantiated
>>>for the parent model it is also instantiated for the
>>>incorporated/mounted model. In our case we expect to do this on
>>>list element creation. Both solutions drafts cover the path
>>>implications, so these are not repeated here.
>>>
>>> 2. that this mechanism allow identification of specific modules to
>>>be incorporated/mounted at time of module definition, i.e. that
>>>no additional module is needed to support 1. This doesn't
>>>preclude definition of such a module.
>>>
>>> 3. that this mechanism allow for a server to control (and
>>>identify) which modules are incorporated/mounted. (see Section
>>>3 LNE in our draft for an envisioned usage.)
>>>
>>> 4. that all capabilities that exist with the mounted module are
>>>available e.g. RPC operations and notifications.
>>>
>>> 5. while our primary requirement is for 'mounting' of top level
>>>modules, mounting of submodules may also be useful. (DT not draft
>>>driven.)
>>>
>>> We make use of the above in sections 3 and 4 of rtgwg-device-model.  We
>>> see having a solution as critical for the simplifications/flexibility
>>> represented in the -02 version of our draft vs the -03 rev.  We don't
>>> see wither solution draft as significantly different and just hope for a
>>> standard solution as soon as possible.  (a draft-ietf-netmod solutions
>>> draft on the topic by BA would be fantastic given the impact on routing
>>> area -- even if it had to document two variations / alternative solutions.)
>>>
>>> Again, this is just my opinion and my coauthors or other

Re: [netmod] draft-ietf-netmod-acl-model status

[Nadeau Thomas]

I don’t think we need to block on that. The 1.1 drafts are nearly done 
and ready to go according to Juergen, so we shouldn’t wait.  If something 
happens to change that causes something to break compilation-wise, that is 
easily fixed in the edit stages.   Also, since your document references those, 
it cannot be progressed ahead of them in the editor process.

—Tom


> On Feb 3, 2016:1:57 PM, at 1:57 PM, Dean Bogdanovic  
> wrote:
> 
> Tom,
> 
> One mailing list suggestion was using yang 1.1 construct. If we do it without 
> that suggestion, then the model doesn’t require update, but it is better with 
> this suggestion
> 
> Dean
> 
>> On Feb 3, 2016, at 7:52 PM, Nadeau Thomas  wrote:
>> 
>> 
>>  Will your model require any updates once 1.1 is ratified?  We don’t 
>> want to predicate having a bunch of models move forward on the 1.1 work 
>> moving forward. 
>> 
>>  —Tom
>> 
>> 
>>> On Feb 3, 2016:11:45 AM, at 11:45 AM, Dean Bogdanovic  
>>> wrote:
>>> 
>>> Tom,
>>> 
>>> We will publish ACL model requiring YANG 1.1 as per discussion on the list
>>> 
>>> Dean
>>> 
 On Feb 3, 2016, at 4:35 PM, Lisa (Yi) Huang  wrote:
 
 Tom,
 
 We discussed the review comments in the working group in offline meeting.
 Will publish a new draft to address comments. Thanks,
 
 Lisa
 
 On 2/1/16, 8:01 AM, "netmod on behalf of Nadeau Thomas"
  wrote:
 
> 
>   ACL Doc Authors:
> 
>   What is your status and plan to address the numerous technical comments
> that have arisen since the WG LC?
> I know there are for example, numerous detailed comments from Juergen and
> I think Elliot Lear posted some too.
> 
>   ‹Tom
> 
> ___
> 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] draft-ietf-netmod-acl-model status

[Dean Bogdanovic]

Tom,

One mailing list suggestion was using yang 1.1 construct. If we do it without 
that suggestion, then the model doesn’t require update, but it is better with 
this suggestion

Dean

> On Feb 3, 2016, at 7:52 PM, Nadeau Thomas  wrote:
> 
> 
>   Will your model require any updates once 1.1 is ratified?  We don’t 
> want to predicate having a bunch of models move forward on the 1.1 work 
> moving forward. 
> 
>   —Tom
> 
> 
>> On Feb 3, 2016:11:45 AM, at 11:45 AM, Dean Bogdanovic  
>> wrote:
>> 
>> Tom,
>> 
>> We will publish ACL model requiring YANG 1.1 as per discussion on the list
>> 
>> Dean
>> 
>>> On Feb 3, 2016, at 4:35 PM, Lisa (Yi) Huang  wrote:
>>> 
>>> Tom,
>>> 
>>> We discussed the review comments in the working group in offline meeting.
>>> Will publish a new draft to address comments. Thanks,
>>> 
>>> Lisa
>>> 
>>> On 2/1/16, 8:01 AM, "netmod on behalf of Nadeau Thomas"
>>>  wrote:
>>> 
 
ACL Doc Authors:
 
What is your status and plan to address the numerous technical comments
 that have arisen since the WG LC?
 I know there are for example, numerous detailed comments from Juergen and
 I think Elliot Lear posted some too.
 
‹Tom
 
 ___
 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] draft-ietf-netmod-acl-model status

[Dean Bogdanovic]

Tom,

We will publish ACL model requiring YANG 1.1 as per discussion on the list

Dean

> On Feb 3, 2016, at 4:35 PM, Lisa (Yi) Huang  wrote:
> 
> Tom,
> 
> We discussed the review comments in the working group in offline meeting.
> Will publish a new draft to address comments. Thanks,
> 
> Lisa
> 
> On 2/1/16, 8:01 AM, "netmod on behalf of Nadeau Thomas"
>  wrote:
> 
>> 
>>  ACL Doc Authors:
>> 
>>  What is your status and plan to address the numerous technical comments
>> that have arisen since the WG LC?
>> I know there are for example, numerous detailed comments from Juergen and
>> I think Elliot Lear posted some too.
>> 
>>  ‹Tom
>> 
>> ___
>> 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] draft-ietf-netmod-acl-model status

[Nadeau Thomas]

Will your model require any updates once 1.1 is ratified?  We don’t 
want to predicate having a bunch of models move forward on the 1.1 work moving 
forward. 

—Tom


> On Feb 3, 2016:11:45 AM, at 11:45 AM, Dean Bogdanovic  
> wrote:
> 
> Tom,
> 
> We will publish ACL model requiring YANG 1.1 as per discussion on the list
> 
> Dean
> 
>> On Feb 3, 2016, at 4:35 PM, Lisa (Yi) Huang  wrote:
>> 
>> Tom,
>> 
>> We discussed the review comments in the working group in offline meeting.
>> Will publish a new draft to address comments. Thanks,
>> 
>> Lisa
>> 
>> On 2/1/16, 8:01 AM, "netmod on behalf of Nadeau Thomas"
>>  wrote:
>> 
>>> 
>>> ACL Doc Authors:
>>> 
>>> What is your status and plan to address the numerous technical comments
>>> that have arisen since the WG LC?
>>> I know there are for example, numerous detailed comments from Juergen and
>>> I think Elliot Lear posted some too.
>>> 
>>> ‹Tom
>>> 
>>> ___
>>> 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] Where can I insert new YANG substatements?

[Martin Bjorklund]

Andy Bierman  wrote:
> On Wed, Feb 3, 2016 at 9:06 AM, Martin Bjorklund  wrote:
> 
> > Hi,
> >
> > William Ivory  wrote:
> > > Hi,
> > >
> > > My colleagues and I are looking for clarification of the last point in
> > > Section 10 of YANG 1.0:
> > >
> > > '   In statements that have any data definition statements as
> > >substatements, those data definition substatements MUST NOT be
> > >reordered.'
> > >
> > > We understand that existing statements must not be reordered in a new
> > > revision of a YANG module, but we're not clear if new statements may
> > > be inserted between existing statements, or must always come at the
> > > 'end' of a list or container definition.
> >
> > They can be inserted anywhere.
> >
> > As Lada pointed out, this should be clarified in 6020bis.  I will do:
> >
> > OLD:
> >
> >   In statements that have any data definition statements as
> >   substatements, those data definition substatements MUST NOT be
> >   reordered.
> >
> > NEW:
> >
> >   In statements that have any data definition statements as
> >   substatements, those data definition substatements MUST NOT be
> >   reordered.  If new data definition statements are added, they can be
> >   added anywhere between these substatement.
> >
> >
> >
> 
> This is not very good.
> You should explain exactly what interoperability is lost if a data-def-stmt
> changes relative order from 1 release to the next.

Note that this how YANG 1.0 works.

The reason for this rule is that the order does matter for rpc
input/output - they are encoded in XML in the order they are defined.

The rule could be limited to input/output, but groupings might be
used, so it would have to be input/output and groupings.


/martin


> If it is a MUST NOT,
> then this should obvious.  Given that list keys MUST be encoded first,
> and XML and JSON allow reordering anyway, it is a completely
> mystery to me why this CLR exists at all.
> 
> (BTW, it has no affect at all on default-stmt, bit-stmt, or enum-stmt,
> the only 3 YANG statements where schema-order is actually relevant).
> 
> 
> Andy
> 
> 
> 
> > > A specific example we're
> > > concerned with is where a grouping is used, and then later that
> > > grouping has an extra element added, but the new node could also be
> > > added directly.  Eg:
> > >
> > > Container foo {
> > > Leaf A
> > > Uses grouping B;
> > > Leaf C
> > > Leaf D
> > > }
> > >
> > > Is it valid in a new revision of the module to do the following, or
> > > must the order be A, B, C, D, E?  What if grouping B has gained a new
> > > statement?
> > >
> > > Container foo {
> > > Leaf A
> > > Uses grouping B;
> > > Leaf C
> > > Leaf E <  ADDED
> > > Leaf D
> > > }
> >
> > This is valid.
> >
> >
> > /martin
> >
> >
> > >
> > > Thanks,
> > >
> > > William
> > >
> > >
> >
> > ___
> > 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] Where can I insert new YANG substatements?

[Andy Bierman]

On Wed, Feb 3, 2016 at 9:06 AM, Martin Bjorklund  wrote:

> Hi,
>
> William Ivory  wrote:
> > Hi,
> >
> > My colleagues and I are looking for clarification of the last point in
> > Section 10 of YANG 1.0:
> >
> > '   In statements that have any data definition statements as
> >substatements, those data definition substatements MUST NOT be
> >reordered.'
> >
> > We understand that existing statements must not be reordered in a new
> > revision of a YANG module, but we're not clear if new statements may
> > be inserted between existing statements, or must always come at the
> > 'end' of a list or container definition.
>
> They can be inserted anywhere.
>
> As Lada pointed out, this should be clarified in 6020bis.  I will do:
>
> OLD:
>
>   In statements that have any data definition statements as
>   substatements, those data definition substatements MUST NOT be
>   reordered.
>
> NEW:
>
>   In statements that have any data definition statements as
>   substatements, those data definition substatements MUST NOT be
>   reordered.  If new data definition statements are added, they can be
>   added anywhere between these substatement.
>
>
>

This is not very good.
You should explain exactly what interoperability is lost if a data-def-stmt
changes relative order from 1 release to the next.  If it is a MUST NOT,
then this should obvious.  Given that list keys MUST be encoded first,
and XML and JSON allow reordering anyway, it is a completely
mystery to me why this CLR exists at all.

(BTW, it has no affect at all on default-stmt, bit-stmt, or enum-stmt,
the only 3 YANG statements where schema-order is actually relevant).


Andy



> > A specific example we're
> > concerned with is where a grouping is used, and then later that
> > grouping has an extra element added, but the new node could also be
> > added directly.  Eg:
> >
> > Container foo {
> > Leaf A
> > Uses grouping B;
> > Leaf C
> > Leaf D
> > }
> >
> > Is it valid in a new revision of the module to do the following, or
> > must the order be A, B, C, D, E?  What if grouping B has gained a new
> > statement?
> >
> > Container foo {
> > Leaf A
> > Uses grouping B;
> > Leaf C
> > Leaf E <  ADDED
> > Leaf D
> > }
>
> This is valid.
>
>
> /martin
>
>
> >
> > Thanks,
> >
> > William
> >
> >
>
> ___
> 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] Where can I insert new YANG substatements?

[William Ivory]

Hi Martin,

Thanks - that looks good to me.

William

-Original Message-
From: Martin Bjorklund [mailto:m...@tail-f.com] 
Sent: 03 February 2016 17:06
To: William Ivory 
Cc: netmod@ietf.org
Subject: Re: [netmod] Where can I insert new YANG substatements?

Hi,

William Ivory  wrote:
> Hi,
> 
> My colleagues and I are looking for clarification of the last point in 
> Section 10 of YANG 1.0:
> 
> '   In statements that have any data definition statements as
>substatements, those data definition substatements MUST NOT be
>reordered.'
> 
> We understand that existing statements must not be reordered in a new 
> revision of a YANG module, but we're not clear if new statements may 
> be inserted between existing statements, or must always come at the 
> 'end' of a list or container definition.

They can be inserted anywhere.

As Lada pointed out, this should be clarified in 6020bis.  I will do:

OLD:

  In statements that have any data definition statements as
  substatements, those data definition substatements MUST NOT be
  reordered.

NEW:

  In statements that have any data definition statements as
  substatements, those data definition substatements MUST NOT be
  reordered.  If new data definition statements are added, they can be
  added anywhere between these substatement.


> A specific example we're
> concerned with is where a grouping is used, and then later that 
> grouping has an extra element added, but the new node could also be 
> added directly.  Eg:
> 
> Container foo {
> Leaf A
> Uses grouping B;
> Leaf C
> Leaf D
> }
> 
> Is it valid in a new revision of the module to do the following, or 
> must the order be A, B, C, D, E?  What if grouping B has gained a new 
> statement?
> 
> Container foo {
> Leaf A
> Uses grouping B;
> Leaf C
> Leaf E <  ADDED
> Leaf D
> }

This is valid.


/martin


> 
> Thanks,
> 
> William
> 
> 

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

Re: [netmod] Where can I insert new YANG substatements?

[Martin Bjorklund]

Hi,

William Ivory  wrote:
> Hi,
> 
> My colleagues and I are looking for clarification of the last point in
> Section 10 of YANG 1.0:
> 
> '   In statements that have any data definition statements as
>substatements, those data definition substatements MUST NOT be
>reordered.'
> 
> We understand that existing statements must not be reordered in a new
> revision of a YANG module, but we're not clear if new statements may
> be inserted between existing statements, or must always come at the
> 'end' of a list or container definition.

They can be inserted anywhere.

As Lada pointed out, this should be clarified in 6020bis.  I will do:

OLD:

  In statements that have any data definition statements as
  substatements, those data definition substatements MUST NOT be
  reordered.

NEW:

  In statements that have any data definition statements as
  substatements, those data definition substatements MUST NOT be
  reordered.  If new data definition statements are added, they can be
  added anywhere between these substatement.


> A specific example we're
> concerned with is where a grouping is used, and then later that
> grouping has an extra element added, but the new node could also be
> added directly.  Eg:
> 
> Container foo {
> Leaf A
> Uses grouping B;
> Leaf C
> Leaf D
> }
> 
> Is it valid in a new revision of the module to do the following, or
> must the order be A, B, C, D, E?  What if grouping B has gained a new
> statement?
> 
> Container foo {
> Leaf A
> Uses grouping B;
> Leaf C
> Leaf E <  ADDED
> Leaf D
> }

This is valid.


/martin


> 
> Thanks,
> 
> William
> 
> 

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

Re: [netmod] AD review: draft-ietf-netmod-yang-json-07

[Martin Bjorklund]

Ladislav Lhotka  wrote:
> 
> > On 03 Feb 2016, at 14:37, Benoit Claise  wrote:
> > 
> > Hi Lada,
> >> 
>  I agree with Juergen that 6087bis should distinguish between complete
>  example modules and short module snippets that are used for explaining a
>  certain YANG language or encoding issue. If you look at this particular
>  example, then changing the JSON document on p. 6 to
>  
> {
>   "example-foomod:top": {
> "foo": 54,
> "example-barmod:bar": true
>   }
> }
>  
>  would IMO just add noise and blur the message the example is supposed to
>  convey.
> >>> So please fix the text in 6087bis.
> >>> Until it's done, I'll stick to the current rule.
> >> I don't want to be excessively bureaucratic but, strictly
> speaking, current rules are those of RFC 6087 that contains no such
> requirement, so we should be OK for now. And I think there is enough
> consensus
> > so Jürgen and you?
> 
> I guess Martin as well, given that 6020bis doesn't follow that rule.

I agree that not all modules must compile, e.g. we have things like:

  module example-foo {
 ...
 container bar { ... }
  }

Having said that, in the upcoming version of 6020bis, I have changed
things like "module acme-system" to "module example-system".



/martin



> 
> Lada
> 
> >> to change the corresponding 6087bis text - after all, 6020bis also has 
> >> example modules whose names don't start with "example-".
> > I'll still have to review it and that will be one of my comments, for sure. 
> > Consistency first.
> > 
> > Regards ,Benoit
> > 
> 
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> 
> 
> 
> 
> ___
> 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] draft-ietf-netmod-acl-model status

[Lisa (Yi) Huang]

Tom,

We discussed the review comments in the working group in offline meeting.
Will publish a new draft to address comments. Thanks,

Lisa

On 2/1/16, 8:01 AM, "netmod on behalf of Nadeau Thomas"
 wrote:

>
>   ACL Doc Authors:
>
>   What is your status and plan to address the numerous technical comments
>that have arisen since the WG LC?
>I know there are for example, numerous detailed comments from Juergen and
>I think Elliot Lear posted some too.
>
>   ‹Tom
>
>___
>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 mount / ysdl example use case

[Kent Watsen]

Yes, the meeting times are in timezone EST.   Doodle should display the 
timezone and let you set your own.  

Kent

> On Feb 3, 2016, at 9:48 AM, Acee Lindem (acee)  wrote:
> 
> Kent - I’m assuming the poll is EST given that is where you are located.
> Thanks,
> Acee
> 
>> On 2/3/16, 8:50 AM, "Kent Watsen"  wrote:
>> 
>> 
>> No problem, I just created another poll for the following week:
>> 
>>http://doodle.com/poll/byugp4umy2m4fwdz
>> 
>> The first poll is now deleted.  For the couple of folks that put values
>> there, please fill in your values again on this new poll.
>> 
>> Kent
>> 
>> 
>> 
>> 
>> 
>>> On 2/3/16, 6:59 AM, "Acee Lindem (acee)"  wrote:
>>> 
>>> 
>>> 
 On 2/3/16, 1:18 AM, "Ladislav Lhotka"  wrote:
 
 
> On 03 Feb 2016, at 03:24, Kent Watsen  wrote:
> 
> 
> [Chair hat on]
> 
> Given the number of competing/complementing drafts involved, and the
> general lack of discussion on any of them, a virtual interim meeting
> might be an expedient way to proceed.  In fairness, we know that there
> has been some discussion, but it hasn’t been picked up yet in a big
> way,
> and now Lou has an updated draft.
> 
> The chairs discussed maybe scheduling one for a couple weeks from now,
> perhaps Thursday Feb 18 starting at 10am EST?   I'm thinking
 
 Thursday at this time doesn't suit me very well, Monday till Wednesday
 of
 that week are OK.
>>> 
>>> I’m out the entire week of Feb 14th.
>>> 
>>> Thanks,
>>> Acee 
>>> 
>>> 
 
 Lada
 
> about this slot only since it worked for us for previously.  Is this
> a
> good time slot?  I assume to schedule for 2 hours, with a plan to end
> early if needed - makes sense? We also need to put together a
> proper
> agenda, perhaps the following?
> 
> 10 min: RTG DT YANG Arch team use-case summary
> 20 min: draft-rtgyangdt-rtgwg-device-model
> 20 min: draft-lhotka-netmod-ysdl
> 20 min: draft-bjorklund-netmod-structural-mount
> 50 min: general discussion or end early
> 
> 
> We hope to schedule the meeting itself tomorrow or the next day, so
> please respond quickly to this email if possible.
> 
> Thanks,
> Kent and Tom
> 
> 
> 
> 
> On 2/2/16, 2:04 PM, "netmod on behalf of Lou Berger"
>  wrote:
> 
>> 
>> I thought it would be worth summarizing what we're looking for in our
>> draft, draft-rtgyangdt-rtgwg-device-model-02 (note new version in
>> case
>> you missed it) with respect to the draft-lhotka-netmod-ysdl and
>> draft-bjorklund-netmod-structural-mount drafts. This is just my view,
>> so
>> my co-authors may wish to chime in and correct me.
>> 
>> I'd be interested in hearing from the authors of YSDL and
>> structural-mount, or anyone else for that matter, on how they see to
>> best meet these needs.
>> 
>> Here's what I think our draft needs:
>> 
>> 1. that there be a mechanism that allows the incorporation (or
>> 'mounting') of the data model defined by one top-level module
>> within another module.
>> 
>> The implication here is that when information is instantiated
>> for the parent model it is also instantiated for the
>> incorporated/mounted model. In our case we expect to do this on
>> list element creation. Both solutions drafts cover the path
>> implications, so these are not repeated here.
>> 
>> 2. that this mechanism allow identification of specific modules to
>> be incorporated/mounted at time of module definition, i.e. that
>> no additional module is needed to support 1. This doesn't
>> preclude definition of such a module.
>> 
>> 3. that this mechanism allow for a server to control (and
>> identify) which modules are incorporated/mounted. (see Section
>> 3 LNE in our draft for an envisioned usage.)
>> 
>> 4. that all capabilities that exist with the mounted module are
>> available e.g. RPC operations and notifications.
>> 
>> 5. while our primary requirement is for 'mounting' of top level
>> modules, mounting of submodules may also be useful. (DT not draft
>> driven.)
>> 
>> We make use of the above in sections 3 and 4 of rtgwg-device-model.
>> We
>> see having a solution as critical for the simplifications/flexibility
>> represented in the -02 version of our draft vs the -03 rev.  We don't
>> see wither solution draft as significantly different and just hope
>> for
>> a
>> standard solution as soon as possible.  (a draft-ietf-netmod
>> solutions
>> draft on the topic by BA would be fantastic given the impact on
>> routing
>> area -- even if it had to document two variations / alternative
>> solutions.)
>> 
>> Again, this is just my opinion and my coauthors or others on the rtg
>> area yang DT may choose to chime in.

Re: [netmod] Yang mount / ysdl example use case

[Acee Lindem (acee)]

Kent - I’m assuming the poll is EST given that is where you are located.
Thanks,
Acee

On 2/3/16, 8:50 AM, "Kent Watsen"  wrote:

>
>No problem, I just created another poll for the following week:
>
>   http://doodle.com/poll/byugp4umy2m4fwdz
>
>The first poll is now deleted.  For the couple of folks that put values
>there, please fill in your values again on this new poll.
>
>Kent
>
>
>
>
>
>On 2/3/16, 6:59 AM, "Acee Lindem (acee)"  wrote:
>
>>
>>
>>On 2/3/16, 1:18 AM, "Ladislav Lhotka"  wrote:
>>
>>>
 On 03 Feb 2016, at 03:24, Kent Watsen  wrote:
 
 
 [Chair hat on]
 
 Given the number of competing/complementing drafts involved, and the
general lack of discussion on any of them, a virtual interim meeting
might be an expedient way to proceed.  In fairness, we know that there
has been some discussion, but it hasn’t been picked up yet in a big
way,
and now Lou has an updated draft.
 
 The chairs discussed maybe scheduling one for a couple weeks from now,
perhaps Thursday Feb 18 starting at 10am EST?   I'm thinking
>>>
>>>Thursday at this time doesn't suit me very well, Monday till Wednesday
>>>of
>>>that week are OK.
>>
>>I’m out the entire week of Feb 14th.
>>
>>Thanks,
>>Acee 
>>
>>
>>>
>>>Lada
>>>
  about this slot only since it worked for us for previously.  Is this
a
good time slot?  I assume to schedule for 2 hours, with a plan to end
early if needed - makes sense? We also need to put together a
proper
agenda, perhaps the following?
 
  10 min: RTG DT YANG Arch team use-case summary
  20 min: draft-rtgyangdt-rtgwg-device-model
  20 min: draft-lhotka-netmod-ysdl
  20 min: draft-bjorklund-netmod-structural-mount
  50 min: general discussion or end early
 
 
 We hope to schedule the meeting itself tomorrow or the next day, so
please respond quickly to this email if possible.
 
 Thanks,
 Kent and Tom
 
 
 
 
 On 2/2/16, 2:04 PM, "netmod on behalf of Lou Berger"
 wrote:
 
> 
> I thought it would be worth summarizing what we're looking for in our
> draft, draft-rtgyangdt-rtgwg-device-model-02 (note new version in
>case
> you missed it) with respect to the draft-lhotka-netmod-ysdl and
> draft-bjorklund-netmod-structural-mount drafts. This is just my view,
>so
> my co-authors may wish to chime in and correct me.
> 
> I'd be interested in hearing from the authors of YSDL and
> structural-mount, or anyone else for that matter, on how they see to
> best meet these needs.
> 
> Here's what I think our draft needs:
> 
> 1. that there be a mechanism that allows the incorporation (or
>  'mounting') of the data model defined by one top-level module
>  within another module.
> 
>  The implication here is that when information is instantiated
>  for the parent model it is also instantiated for the
>  incorporated/mounted model. In our case we expect to do this on
>  list element creation. Both solutions drafts cover the path
>  implications, so these are not repeated here.
> 
> 2. that this mechanism allow identification of specific modules to
>  be incorporated/mounted at time of module definition, i.e. that
>  no additional module is needed to support 1. This doesn't
>  preclude definition of such a module.
> 
> 3. that this mechanism allow for a server to control (and
>  identify) which modules are incorporated/mounted. (see Section
>  3 LNE in our draft for an envisioned usage.)
> 
> 4. that all capabilities that exist with the mounted module are
>  available e.g. RPC operations and notifications.
> 
> 5. while our primary requirement is for 'mounting' of top level
>  modules, mounting of submodules may also be useful. (DT not draft
>  driven.)
> 
> We make use of the above in sections 3 and 4 of rtgwg-device-model.
>We
> see having a solution as critical for the simplifications/flexibility
> represented in the -02 version of our draft vs the -03 rev.  We don't
> see wither solution draft as significantly different and just hope
>for
>a
> standard solution as soon as possible.  (a draft-ietf-netmod
>solutions
> draft on the topic by BA would be fantastic given the impact on
>routing
> area -- even if it had to document two variations / alternative
>solutions.)
> 
> Again, this is just my opinion and my coauthors or others on the rtg
> area yang DT may choose to chime in.
> 
> Lou
> 
> 
> 
> ___
> 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
ht

Re: [netmod] AD review: draft-ietf-netmod-yang-json-07

[Ladislav Lhotka]

> On 03 Feb 2016, at 15:35, Martin Bjorklund  wrote:
> 
> Benoit Claise  wrote:
>> Hi Lada,
>> 
>> Thanks for the quick reply.
>>> Hi Benoit,
>>> 
>>> thank you for the review, please see my responses inline.
>>> 
>>> Benoit Claise  writes:
> 
> [...]
> 
 o  identity,
 
 There is no identity definition in the RFC 6020 terminology section.
>>> Maybe it is an omission in 6020bis?
>> Ok, let's fix it in 6020bis then.
> 
> Ok.  First I wrote:
> 
> o  identity: A globally unique, abstract, and untyped identity.
> 
> But this is kind of recursive...
> 
> o  identity: A globally unique, abstract, and untyped label.
> 
> Any other proposal?

s/label/name/ ?

Lada

> 
> 
> 
> /martin
> 
> 
> 
> 
> 
> 
> 
>>> 
 -
module foomod {
 
   namespace"http://example.com/foomod";;
 
   prefix "foo";
 
   container top {
 leaf foo {
   type uint8;
 }
   }
 }
 
 Use "example-" in the module name, as mentioned
 inhttps://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-05:
 
 Example modules are non-normative, and SHOULD be named with the
 prefix "example-".
 
 Same remark for module barmod (and btw, pay attention to the "import
 foomod") and module exmod
>>> I agree with Juergen that 6087bis should distinguish between complete
>>> example modules and short module snippets that are used for explaining
>>> a
>>> certain YANG language or encoding issue. If you look at this
>>> particular
>>> example, then changing the JSON document on p. 6 to
>>> 
>>>{
>>>  "example-foomod:top": {
>>>"foo": 54,
>>>"example-barmod:bar": true
>>>  }
>>>}
>>> 
>>> would IMO just add noise and blur the message the example is supposed
>>> to
>>> convey.
>> So please fix the text in 6087bis.
>> Until it's done, I'll stick to the current rule.
>> 
>> Regards, Benoit
>> 
>> ___
>> 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] AD review: draft-ietf-netmod-yang-json-07

[Martin Bjorklund]

Benoit Claise  wrote:
> Hi Lada,
> 
> Thanks for the quick reply.
> > Hi Benoit,
> >
> > thank you for the review, please see my responses inline.
> >
> > Benoit Claise  writes:

[...]

> >>  o  identity,
> >>
> >> There is no identity definition in the RFC 6020 terminology section.
> > Maybe it is an omission in 6020bis?
> Ok, let's fix it in 6020bis then.

Ok.  First I wrote:

 o  identity: A globally unique, abstract, and untyped identity.

But this is kind of recursive...

 o  identity: A globally unique, abstract, and untyped label.

Any other proposal?



/martin







> >
> >> -
> >> module foomod {
> >>
> >>namespace"http://example.com/foomod";;
> >>
> >>prefix "foo";
> >>
> >>container top {
> >>  leaf foo {
> >>type uint8;
> >>  }
> >>}
> >>  }
> >>
> >> Use "example-" in the module name, as mentioned
> >> inhttps://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-05:
> >>
> >>  Example modules are non-normative, and SHOULD be named with the
> >>  prefix "example-".
> >>
> >> Same remark for module barmod (and btw, pay attention to the "import
> >> foomod") and module exmod
> > I agree with Juergen that 6087bis should distinguish between complete
> > example modules and short module snippets that are used for explaining
> > a
> > certain YANG language or encoding issue. If you look at this
> > particular
> > example, then changing the JSON document on p. 6 to
> >
> > {
> >   "example-foomod:top": {
> > "foo": 54,
> > "example-barmod:bar": true
> >   }
> > }
> >
> > would IMO just add noise and blur the message the example is supposed
> > to
> > convey.
> So please fix the text in 6087bis.
> Until it's done, I'll stick to the current rule.
> 
> Regards, Benoit
> 
> ___
> 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 mount / ysdl example use case

[Robert Wilton]

Hi Kent,

There is also another Yang Mount related draft: draft-clemm-netmod-mount-03

Now, this draft doesn't directly address the RTG DT Arch team use-case, 
and seems to cover two more complex problem scenarios (remote mount and 
alias mount), but these do appear to be a valid mount use cases (e.g. I 
think that it is used by OpenDaylight SDN controller), and I know that 
there is at least one implementation of this draft.


So, I want to echo Eric Voit's comments that it would be good if 
whatever basic YANG mount draft we converge on is able to be cleanly 
extended to cover the more complex mount scenarios.


As such, if Alex Clemm or Eric Voit are willing, I think that it would 
be useful if one of them could comment on how feasible it is to extend 
either netmod-structual-mount or netmod-ysdl to cover the remote mount 
and alias mount scenarios described in draft-clemm-netmod-mount-03.  
Hence, if they agree, do you think that you would be able to add a 15 
min slot to the agenda to cover this please?


Thanks,
Rob


On 03/02/2016 02:24, Kent Watsen wrote:

[Chair hat on]

Given the number of competing/complementing drafts involved, and the general 
lack of discussion on any of them, a virtual interim meeting might be an 
expedient way to proceed.  In fairness, we know that there has been some 
discussion, but it hasn’t been picked up yet in a big way, and now Lou has an 
updated draft.

The chairs discussed maybe scheduling one for a couple weeks from now, perhaps 
Thursday Feb 18 starting at 10am EST?   I'm thinking about this slot only since 
it worked for us for previously.  Is this a good time slot?  I assume to 
schedule for 2 hours, with a plan to end early if needed - makes sense? We 
also need to put together a proper agenda, perhaps the following?

   10 min: RTG DT YANG Arch team use-case summary
   20 min: draft-rtgyangdt-rtgwg-device-model
   20 min: draft-lhotka-netmod-ysdl
   20 min: draft-bjorklund-netmod-structural-mount
   50 min: general discussion or end early


We hope to schedule the meeting itself tomorrow or the next day, so please 
respond quickly to this email if possible.

Thanks,
Kent and Tom




On 2/2/16, 2:04 PM, "netmod on behalf of Lou Berger"  wrote:


I thought it would be worth summarizing what we're looking for in our
draft, draft-rtgyangdt-rtgwg-device-model-02 (note new version in case
you missed it) with respect to the draft-lhotka-netmod-ysdl and
draft-bjorklund-netmod-structural-mount drafts. This is just my view, so
my co-authors may wish to chime in and correct me.

I'd be interested in hearing from the authors of YSDL and
structural-mount, or anyone else for that matter, on how they see to
best meet these needs.

Here's what I think our draft needs:

1. that there be a mechanism that allows the incorporation (or
   'mounting') of the data model defined by one top-level module
   within another module.

   The implication here is that when information is instantiated
   for the parent model it is also instantiated for the
   incorporated/mounted model. In our case we expect to do this on
   list element creation. Both solutions drafts cover the path
   implications, so these are not repeated here.

2. that this mechanism allow identification of specific modules to
   be incorporated/mounted at time of module definition, i.e. that
   no additional module is needed to support 1. This doesn't
   preclude definition of such a module.

3. that this mechanism allow for a server to control (and
   identify) which modules are incorporated/mounted. (see Section
   3 LNE in our draft for an envisioned usage.)

4. that all capabilities that exist with the mounted module are
   available e.g. RPC operations and notifications.

5. while our primary requirement is for 'mounting' of top level
   modules, mounting of submodules may also be useful. (DT not draft
   driven.)

We make use of the above in sections 3 and 4 of rtgwg-device-model.  We
see having a solution as critical for the simplifications/flexibility
represented in the -02 version of our draft vs the -03 rev.  We don't
see wither solution draft as significantly different and just hope for a
standard solution as soon as possible.  (a draft-ietf-netmod solutions
draft on the topic by BA would be fantastic given the impact on routing
area -- even if it had to document two variations / alternative solutions.)

Again, this is just my opinion and my coauthors or others on the rtg
area yang DT may choose to chime in.

Lou



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

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


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

Re: [netmod] Yang mount / ysdl example use case

[Kent Watsen]

No problem, I just created another poll for the following week:

http://doodle.com/poll/byugp4umy2m4fwdz

The first poll is now deleted.  For the couple of folks that put values there, 
please fill in your values again on this new poll.

Kent





On 2/3/16, 6:59 AM, "Acee Lindem (acee)"  wrote:

>
>
>On 2/3/16, 1:18 AM, "Ladislav Lhotka"  wrote:
>
>>
>>> On 03 Feb 2016, at 03:24, Kent Watsen  wrote:
>>> 
>>> 
>>> [Chair hat on]
>>> 
>>> Given the number of competing/complementing drafts involved, and the
>>>general lack of discussion on any of them, a virtual interim meeting
>>>might be an expedient way to proceed.  In fairness, we know that there
>>>has been some discussion, but it hasn’t been picked up yet in a big way,
>>>and now Lou has an updated draft.
>>> 
>>> The chairs discussed maybe scheduling one for a couple weeks from now,
>>>perhaps Thursday Feb 18 starting at 10am EST?   I'm thinking
>>
>>Thursday at this time doesn't suit me very well, Monday till Wednesday of
>>that week are OK.
>
>I’m out the entire week of Feb 14th.
>
>Thanks,
>Acee 
>
>
>>
>>Lada
>>
>>>  about this slot only since it worked for us for previously.  Is this a
>>>good time slot?  I assume to schedule for 2 hours, with a plan to end
>>>early if needed - makes sense? We also need to put together a proper
>>>agenda, perhaps the following?
>>> 
>>>  10 min: RTG DT YANG Arch team use-case summary
>>>  20 min: draft-rtgyangdt-rtgwg-device-model
>>>  20 min: draft-lhotka-netmod-ysdl
>>>  20 min: draft-bjorklund-netmod-structural-mount
>>>  50 min: general discussion or end early
>>> 
>>> 
>>> We hope to schedule the meeting itself tomorrow or the next day, so
>>>please respond quickly to this email if possible.
>>> 
>>> Thanks,
>>> Kent and Tom
>>> 
>>> 
>>> 
>>> 
>>> On 2/2/16, 2:04 PM, "netmod on behalf of Lou Berger"
>>> wrote:
>>> 
 
 I thought it would be worth summarizing what we're looking for in our
 draft, draft-rtgyangdt-rtgwg-device-model-02 (note new version in case
 you missed it) with respect to the draft-lhotka-netmod-ysdl and
 draft-bjorklund-netmod-structural-mount drafts. This is just my view,
so
 my co-authors may wish to chime in and correct me.
 
 I'd be interested in hearing from the authors of YSDL and
 structural-mount, or anyone else for that matter, on how they see to
 best meet these needs.
 
 Here's what I think our draft needs:
 
 1. that there be a mechanism that allows the incorporation (or
  'mounting') of the data model defined by one top-level module
  within another module.
 
  The implication here is that when information is instantiated
  for the parent model it is also instantiated for the
  incorporated/mounted model. In our case we expect to do this on
  list element creation. Both solutions drafts cover the path
  implications, so these are not repeated here.
 
 2. that this mechanism allow identification of specific modules to
  be incorporated/mounted at time of module definition, i.e. that
  no additional module is needed to support 1. This doesn't
  preclude definition of such a module.
 
 3. that this mechanism allow for a server to control (and
  identify) which modules are incorporated/mounted. (see Section
  3 LNE in our draft for an envisioned usage.)
 
 4. that all capabilities that exist with the mounted module are
  available e.g. RPC operations and notifications.
 
 5. while our primary requirement is for 'mounting' of top level
  modules, mounting of submodules may also be useful. (DT not draft
  driven.)
 
 We make use of the above in sections 3 and 4 of rtgwg-device-model.  We
 see having a solution as critical for the simplifications/flexibility
 represented in the -02 version of our draft vs the -03 rev.  We don't
 see wither solution draft as significantly different and just hope for
a
 standard solution as soon as possible.  (a draft-ietf-netmod solutions
 draft on the topic by BA would be fantastic given the impact on routing
 area -- even if it had to document two variations / alternative
solutions.)
 
 Again, this is just my opinion and my coauthors or others on the rtg
 area yang DT may choose to chime in.
 
 Lou
 
 
 
 ___
 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] AD review: draft-ietf-netmod-yang-json-07

[Ladislav Lhotka]

> On 03 Feb 2016, at 14:37, Benoit Claise  wrote:
> 
> Hi Lada,
>> 
 I agree with Juergen that 6087bis should distinguish between complete
 example modules and short module snippets that are used for explaining a
 certain YANG language or encoding issue. If you look at this particular
 example, then changing the JSON document on p. 6 to
 
{
  "example-foomod:top": {
"foo": 54,
"example-barmod:bar": true
  }
}
 
 would IMO just add noise and blur the message the example is supposed to
 convey.
>>> So please fix the text in 6087bis.
>>> Until it's done, I'll stick to the current rule.
>> I don't want to be excessively bureaucratic but, strictly speaking, current 
>> rules are those of RFC 6087 that contains no such requirement, so we should 
>> be OK for now. And I think there is enough consensus
> so Jürgen and you?

I guess Martin as well, given that 6020bis doesn't follow that rule.

Lada

>> to change the corresponding 6087bis text - after all, 6020bis also has 
>> example modules whose names don't start with "example-".
> I'll still have to review it and that will be one of my comments, for sure. 
> Consistency first.
> 
> Regards ,Benoit
> 

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




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

Re: [netmod] AD review: draft-ietf-netmod-yang-json-07

[Benoit Claise]

Hi Lada,



I agree with Juergen that 6087bis should distinguish between complete
example modules and short module snippets that are used for explaining a
certain YANG language or encoding issue. If you look at this particular
example, then changing the JSON document on p. 6 to

{
  "example-foomod:top": {
"foo": 54,
"example-barmod:bar": true
  }
}

would IMO just add noise and blur the message the example is supposed to
convey.

So please fix the text in 6087bis.
Until it's done, I'll stick to the current rule.

I don't want to be excessively bureaucratic but, strictly speaking, current 
rules are those of RFC 6087 that contains no such requirement, so we should be 
OK for now. And I think there is enough consensus

so Jürgen and you?

to change the corresponding 6087bis text - after all, 6020bis also has example modules 
whose names don't start with "example-".
I'll still have to review it and that will be one of my comments, for 
sure. Consistency first.


Regards ,Benoit

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

Re: [netmod] AD review: draft-ietf-netmod-yang-json-07

[Ladislav Lhotka]

> On 03 Feb 2016, at 13:58, Benoit Claise  wrote:
> 
> Hi Lada,
> 
> Thanks for the quick reply.
>> Hi Benoit,
>> 
>> thank you for the review, please see my responses inline.
>> 
>> Benoit Claise  writes:
>> 
>>> Dear all,
>>> 
>>> I understood from the chairs that draft-ietf-netmod-yang-json is now
>>> ready and that the write-up will be completed end of this week.
>>> In order to speed up the publication, here is my AD review.
>>> 
>>> - Editorial:
>>> 
>>> This document defines encoding rules for representing configuration,
>>> state data, RPC operation or action input and output parameters, and
>>> notifications defined using YANG as JavaScript Object Notation (JSON)
>>> text.
>>> 
>>> "RPC operation or action input and output parameters"
>>> ", or ... and, " it's always complicated.
>>> Why not only "RPC operation or action"?
>> Because we aren't encoding operations, just their parameters.
> Good point.
>> 
>>> At the very minimum "input and output parameters" to "input/output
>>> parameters"
>> OK, so how about using just "parameters of RPC operations or actions" in
>> the abstract, and "input/output parameters of RPC operations or actions"
>> elsewhere?
> Sure.

Done.

>> 
>>> Same remark for section 1.1
>>> 
>>> The specification of YANG 1.1 data modelling language
>>> [I-D.ietf-netmod-rfc6020bis
>>> ]
>>>  defines only XML encoding for data
>>> instances, i.e., contents of configuration datastores, state data,
>>> RPC operation or action input and output parameters, and event
>>> notifications.
>>> 
>>> If you want to extend, also fine.
>>> 
>>> The specification of YANG 1.1 data modelling language
>>> [I-D.ietf-netmod-rfc6020bis
>>> ]
>>>  defines only XML encoding for data
>>> instances, i.e., contents of configuration datastores, state data,
>>> RPC operation input and output parameters, action input and output
>>> parameters, and event notifications.
>>> 
>>> Btw, "RPC", "action" and "input and output parameters" are only
>>> mentioned in the abstract and this introduction, not anymore in the body
>>> of the document. There is nothing specific to these worth noting? Not
>>> even an example?
>> This document is about encoding YANG data nodes, and the rules are the
>> same for any data tree.
> Not worth mentioning something such as
> " There is nothing specific to input and output parameters compared to any 
> other data tree..."?

OK, I'll add such a note.

...

>> I agree with Juergen that 6087bis should distinguish between complete
>> example modules and short module snippets that are used for explaining a
>> certain YANG language or encoding issue. If you look at this particular
>> example, then changing the JSON document on p. 6 to
>> 
>>{
>>  "example-foomod:top": {
>>"foo": 54,
>>"example-barmod:bar": true
>>  }
>>}
>> 
>> would IMO just add noise and blur the message the example is supposed to
>> convey.
> So please fix the text in 6087bis.
> Until it's done, I'll stick to the current rule.

I don't want to be excessively bureaucratic but, strictly speaking, current 
rules are those of RFC 6087 that contains no such requirement, so we should be 
OK for now. And I think there is enough consensus to change the corresponding 
6087bis text - after all, 6020bis also has example modules whose names don't 
start with "example-".

Thanks, Lada

> 
> Regards, Benoit

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




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

Re: [netmod] AD review: draft-ietf-netmod-yang-json-07

[Benoit Claise]

Hi Lada,

Thanks for the quick reply.

Hi Benoit,

thank you for the review, please see my responses inline.

Benoit Claise  writes:


Dear all,

I understood from the chairs that draft-ietf-netmod-yang-json is now
ready and that the write-up will be completed end of this week.
In order to speed up the publication, here is my AD review.

- Editorial:

 This document defines encoding rules for representing configuration,
 state data, RPC operation or action input and output parameters, and
 notifications defined using YANG as JavaScript Object Notation (JSON)
 text.

"RPC operation or action input and output parameters"
", or ... and, " it's always complicated.
Why not only "RPC operation or action"?

Because we aren't encoding operations, just their parameters.

Good point.



At the very minimum "input and output parameters" to "input/output
parameters"

OK, so how about using just "parameters of RPC operations or actions" in
the abstract, and "input/output parameters of RPC operations or actions"
elsewhere?

Sure.



Same remark for section 1.1

 The specification of YANG 1.1 data modelling language
 [I-D.ietf-netmod-rfc6020bis
]
 defines only XML encoding for data
 instances, i.e., contents of configuration datastores, state data,
 RPC operation or action input and output parameters, and event
 notifications.

If you want to extend, also fine.

 The specification of YANG 1.1 data modelling language
 [I-D.ietf-netmod-rfc6020bis
]
 defines only XML encoding for data
 instances, i.e., contents of configuration datastores, state data,
 RPC operation input and output parameters, action input and output
 parameters, and event notifications.

Btw, "RPC", "action" and "input and output parameters" are only
mentioned in the abstract and this introduction, not anymore in the body
of the document. There is nothing specific to these worth noting? Not
even an example?

This document is about encoding YANG data nodes, and the rules are the
same for any data tree.

Not worth mentioning something such as
" There is nothing specific to input and output parameters compared to 
any other data tree..."?

Encoding of operations or notifications is a
subject for a protocol spec, and RESTCONF does provide examples.


- Editorial

In the introduction, you might want to complete the last sentence

NEW:
 The specification of YANG 1.1 data modelling language
 [I-D.ietf-netmod-rfc6020bis
]
 defines only XML encoding for data
 instances, i.e., contents of configuration datastores, state data,
 RPC operation or action input and output parameters, and event
 notifications.  The aim of this document is to define rules for
 encoding the same data as JavaScript Object Notation (JSON)
 text [RFC7159 ].

NEW:
 The specification of YANG 1.1 data modelling language
 [I-D.ietf-netmod-rfc6020bis
]
 defines only XML encoding for data
 instances, i.e., contents of configuration datastores, state data,
 RPC operation or action input and output parameters, and event
 notifications.  The aim of this document is to define rules for
 encoding the same data as JavaScript Object Notation (JSON)
 text [RFC7159 ], most precisely the 
Internet JSON (I-JSON) restricted
 profile [RFC7493 ].

I would say that for the introduction the more general term (JSON) is
appropriate, the reasons for sticking to I-JSON are explained later. In
fact, this document specifies a profile that's even more restricted than
I-JSON.

Fair enough.




-
section 2:

 The following terms are defined in [I-D.ietf-netmod-rfc6020bis
]:
...

 o  identity,

There is no identity definition in the RFC 6020 terminology section.

Maybe it is an omission in 6020bis?

Ok, let's fix it in 6020bis then.



-
module foomod {

   namespace"http://example.com/foomod";;

   prefix "foo";

   container top {
 leaf foo {
   type uint8;
 }
   }
 }

Use "example-" in the module name, as mentioned 
inhttps://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-05:

 Example modules are non-normative, and SHOULD be named with the
 prefix "example-".

Same remark for module barmod (and btw, pay attention to the "import
foomod") and module exmod

I agree with Juergen that 6087bis should distinguish between complete
example modules and short module snippets that 

Re: [netmod] AD review: draft-ietf-netmod-yang-json-07

[Ladislav Lhotka]

Hi Benoit,

thank you for the review, please see my responses inline.

Benoit Claise  writes:

> Dear all,
>
> I understood from the chairs that draft-ietf-netmod-yang-json is now 
> ready and that the write-up will be completed end of this week.
> In order to speed up the publication, here is my AD review.
>
> - Editorial:
>
> This document defines encoding rules for representing configuration,
> state data, RPC operation or action input and output parameters, and
> notifications defined using YANG as JavaScript Object Notation (JSON)
> text.
>
> "RPC operation or action input and output parameters"
> ", or ... and, " it's always complicated.
> Why not only "RPC operation or action"?

Because we aren't encoding operations, just their parameters.

>
> At the very minimum "input and output parameters" to "input/output 
> parameters"

OK, so how about using just "parameters of RPC operations or actions" in
the abstract, and "input/output parameters of RPC operations or actions"
elsewhere?

>
> Same remark for section 1.1
>
> The specification of YANG 1.1 data modelling language
> [I-D.ietf-netmod-rfc6020bis 
> ]
>  defines only XML encoding for data
> instances, i.e., contents of configuration datastores, state data,
> RPC operation or action input and output parameters, and event
> notifications.
>
> If you want to extend, also fine.
>
> The specification of YANG 1.1 data modelling language
> [I-D.ietf-netmod-rfc6020bis 
> ]
>  defines only XML encoding for data
> instances, i.e., contents of configuration datastores, state data,
> RPC operation input and output parameters, action input and output
> parameters, and event notifications.
>
> Btw, "RPC", "action" and "input and output parameters" are only 
> mentioned in the abstract and this introduction, not anymore in the body 
> of the document. There is nothing specific to these worth noting? Not 
> even an example?

This document is about encoding YANG data nodes, and the rules are the
same for any data tree. Encoding of operations or notifications is a
subject for a protocol spec, and RESTCONF does provide examples.

>
> - Editorial
>
> In the introduction, you might want to complete the last sentence
>
> NEW:
> The specification of YANG 1.1 data modelling language
> [I-D.ietf-netmod-rfc6020bis 
> ]
>  defines only XML encoding for data
> instances, i.e., contents of configuration datastores, state data,
> RPC operation or action input and output parameters, and event
> notifications.  The aim of this document is to define rules for
> encoding the same data as JavaScript Object Notation (JSON)
> text [RFC7159 ].
>
> NEW:
> The specification of YANG 1.1 data modelling language
> [I-D.ietf-netmod-rfc6020bis 
> ]
>  defines only XML encoding for data
> instances, i.e., contents of configuration datastores, state data,
> RPC operation or action input and output parameters, and event
> notifications.  The aim of this document is to define rules for
> encoding the same data as JavaScript Object Notation (JSON)
> text [RFC7159 ], most precisely the 
> Internet JSON (I-JSON) restricted
> profile [RFC7493 ].

I would say that for the introduction the more general term (JSON) is
appropriate, the reasons for sticking to I-JSON are explained later. In
fact, this document specifies a profile that's even more restricted than
I-JSON.

>
>
> -
> section 2:
>
> The following terms are defined in [I-D.ietf-netmod-rfc6020bis 
> ]:
>...
>
> o  identity,
>
> There is no identity definition in the RFC 6020 terminology section.

Maybe it is an omission in 6020bis?

> Are you referring to the identity statement, 
> https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-09#section-7.18
> ?

No, I am referring to a "globally unique, abstract, and untyped
identity" (sec. 7.18 in 6020bis) that's defined by an "identity" statement.

>
> - Editorial.
>
> OLD:
>   An object member name MUST be in one of the following forms:
> NEW:
>   A JSON object member name MUST be encoded in one of the following forms:
>

OK.

>
> -
>module foomod {
>
>   namespace"http://example.com/foomod";;
>
>   prefix "foo";
>
>   container top {
> leaf foo {
>   type uint8;
> }
>   }
> }
>
> Use "example-" in the module name, as mentioned 
> inhttps://tools.ietf.org

Re: [netmod] Yang mount / ysdl example use case

[Acee Lindem (acee)]

On 2/3/16, 1:18 AM, "Ladislav Lhotka"  wrote:

>
>> On 03 Feb 2016, at 03:24, Kent Watsen  wrote:
>> 
>> 
>> [Chair hat on]
>> 
>> Given the number of competing/complementing drafts involved, and the
>>general lack of discussion on any of them, a virtual interim meeting
>>might be an expedient way to proceed.  In fairness, we know that there
>>has been some discussion, but it hasn’t been picked up yet in a big way,
>>and now Lou has an updated draft.
>> 
>> The chairs discussed maybe scheduling one for a couple weeks from now,
>>perhaps Thursday Feb 18 starting at 10am EST?   I'm thinking
>
>Thursday at this time doesn't suit me very well, Monday till Wednesday of
>that week are OK.

I’m out the entire week of Feb 14th.

Thanks,
Acee 


>
>Lada
>
>>  about this slot only since it worked for us for previously.  Is this a
>>good time slot?  I assume to schedule for 2 hours, with a plan to end
>>early if needed - makes sense? We also need to put together a proper
>>agenda, perhaps the following?
>> 
>>  10 min: RTG DT YANG Arch team use-case summary
>>  20 min: draft-rtgyangdt-rtgwg-device-model
>>  20 min: draft-lhotka-netmod-ysdl
>>  20 min: draft-bjorklund-netmod-structural-mount
>>  50 min: general discussion or end early
>> 
>> 
>> We hope to schedule the meeting itself tomorrow or the next day, so
>>please respond quickly to this email if possible.
>> 
>> Thanks,
>> Kent and Tom
>> 
>> 
>> 
>> 
>> On 2/2/16, 2:04 PM, "netmod on behalf of Lou Berger"
>> wrote:
>> 
>>> 
>>> I thought it would be worth summarizing what we're looking for in our
>>> draft, draft-rtgyangdt-rtgwg-device-model-02 (note new version in case
>>> you missed it) with respect to the draft-lhotka-netmod-ysdl and
>>> draft-bjorklund-netmod-structural-mount drafts. This is just my view,
>>>so
>>> my co-authors may wish to chime in and correct me.
>>> 
>>> I'd be interested in hearing from the authors of YSDL and
>>> structural-mount, or anyone else for that matter, on how they see to
>>> best meet these needs.
>>> 
>>> Here's what I think our draft needs:
>>> 
>>> 1. that there be a mechanism that allows the incorporation (or
>>>  'mounting') of the data model defined by one top-level module
>>>  within another module.
>>> 
>>>  The implication here is that when information is instantiated
>>>  for the parent model it is also instantiated for the
>>>  incorporated/mounted model. In our case we expect to do this on
>>>  list element creation. Both solutions drafts cover the path
>>>  implications, so these are not repeated here.
>>> 
>>> 2. that this mechanism allow identification of specific modules to
>>>  be incorporated/mounted at time of module definition, i.e. that
>>>  no additional module is needed to support 1. This doesn't
>>>  preclude definition of such a module.
>>> 
>>> 3. that this mechanism allow for a server to control (and
>>>  identify) which modules are incorporated/mounted. (see Section
>>>  3 LNE in our draft for an envisioned usage.)
>>> 
>>> 4. that all capabilities that exist with the mounted module are
>>>  available e.g. RPC operations and notifications.
>>> 
>>> 5. while our primary requirement is for 'mounting' of top level
>>>  modules, mounting of submodules may also be useful. (DT not draft
>>>  driven.)
>>> 
>>> We make use of the above in sections 3 and 4 of rtgwg-device-model.  We
>>> see having a solution as critical for the simplifications/flexibility
>>> represented in the -02 version of our draft vs the -03 rev.  We don't
>>> see wither solution draft as significantly different and just hope for
>>>a
>>> standard solution as soon as possible.  (a draft-ietf-netmod solutions
>>> draft on the topic by BA would be fantastic given the impact on routing
>>> area -- even if it had to document two variations / alternative
>>>solutions.)
>>> 
>>> Again, this is just my opinion and my coauthors or others on the rtg
>>> area yang DT may choose to chime in.
>>> 
>>> Lou
>>> 
>>> 
>>> 
>>> ___
>>> 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] Where can I insert new YANG substatements?

[Andy Bierman]

On Wed, Feb 3, 2016 at 1:55 AM, William Ivory  wrote:

> Hi Lada,
>
> I was hoping for more than 'I think' and ' Hmm.  The rule is not clear.
> In fact, one can argue that it is wrong:'.  Is anyone willing / able to
> give me a definitive answer?
>
> Thanks,
>
> William
>
> -Original Message-
> From: Ladislav Lhotka [mailto:lho...@nic.cz]
> Sent: 03 February 2016 09:19
> To: William Ivory 
> Cc: netmod@ietf.org
> Subject: Re: [netmod] Where can I insert new YANG substatements?
>
> Hi William,
>
>
> > On 03 Feb 2016, at 09:58, William Ivory  wrote:
> >
> > Hi,
> >
> > My colleagues and I are looking for clarification of the last point in
> Section 10 of YANG 1.0:
> >
> > ‘   In statements that have any data definition statements as
> >substatements, those data definition substatements MUST NOT be
> >reordered.’
>
> This was already discussed:
>
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_netmod_CiVOMEDXfbQKKbgTXTznZh2HQQw&d=CwIFaQ&c=IL_XqQWOjubgfqINi2jTzg&r=GByLeg9jZvOv_AlgBo9uvdDrxizlOR7l_SnTXowyJU8&m=IVWnHPIm0qEHmxsw6Hhp_1xhdn2lIC4CSzMCsjh-zLo&s=SqU7w-muS4t_zhH19_1iyPLVl3tD24OUgJijkp4NX4E&e=
>
> My understanding was that the paragraph you cite would be modified in
> 6020bis, but apparently it hasn't been so far. I don't see any reason for
> insisting on the order of sibling data node definitions in configuration
> and state data since in instance documents the order is arbitrary in both
> XML and JSON encoding.
>
>

I have also mentioned in the past that this MUST NOT needs to be changed
or at least clarified.

According to RFC 2119, "MUST NOT" is supposed to be used when harm
to inter-operability needs to be prevented. There are only 2 corner-cases
where YANG-stmt order matters
 - default-stmt for a leaf-list
 - auto-numbering for enum or bits

There are already update rules to prevent these statements from being
reordered,
so this MUST NOT is not needed at all.



>
> > We understand that existing statements must not be reordered in a new
> revision of a YANG module, but we’re not clear if new statements may be
> inserted between existing statements, or must always come at the ‘end’ of a
> list or container definition.  A specific example we’re concerned with is
> where a grouping is used, and then later that grouping has an extra element
> added, but the new node could also be added directly.  Eg:
> >
> > Container foo {
> > Leaf A
> > Uses grouping B;
> > Leaf C
> > Leaf D
> > }
> >
> > Is it valid in a new revision of the module to do the following, or must
> the order be A, B, C, D, E?  What if grouping B has gained a new statement?
> >
> > Container foo {
> > Leaf A
> > Uses grouping B;
> > Leaf C
> > Leaf E <  ADDED
> > Leaf D
> > }
>
> I think this is allowed in any case.
>
>

This is allowed.

It is also allowed to move objects to/from submodules and there is
no fixed order to submodules within a module.

This is also allowed, which has the same affect:

   container bar {
  uses foo;   /// <--- add leaf E after D, still reorders X
  leaf X{}
   }




> Lada
>
>

Andy


> >
> > Thanks,
> >
> > William
> >
> >
> > ___
> > netmod mailing list
> > netmod@ietf.org
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=CwIFaQ&c=IL_XqQWOjubgfqINi2jTzg&r=GByLeg9jZvOv_AlgBo9uvdDrxizlOR7l_SnTXowyJU8&m=IVWnHPIm0qEHmxsw6Hhp_1xhdn2lIC4CSzMCsjh-zLo&s=0jQV22VeCUg5PDxgGj0fih8or13yFSYEsMqK1ALagu8&e=
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
> ___
> 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] AD review: draft-ietf-netmod-yang-json-07

[Juergen Schoenwaelder]

On Wed, Feb 03, 2016 at 11:19:33AM +0100, Benoit Claise wrote:

>   module foomod {
> 
>  namespace"http://example.com/foomod";;
> 
>  prefix "foo";
> 
>  container top {
>leaf foo {
>  type uint8;
>}
>  }
>}
> 
> Use "example-" in the module name, as mentioned 
> inhttps://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-05:
> 
>Example modules are non-normative, and SHOULD be named with the
>prefix "example-".
> 
> Same remark for module barmod (and btw, pay attention to the "import 
> foomod") and module exmod

I still believe the text in draft-ietf-netmod-rfc6087bis-05 needs
fixing to distinguish between examples that should be subject to
validation and examples that are just there for documentation purposes
and which are typically designed to be incomplete in order to aid the
reader.

/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 mount / ysdl example use case

[Kent Watsen]

Okay, I set up a doodle poll to help us pick a time:

http://doodle.com/poll/dv68psxn33yt4ehf

Would the draft authors and other key participants please fill in their 
availability?

Thanks,
Kent




On 2/3/16, 1:18 AM, "Ladislav Lhotka"  wrote:

>
>> On 03 Feb 2016, at 03:24, Kent Watsen  wrote:
>> 
>> 
>> [Chair hat on]
>> 
>> Given the number of competing/complementing drafts involved, and the general 
>> lack of discussion on any of them, a virtual interim meeting might be an 
>> expedient way to proceed.  In fairness, we know that there has been some 
>> discussion, but it hasn’t been picked up yet in a big way, and now Lou has 
>> an updated draft.  
>> 
>> The chairs discussed maybe scheduling one for a couple weeks from now, 
>> perhaps Thursday Feb 18 starting at 10am EST?   I'm thinking
>
>Thursday at this time doesn't suit me very well, Monday till Wednesday of that 
>week are OK.
>
>Lada
>
>>  about this slot only since it worked for us for previously.  Is this a good 
>> time slot?  I assume to schedule for 2 hours, with a plan to end early if 
>> needed - makes sense? We also need to put together a proper agenda, 
>> perhaps the following?
>> 
>>  10 min: RTG DT YANG Arch team use-case summary
>>  20 min: draft-rtgyangdt-rtgwg-device-model
>>  20 min: draft-lhotka-netmod-ysdl
>>  20 min: draft-bjorklund-netmod-structural-mount
>>  50 min: general discussion or end early
>> 
>> 
>> We hope to schedule the meeting itself tomorrow or the next day, so please 
>> respond quickly to this email if possible.
>> 
>> Thanks,
>> Kent and Tom
>> 
>> 
>> 
>> 
>> On 2/2/16, 2:04 PM, "netmod on behalf of Lou Berger" 
>>  wrote:
>> 
>>> 
>>> I thought it would be worth summarizing what we're looking for in our
>>> draft, draft-rtgyangdt-rtgwg-device-model-02 (note new version in case
>>> you missed it) with respect to the draft-lhotka-netmod-ysdl and
>>> draft-bjorklund-netmod-structural-mount drafts. This is just my view, so
>>> my co-authors may wish to chime in and correct me.
>>> 
>>> I'd be interested in hearing from the authors of YSDL and
>>> structural-mount, or anyone else for that matter, on how they see to
>>> best meet these needs.
>>> 
>>> Here's what I think our draft needs:
>>> 
>>> 1. that there be a mechanism that allows the incorporation (or
>>>  'mounting') of the data model defined by one top-level module
>>>  within another module.
>>> 
>>>  The implication here is that when information is instantiated
>>>  for the parent model it is also instantiated for the
>>>  incorporated/mounted model. In our case we expect to do this on
>>>  list element creation. Both solutions drafts cover the path
>>>  implications, so these are not repeated here.
>>> 
>>> 2. that this mechanism allow identification of specific modules to
>>>  be incorporated/mounted at time of module definition, i.e. that
>>>  no additional module is needed to support 1. This doesn't
>>>  preclude definition of such a module.
>>> 
>>> 3. that this mechanism allow for a server to control (and
>>>  identify) which modules are incorporated/mounted. (see Section
>>>  3 LNE in our draft for an envisioned usage.)
>>> 
>>> 4. that all capabilities that exist with the mounted module are
>>>  available e.g. RPC operations and notifications.
>>> 
>>> 5. while our primary requirement is for 'mounting' of top level
>>>  modules, mounting of submodules may also be useful. (DT not draft
>>>  driven.)
>>> 
>>> We make use of the above in sections 3 and 4 of rtgwg-device-model.  We
>>> see having a solution as critical for the simplifications/flexibility
>>> represented in the -02 version of our draft vs the -03 rev.  We don't
>>> see wither solution draft as significantly different and just hope for a
>>> standard solution as soon as possible.  (a draft-ietf-netmod solutions
>>> draft on the topic by BA would be fantastic given the impact on routing
>>> area -- even if it had to document two variations / alternative solutions.)
>>> 
>>> Again, this is just my opinion and my coauthors or others on the rtg
>>> area yang DT may choose to chime in.
>>> 
>>> Lou
>>> 
>>> 
>>> 
>>> ___
>>> 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

[netmod] AD review: draft-ietf-netmod-yang-json-07

[Benoit Claise]

Dear all,

I understood from the chairs that draft-ietf-netmod-yang-json is now 
ready and that the write-up will be completed end of this week.

In order to speed up the publication, here is my AD review.

- Editorial:

   This document defines encoding rules for representing configuration,
   state data, RPC operation or action input and output parameters, and
   notifications defined using YANG as JavaScript Object Notation (JSON)
   text.

"RPC operation or action input and output parameters"
", or ... and, " it's always complicated.
Why not only "RPC operation or action"?

At the very minimum "input and output parameters" to "input/output 
parameters"


Same remark for section 1.1

   The specification of YANG 1.1 data modelling language
   [I-D.ietf-netmod-rfc6020bis 
] defines only XML encoding for data

   instances, i.e., contents of configuration datastores, state data,
   RPC operation or action input and output parameters, and event
   notifications.

If you want to extend, also fine.

   The specification of YANG 1.1 data modelling language
   [I-D.ietf-netmod-rfc6020bis 
] defines only XML encoding for data

   instances, i.e., contents of configuration datastores, state data,
   RPC operation input and output parameters, action input and output
   parameters, and event notifications.

Btw, "RPC", "action" and "input and output parameters" are only 
mentioned in the abstract and this introduction, not anymore in the body 
of the document. There is nothing specific to these worth noting? Not 
even an example?


- Editorial

In the introduction, you might want to complete the last sentence

NEW:
   The specification of YANG 1.1 data modelling language
   [I-D.ietf-netmod-rfc6020bis 
] defines only XML encoding for data

   instances, i.e., contents of configuration datastores, state data,
   RPC operation or action input and output parameters, and event
   notifications.  The aim of this document is to define rules for
   encoding the same data as JavaScript Object Notation (JSON)
   text [RFC7159 ].

NEW:
   The specification of YANG 1.1 data modelling language
   [I-D.ietf-netmod-rfc6020bis 
] defines only XML encoding for data

   instances, i.e., contents of configuration datastores, state data,
   RPC operation or action input and output parameters, and event
   notifications.  The aim of this document is to define rules for
   encoding the same data as JavaScript Object Notation (JSON)
   text [RFC7159 ], most precisely the 
Internet JSON (I-JSON) restricted
   profile [RFC7493 ].


-
section 2:

   The following terms are defined in [I-D.ietf-netmod-rfc6020bis 
]:

  ...

   o  identity,

There is no identity definition in the RFC 6020 terminology section.
Are you referring to the identity statement, 
https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-09#section-7.18 ?


- Editorial.

OLD:
An object member name MUST be in one of the following forms:
NEW:
A JSON object member name MUST be encoded in one of the following forms:


-
  module foomod {

 namespace"http://example.com/foomod";;

 prefix "foo";

 container top {
   leaf foo {
 type uint8;
   }
 }
   }

Use "example-" in the module name, as mentioned 
inhttps://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-05:

   Example modules are non-normative, and SHOULD be named with the
   prefix "example-".

Same remark for module barmod (and btw, pay attention to the "import 
foomod") and module exmod



- Editorial (Appendix A):

OLD:
   The "if-mib" feature defined in the "ietf-
   interfaces" module is considered to be active.

NEW:
   The "if-mib" feature defined in the "ietf-
   interfaces" module is supported.

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

Re: [netmod] Where can I insert new YANG substatements?

[William Ivory]

Hi Lada,

I was hoping for more than 'I think' and ' Hmm.  The rule is not clear.  In 
fact, one can argue that it is wrong:'.  Is anyone willing / able to give me a 
definitive answer?

Thanks,

William

-Original Message-
From: Ladislav Lhotka [mailto:lho...@nic.cz] 
Sent: 03 February 2016 09:19
To: William Ivory 
Cc: netmod@ietf.org
Subject: Re: [netmod] Where can I insert new YANG substatements?

Hi William,


> On 03 Feb 2016, at 09:58, William Ivory  wrote:
> 
> Hi,
>  
> My colleagues and I are looking for clarification of the last point in 
> Section 10 of YANG 1.0:
>  
> ‘   In statements that have any data definition statements as
>substatements, those data definition substatements MUST NOT be
>reordered.’

This was already discussed:

https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_netmod_CiVOMEDXfbQKKbgTXTznZh2HQQw&d=CwIFaQ&c=IL_XqQWOjubgfqINi2jTzg&r=GByLeg9jZvOv_AlgBo9uvdDrxizlOR7l_SnTXowyJU8&m=IVWnHPIm0qEHmxsw6Hhp_1xhdn2lIC4CSzMCsjh-zLo&s=SqU7w-muS4t_zhH19_1iyPLVl3tD24OUgJijkp4NX4E&e=
 

My understanding was that the paragraph you cite would be modified in 6020bis, 
but apparently it hasn't been so far. I don't see any reason for insisting on 
the order of sibling data node definitions in configuration and state data 
since in instance documents the order is arbitrary in both XML and JSON 
encoding.

>  
> We understand that existing statements must not be reordered in a new 
> revision of a YANG module, but we’re not clear if new statements may be 
> inserted between existing statements, or must always come at the ‘end’ of a 
> list or container definition.  A specific example we’re concerned with is 
> where a grouping is used, and then later that grouping has an extra element 
> added, but the new node could also be added directly.  Eg:
>  
> Container foo {
> Leaf A
> Uses grouping B;
> Leaf C
> Leaf D 
> }
>  
> Is it valid in a new revision of the module to do the following, or must the 
> order be A, B, C, D, E?  What if grouping B has gained a new statement?
>  
> Container foo {
> Leaf A
> Uses grouping B;
> Leaf C
> Leaf E <  ADDED
> Leaf D
> }

I think this is allowed in any case.

Lada

>  
> Thanks,
>  
> William
>  
>  
> ___
> netmod mailing list
> netmod@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=CwIFaQ&c=IL_XqQWOjubgfqINi2jTzg&r=GByLeg9jZvOv_AlgBo9uvdDrxizlOR7l_SnTXowyJU8&m=IVWnHPIm0qEHmxsw6Hhp_1xhdn2lIC4CSzMCsjh-zLo&s=0jQV22VeCUg5PDxgGj0fih8or13yFSYEsMqK1ALagu8&e=
>  

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




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

Re: [netmod] Where can I insert new YANG substatements?

[Ladislav Lhotka]

Hi William,


> On 03 Feb 2016, at 09:58, William Ivory  wrote:
> 
> Hi,
>  
> My colleagues and I are looking for clarification of the last point in 
> Section 10 of YANG 1.0:
>  
> ‘   In statements that have any data definition statements as
>substatements, those data definition substatements MUST NOT be
>reordered.’

This was already discussed:

https://mailarchive.ietf.org/arch/msg/netmod/CiVOMEDXfbQKKbgTXTznZh2HQQw

My understanding was that the paragraph you cite would be modified in 6020bis, 
but apparently it hasn't been so far. I don't see any reason for insisting on 
the order of sibling data node definitions in configuration and state data 
since in instance documents the order is arbitrary in both XML and JSON 
encoding.

>  
> We understand that existing statements must not be reordered in a new 
> revision of a YANG module, but we’re not clear if new statements may be 
> inserted between existing statements, or must always come at the ‘end’ of a 
> list or container definition.  A specific example we’re concerned with is 
> where a grouping is used, and then later that grouping has an extra element 
> added, but the new node could also be added directly.  Eg:
>  
> Container foo {
> Leaf A
> Uses grouping B;
> Leaf C
> Leaf D 
> }
>  
> Is it valid in a new revision of the module to do the following, or must the 
> order be A, B, C, D, E?  What if grouping B has gained a new statement?
>  
> Container foo {
> Leaf A
> Uses grouping B;
> Leaf C
> Leaf E <  ADDED
> Leaf D
> }

I think this is allowed in any case.

Lada

>  
> Thanks,
>  
> William
>  
>  
> ___
> 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

[netmod] Where can I insert new YANG substatements?

[William Ivory]

Hi,

My colleagues and I are looking for clarification of the last point in Section 
10 of YANG 1.0:

'   In statements that have any data definition statements as
   substatements, those data definition substatements MUST NOT be
   reordered.'

We understand that existing statements must not be reordered in a new revision 
of a YANG module, but we're not clear if new statements may be inserted between 
existing statements, or must always come at the 'end' of a list or container 
definition.  A specific example we're concerned with is where a grouping is 
used, and then later that grouping has an extra element added, but the new node 
could also be added directly.  Eg:

Container foo {
Leaf A
Uses grouping B;
Leaf C
Leaf D
}

Is it valid in a new revision of the module to do the following, or must the 
order be A, B, C, D, E?  What if grouping B has gained a new statement?

Container foo {
Leaf A
Uses grouping B;
Leaf C
Leaf E <  ADDED
Leaf D
}

Thanks,

William


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

Re: [netmod] chars that require quoting

[Jernej Tuljak]

Ladislav Lhotka je 3.2.2016 ob 6:59 napisal:

On 03 Feb 2016, at 05:02, Andy Bierman  wrote:



On Tue, Feb 2, 2016 at 9:50 AM, Ladislav Lhotka  wrote:


On 02 Feb 2016, at 18:25, Andy Bierman  wrote:



On Tue, Feb 2, 2016 at 4:04 AM, Jernej Tuljak  wrote:
Ladislav Lhotka je 2.2.2016 ob 12:25 napisal:
On 02 Feb 2016, at 12:16, Martin Bjorklund  wrote:

Ladislav Lhotka  wrote:
On 02 Feb 2016, at 09:51, Jernej Tuljak  wrote:

Martin Bjorklund je 1.2.2016 ob 20:48 napisal:
Juergen Schoenwaelder  wrote:
If a specification is not explicit enough, then people often implement
what they find implemented in other similar contexts. This means the
code often ends up reflecting which tools an implementor was familiar
with. In a shell, echo f\"oo gives you f"oo (and the same is true for
Tcl, which has otherwise the behavior you implemented for pyang,
treating " as a regular character in an unquoted string.)

It would help to know what implementations do with identifiers like
f"o"o and f\"o\"o. If they do different things, then there is likely
some evidence that implementors arrived at different conclusions.
I don't mind a clarification.  How about:

OLD:

   If a string contains any space, tab, or newline characters, a
   semicolon (";"), braces ("{" or "}"), or comment sequences ("//",
   "/*", or "*/"), then it MUST be enclosed within double or single
   quotes.

NEW:

   If a string contains any space, tab, or newline characters, a
   semicolon (";"), braces ("{" or "}"), or comment sequences ("//",
   "/*", or "*/"), then it MUST be enclosed within double or single
   quotes.  If a string does not contain any of these characters, it
   MAY be unquoted.

   Within an unquoted string, every character is preserved.  Note that
   this means that the backslash, single quote, and double quote
   characters can occur in an unquoted string.
I don't think this can be implemented, like I did not in the linked archive. It 
does not make clear whether these are two statements or a single one:

   default ";
   units ";


What about this:

   default ";//foo";
   units \";


This is not the C and C++ way of doing things (possibly not even SMIng way). 
These are the only languages mentioned in the document (Section 6). It also 
does not promote readability and makes lexers unnecessarily complex.
+1

I think the safest solution would be to disallow in unquoted strings
all characters that have a special meaning anywhere in YANG
syntax. This can hardly cause any troubles to module authors.
Fine with me.  Something like:

NEW:

   If a string contains any space, tab, or newline characters, a single
   or double quote, semicolon (";"), braces ("{" or "}"), or comment
   sequences ("//", "/*", or "*/"), then it MUST be enclosed within
   double or single quotes.  If a string does not contain any of these
   characters, it MAY be unquoted.

   Within an unquoted string, every character is preserved.  Note that
   this means that the backslash character does not have any special
   meaning in an unquoted string.
I like this.

+1



I don't understand this text.
The parser looks for certain tokens in specific contexts.


   container A;container B;container C;

   container foo{container bar{container baz;}}

   augment /foo/bar/baz{container Z;}

pyang and yangdump-pro handle these unquoted strings correctly.

I think your text is supposed to mean that chars with special meanings
in specific contexts need to be quoted to use them as plain chars without
any special meaning.

I strongly object to this new text since it tells the YANG author they
cannot use unquoted strings like the examples above.

Why do you think there is anything in the new text to this effect? All of your 
examples remain perfectly OK. The only change compared to 6020bis-09 is that 
the newline, single- and double-quote characters cannot appear in unquoted 
argument strings.



If a string contains any space, tab, or newline characters, a single

   or double quote, semicolon (";"), braces ("{" or "}"), or comment
   sequences ("//", "/*", or "*/"), then it MUST be enclosed within
   double or single quotes.


This is not true;  The example above contains valid unquoted strings that 
contain a semicolon.

Huh? The text is about characters in unquoted *argument* strings. The 
semicolons in your examples aren't syntactically part of an argument. This 
hasn't changed: semicolons and curly braces were not permitted in an unquoted 
argument already in YANG 1.0.


I agree.

  container A ; container B ; container C ;

  container foo { container bar { container baz ; } }

  augment /foo/bar/baz { container Z ; }

The semantics of the above should be equivalent to Andy's example. This 
is probably some sort of a misunderstanding.


The new text is only adding quotes and newlines to the list of 
characters that need to be inside quoted strings in order to not be 
recognized as a token, a token start or a token separator.


Jernej



Lada


The only strings that MUST be enco