date:20151216


> On 17 Dec 2015, at 08:17, Juergen Schoenwaelder 
>  wrote:
> 
> On Thu, Dec 17, 2015 at 02:18:42AM +, Kent Watsen wrote:
>> 
>> [as a contributor]
>> 
>> Hi Andy,
>> 
>> I’m struggling a bit to understand what is motivating you to ask this 
>> question.That is, as a tool vendor, I wouldn’t think that any decision 
>> made here would affect you immediately.   My expectations are that any 
>> impact to YANG/NETCONF/RESTCONF would be backwards compatible, such that 
>> implementations would only opt-in when needed - a pay as you grow strategy.  
>>  But herein perhaps lies an unstated requirement, that the impact to 
>> YANG/NETCONF/RESTCONF needs to be backwards compatible with respect to 
>> existing deployments.  Did we miss it or is it too obvious?
>> 
> 
> It may be obvious for many of us but for the sake of completeness I
> prefer to have this backwards compatibility assumption explicitely
> stated.

+1

Lada

> 
> /js
> 
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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




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

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

2015-12-16 Thread Juergen Schoenwaelder

On Thu, Dec 17, 2015 at 02:18:42AM +, Kent Watsen wrote:
> 
> [as a contributor]
> 
> Hi Andy,
> 
> I’m struggling a bit to understand what is motivating you to ask this 
> question.That is, as a tool vendor, I wouldn’t think that any decision 
> made here would affect you immediately.   My expectations are that any impact 
> to YANG/NETCONF/RESTCONF would be backwards compatible, such that 
> implementations would only opt-in when needed - a pay as you grow strategy.   
> But herein perhaps lies an unstated requirement, that the impact to 
> YANG/NETCONF/RESTCONF needs to be backwards compatible with respect to 
> existing deployments.  Did we miss it or is it too obvious?
>

It may be obvious for many of us but for the sake of completeness I
prefer to have this backwards compatibility assumption explicitely
stated.

/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] Guidance on list vs. container of list


> On 16 Dec 2015, at 18:04, Christian Hopps  wrote:
> 
> 
> Andy Bierman  writes:
> 
>> Hi,
>> 
>> Use of NP-containers are subjective, based on how you want to organize your 
>> data.  The extra layer of containment may be a waste, but it sometimes has a 
>> purpose
>> 
>>  - 2 or more sibling lists with lots of entries can be mixed in   JSON, 
>> so putting each list in its container prevents that.
> Did you mean XML here (Lada indicated it's not the case with JSON)? I was 
> curious if mixing like this was allowed in XML case (whether items from 2 
> different lists or even sibling leafs). I was hoping that once a list started 
> in the XML all items in the list would be present before other items outside 
> the list. If what your saying applies to XML then one would have to iterate 
> all sibling nodes in

The possibility of (leaf-)list entries being interleaved with other sibling XML 
elements is explicitly mentioned in RFC 6020 (sec. 7.7.6 and 7.8.5). This 
shouldn't come as a surprise because XML has no notion of lists.

>  the containing node to collect the list. This would seem to be the case even 
> with sibling leafs in the model. I find this a bit surprising, and would 
> expect bugs in implementation if so. :)
>> - container servers as a conceptual 'root' for external  augments
> This might be useful in some cases, probably not a reason to always include a 
> container wrapper though.
>> - There is no standard way to 'delete-all' in NETCONF or  RESTCONF but a 
>> 'replace' on the parent container can be used for this purpose.  
>> (container of list or leaf-list)
> 
> This is an interesting use -- using a modeling technique to to get around 
> missing functionality in the protocol (hello opstate! :)
> Seriously though, should we consider adding delete-all functionality then?

Absolutely.

Lada

> 
> Thanks, Chris.
> 
>> Andy
>> 
>> 
>> On Mon, Dec 14, 2015 at 5:56 PM, Christian Hopps  wrote:
>> 
>>> 
>>> Some models seem to place a single list of things inside a container also 
>>> named after the items in the list, e.g.,
>>> 
>>> +--ro modulename   +--rw ribs  +--rw rib* [name] +--rw name I 
>>> don't see the purpose of these containers. It seems to me that one can 
>>> model and query the exact same data without the outer container. That is,
>>> 
>>> +--ro modulename   +--rw rib* [name]  +--rw name Is there something 
>>> useful about these containers that I've missed, as it's a fairly common 
>>> pattern in the models I've been looking at.   Example comparisons below..  
>>> Thanks, Chris.
>>> 
>>> 
>>> w/ container:  foo 
>>>bar ...  
>>>  w/o container:  
>>> foobar   ...
>>>  Likewise if you want to fetch all ribs you can either way:
>>> 
>>>
>>> or
>>> 
>>>
>>> Or a particular rib
>>> 
>>>   
>>> foo
>>>  or
>>> 
>>>   foo
>>>Using xpath:
>>> 
>>>   /modulename/ribs/rib[name='foo'] or
>>> 
>>>   /modulename/rib[name='foo']
>>> 
>>> ___ 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






signature.asc
Description: Message signed with OpenPGP using GPGMail
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Guidance on list vs. container of list


> On 16 Dec 2015, at 18:08, Martin Bjorklund  wrote:
> 
> Anees Shaikh  wrote:
>> I'm not suggesting this is necessarily standard behavior :-)
> 
> I think this demonstrates that it is probably not a good idea to
> design (standard) data models to optimize for a single protocol /
> implementation.  For NETCONF, the problem is clearly in the protocol,
> and it should be fixed in the protocol (Andy already showed a
> solution).

Agreed. This deficiency also blocks the introduction of keyless config lists 
that several people requested.

> 
> Going back to the original question, I don't think there's a single
> rule to be used.  Sometimes the additional container makes sense, but
> in some cases (normally further down in the hierarchy, for "smaller"
> lists) it just adds noise.

Also, it is usually a good idea to use a wrapper container for user-ordered 
lists.

Lada

> 
> 
> /martin
> 
> 
> , but some
>> major implementations behave this way (it could be useful in some
>> circumstances) -- on those platforms, the enclosing container makes a
>> request for the whole list arguably less ambiguous.
>> 
>> thanks.
>> -- Anees
>> 
>> On Wed, Dec 16, 2015 at 8:48 AM, Christian Hopps  wrote:
>> 
>>> 
>>> Anees Shaikh  writes:
>>> 
>>> hi Chris, in OpenConfig models we use enclosing containers on lists based
 on feedback from some implementors who claimed that it made it more
 efficient to, for example, retrieve the entire list (ask for the
 container), retrieve the keys in the list (ask for the list node), or
 retrieve a particular element of the list (specify the key).
 
>>> 
>>> But, I don't think asking for the list node returns only keys, I think it
>>> returns the entire content of the node, i.e., it's equivalent to asking for
>>> the out container if that container only contains a single list (the model
>>> in question here).
>>> Thanks,
>>> Chris.
>>> 
>>> 
>>> Aside from some stuttering in the paths (which can be a little annoying
 but I don't expect to write the config instances by hand), there didn't
 seem to be a major downside.  So we try to be consistent across the models
 with this approach.  After getting some more experience with the
 implementations, we might revisit.
 
 thanks.  -- Anees
 
 On Mon, Dec 14, 2015 at 6:30 PM, Andy Bierman  wrote:
 
 Hi,
> 
> Use of NP-containers are subjective, based on how you want to organize
> your data.  The extra layer of containment may be a waste, but it 
> sometimes
> has a purpose
> 
>  - 2 or more sibling lists with lots of entries can be mixed   in
> JSON, so putting each list in its container prevents that.  - There is
> no standard way to 'delete-all' in NETCONF or  RESTCONF but a 
> 'replace'
> on the parent container can be used for this purpose.  (container of
> list or leaf-list)  - container servers as a conceptual 'root' for
> external  augments
> 
> Andy
> 
> 
> On Mon, Dec 14, 2015 at 5:56 PM, Christian Hopps 
> wrote:
> 
> 
>> Some models seem to place a single list of things inside a container
>> also named after the items in the list, e.g.,
>> 
>> +--ro modulename   +--rw ribs  +--rw rib* [name] +--rw name
>> I don't see the purpose of these containers. It seems to me that one can
>> model and query the exact same data without the outer container. That is,
>> 
>> +--ro modulename   +--rw rib* [name]  +--rw name Is there something
>> useful about these containers that I've missed, as it's a fairly common
>> pattern in the models I've been looking at.   Example comparisons below..
>> Thanks, Chris.
>> 
>> 
>> w/ container:  
>> foobar ...
>>   w/o container:  
>> foobar   ...
>>  Likewise if you want to fetch all ribs you can either way:
>> 
>>   
>>  or
>> 
>>   
>>  Or a particular rib
>> 
>>   
>> foo
>>  or
>> 
>>   foo
>>   Using xpath:
>> 
>>   /modulename/ribs/rib[name='foo'] or
>> 
>>   /modulename/rib[name='foo']
>> 
>> ___ 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

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




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

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

On Wed, Dec 16, 2015 at 6:18 PM, Kent Watsen  wrote:

>
> [as a contributor]
>
> Hi Andy,
>
> I’m struggling a bit to understand what is motivating you to ask this
> question.That is, as a tool vendor, I wouldn’t think that any decision
> made here would affect you immediately.   My expectations are that any
> impact to YANG/NETCONF/RESTCONF would be backwards compatible, such that
> implementations would only opt-in when needed - a pay as you grow strategy.
>   But herein perhaps lies an unstated requirement, that the impact to
> YANG/NETCONF/RESTCONF needs to be backwards compatible with respect to
> existing deployments.  Did we miss it or is it too obvious?
>
> I agree that supporting these requirements will be unnecessary for many
> platforms.  After all, we’ve gone decades without needing such visibility,
> and that’s not going to change for many platforms for some time, if ever.
>
> You ask for objective metrics for determining solution applicability.  My
> thinking is to just let the market decide - is it not good enough?   If I
> tried to quantify it, I might say that its only useful for networking
> devices (as their operational state somehow matters more?) and that it’s
> only useful when there is no guarantee that the intended config will become
> operational (i.e. applied) in some bounded amount of time.   Just throwing
> out ideas here, but I like best letting the market decide.
>
>

There seemed to be agreement that most devices will apply intended config
within 5 seconds (not counting the 'waiting for line card' corner-case).
We usually see exec. times way under 1 sec., but if others are having
a problem with delays, I guess they will find this work useful.



> Kent
>


Andy


>
>
> From: netmod  on behalf of Andy Bierman <
> a...@yumaworks.com>
> Date: Wednesday, December 16, 2015 at 7:21 PM
> To: Thomas Nadeau 
> Cc: "netmod-cha...@tools.ietf.org" , "
> netmod@ietf.org" 
> Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
>
> Hi,
>
> I have asked repeatedly for some indication of scope in these requirements.
> There is an assumption all possible YANG-based platforms have intended
> and applied state that can be different for a long enough interval such
> that retrieving
> the differences is operationally useful.
>
> For devices that converge in milli-seconds or even as long as 5 seconds,
> I do not see the point of implementing solutions for these requirements.
> I would prefer that this draft specify some sort of objective
> metric for determining the solution applicability.
>
>
> Andy
>
>
> On Wed, Dec 16, 2015 at 4:10 PM, Nadeau Thomas 
> wrote:
>
>>
>> This is a WG Last Call on draft-ietf-netmod-opstate-reqs-01.
>> Please post comments on this draft by Wednesday, December 30, 2015
>> at 9AM EST.
>>
>> Tom/Kent
>>
>>
>> ___
>> 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] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

2015-12-16 Thread Kent Watsen


[as a contributor]

Hi Andy,

I’m struggling a bit to understand what is motivating you to ask this question. 
   That is, as a tool vendor, I wouldn’t think that any decision made here 
would affect you immediately.   My expectations are that any impact to 
YANG/NETCONF/RESTCONF would be backwards compatible, such that implementations 
would only opt-in when needed - a pay as you grow strategy.   But herein 
perhaps lies an unstated requirement, that the impact to YANG/NETCONF/RESTCONF 
needs to be backwards compatible with respect to existing deployments.  Did we 
miss it or is it too obvious?

I agree that supporting these requirements will be unnecessary for many 
platforms.  After all, we’ve gone decades without needing such visibility, and 
that’s not going to change for many platforms for some time, if ever.

You ask for objective metrics for determining solution applicability.  My 
thinking is to just let the market decide - is it not good enough?   If I tried 
to quantify it, I might say that its only useful for networking devices (as 
their operational state somehow matters more?) and that it’s only useful when 
there is no guarantee that the intended config will become operational (i.e. 
applied) in some bounded amount of time.   Just throwing out ideas here, but I 
like best letting the market decide.

Kent


From: netmod mailto:netmod-boun...@ietf.org>> on 
behalf of Andy Bierman mailto:a...@yumaworks.com>>
Date: Wednesday, December 16, 2015 at 7:21 PM
To: Thomas Nadeau mailto:tnad...@lucidvision.com>>
Cc: "netmod-cha...@tools.ietf.org" 
mailto:netmod-cha...@tools.ietf.org>>, 
"netmod@ietf.org" 
mailto:netmod@ietf.org>>
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

Hi,

I have asked repeatedly for some indication of scope in these requirements.
There is an assumption all possible YANG-based platforms have intended
and applied state that can be different for a long enough interval such that 
retrieving
the differences is operationally useful.

For devices that converge in milli-seconds or even as long as 5 seconds,
I do not see the point of implementing solutions for these requirements.
I would prefer that this draft specify some sort of objective
metric for determining the solution applicability.


Andy


On Wed, Dec 16, 2015 at 4:10 PM, Nadeau Thomas 
mailto:tnad...@lucidvision.com>> wrote:

This is a WG Last Call on draft-ietf-netmod-opstate-reqs-01.
Please post comments on this draft by Wednesday, December 30, 2015
at 9AM EST.

Tom/Kent


___
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] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

Hi,

I have asked repeatedly for some indication of scope in these requirements.
There is an assumption all possible YANG-based platforms have intended
and applied state that can be different for a long enough interval such
that retrieving
the differences is operationally useful.

For devices that converge in milli-seconds or even as long as 5 seconds,
I do not see the point of implementing solutions for these requirements.
I would prefer that this draft specify some sort of objective
metric for determining the solution applicability.

Andy

On Wed, Dec 16, 2015 at 4:10 PM, Nadeau Thomas 
wrote:

>
> This is a WG Last Call on draft-ietf-netmod-opstate-reqs-01.
> Please post comments on this draft by Wednesday, December 30, 2015
> at 9AM EST.
>
> Tom/Kent
>
>
> ___
> 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] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01


This is a WG Last Call on draft-ietf-netmod-opstate-reqs-01.
Please post comments on this draft by Wednesday, December 30, 2015
at 9AM EST.

Tom/Kent


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

Re: [netmod] Y02: context node

Jernej Tuljak  wrote:
> 
> Dne 16.12.2015 ob 17:18 je Martin Bjorklund zapisal(a):
> > Jernej Tuljak  wrote:
> >> Ladislav Lhotka je 16.12.2015 ob 15:10 napisal:
>  On 16 Dec 2015, at 14:08, Jernej Tuljak  wrote:
> 
>  Martin Bjorklund je 16.12.2015 ob 13:48 napisal:
> > Jernej Tuljak  wrote:
> >> Martin Bjorklund je 25.11.2015 ob 11:16 napisal:
> >>> Ladislav Lhotka  wrote:
>  Hi,
> 
>  I'd like to resolve this issue. Here is a complete example (valid, I
>  believe):
> 
>  module context {
>   namespace "http://example.com/context";;
>   prefix ctx;
> 
>   leaf foo {
> config false;
> type uint32;
>   }
>   rpc oper {
> output {
>   must "/foo mod foo = 0";
>   leaf foo {
> type uint32;
>   }
> }
>   }
>  }
> 
>  1. What does the accessible tree look like?
> >>> Note that the anser to this depends on the outcomne of Y04.  Andy has
> >>> strong objections to Y04-02, and proposed Y04-04 instead.
> >>>
> >>> Assuming Y04-02, and assuming /foo has the value 20 and the oper rpc's
> >>> result has foo = 10, the accessible tree would look like this:
> >>>
> >>>   
> >>> +-- oper
> >>> |   +-- foo = 10
> >>> +-- foo = 20
> >>>
> >>>
> >>> (If we instead move back to Y04-04, the accessible tree would be:
> >>>
> >>>   
> >>> +-- oper
> >>> +-- foo = 10
> >>>
> >>> )
> >>>
>  2. What is the context node for the "must" expression?
> >>> /oper
> >> This change to the accessible tree (1.0 --> 1.1) may break some
> >> existing "when" XPath expressions (those under "output" statement).
> > Maybe.  The old text said:
> >
> >  o  If the context node represents RPC output parameters, the tree 
> > is
> > the RPC reply instance document.
> >
> > So this probably meant that for this definition:
> >
> > module ex {
> >   ...
> >   prefix x;
> >   ...
> >   rpc foo {
> > output {
> >   leaf bar { ... }
> > }
> >   }
> > }
> >
> > The accessile tree was:
> >
> >  nc:rpc-reply
> >+-- x:bar
> >
> > This is very NETCONF-specifc.  With 1.1, the tree would be:
> >
> >  x:foo
> >+-- x:bar
> >
> > which is protocol-neutral.
> >
> >> Is
> >> this compatible with 1.1 charter - "All compliant YANG 1.0 modules
> >> must be accepted as compliant YANG 1.1 modules"?
> >>
> >> rpc my-rpc {
> >>   output {
> >> uses my-stuff {
> >>   when "specific-param = 'foo'";// 1.0
> >> // when "my-rpc/specific-param = 'foo'" // 1.1
> > This is not correct.  If a relative path is used, it would be the same
> > in 1.0 and 1.1.
>  I disagree due to current text:
> 
>  o  data node: A node in the schema tree that can be instantiated in a
> data tree.  One of container, leaf, leaf-list, list, anydata, and
> anyxml.
> 
>  o  If the XPath expression is defined in a substatement to an
> "output" statement in an "rpc" or "action" statement, the
> accessible tree is the RPC or action operation instance, all state
> data in the server, and the running configuration datastore.  The
> root node has top-level data nodes in all modules as children.
> Additionally, for an RPC, the root node also has the node
> representing the RPC operation being defined as a child.  The node
> representing the operation being defined has the operation's
> output parameters as children.
> 
>  o  If the "when" statement is a child of a "uses", "choice", or
> "case" statement, then the context node is the closest ancestor
> node to the "uses", "choice", or "case" node that is also a data
> node.  If no such node exists, the context node is the root node.
> The accessible tree is tentatively altered during the processing
> of the XPath expression by removing all instances (if any) of the
> nodes added by the "uses", "choice", or "case" statement.
> 
> 
>  It clearly says that the context node is the root node ("/"), not the
>  node representing the RPC ("/my-rpc"), which is a child to root
>  node. The "root node" aka "document root" can only mean a single thing
>  XPath terminology.
> >>> RFC 6020 clearly says that the tree is the rpc reply instance
> >>> document, so it is a different document whose root no

Re: [netmod] Guidance on list vs. container of list

On Wed, Dec 16, 2015 at 9:04 AM, Christian Hopps  wrote:

>
> Andy Bierman  writes:
>
> Hi,
>>
>> Use of NP-containers are subjective, based on how you want to organize
>> your data.  The extra layer of containment may be a waste, but it sometimes
>> has a purpose
>>
>>   - 2 or more sibling lists with lots of entries can be mixed in   JSON,
>>so putting each list in its container prevents that.
>>
>
> Did you mean XML here (Lada indicated it's not the case with JSON)? I was
> curious if mixing like this was allowed in XML case (whether items from 2
> different lists or even sibling leafs). I was hoping that once a list
> started in the XML all items in the list would be present before other
> items outside the list. If what your saying applies to XML then one would
> have to iterate all sibling nodes in the containing node to collect the
> list. This would seem to be the case even with sibling leafs in the model.
> I find this a bit surprising, and would expect bugs in implementation if
> so. :)
>

Lada is correct so ignore this use-case



>  - container servers as a conceptual 'root' for external  augments
>>
>
> This might be useful in some cases, probably not a reason to always
> include a container wrapper though.
>
>>  - There is no standard way to 'delete-all' in NETCONF or  RESTCONF
>>  but a 'replace' on the parent container can be used for this purpose.
>> (container of list or leaf-list)
>>
>
> This is an interesting use -- using a modeling technique to to get around
> missing functionality in the protocol (hello opstate! :)
> Seriously though, should we consider adding delete-all functionality then?
>


Maybe in the future if NETCONF gets updated



> Thanks, Chris.
>


Andy


>
> Andy
>>
>>
>> On Mon, Dec 14, 2015 at 5:56 PM, Christian Hopps 
>> wrote:
>>
>>
>>> Some models seem to place a single list of things inside a container
>>> also named after the items in the list, e.g.,
>>>
>>> +--ro modulename   +--rw ribs  +--rw rib* [name] +--rw name
>>> I don't see the purpose of these containers. It seems to me that one can
>>> model and query the exact same data without the outer container. That is,
>>>
>>> +--ro modulename   +--rw rib* [name]  +--rw name Is there something
>>> useful about these containers that I've missed, as it's a fairly common
>>> pattern in the models I've been looking at.   Example comparisons below..
>>> Thanks, Chris.
>>>
>>>
>>> w/ container:  
>>> foobar ...
>>>   w/o container:  
>>> foobar   ...
>>>  Likewise if you want to fetch all ribs you can either way:
>>>
>>>
>>>  or
>>>
>>>
>>>  Or a particular rib
>>>
>>>
>>> foo
>>>  or
>>>
>>>foo
>>>Using xpath:
>>>
>>>/modulename/ribs/rib[name='foo'] or
>>>
>>>/modulename/rib[name='foo']
>>>
>>> ___ 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] Guidance on list vs. container of list

Anees Shaikh  wrote:
> I'm not suggesting this is necessarily standard behavior :-)

I think this demonstrates that it is probably not a good idea to
design (standard) data models to optimize for a single protocol /
implementation.  For NETCONF, the problem is clearly in the protocol,
and it should be fixed in the protocol (Andy already showed a
solution).

Going back to the original question, I don't think there's a single
rule to be used.  Sometimes the additional container makes sense, but
in some cases (normally further down in the hierarchy, for "smaller"
lists) it just adds noise.


/martin


, but some
> major implementations behave this way (it could be useful in some
> circumstances) -- on those platforms, the enclosing container makes a
> request for the whole list arguably less ambiguous.
> 
> thanks.
> -- Anees
> 
> On Wed, Dec 16, 2015 at 8:48 AM, Christian Hopps  wrote:
> 
> >
> > Anees Shaikh  writes:
> >
> > hi Chris, in OpenConfig models we use enclosing containers on lists based
> >> on feedback from some implementors who claimed that it made it more
> >> efficient to, for example, retrieve the entire list (ask for the
> >> container), retrieve the keys in the list (ask for the list node), or
> >> retrieve a particular element of the list (specify the key).
> >>
> >
> > But, I don't think asking for the list node returns only keys, I think it
> > returns the entire content of the node, i.e., it's equivalent to asking for
> > the out container if that container only contains a single list (the model
> > in question here).
> > Thanks,
> > Chris.
> >
> >
> > Aside from some stuttering in the paths (which can be a little annoying
> >> but I don't expect to write the config instances by hand), there didn't
> >> seem to be a major downside.  So we try to be consistent across the models
> >> with this approach.  After getting some more experience with the
> >> implementations, we might revisit.
> >>
> >> thanks.  -- Anees
> >>
> >> On Mon, Dec 14, 2015 at 6:30 PM, Andy Bierman  wrote:
> >>
> >> Hi,
> >>>
> >>> Use of NP-containers are subjective, based on how you want to organize
> >>> your data.  The extra layer of containment may be a waste, but it 
> >>> sometimes
> >>> has a purpose
> >>>
> >>>   - 2 or more sibling lists with lots of entries can be mixed   in
> >>> JSON, so putting each list in its container prevents that.  - There is
> >>> no standard way to 'delete-all' in NETCONF or  RESTCONF but a 
> >>> 'replace'
> >>> on the parent container can be used for this purpose.  (container of
> >>> list or leaf-list)  - container servers as a conceptual 'root' for
> >>> external  augments
> >>>
> >>> Andy
> >>>
> >>>
> >>> On Mon, Dec 14, 2015 at 5:56 PM, Christian Hopps 
> >>> wrote:
> >>>
> >>>
>  Some models seem to place a single list of things inside a container
>  also named after the items in the list, e.g.,
> 
>  +--ro modulename   +--rw ribs  +--rw rib* [name] +--rw name
>  I don't see the purpose of these containers. It seems to me that one can
>  model and query the exact same data without the outer container. That is,
> 
>  +--ro modulename   +--rw rib* [name]  +--rw name Is there something
>  useful about these containers that I've missed, as it's a fairly common
>  pattern in the models I've been looking at.   Example comparisons below..
>  Thanks, Chris.
> 
> 
>  w/ container:  
>  foobar ...
>    w/o container:  
>  foobar   ...
>   Likewise if you want to fetch all ribs you can either way:
> 
> 
>   or
> 
> 
>   Or a particular rib
> 
> 
>  foo
>   or
> 
> foo
> Using xpath:
> 
> /modulename/ribs/rib[name='foo'] or
> 
> /modulename/rib[name='foo']
> 
>  ___ 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] Guidance on list vs. container of list

2015-12-16 Thread Christian Hopps



Andy Bierman  writes:


Hi,

Use of NP-containers are subjective, based on how you want to 
organize your data.  The extra layer of containment may be a 
waste, but it sometimes has a purpose


  - 2 or more sibling lists with lots of entries can be mixed in 
  JSON, 
so putting each list in its container prevents that. 


Did you mean XML here (Lada indicated it's not the case with 
JSON)? I was curious if mixing like this was allowed in XML case 
(whether items from 2 different lists or even sibling leafs). I 
was hoping that once a list started in the XML all items in the 
list would be present before other items outside the list. If what 
your saying applies to XML then one would have to iterate all 
sibling nodes in the containing node to collect the list. This 
would seem to be the case even with sibling leafs in the model. I 
find this a bit surprising, and would expect bugs in 
implementation if so. :) 

 - container servers as a conceptual 'root' for external 
 augments 


This might be useful in some cases, probably not a reason to 
always include a container wrapper though. 

 - There is no standard way to 'delete-all' in NETCONF or 
 RESTCONF 
but a 'replace' on the parent container can be used for this 
purpose.  (container of list or leaf-list) 


This is an interesting use -- using a modeling technique to to get 
around missing functionality in the protocol (hello opstate! :) 

Seriously though, should we consider adding delete-all 
functionality then? 


Thanks, Chris.


Andy


On Mon, Dec 14, 2015 at 5:56 PM, Christian Hopps 
 wrote:




Some models seem to place a single list of things inside a 
container also named after the items in the list, e.g.,


+--ro modulename 
  +--rw ribs 
 +--rw rib* [name] +--rw name 
I don't see the purpose of these containers. It seems to me 
that one can model and query the exact same data without the 
outer container. That is,


+--ro modulename 
  +--rw rib* [name]  +--rw name 
Is there something useful about these containers that I've 
missed, as it's a fairly common pattern in the models I've been 
looking at.   Example comparisons below..  Thanks, Chris.



w/ container: 
  
   foo 
   bar ... 
  w/o container: 

 foo
bar   ... Likewise if 
you want to fetch all ribs you can either way:



  

  

or



  

  

Or a particular rib



  
 foo 
  
  

or



   foo 

  

Using xpath:


   /modulename/ribs/rib[name='foo'] 
or


   /modulename/rib[name='foo']

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







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

Re: [netmod] Guidance on list vs. container of list

2015-12-16 Thread Christian Hopps



Anees Shaikh  writes:

hi Chris, in OpenConfig models we use enclosing containers on 
lists based on feedback from some implementors who claimed that 
it made it more efficient to, for example, retrieve the entire 
list (ask for the container), retrieve the keys in the list (ask 
for the list node), or retrieve a particular element of the list 
(specify the key). 


But, I don't think asking for the list node returns only keys, I 
think it returns the entire content of the node, i.e., it's 
equivalent to asking for the out container if that container only 
contains a single list (the model in question here). 


Thanks,
Chris.

Aside from some stuttering in the paths (which can be a little 
annoying but I don't expect to write the config instances by 
hand), there didn't seem to be a major downside.  So we try to 
be consistent across the models with this approach.  After 
getting some more experience with the implementations, we might 
revisit.


thanks.  -- Anees

On Mon, Dec 14, 2015 at 6:30 PM, Andy Bierman 
 wrote:



Hi,

Use of NP-containers are subjective, based on how you want to 
organize your data.  The extra layer of containment may be a 
waste, but it sometimes has a purpose


  - 2 or more sibling lists with lots of entries can be mixed 
  in JSON, 
so putting each list in its container prevents that. 
 - There is no standard way to 'delete-all' in NETCONF or 
 RESTCONF 
but a 'replace' on the parent container can be used for 
this purpose.  (container of list or leaf-list) 
 - container servers as a conceptual 'root' for external 
 augments


Andy


On Mon, Dec 14, 2015 at 5:56 PM, Christian Hopps 


wrote:



Some models seem to place a single list of things inside a 
container also named after the items in the list, e.g.,


+--ro modulename 
  +--rw ribs 
 +--rw rib* [name] +--rw name 
I don't see the purpose of these containers. It seems to me 
that one can model and query the exact same data without the 
outer container. That is,


+--ro modulename 
  +--rw rib* [name]  +--rw name 
Is there something useful about these containers that I've 
missed, as it's a fairly common pattern in the models I've 
been looking at.   Example comparisons below..  Thanks, Chris.



w/ container: 
  
   foo 
   bar ... 
  w/o container: 

 foo
bar   ... Likewise if 
you want to fetch all ribs you can either way:



  

  

or



  

  

Or a particular rib



  
 foo 
  
  

or



   foo 

  

Using xpath:


   /modulename/ribs/rib[name='foo'] 
or


   /modulename/rib[name='foo']

___ 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







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

Re: [netmod] Y02: context node

Jernej Tuljak  wrote:
> Ladislav Lhotka je 16.12.2015 ob 15:10 napisal:
> >> On 16 Dec 2015, at 14:08, Jernej Tuljak  wrote:
> >>
> >> Martin Bjorklund je 16.12.2015 ob 13:48 napisal:
> >>> Jernej Tuljak  wrote:
>  Martin Bjorklund je 25.11.2015 ob 11:16 napisal:
> > Ladislav Lhotka  wrote:
> >> Hi,
> >>
> >> I'd like to resolve this issue. Here is a complete example (valid, I
> >> believe):
> >>
> >> module context {
> >> namespace "http://example.com/context";;
> >> prefix ctx;
> >>
> >> leaf foo {
> >>   config false;
> >>   type uint32;
> >> }
> >> rpc oper {
> >>   output {
> >> must "/foo mod foo = 0";
> >> leaf foo {
> >>   type uint32;
> >> }
> >>   }
> >> }
> >> }
> >>
> >> 1. What does the accessible tree look like?
> > Note that the anser to this depends on the outcomne of Y04.  Andy has
> > strong objections to Y04-02, and proposed Y04-04 instead.
> >
> > Assuming Y04-02, and assuming /foo has the value 20 and the oper rpc's
> > result has foo = 10, the accessible tree would look like this:
> >
> >  
> >+-- oper
> >|   +-- foo = 10
> >+-- foo = 20
> >
> >
> > (If we instead move back to Y04-04, the accessible tree would be:
> >
> >  
> >+-- oper
> >+-- foo = 10
> >
> > )
> >
> >> 2. What is the context node for the "must" expression?
> >/oper
>  This change to the accessible tree (1.0 --> 1.1) may break some
>  existing "when" XPath expressions (those under "output" statement).
> >>> Maybe.  The old text said:
> >>>
> >>> o  If the context node represents RPC output parameters, the tree is
> >>>the RPC reply instance document.
> >>>
> >>> So this probably meant that for this definition:
> >>>
> >>>module ex {
> >>>  ...
> >>>  prefix x;
> >>>  ...
> >>>  rpc foo {
> >>>output {
> >>>  leaf bar { ... }
> >>>}
> >>>  }
> >>>}
> >>>
> >>> The accessile tree was:
> >>>
> >>> nc:rpc-reply
> >>>   +-- x:bar
> >>>
> >>> This is very NETCONF-specifc.  With 1.1, the tree would be:
> >>>
> >>> x:foo
> >>>   +-- x:bar
> >>>
> >>> which is protocol-neutral.
> >>>
>  Is
>  this compatible with 1.1 charter - "All compliant YANG 1.0 modules
>  must be accepted as compliant YANG 1.1 modules"?
> 
> rpc my-rpc {
>   output {
> uses my-stuff {
>   when "specific-param = 'foo'";// 1.0
>  // when "my-rpc/specific-param = 'foo'" // 1.1
> >>> This is not correct.  If a relative path is used, it would be the same
> >>> in 1.0 and 1.1.
> >> I disagree due to current text:
> >>
> >>o  data node: A node in the schema tree that can be instantiated in a
> >>   data tree.  One of container, leaf, leaf-list, list, anydata, and
> >>   anyxml.
> >>
> >>o  If the XPath expression is defined in a substatement to an
> >>   "output" statement in an "rpc" or "action" statement, the
> >>   accessible tree is the RPC or action operation instance, all state
> >>   data in the server, and the running configuration datastore.  The
> >>   root node has top-level data nodes in all modules as children.
> >>   Additionally, for an RPC, the root node also has the node
> >>   representing the RPC operation being defined as a child.  The node
> >>   representing the operation being defined has the operation's
> >>   output parameters as children.
> >>
> >>o  If the "when" statement is a child of a "uses", "choice", or
> >>   "case" statement, then the context node is the closest ancestor
> >>   node to the "uses", "choice", or "case" node that is also a data
> >>   node.  If no such node exists, the context node is the root node.
> >>   The accessible tree is tentatively altered during the processing
> >>   of the XPath expression by removing all instances (if any) of the
> >>   nodes added by the "uses", "choice", or "case" statement.
> >>
> >>
> >> It clearly says that the context node is the root node ("/"), not the
> >> node representing the RPC ("/my-rpc"), which is a child to root
> >> node. The "root node" aka "document root" can only mean a single thing
> >> XPath terminology.
> > RFC 6020 clearly says that the tree is the rpc reply instance
> > document, so it is a different document whose root node coincides with
> > . The problem of 6020bis is that we need a definition
> > that's independent of XML, and that's not so easy, but I agree with
> > Martin that nothing should change for relative paths.
> 
> I'm not against the new accessible tree. That nothing should change
> for relative paths is a given, IMO. So what about absolute location
> paths?
> 
> The previous accessible tree for a "when" express

Re: [netmod] Y02: context node


> On 16 Dec 2015, at 16:17, Jernej Tuljak  wrote:
> 
> Ladislav Lhotka je 16.12.2015 ob 15:10 napisal:
>>> On 16 Dec 2015, at 14:08, Jernej Tuljak  wrote:
>>> 
>>> Martin Bjorklund je 16.12.2015 ob 13:48 napisal:
 Jernej Tuljak  wrote:
> Martin Bjorklund je 25.11.2015 ob 11:16 napisal:
>> Ladislav Lhotka  wrote:
>>> Hi,
>>> 
>>> I'd like to resolve this issue. Here is a complete example (valid, I
>>> believe):
>>> 
>>> module context {
>>>namespace "http://example.com/context";;
>>>prefix ctx;
>>> 
>>>leaf foo {
>>>  config false;
>>>  type uint32;
>>>}
>>>rpc oper {
>>>  output {
>>>must "/foo mod foo = 0";
>>>leaf foo {
>>>  type uint32;
>>>}
>>>  }
>>>}
>>> }
>>> 
>>> 1. What does the accessible tree look like?
>> Note that the anser to this depends on the outcomne of Y04.  Andy has
>> strong objections to Y04-02, and proposed Y04-04 instead.
>> 
>> Assuming Y04-02, and assuming /foo has the value 20 and the oper rpc's
>> result has foo = 10, the accessible tree would look like this:
>> 
>> 
>>   +-- oper
>>   |   +-- foo = 10
>>   +-- foo = 20
>> 
>> 
>> (If we instead move back to Y04-04, the accessible tree would be:
>> 
>> 
>>   +-- oper
>>   +-- foo = 10
>> 
>> )
>> 
>>> 2. What is the context node for the "must" expression?
>>   /oper
> This change to the accessible tree (1.0 --> 1.1) may break some
> existing "when" XPath expressions (those under "output" statement).
 Maybe.  The old text said:
 
o  If the context node represents RPC output parameters, the tree is
   the RPC reply instance document.
 
 So this probably meant that for this definition:
 
   module ex {
 ...
 prefix x;
 ...
 rpc foo {
   output {
 leaf bar { ... }
   }
 }
   }
 
 The accessile tree was:
 
nc:rpc-reply
  +-- x:bar
 
 This is very NETCONF-specifc.  With 1.1, the tree would be:
 
x:foo
  +-- x:bar
 
 which is protocol-neutral.
 
> Is
> this compatible with 1.1 charter - "All compliant YANG 1.0 modules
> must be accepted as compliant YANG 1.1 modules"?
> 
>   rpc my-rpc {
> output {
>   uses my-stuff {
> when "specific-param = 'foo'";// 1.0
> // when "my-rpc/specific-param = 'foo'" // 1.1
 This is not correct.  If a relative path is used, it would be the same
 in 1.0 and 1.1.
>>> I disagree due to current text:
>>> 
>>>   o  data node: A node in the schema tree that can be instantiated in a
>>>  data tree.  One of container, leaf, leaf-list, list, anydata, and
>>>  anyxml.
>>> 
>>>   o  If the XPath expression is defined in a substatement to an
>>>  "output" statement in an "rpc" or "action" statement, the
>>>  accessible tree is the RPC or action operation instance, all state
>>>  data in the server, and the running configuration datastore.  The
>>>  root node has top-level data nodes in all modules as children.
>>>  Additionally, for an RPC, the root node also has the node
>>>  representing the RPC operation being defined as a child.  The node
>>>  representing the operation being defined has the operation's
>>>  output parameters as children.
>>> 
>>>   o  If the "when" statement is a child of a "uses", "choice", or
>>>  "case" statement, then the context node is the closest ancestor
>>>  node to the "uses", "choice", or "case" node that is also a data
>>>  node.  If no such node exists, the context node is the root node.
>>>  The accessible tree is tentatively altered during the processing
>>>  of the XPath expression by removing all instances (if any) of the
>>>  nodes added by the "uses", "choice", or "case" statement.
>>> 
>>> 
>>> It clearly says that the context node is the root node ("/"), not the node 
>>> representing the RPC ("/my-rpc"), which is a child to root node. The "root 
>>> node" aka "document root" can only mean a single thing XPath terminology.
>> RFC 6020 clearly says that the tree is the rpc reply instance document, so 
>> it is a different document whose root node coincides with . The 
>> problem of 6020bis is that we need a definition that's independent of XML, 
>> and that's not so easy, but I agree with Martin that nothing should change 
>> for relative paths.
> 
> I'm not against the new accessible tree. That nothing should change for 
> relative paths is a given, IMO. So what about absolute location paths?
> 
> The previous accessible tree for a "when" expression under "output" was:
> 
> 
>  +- x:bar
> 
> and now it is:
> 
> 
>  +- x:foo
>+- x:bar
> 
> The absolute path to "x:bar" wa

Re: [netmod] Y02: context node

On Wed, Dec 16, 2015 at 7:17 AM, Jernej Tuljak  wrote:

> Ladislav Lhotka je 16.12.2015 ob 15:10 napisal:
>
>> On 16 Dec 2015, at 14:08, Jernej Tuljak  wrote:
>>>
>>> Martin Bjorklund je 16.12.2015 ob 13:48 napisal:
>>>
 Jernej Tuljak  wrote:

> Martin Bjorklund je 25.11.2015 ob 11:16 napisal:
>
>> Ladislav Lhotka  wrote:
>>
>>> Hi,
>>>
>>> I'd like to resolve this issue. Here is a complete example (valid, I
>>> believe):
>>>
>>> module context {
>>> namespace "http://example.com/context";;
>>> prefix ctx;
>>>
>>> leaf foo {
>>>   config false;
>>>   type uint32;
>>> }
>>> rpc oper {
>>>   output {
>>> must "/foo mod foo = 0";
>>> leaf foo {
>>>   type uint32;
>>> }
>>>   }
>>> }
>>> }
>>>
>>> 1. What does the accessible tree look like?
>>>
>> Note that the anser to this depends on the outcomne of Y04.  Andy has
>> strong objections to Y04-02, and proposed Y04-04 instead.
>>
>> Assuming Y04-02, and assuming /foo has the value 20 and the oper rpc's
>> result has foo = 10, the accessible tree would look like this:
>>
>>  
>>+-- oper
>>|   +-- foo = 10
>>+-- foo = 20
>>
>>
>> (If we instead move back to Y04-04, the accessible tree would be:
>>
>>  
>>+-- oper
>>+-- foo = 10
>>
>> )
>>
>> 2. What is the context node for the "must" expression?
>>>
>>/oper
>>
> This change to the accessible tree (1.0 --> 1.1) may break some
> existing "when" XPath expressions (those under "output" statement).
>
 Maybe.  The old text said:

 o  If the context node represents RPC output parameters, the tree is
the RPC reply instance document.

 So this probably meant that for this definition:

module ex {
  ...
  prefix x;
  ...
  rpc foo {
output {
  leaf bar { ... }
}
  }
}

 The accessile tree was:

 nc:rpc-reply
   +-- x:bar

 This is very NETCONF-specifc.  With 1.1, the tree would be:

 x:foo
   +-- x:bar

 which is protocol-neutral.

 Is
> this compatible with 1.1 charter - "All compliant YANG 1.0 modules
> must be accepted as compliant YANG 1.1 modules"?
>
>rpc my-rpc {
>  output {
>uses my-stuff {
>  when "specific-param = 'foo'";// 1.0
> // when "my-rpc/specific-param = 'foo'" // 1.1
>
 This is not correct.  If a relative path is used, it would be the same
 in 1.0 and 1.1.

>>> I disagree due to current text:
>>>
>>>o  data node: A node in the schema tree that can be instantiated in a
>>>   data tree.  One of container, leaf, leaf-list, list, anydata, and
>>>   anyxml.
>>>
>>>o  If the XPath expression is defined in a substatement to an
>>>   "output" statement in an "rpc" or "action" statement, the
>>>   accessible tree is the RPC or action operation instance, all state
>>>   data in the server, and the running configuration datastore.  The
>>>   root node has top-level data nodes in all modules as children.
>>>   Additionally, for an RPC, the root node also has the node
>>>   representing the RPC operation being defined as a child.  The node
>>>   representing the operation being defined has the operation's
>>>   output parameters as children.
>>>
>>>o  If the "when" statement is a child of a "uses", "choice", or
>>>   "case" statement, then the context node is the closest ancestor
>>>   node to the "uses", "choice", or "case" node that is also a data
>>>   node.  If no such node exists, the context node is the root node.
>>>   The accessible tree is tentatively altered during the processing
>>>   of the XPath expression by removing all instances (if any) of the
>>>   nodes added by the "uses", "choice", or "case" statement.
>>>
>>>
>>> It clearly says that the context node is the root node ("/"), not the
>>> node representing the RPC ("/my-rpc"), which is a child to root node. The
>>> "root node" aka "document root" can only mean a single thing XPath
>>> terminology.
>>>
>> RFC 6020 clearly says that the tree is the rpc reply instance document,
>> so it is a different document whose root node coincides with .
>> The problem of 6020bis is that we need a definition that's independent of
>> XML, and that's not so easy, but I agree with Martin that nothing should
>> change for relative paths.
>>
>
> I'm not against the new accessible tree. That nothing should change for
> relative paths is a given, IMO. So what about absolute location paths?
>
> The previous accessible tree for a "when" expression under "output" was:
>
> 
>

Re: [netmod] Y02: context node

2015-12-16 Thread Jernej Tuljak

Ladislav Lhotka je 16.12.2015 ob 15:10 napisal:

On 16 Dec 2015, at 14:08, Jernej Tuljak wrote:

Martin Bjorklund je 16.12.2015 ob 13:48 napisal:

Jernej Tuljak wrote:

Martin Bjorklund je 25.11.2015 ob 11:16 napisal:

Ladislav Lhotka wrote:

Hi,

I'd like to resolve this issue. Here is a complete example (valid, I
believe):

module context {
namespace "http://example.com/context";;
prefix ctx;

leaf foo {
config false;
type uint32;
}
rpc oper {
output {
must "/foo mod foo = 0";
leaf foo {
type uint32;
}
}
}
}

1. What does the accessible tree look like?

Note that the anser to this depends on the outcomne of Y04. Andy has
strong objections to Y04-02, and proposed Y04-04 instead.

Assuming Y04-02, and assuming /foo has the value 20 and the oper rpc's
result has foo = 10, the accessible tree would look like this:

+-- oper
| +-- foo = 10
+-- foo = 20

(If we instead move back to Y04-04, the accessible tree would be:

+-- oper
+-- foo = 10

)

2. What is the context node for the "must" expression?

/oper

This change to the accessible tree (1.0 --> 1.1) may break some
existing "when" XPath expressions (those under "output" statement).

Maybe. The old text said:

o If the context node represents RPC output parameters, the tree is
the RPC reply instance document.

So this probably meant that for this definition:

module ex {
...
prefix x;
...
rpc foo {
output {
leaf bar { ... }
}
}
}

The accessile tree was:

nc:rpc-reply
+-- x:bar

This is very NETCONF-specifc. With 1.1, the tree would be:

x:foo
+-- x:bar

which is protocol-neutral.

Is
this compatible with 1.1 charter - "All compliant YANG 1.0 modules
must be accepted as compliant YANG 1.1 modules"?

rpc my-rpc {
output {
uses my-stuff {
when "specific-param = 'foo'";// 1.0
// when "my-rpc/specific-param = 'foo'" // 1.1

This is not correct. If a relative path is used, it would be the same
in 1.0 and 1.1.

I disagree due to current text:

o data node: A node in the schema tree that can be instantiated in a
data tree. One of container, leaf, leaf-list, list, anydata, and
anyxml.

o If the XPath expression is defined in a substatement to an
"output" statement in an "rpc" or "action" statement, the
accessible tree is the RPC or action operation instance, all state
data in the server, and the running configuration datastore. The
root node has top-level data nodes in all modules as children.
Additionally, for an RPC, the root node also has the node
representing the RPC operation being defined as a child. The node
representing the operation being defined has the operation's
output parameters as children.

o If the "when" statement is a child of a "uses", "choice", or
"case" statement, then the context node is the closest ancestor
node to the "uses", "choice", or "case" node that is also a data
node. If no such node exists, the context node is the root node.
The accessible tree is tentatively altered during the processing
of the XPath expression by removing all instances (if any) of the
nodes added by the "uses", "choice", or "case" statement.

It clearly says that the context node is the root node ("/"), not the node representing the RPC
("/my-rpc"), which is a child to root node. The "root node" aka "document root" can only
mean a single thing XPath terminology.

RFC 6020 clearly says that the tree is the rpc reply instance document, so it is a
different document whose root node coincides with . The problem of
6020bis is that we need a definition that's independent of XML, and that's not so
easy, but I agree with Martin that nothing should change for relative paths.

I'm not against the new accessible tree. That nothing should change for
relative paths is a given, IMO. So what about absolute location paths?

The previous accessible tree for a "when" expression under "output" was:

+- x:bar

and now it is:

+- x:foo
+- x:bar

The absolute path to "x:bar" was:

/x:bar

and is now:

/x:foo/x:bar

and this needs to be taken into account for at least relative paths to
stay the same. Again, the root node is "/" in any case. So the context
node needs to be set explicitly "/x:foo" for this corner case. I dare
say it is not even a corner case. There is a similar YANG pattern to my
"my-rpc" example in ietf-netconf-notifications for a "notification".

Jernej

Lada

Jernej

If an absolute path is used, it would be:

when "/nc:rpc-reply/x:specific-param = 'foo'"; // 1.0
when "/x:my-rpc/x:specific-param = 'foo'"; // 1.1

I wonder if any implementation of 1.0 supports this absolute form.

/martin

}
leaf specific-param {
type string;
}

Re: [netmod] IPR Check: draft-ietf-netmod-rfc6020bis-09

Hi,

I am not aware of any IPR related to draft-ietf-netmod-rfc6020bis-09.


/martin


Juergen Schoenwaelder  wrote:
> This mail starts the IPR poll on draft-ietf-netmod-rfc6020bis-09.
> 
> Are you aware of any IPR that applies to draft-ietf-netmod-rfc6020bis-09?
> If so, has this IPR been disclosed in compliance with IETF IPR rules
> (see RFCs 3979, 4879, 3669 and 5378 for more details)?
> 
> If you are listed as a document author or contributor please respond
> to this email explicitly regardless of whether or not you are aware of
> any relevant IPR. The response needs to be sent to the NETMOD WG
> mailing list. The document will not advance to the next stage until a
> response has been received from each author and contributor.
> 
> If you are on the NETMOD WG email list but are not listed as an author
> or contributor, then please explicitly respond only if you are aware
> of any IPR that has not yet been disclosed in conformance with IETF
> rules.
> 
> /js
> 
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 

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

Re: [netmod] call for consensus to adopt draft-entitydt-netmod-entity as NETMOD WG draft


> On 16 Dec 2015, at 09:55, Benoit Claise  wrote:
> 
> Dear all,
>>> On 15 Dec 2015, at 13:34, Nadeau Thomas  wrote:
>>> 
>>> 
>>> NETMOD:
>>> 
>>> The Broadband Forum and the members of the design team who worked on the
>>> IETF Entity module have asked that the working group considerthe 
>>> ietf-entity YANG module
>>> (currently https://datatracker.ietf.org/doc/draft-entitydt-netmod-entity/ 
>>> which is
>>> still in individual draft status) as a working group item.
>>> 
>>> Should we move to adopt draft-entitydt-netmod-entity as a WG item and
>>> correspondingly add this to the WG charter as a milestone?  Please comment 
>>> by
>>> Tuesday, December 22, 2015 at 9AM EST at which time the WG Chairs will
>>> gauge whether or not there is consensus to move forward with the document.
> Support.
>> I would strongly prefer to finish the existing items first, or at least the 
>> critical ones on which other work depends. Adding more items would mean that 
>> both old and new items receive less attention on the average. We already 
>> have at most one or two reviews per WGLC, and this is IMO insufficient.
> While I understand the concern of work prioritization, one of the issues in 
> NETMOD is that we need to grow the number of people involved in 
> participating/editing/reviewing, and I'm happy to see Dan and Jimmy taking 
> the lead here.

Of course, my comment wasn't directed against this draft in particular, or Dan 
and Jimmy. Unfortunately, the increase in the number of I-Ds doesn't seems to 
be proportional to the increase in the number of reviewers.

Lada

> 
> Regards, Benoit
>> 
>> Lada
>> 
>>> —Tom
>>> 
>>> ___
>>> 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
> 

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




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

[netmod] IPR Check: draft-ietf-netmod-rfc6020bis-09

2015-12-16 Thread Juergen Schoenwaelder

This mail starts the IPR poll on draft-ietf-netmod-rfc6020bis-09.

Are you aware of any IPR that applies to draft-ietf-netmod-rfc6020bis-09?
If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details)?

If you are listed as a document author or contributor please respond
to this email explicitly regardless of whether or not you are aware of
any relevant IPR. The response needs to be sent to the NETMOD WG
mailing list. The document will not advance to the next stage until a
response has been received from each author and contributor.

If you are on the NETMOD WG email list but are not listed as an author
or contributor, then please explicitly respond only if you are aware
of any IPR that has not yet been disclosed in conformance with IETF
rules.

/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] Y02: context node


> On 16 Dec 2015, at 14:08, Jernej Tuljak  wrote:
> 
> Martin Bjorklund je 16.12.2015 ob 13:48 napisal:
>> Jernej Tuljak  wrote:
>>> Martin Bjorklund je 25.11.2015 ob 11:16 napisal:
 Ladislav Lhotka  wrote:
> Hi,
> 
> I'd like to resolve this issue. Here is a complete example (valid, I
> believe):
> 
> module context {
>namespace "http://example.com/context";;
>prefix ctx;
> 
>leaf foo {
>  config false;
>  type uint32;
>}
>rpc oper {
>  output {
>must "/foo mod foo = 0";
>leaf foo {
>  type uint32;
>}
>  }
>}
> }
> 
> 1. What does the accessible tree look like?
 Note that the anser to this depends on the outcomne of Y04.  Andy has
 strong objections to Y04-02, and proposed Y04-04 instead.
 
 Assuming Y04-02, and assuming /foo has the value 20 and the oper rpc's
 result has foo = 10, the accessible tree would look like this:
 
 
   +-- oper
   |   +-- foo = 10
   +-- foo = 20
 
 
 (If we instead move back to Y04-04, the accessible tree would be:
 
 
   +-- oper
   +-- foo = 10
 
 )
 
> 2. What is the context node for the "must" expression?
   /oper
>>> This change to the accessible tree (1.0 --> 1.1) may break some
>>> existing "when" XPath expressions (those under "output" statement).
>> Maybe.  The old text said:
>> 
>>o  If the context node represents RPC output parameters, the tree is
>>   the RPC reply instance document.
>> 
>> So this probably meant that for this definition:
>> 
>>   module ex {
>> ...
>> prefix x;
>> ...
>> rpc foo {
>>   output {
>> leaf bar { ... }
>>   }
>> }
>>   }
>> 
>> The accessile tree was:
>> 
>>nc:rpc-reply
>>  +-- x:bar
>> 
>> This is very NETCONF-specifc.  With 1.1, the tree would be:
>> 
>>x:foo
>>  +-- x:bar
>> 
>> which is protocol-neutral.
>> 
>>> Is
>>> this compatible with 1.1 charter - "All compliant YANG 1.0 modules
>>> must be accepted as compliant YANG 1.1 modules"?
>>> 
>>>   rpc my-rpc {
>>> output {
>>>   uses my-stuff {
>>> when "specific-param = 'foo'";// 1.0
>>> // when "my-rpc/specific-param = 'foo'" // 1.1
>> This is not correct.  If a relative path is used, it would be the same
>> in 1.0 and 1.1.
> 
> I disagree due to current text:
> 
>   o  data node: A node in the schema tree that can be instantiated in a
>  data tree.  One of container, leaf, leaf-list, list, anydata, and
>  anyxml.
> 
>   o  If the XPath expression is defined in a substatement to an
>  "output" statement in an "rpc" or "action" statement, the
>  accessible tree is the RPC or action operation instance, all state
>  data in the server, and the running configuration datastore.  The
>  root node has top-level data nodes in all modules as children.
>  Additionally, for an RPC, the root node also has the node
>  representing the RPC operation being defined as a child.  The node
>  representing the operation being defined has the operation's
>  output parameters as children.
> 
>   o  If the "when" statement is a child of a "uses", "choice", or
>  "case" statement, then the context node is the closest ancestor
>  node to the "uses", "choice", or "case" node that is also a data
>  node.  If no such node exists, the context node is the root node.
>  The accessible tree is tentatively altered during the processing
>  of the XPath expression by removing all instances (if any) of the
>  nodes added by the "uses", "choice", or "case" statement.
> 
> 
> It clearly says that the context node is the root node ("/"), not the node 
> representing the RPC ("/my-rpc"), which is a child to root node. The "root 
> node" aka "document root" can only mean a single thing XPath terminology.

RFC 6020 clearly says that the tree is the rpc reply instance document, so it 
is a different document whose root node coincides with . The problem 
of 6020bis is that we need a definition that's independent of XML, and that's 
not so easy, but I agree with Martin that nothing should change for relative 
paths.

Lada 

> 
> Jernej
> 
>> 
>> If an absolute path is used, it would be:
>> 
>>when "/nc:rpc-reply/x:specific-param = 'foo'"; // 1.0
>>when "/x:my-rpc/x:specific-param = 'foo'"; // 1.1
>> 
>> 
>> I wonder if any implementation of 1.0 supports this absolute form.
>> 
>> 
>> /martin
>> 
>> 
>>>   }
>>>   leaf specific-param {
>>> type string;
>>>   }
>>> }
>>>   }
>>> 
>>> Jernej
>>> 
 /martin
 
 
 
> Thanks, Lada
> 
> Martin Bjorklund  writes:
> 
>> Ladislav Lhotka  wrote:
>>> Hi,
>>> 
>>> Y02-01 allows "must" as a substatement of "input", "output" and
>>> "notification" but for these cases the specifi

Re: [netmod] IPR Check: draft-ietf-netmod-opstate-reqs-01

2015-12-16 Thread Robert Wilton


I have no nor know of any IPR Claims against this document.

Thanks,
Rob


On 16/12/2015 13:13, Nadeau Thomas wrote:

This mail starts the IPR poll on draft-ietf-netmod-opstate-reqs-01.

Are you aware of any IPR that applies to draft-ietf-netmod-opstate-reqs-01?
If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs
3979, 4879, 3669 and 5378 for more details)?

If you are listed as a document author or contributor please respond to this
email explicitly regardless of whether or not you are aware of any relevant IPR.
The response needs to be sent to the NETMOD WG mailing list.  The document
will not advance to the next stage until a response has been received from each
author and contributor.

If you are on the NETMOD WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of any IPR 
that
has not yet been disclosed in conformance with IETF rules.

Thank you,

Kent and Tom, NETMOD WG Chairs

___
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] call for consensus to adopt draft-entitydt-netmod-entity as NETMOD WG draft

2015-12-16 Thread Benoit Claise


Hi Tom,

Good question. I should have made it clear. Sorry.
"While I understand the concern of work prioritization, one of the 
issues in NETMOD is that we need to grow the number of people involved 
in participating/editing/reviewing, and I'm happy to see Dan and Jimmy 
taking the lead here." This remark is done as OPS AD.


Also, I discussed, as OPS AD, with the chairs, having an identity YANG 
model design team in the past.

However, my "support" below is an individual.

Regards, Benoit

On Dec 16, 2015:3:55 AM, at 3:55 AM, Benoit Claise  wrote:

Dear all,

On 15 Dec 2015, at 13:34, Nadeau Thomas  wrote:


NETMOD:

The Broadband Forum and the members of the design team who worked on the
IETF Entity module have asked that the working group considerthe ietf-entity 
YANG module
(currently https://datatracker.ietf.org/doc/draft-entitydt-netmod-entity/ which 
is
still in individual draft status) as a working group item.

Should we move to adopt draft-entitydt-netmod-entity as a WG item and
correspondingly add this to the WG charter as a milestone?  Please comment by
Tuesday, December 22, 2015 at 9AM EST at which time the WG Chairs will
gauge whether or not there is consensus to move forward with the document.

Support.

I would strongly prefer to finish the existing items first, or at least the 
critical ones on which other work depends. Adding more items would mean that 
both old and new items receive less attention on the average. We already have 
at most one or two reviews per WGLC, and this is IMO insufficient.

While I understand the concern of work prioritization, one of the issues in 
NETMOD is that we need to grow the number of people involved in 
participating/editing/reviewing, and I'm happy to see Dan and Jimmy taking the 
lead here.

Regards, Benoit

Are you speaking as AD or as an individual?

—Tom



Lada


—Tom

___
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 mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] IPR Check: draft-ietf-netmod-opstate-reqs-01


I have no nor know of any IPR Claims against this document.

—Tom (speaking as an individual contributor)



> On Dec 16, 2015:8:13 AM, at 8:13 AM, Nadeau Thomas  
> wrote:
> 
> This mail starts the IPR poll on draft-ietf-netmod-opstate-reqs-01.
> 
> Are you aware of any IPR that applies to draft-ietf-netmod-opstate-reqs-01?
> If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs
> 3979, 4879, 3669 and 5378 for more details)?
> 
> If you are listed as a document author or contributor please respond to this
> email explicitly regardless of whether or not you are aware of any relevant 
> IPR.
> The response needs to be sent to the NETMOD WG mailing list.  The document
> will not advance to the next stage until a response has been received from 
> each
> author and contributor.
> 
> If you are on the NETMOD WG email list but are not listed as an author or
> contributor, then please explicitly respond only if you are aware of any IPR 
> that
> has not yet been disclosed in conformance with IETF rules.
> 
> Thank you,
> 
> Kent and Tom, NETMOD WG Chairs
> 
> ___
> 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] IPR Check: draft-ietf-netmod-opstate-reqs-01

This mail starts the IPR poll on draft-ietf-netmod-opstate-reqs-01.

Are you aware of any IPR that applies to draft-ietf-netmod-opstate-reqs-01?
If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs
3979, 4879, 3669 and 5378 for more details)?

If you are listed as a document author or contributor please respond to this
email explicitly regardless of whether or not you are aware of any relevant IPR.
The response needs to be sent to the NETMOD WG mailing list.  The document
will not advance to the next stage until a response has been received from each
author and contributor.

If you are on the NETMOD WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of any IPR 
that
has not yet been disclosed in conformance with IETF rules.

Thank you,

Kent and Tom, NETMOD WG Chairs

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

[netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01


This is a WG Last Call on draft-ietf-netmod-opstate-reqs-01.
Please post comments on this draft by Wednesday, December 30, 2015
at 9AM EST.

Tom/Kent


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

Re: [netmod] Y02: context node

2015-12-16 Thread Jernej Tuljak


Martin Bjorklund je 16.12.2015 ob 13:48 napisal:

Jernej Tuljak  wrote:

Martin Bjorklund je 25.11.2015 ob 11:16 napisal:

Ladislav Lhotka  wrote:

Hi,

I'd like to resolve this issue. Here is a complete example (valid, I
believe):

module context {
namespace "http://example.com/context";;
prefix ctx;

leaf foo {
  config false;
  type uint32;
}
rpc oper {
  output {
must "/foo mod foo = 0";
leaf foo {
  type uint32;
}
  }
}
}

1. What does the accessible tree look like?

Note that the anser to this depends on the outcomne of Y04.  Andy has
strong objections to Y04-02, and proposed Y04-04 instead.

Assuming Y04-02, and assuming /foo has the value 20 and the oper rpc's
result has foo = 10, the accessible tree would look like this:

 
   +-- oper
   |   +-- foo = 10
   +-- foo = 20


(If we instead move back to Y04-04, the accessible tree would be:

 
   +-- oper
   +-- foo = 10

)


2. What is the context node for the "must" expression?

   /oper

This change to the accessible tree (1.0 --> 1.1) may break some
existing "when" XPath expressions (those under "output" statement).

Maybe.  The old text said:

o  If the context node represents RPC output parameters, the tree is
   the RPC reply instance document.

So this probably meant that for this definition:

   module ex {
 ...
 prefix x;
 ...
 rpc foo {
   output {
 leaf bar { ... }
   }
 }
   }

The accessile tree was:

nc:rpc-reply
  +-- x:bar

This is very NETCONF-specifc.  With 1.1, the tree would be:

x:foo
  +-- x:bar

which is protocol-neutral.


Is
this compatible with 1.1 charter - "All compliant YANG 1.0 modules
must be accepted as compliant YANG 1.1 modules"?

   rpc my-rpc {
 output {
   uses my-stuff {
 when "specific-param = 'foo'";// 1.0
// when "my-rpc/specific-param = 'foo'" // 1.1

This is not correct.  If a relative path is used, it would be the same
in 1.0 and 1.1.


I disagree due to current text:

   o  data node: A node in the schema tree that can be instantiated in a
  data tree.  One of container, leaf, leaf-list, list, anydata, and
  anyxml.

   o  If the XPath expression is defined in a substatement to an
  "output" statement in an "rpc" or "action" statement, the
  accessible tree is the RPC or action operation instance, all state
  data in the server, and the running configuration datastore.  The
  root node has top-level data nodes in all modules as children.
  Additionally, for an RPC, the root node also has the node
  representing the RPC operation being defined as a child.  The node
  representing the operation being defined has the operation's
  output parameters as children.

   o  If the "when" statement is a child of a "uses", "choice", or
  "case" statement, then the context node is the closest ancestor
  node to the "uses", "choice", or "case" node that is also a data
  node.  If no such node exists, the context node is the root node.
  The accessible tree is tentatively altered during the processing
  of the XPath expression by removing all instances (if any) of the
  nodes added by the "uses", "choice", or "case" statement.


It clearly says that the context node is the root node ("/"), not the 
node representing the RPC ("/my-rpc"), which is a child to root node. 
The "root node" aka "document root" can only mean a single thing  XPath 
terminology.


Jernej



If an absolute path is used, it would be:

when "/nc:rpc-reply/x:specific-param = 'foo'"; // 1.0
when "/x:my-rpc/x:specific-param = 'foo'"; // 1.1


I wonder if any implementation of 1.0 supports this absolute form.


/martin



   }
   leaf specific-param {
 type string;
   }
 }
   }

Jernej


/martin




Thanks, Lada

Martin Bjorklund  writes:


Ladislav Lhotka  wrote:

Hi,

Y02-01 allows "must" as a substatement of "input", "output" and
"notification" but for these cases the specification of the context
node in sec. 7.5.3 doesn't work.

 o  The context node is the node in the accessible tree for which the
"must" statement is defined.

You are right.  But note how the accessible tree is defined.  There is
a node for the operation / notification.  This node should be the
context node:

 o  If the "must" statement is a substatement of a "notification"
statement, the context node is the node representing the
notification in the accessible tree.

 o  If the "must" statement is a substatement of a "input"
statement, the context node is the node representing the
operation in the accessible tree.

 o  If the "must" statement is a substatement of a "output"
statement, the context node is the node representing the
operation in the accessible tree.


/martin

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


___

Re: [netmod] call for consensus to adopt draft-entitydt-netmod-entity as NETMOD WG draft


> On Dec 16, 2015:3:55 AM, at 3:55 AM, Benoit Claise  wrote:
> 
> Dear all,
>>> On 15 Dec 2015, at 13:34, Nadeau Thomas  wrote:
>>> 
>>> 
>>> NETMOD:
>>> 
>>> The Broadband Forum and the members of the design team who worked on the
>>> IETF Entity module have asked that the working group considerthe 
>>> ietf-entity YANG module
>>> (currently https://datatracker.ietf.org/doc/draft-entitydt-netmod-entity/ 
>>> which is
>>> still in individual draft status) as a working group item.
>>> 
>>> Should we move to adopt draft-entitydt-netmod-entity as a WG item and
>>> correspondingly add this to the WG charter as a milestone?  Please comment 
>>> by
>>> Tuesday, December 22, 2015 at 9AM EST at which time the WG Chairs will
>>> gauge whether or not there is consensus to move forward with the document.
> Support.
>> I would strongly prefer to finish the existing items first, or at least the 
>> critical ones on which other work depends. Adding more items would mean that 
>> both old and new items receive less attention on the average. We already 
>> have at most one or two reviews per WGLC, and this is IMO insufficient.
> While I understand the concern of work prioritization, one of the issues in 
> NETMOD is that we need to grow the number of people involved in 
> participating/editing/reviewing, and I'm happy to see Dan and Jimmy taking 
> the lead here.
> 
> Regards, Benoit

Are you speaking as AD or as an individual?

—Tom


>> 
>> Lada
>> 
>>> —Tom
>>> 
>>> ___
>>> 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 mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Y02: context node