[netmod] netmod - Requested sessions have been scheduled for IETF 95

["IETF Secretariat"]

Dear Kent Watsen,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request. 

netmod Session 1 (2:00:00)
Monday, Afternoon Session III 1740-1940
Room Name: Atlantico C size: 225
-
netmod Session 2 (2:00:00)
Monday, Afternoon Session II 1550-1720
Room Name: Atlantico C size: 225
-



Request Information:


-
Working Group Name: NETCONF Data Modeling Language
Area Name: Operations and Management Area
Session Requester: Kent Watsen

Number of Sessions: 2
Length of Session(s):  2 Hours, 2 Hours
Number of Attendees: 100
Conflicts to Avoid: 
 First Priority: netconf rtgwg
 Second Priority: i2rs



Special Requests:
  
-

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

Re: [netmod] 'Namespace Qualified' in draft-ietf-netmod-yang-json-08

[Rob Shakir]

Thanks Lada and others for the responses here. Much clearer to me.

r.


On 4 March, 2016 at 5:05:03 AM, Ladislav Lhotka (lho...@nic.cz) wrote:

Hi Rob,  

Rob Shakir  writes:  

> Hi NETMOD,  
>  
> I am in the process of implementing draft-ietf-netmod-yang-json–08, and had 
> some queries as to the content. Hopefully there is some misunderstanding on 
> my part, or it helps to clean up the text for future people 
> reviewing/implementing.  
>  
> The phrase ‘namespace-qualified’ seems to have some ambiguity through the 
> document. For example, in the case that we have two modules:  
>  
> module mod-a {  
> prefix "pfx-a";  
> namespace "http://a.tld;;  
>  
> container container-a {  
> leaf leaf-a {  
> type string;  
> }  
>  
> leaf ref-a {  
> type identityref {  
> base SOME_IDENTITY;  
> }  
> }  
> }  
> }  
>  
> module mod-b {  
> prefix "pfx-b";  
> namespace "http://b.tld;;  
>  
> container container-b {  
> leaf leaf-b {  
> type string;  
> }  
>  
> leaf ref-b {  
> type identityref {  
> base SOME_IDENTITY;  
> }  
> }  
> }  
> }  
> Then, AIUI, the encoding needs to specify the names of the modules for  
> both container-a and container-b (since they sit at the  
> root; and are in different namespaces) - so we encode  
> these as JSON objects named mod-a:container-a and  
> mod-b:container-b as per Section 4 of the document.  

Correct.  

>  
> In this case, we never use the actual namespace (i.e., http://a.tld  
> and http://b.tld) so calling it ‘namespace qualified’ appears  
> ambiguous. Should it be simply referred to as ‘module-qualified’?  

Namespaces (= sets of names) as defined by YANG are  
encoding-independent. However, XML and JSON use different namespace  
identifiers. XML uses naturally the mechanism of [XML-NAMES], i.e. namespace 
URIs  
and references via declared prefixes. JSON in general doesn't support  
namespaced member names, but we could conveniently use the module name  
as the namespace identifier. So this is what Sec. 4 defines:  

The name of a module determines the namespace of all data node names  
defined in that module. If a data node is defined in a submodule,  
then the namespace-qualified member name uses the name of the main  
module to which the submodule belongs.  

This is then later extended to other named entities such as identities.  
>  
> Secondarily, the example in Section 6.8 does not actually use the name  
> of the module, it rather uses the prefix (if for the interface-type  
> leaf). This doesn’t seem to be explained anywhere within the text. Is  
> this a mistake?  

No, it's correct. YANG adopted the XML namespace rules, so declared  
prefixes are used in YANG modules. The JSON-encoded name of the identity  
uses the rules of the yang-json document, i.e. module name as the  
namespace identifier.  

> It seems to me that using the module name consistently throughout the  
> encoding is preferable, since this cannot be different in a number of  
> places; and isn’t as long as the namespace value to make readability  
> worse.  

Module name is used consistently in JSON encoding, but we have to use  
YANG rules when dealing with YANG modules.  

It is somewhat confusing but I believe this is the best solution we  
could come up with.  

>  
> I also didn’t understand why an identityref value encodes the  
> namespace in the actual value? It seems like the “base” of the  
> identityref should qualify all possible values here; with the only  
> case that we would ever need this is one where we have:  

I think Per explained this part nicely.  

Thanks, Lada  

>  
> leaf some-reference {  
> type union {  
> type identityref {  
> base "a";  
> }  
> type identityref {  
> base "b";  
> }  
> }  
> }  
> And a and b both define a value with the same name (where one needs the 
> prefix to be able to refer to the b version).  
>  
> Thanks,  
> r.  
> ___  
> 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] I-D Action: draft-ietf-netmod-acl-model-07.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the NETCONF Data Modeling Language of the IETF.

Title   : Network Access Control List (ACL) YANG Data Model
Authors : Dean Bogdanovic
  Kiran Agrahara Sreenivasa
  Lisa Huang
  Dana Blair
Filename: draft-ietf-netmod-acl-model-07.txt
Pages   : 27
Date: 2016-03-11

Abstract:
   This document describes a data model of Access Control List (ACL)
   basic building blocks.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-netmod-acl-model-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-acl-model-07


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

Re: [netmod] action and mandatory node

[Andy Bierman]

On Fri, Mar 11, 2016 at 9:11 AM, t.petch  wrote:

> Given
>
> container... list... action
>
> with the usual twiddly brackets, and a separate mandatory data node
> alongside the list in the top level container, is there a requirement to
> include that mandatory data node in the XML RPC?
>
> 6020bis s.7.15.2 says
>
> " The "action" element contains an hierarchy of nodes that identifies
>the node in the datastore.  It MUST contain all containers and list
>nodes from the top level down to the list or container containing the
>action.  "
>
> which suggests, without quite clearly telling me, that it is only the
> nodes in the direct path from the top level that have to be included,
> not any off to one side in the tree.
>
> If that is correct, I suggest
>
> OLD
> "It MUST contain all containers and list
>nodes from the top level down to the list or container containing the
>action.  "
> NEW
> " It MUST contain all containers and list
>nodes in the direct path from the top level down to the list or
> container containing the  action (node).  "
>
>
The more precise term in YANG Xpath would be "ancestor data nodes"



> Tom Petch
>
>

Andy


> ___
> 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] Gen-Art LC review: draft-ietf-netmod-yang-metadata-04

[Juergen Schoenwaelder]

I assume 'An annotation carries a single value.' should be clear
enough. A reference to section 7.6 is actually misleading since
that section deals with many more things that are not applicable
to leafs. But I think we are already done with this.

/js

On Fri, Mar 11, 2016 at 04:39:54PM +, tom p. wrote:
> - Original Message -
> From: "Juergen Schoenwaelder" 
> Sent: Friday, March 11, 2016 1:07 PM
> 
> 
> > On Fri, Mar 11, 2016 at 11:15:28AM +, tom p. wrote:
> > > Lada, Robert
> > >
> > > The other angle from which this might be approached is that the I-D
> > > already says
> > >
> > > "   Using the "type" statement, a type is specified for the
> annotation
> > >value according to the same rules as for YANG "leaf" type. "
> > >
> > > while rfc6020bis says
> > >
> > > "   The "leaf" statement is used to define a scalar variable of a
> > >particular built-in or derived type."
> > >
> > > so if you know your YANG off by heart, then you will know that
> > > annotations must be scalar.  I agree that the text needs to be
> clearer.
> > > Perhaps,
> > > OLD
> > > "   o  annotations are scalar values and cannot be further
> structured;"
> > > NEW
> > > "Annotations obey the same rules as for a YANG "leaf" type
> [rfc6020bis
> > > s.7.6] and so are limited to scalar variables."
> >
> > There is no 'leaf type' in YANG. YANG has leaf nodes in the schema
> > tree. An annotation is not a node in the schema tree. Perhaps
> > something like this:
> 
> Juergen
> 
> Well, I know, but I was quoting directly from yang-metadata-04 s.3,
> namely
> 
> "Using the "type" statement, a type is specified for the annotation
>value according to the same rules as for YANG "leaf" type. "
> 
> which is why I gave a reference to s7.6 of RFC6020bis rather than s.7.4.
> 
> Perhaps change s.3 in addition to your change
> 
> OLD
>Using the "type" statement, a type is specified for the annotation
>value according to the same rules as for YANG "leaf" type.
> NEW
>Using the "type" statement, a type is specified for the annotation
>value according to the same rules as for the type of a YANG
> "leaf"[RFC6020bis s.7.6].
> 
> I do think that that mention of leaf is helpful - as you say, the WG
> agreed to this restriction as opposed to allowing more complex
> annotations and referencing "leaf" for me makes that clearer.
> 
> Tom Petch
> 
> >   An annotation carries a single value. The type substatement, which
> >   must be present, takes as an argument the name of an existing
> >   built-in or derived type and the value of the annotation must match
> >   this type. See Section 7.4 of [RFC6020bis] for details.
> >
> > /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] action and mandatory node

[t . petch]

Given

container... list... action

with the usual twiddly brackets, and a separate mandatory data node
alongside the list in the top level container, is there a requirement to
include that mandatory data node in the XML RPC?

6020bis s.7.15.2 says

" The "action" element contains an hierarchy of nodes that identifies
   the node in the datastore.  It MUST contain all containers and list
   nodes from the top level down to the list or container containing the
   action.  "

which suggests, without quite clearly telling me, that it is only the
nodes in the direct path from the top level that have to be included,
not any off to one side in the tree.

If that is correct, I suggest

OLD
"It MUST contain all containers and list
   nodes from the top level down to the list or container containing the
   action.  "
NEW
" It MUST contain all containers and list
   nodes in the direct path from the top level down to the list or
container containing the  action (node).  "

Tom Petch

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

Re: [netmod] Gen-Art LC review: draft-ietf-netmod-yang-metadata-04

[tom p .]

- Original Message -
From: "Juergen Schoenwaelder" 
Sent: Friday, March 11, 2016 1:07 PM


> On Fri, Mar 11, 2016 at 11:15:28AM +, tom p. wrote:
> > Lada, Robert
> >
> > The other angle from which this might be approached is that the I-D
> > already says
> >
> > "   Using the "type" statement, a type is specified for the
annotation
> >value according to the same rules as for YANG "leaf" type. "
> >
> > while rfc6020bis says
> >
> > "   The "leaf" statement is used to define a scalar variable of a
> >particular built-in or derived type."
> >
> > so if you know your YANG off by heart, then you will know that
> > annotations must be scalar.  I agree that the text needs to be
clearer.
> > Perhaps,
> > OLD
> > "   o  annotations are scalar values and cannot be further
structured;"
> > NEW
> > "Annotations obey the same rules as for a YANG "leaf" type
[rfc6020bis
> > s.7.6] and so are limited to scalar variables."
>
> There is no 'leaf type' in YANG. YANG has leaf nodes in the schema
> tree. An annotation is not a node in the schema tree. Perhaps
> something like this:

Juergen

Well, I know, but I was quoting directly from yang-metadata-04 s.3,
namely

"Using the "type" statement, a type is specified for the annotation
   value according to the same rules as for YANG "leaf" type. "

which is why I gave a reference to s7.6 of RFC6020bis rather than s.7.4.

Perhaps change s.3 in addition to your change

OLD
   Using the "type" statement, a type is specified for the annotation
   value according to the same rules as for YANG "leaf" type.
NEW
   Using the "type" statement, a type is specified for the annotation
   value according to the same rules as for the type of a YANG
"leaf"[RFC6020bis s.7.6].

I do think that that mention of leaf is helpful - as you say, the WG
agreed to this restriction as opposed to allowing more complex
annotations and referencing "leaf" for me makes that clearer.

Tom Petch

>   An annotation carries a single value. The type substatement, which
>   must be present, takes as an argument the name of an existing
>   built-in or derived type and the value of the annotation must match
>   this type. See Section 7.4 of [RFC6020bis] for details.
>
> /js
>

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

Re: [netmod] yang-next

[Lou Berger]

I tried and failed to  the repo to email events to the list.

If anyone knows how to do this, please send mail to netmod-cha...@ietf.org.

Thanks,
Lou


On 3/11/2016 5:17 AM, Martin Bjorklund wrote:
> I think it is a good idea to capture ideas like this, but I also think
> that such ideas should be discussed on the ML.


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

[netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-metadata-06.txt

[Ladislav Lhotka]

Hi,

this revision contains minor clarifications regarding the type of annotations, 
mainly based on Juergen's suggestion.

Thanks, Lada

> Begin forwarded message:
> 
> From: internet-dra...@ietf.org
> Subject: New Version Notification for draft-ietf-netmod-yang-metadata-06.txt
> Date: 11 March 2016 at 16:57:42 GMT+1
> To: "Ladislav Lhotka" 
> 
> 
> A new version of I-D, draft-ietf-netmod-yang-metadata-06.txt
> has been successfully submitted by Ladislav Lhotka and posted to the
> IETF repository.
> 
> Name: draft-ietf-netmod-yang-metadata
> Revision: 06
> Title:Defining and Using Metadata with YANG
> Document date:2016-03-11
> Group:netmod
> Pages:20
> URL:
> https://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-metadata-06.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-metadata/
> Htmlized:   https://tools.ietf.org/html/draft-ietf-netmod-yang-metadata-06
> Diff:   
> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-metadata-06
> 
> Abstract:
>   This document defines a YANG extension statement that allows for
>   defining metadata annotations in YANG modules.  The document also
>   specifies XML and JSON encoding of annotations and other rules for
>   annotating instances of YANG data nodes.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 

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

[Kent Watsen]

>I think it is a good idea to capture ideas like this, but I also think
>that such ideas should be discussed on the ML.  But maybe that's what
>you meant.


My thought is to defer any discussion on the ML until we actually want to start 
working on yang-next.  That said, it would be good to ensure that any issues 
posted in the interim are suitably captured; that what’s being asked for is 
clearly understood.   Of course, we could at a later point in time reach out to 
the github userid to ask for a clarification and, in the case of no response, 
either do our best or drop it.  To me, it is sufficient to just capture the 
ideas, with no discussion happening until later and then, of course, they would 
be on the ML.

Thanks,
Kent

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

Re: [netmod] Gen-Art LC review: draft-ietf-netmod-yang-metadata-04

[Robert Sparks]

Yes, thanks.

On 3/11/16 9:04 AM, Ladislav Lhotka wrote:

On 11 Mar 2016, at 14:07, Juergen Schoenwaelder 
 wrote:

On Fri, Mar 11, 2016 at 11:15:28AM +, tom p. wrote:

Lada, Robert

The other angle from which this might be approached is that the I-D
already says

"   Using the "type" statement, a type is specified for the annotation
   value according to the same rules as for YANG "leaf" type. "

while rfc6020bis says

"   The "leaf" statement is used to define a scalar variable of a
   particular built-in or derived type."

so if you know your YANG off by heart, then you will know that
annotations must be scalar.  I agree that the text needs to be clearer.
Perhaps,
OLD
"   o  annotations are scalar values and cannot be further structured;"
NEW
"Annotations obey the same rules as for a YANG "leaf" type [rfc6020bis
s.7.6] and so are limited to scalar variables."

There is no 'leaf type' in YANG. YANG has leaf nodes in the schema
tree. An annotation is not a node in the schema tree. Perhaps
something like this:

  An annotation carries a single value. The type substatement, which
  must be present, takes as an argument the name of an existing
  built-in or derived type and the value of the annotation must match
  this type. See Section 7.4 of [RFC6020bis] for details.

Looks good, thanks. Robert, Tom, do you think this text is sufficient?

Lada


/js

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

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






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

Re: [netmod] Gen-Art LC review: draft-ietf-netmod-yang-metadata-04

[Ladislav Lhotka]

> On 11 Mar 2016, at 14:07, Juergen Schoenwaelder 
>  wrote:
> 
> On Fri, Mar 11, 2016 at 11:15:28AM +, tom p. wrote:
>> Lada, Robert
>> 
>> The other angle from which this might be approached is that the I-D
>> already says
>> 
>> "   Using the "type" statement, a type is specified for the annotation
>>   value according to the same rules as for YANG "leaf" type. "
>> 
>> while rfc6020bis says
>> 
>> "   The "leaf" statement is used to define a scalar variable of a
>>   particular built-in or derived type."
>> 
>> so if you know your YANG off by heart, then you will know that
>> annotations must be scalar.  I agree that the text needs to be clearer.
>> Perhaps,
>> OLD
>> "   o  annotations are scalar values and cannot be further structured;"
>> NEW
>> "Annotations obey the same rules as for a YANG "leaf" type [rfc6020bis
>> s.7.6] and so are limited to scalar variables."
> 
> There is no 'leaf type' in YANG. YANG has leaf nodes in the schema
> tree. An annotation is not a node in the schema tree. Perhaps
> something like this:
> 
>  An annotation carries a single value. The type substatement, which
>  must be present, takes as an argument the name of an existing
>  built-in or derived type and the value of the annotation must match
>  this type. See Section 7.4 of [RFC6020bis] for details.

Looks good, thanks. Robert, Tom, do you think this text is sufficient? 

Lada

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

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




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

[netmod] features - a Cartesian explosion

[t . petch]

One of my comments on syslog was that it had 10 features.  Assuming that
each can be present or absent, that would seem to allow over 1000
different possible implementations, almost all of which will likely
never be seen in the field.

And yet, if there are 1000 possible implementations, does not that mean
having to code 1000 different paths, having to test 1000 different
possibilities, never having two interworking boxes unless they are the
same model with the same software level from the same manufacturer?

It is so easy to add 'feature' to a YANG model; is some restraint called
for?

Tom Petch

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

Re: [netmod] Broadband Forum questions about announcing capabilities

[Bogaert, Bart (Nokia - BE)]

Hi,

 

It is my understanding that “narrowing” the possibilities (e.g. range) of a 
leaf is acceptable and even the Best Practices document RFC6087bis-05 suggests 
this in section 5.19.  So why would this approach not be approved? These 
limitations could be the result of e.g. memory constraints of the box and one 
might want to expose this to the client accepting configurations changes in 
case the target device would temporarily not be available (some kind of 
pre-provisioning by the NETCONF client running on a network management 
platform).

 

Best regards - Vriendelijke groeten,

Bart Bogaert

System Architect Data-Centric SW Architectures 

Fixed Networks - Broadband Access BU,  Nokia

Contact number +32 3 2408310 (+32 477 673952)

 

From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of EXT William Lupton
Sent: 11 March 2016 11:14
To: netmod@ietf.org
Subject: [netmod] Broadband Forum questions about announcing capabilities

 

All,

 

BBF has a question about how to announce capabilities. This is illustrated by a 
specific example but it’s a general question. There is some overlap with past 
“Broadband Forum questions on RFC 6087bis 
 ” 
and “Restricting interface name maximum length and character set 
 ” 
threads.

 

Here’s the example. We have a list of profiles and we want the server to be 
able to indicate the maximum number of supported profiles. The two ways that we 
have considered doing this are:

1.  Add a leaf that indicates the maximum number of supported profiles.
2.  Use a deviation to indicate max-elements on the profile list.

 

We have got the impression from the RFCs and past discussion (cited above) that 
NETMOD’s preferred approach is the first one, and you would not approve of the 
second one. Is that correct? Any other thoughts?

 

Note that use of deviations in this way is not contravening RFC 6020bis’s 
“deviations MUST never be part of a published standard” because our published 
YANG will not include deviations. We would be using them only in the sense that 
they would be the recommended way for an implementation to announce its 
capabilities. Strictly (in the example given above) this is a deviation from 
the standard because an unspecified max-elements statement defaults to 
“unbounded”.

 

Thanks,

William Lupton



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Broadband Forum questions about announcing capabilities

[William Lupton]

All,

BBF has a question about how to announce capabilities. This is illustrated by a 
specific example but it’s a general question. There is some overlap with past 
“Broadband Forum questions on RFC 6087bis 
” and 
“Restricting interface name maximum length and character set 
” 
threads.

Here’s the example. We have a list of profiles and we want the server to be 
able to indicate the maximum number of supported profiles. The two ways that we 
have considered doing this are:
Add a leaf that indicates the maximum number of supported profiles.
Use a deviation to indicate max-elements on the profile list.

We have got the impression from the RFCs and past discussion (cited above) that 
NETMOD’s preferred approach is the first one, and you would not approve of the 
second one. Is that correct? Any other thoughts?

Note that use of deviations in this way is not contravening RFC 6020bis’s 
“deviations MUST never be part of a published standard” because our published 
YANG will not include deviations. We would be using them only in the sense that 
they would be the recommended way for an implementation to announce its 
capabilities. Strictly (in the example given above) this is a deviation from 
the standard because an unspecified max-elements statement defaults to 
“unbounded”.

Thanks,
William Lupton___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-metadata-05.txt

[Ladislav Lhotka]

> On 10 Mar 2016, at 17:57, Andy Bierman  wrote:
> 
> 
> 
> On Thu, Mar 10, 2016 at 4:18 AM, Ladislav Lhotka  wrote:
> 
> > On 10 Mar 2016, at 12:34, Robert Wilton  wrote:
> >
> >
> >
> > On 10/03/2016 11:19, Martin Bjorklund wrote:
> >> Ladislav Lhotka  wrote:
>  On 10 Mar 2016, at 11:16, Juergen Schoenwaelder
>   wrote:
> 
>  On Thu, Mar 10, 2016 at 10:49:33AM +0100, Ladislav Lhotka wrote:
> >> On 10 Mar 2016, at 10:18, Juergen Schoenwaelder
> >>  wrote:
> >>
> >> On Thu, Mar 10, 2016 at 09:44:04AM +0100, Ladislav Lhotka wrote:
> >>> Hi,
> >>>
> >>> this revision is based on the IETF LC. In particular, Robert Sparks
> >>> suggested in his Gen-ART LC review to include an explanation as to why
> >>> we chose a YANG extension rather than a built-in statement. I added a
> >>> paragraph at the end of Introduction, please have a look, I hope it's
> >>> a fair account that shouldn't cause any controversy.
> >>>
> >> I think it is a feature to use extensions for new statements that do
> >> not have to be in the core. Modularity is a good thing, the YANG
> >> 1.1. specification is already 200 papges. When adding new statements,
> >> we should rather ask the question 'can this not also be done using
> >> extensions'?
> > I am not convinced about that. If we have a host of "standard"
> > extensions (annotation, complex-type and co., mount-point,
> > mount-module, you name them), every module author then may choose a
> > subset of extensions for use in the module
> >> Sure.  The author will use the subset of core statement + extensions
> >> that is needed.  If the module doesn't need meta-data, it won't be
> >> used regardless of if it's a core statement or an extension.
> >>
> > and then the value of YANG
> > as a standard data modelling language would be gone.
> >
>  There will be a natural filter; things that are widely used will be
>  widely supported, things that are not widely supported will not be
>  widely used. We have the same with protocols and protocol extensions,
> >>> Asymptotically, yes. But the modules developed in the meantime will be
> >>> a mess.
> >> I disagree.  I agree w/ Juergen that defining extensions when it is
> >> possible is a feature.
> > I actually also agree with Juergen and Martin.
> >
> > I see that the one of the advantages of using extensions is that it allows 
> > them to evolve independently and more quickly than the base draft.  And I 
> > would think that it is easier to deprecate an old extension if it was 
> > superseded by a better approach.
> 
> This would all be fine as long as modules developed with such extensions stay 
> experimental, too.
> 
> 
> 
> I think standard extensions can be in standard YANG modules.
> My problem with extensions is that they become mandatory-to-implement
> if the module is advertised.

I don't agree - this doesn't happen automatically. There must be some extra 
mechanism for an extension to become mandatory to implement, e.g. a special 
protocol, or a negotiated capability in an existing protocol.

For example, if my RESTCONF implementation uses future modules that happen to 
contain the "mount-point" extension, I don't want structural-mount to become 
mandatory to implement.

> 
> IMO, YANG 1.1 MUST require that if-feature-stmt can appear within an external 
> statement.
> There is currently no way to create an optional extension.
> 
> We have also received customer requests to allow the if-feature-stmt inside
> the deviation-stmt, which would be a really useful addition to YANG 1.1.

IMO it is way too late to consider such new features for inclusion in YANG 1.1.

Lada

> 
> 
> 
> Lada
> 
> >
> > Rob
> 
> 
> Andy
>  
> 
> --
> 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