Re: [netmod] comments on draft-ietf-netmod-yang-instance-file-format-04

[Andy Bierman]

On Thu, Oct 10, 2019 at 8:34 AM Andy Bierman  wrote:

>
>
> On Thu, Oct 10, 2019 at 5:06 AM Martin Bjorklund  wrote:
>
>> Hi,
>>
>> I have some mostly cosmetic comments on this draft.
>>
>>   o  "YANG" should be spelled "YANG".  Not Yang etc.
>>
>>
>>   o  "NETCONF" should be spelled "NETCONF".
>>
>>
>>   o  leaf-list module
>>
>> The type of this leaf-list is a string with:
>>
>>   pattern '.+@\d{4}-\d{2}-\d{2}\.yang';
>>
>> I think the revision needs to be optional, and the suffix ".yang"
>> dropped, since it doesn't add any value:
>>
>>   pattern '.+(@\d{4}-\d{2}-\d{2})?';
>>
>>(same for inline-spec).
>>
>>
>>
>
> IMO the filespec SHOULD follow the pattern in
> https://tools.ietf.org/html/rfc7950#section-5.2
>
> Except a new file extension SHOULD be used.
> Suggest: .yif == YANG Instance File
>
> Obviously it would be a horrible idea to use .yang since that extension
> is already used to identify a YANG schema file.
>
>

Sorry about the confusion over this comment.

There should be reusable typedefs defined in rfc6991bis representing the
format in 7950, sec. 5.2

There should also be file extensions defined for an XML or JSON file that
is expected to
follow the YIF structure.


Andy




>   o  schema-uri
>>
>> The description says:
>>
>>   A reference to another YANG instance data file.
>>   This instance data file will use the same set of target
>>   YANG modules, revisions, supported features and deviations
>>   as the referenced YANG instance data file.
>>
>>I don't understand what this means.  Does it mean that the schema
>>for this document is the same as the schema defined in the
>>schema-uri file, or that the schema-uri file defines the schema in
>>its content-data?
>>
>>I *think* it is the former.  In either case, the name of the leaf
>>can perhaps be changed to reflect the semantics, rather than the
>>syntax (i.e., don't call it xxx-uri just b/c its type is an uri).
>>Perhaps 'same-schema-as-file'.
>>
>>
>>   o  Data node naming.
>>
>> The current structure of the model is:
>>
>> +--rw (content-schema-spec)?
>> |  +--:(simplified-inline)
>> | +--rw module* string
>> |  +--:(inline)
>> |  |  +--rw inline-spec*string
>> |  |  +--rw inline-content-schema   
>> |  +--:(uri)
>> | +--rw schema-uri?   inet:uri
>> ...
>> +--rw content-data? 
>>
>>
>> To make the instance document more understandable, I suggest the
>> following structure, which adds a wrapping container for the
>> schema, and renames the inline and uri nodes:
>>
>> +--rw content-schema
>>+--rw (content-schema-spec)?
>>|  +--:(simplified-inline)
>>| +--rw module* string
>>|  +--:(inline)
>>|  |  +--rw inline-module*  string
>>|  |  +--rw inline-schema   
>>|  +--:(uri)
>>| +--rw same-schema-as-file?inet:uri
>> ...
>> +--rw content-data? 
>>
>>
>>
>
> +1, except not in favor of so many ways to specify schema.
> That means the file reader MUST support all of them.
>
>
>
>>   o  Format the YANG module
>>
>> I suggest you run the YANG module through:
>>
>>   pyang -f yang --keep-comments --yang-line-length 69
>>
>>   o  3.2
>>
>> The element "" needs a namespace declaration.
>>
>>
>>
>> /martin
>>
>>
>>
>
> Andy
>
>
>
>>
>>
>>
>> /martin
>>
>> ___
>> 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] comments on draft-ietf-netmod-yang-instance-file-format-04

[Andy Bierman]

On Thu, Oct 10, 2019 at 5:06 AM Martin Bjorklund  wrote:

> Hi,
>
> I have some mostly cosmetic comments on this draft.
>
>   o  "YANG" should be spelled "YANG".  Not Yang etc.
>
>
>   o  "NETCONF" should be spelled "NETCONF".
>
>
>   o  leaf-list module
>
> The type of this leaf-list is a string with:
>
>   pattern '.+@\d{4}-\d{2}-\d{2}\.yang';
>
> I think the revision needs to be optional, and the suffix ".yang"
> dropped, since it doesn't add any value:
>
>   pattern '.+(@\d{4}-\d{2}-\d{2})?';
>
>(same for inline-spec).
>
>
>

IMO the filespec SHOULD follow the pattern in
https://tools.ietf.org/html/rfc7950#section-5.2

Except a new file extension SHOULD be used.
Suggest: .yif == YANG Instance File

Obviously it would be a horrible idea to use .yang since that extension
is already used to identify a YANG schema file.


  o  schema-uri
>
> The description says:
>
>   A reference to another YANG instance data file.
>   This instance data file will use the same set of target
>   YANG modules, revisions, supported features and deviations
>   as the referenced YANG instance data file.
>
>I don't understand what this means.  Does it mean that the schema
>for this document is the same as the schema defined in the
>schema-uri file, or that the schema-uri file defines the schema in
>its content-data?
>
>I *think* it is the former.  In either case, the name of the leaf
>can perhaps be changed to reflect the semantics, rather than the
>syntax (i.e., don't call it xxx-uri just b/c its type is an uri).
>Perhaps 'same-schema-as-file'.
>
>
>   o  Data node naming.
>
> The current structure of the model is:
>
> +--rw (content-schema-spec)?
> |  +--:(simplified-inline)
> | +--rw module* string
> |  +--:(inline)
> |  |  +--rw inline-spec*string
> |  |  +--rw inline-content-schema   
> |  +--:(uri)
> | +--rw schema-uri?   inet:uri
> ...
> +--rw content-data? 
>
>
> To make the instance document more understandable, I suggest the
> following structure, which adds a wrapping container for the
> schema, and renames the inline and uri nodes:
>
> +--rw content-schema
>+--rw (content-schema-spec)?
>|  +--:(simplified-inline)
>| +--rw module* string
>|  +--:(inline)
>|  |  +--rw inline-module*  string
>|  |  +--rw inline-schema   
>|  +--:(uri)
>| +--rw same-schema-as-file?inet:uri
> ...
> +--rw content-data? 
>
>
>

+1, except not in favor of so many ways to specify schema.
That means the file reader MUST support all of them.



>   o  Format the YANG module
>
> I suggest you run the YANG module through:
>
>   pyang -f yang --keep-comments --yang-line-length 69
>
>   o  3.2
>
> The element "" needs a namespace declaration.
>
>
>
> /martin
>
>
>

Andy



>
>
>
> /martin
>
> ___
> 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] IANA registries

[Ladislav Lhotka]

On Thu, 2019-10-10 at 14:07 +0200, Martin Bjorklund wrote:
> Ladislav Lhotka  wrote:
> > Hi,
> > 
> > some of you have probably seen the discussions around
> > 
> > https://tools.ietf.org/html/draft-lhotka-dnsop-iana-class-type-yang-02
> > 
> > We proposed to adopt it as a work item in the DNSOP WG, but despite
> > some support this is probably not going to happen. The substantial
> > objections are:
> > 
> > 1. It is not good to publish a YANG snapshot of an IANA registry as an RFC
> > because future implementors will use the module from that RFC and implement
> > registry entries that may have been deprecated in the mean time. 
> > 
> > 2. The meaning of "deprecated" and "obsolete" defined by IANA (RFC
> > 8126) differs from the definition in RFC 7950.
> > 
> > I already raised #2 in this mailing list, and I think it should be
> > addressed in the next version of YANG.
> > 
> > Regarding #1, I tried to explain that the RFC is only intended to contain an
> > initial revision of the corresponding YANG module, but it didn't help. One
> > suggestion was to avoid representing the registries as enumerations or sets
> of
> > identities, and use only integers.
> 
> That's a bit odd.  But perhaps it can be solved by actually not
> filling in all values in this module, but rather make it a template
> and instruct IANA to fill it in with the contents of the registry at
> the time of publication.

OK, so the module template in the RFC couldn't be used at all - this might
indeed help.

My idea was to tag the RFC as historic as soon as IANA takes over the module
maintenance.

I think part of the problem is that the new revisions are available from a
rather obscure place - the YANG Parameters registry page:

https://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml

Lada

> 
> 
> 
> /martin
> 
> 
> > I wonder if we can come up with a reasonable solution. Without
> > having the important registries as YANG modules, it is difficult to
> > work on other modules - for DNS, in this case, but it could apply to
> > other areas, too.
> > 
> > Thanks, Lada
> > 
> > -- 
> > Ladislav Lhotka
> > Head, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
> > 
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> > 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

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

Re: [netmod] IANA registries

[Martin Bjorklund]

Ladislav Lhotka  wrote:
> Hi,
> 
> some of you have probably seen the discussions around
> 
> https://tools.ietf.org/html/draft-lhotka-dnsop-iana-class-type-yang-02
> 
> We proposed to adopt it as a work item in the DNSOP WG, but despite
> some support this is probably not going to happen. The substantial
> objections are:
> 
> 1. It is not good to publish a YANG snapshot of an IANA registry as an RFC
> because future implementors will use the module from that RFC and implement
> registry entries that may have been deprecated in the mean time. 
> 
> 2. The meaning of "deprecated" and "obsolete" defined by IANA (RFC
> 8126) differs from the definition in RFC 7950.
> 
> I already raised #2 in this mailing list, and I think it should be
> addressed in the next version of YANG.
> 
> Regarding #1, I tried to explain that the RFC is only intended to contain an
> initial revision of the corresponding YANG module, but it didn't help. One
> suggestion was to avoid representing the registries as enumerations or sets of
> identities, and use only integers.

That's a bit odd.  But perhaps it can be solved by actually not
filling in all values in this module, but rather make it a template
and instruct IANA to fill it in with the contents of the registry at
the time of publication.



/martin


> I wonder if we can come up with a reasonable solution. Without
> having the important registries as YANG modules, it is difficult to
> work on other modules - for DNS, in this case, but it could apply to
> other areas, too.
> 
> Thanks, Lada
> 
> -- 
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 
> ___
> 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] comments on draft-ietf-netmod-yang-instance-file-format-04

[Martin Bjorklund]

Hi,

I have some mostly cosmetic comments on this draft.

  o  "YANG" should be spelled "YANG".  Not Yang etc.


  o  "NETCONF" should be spelled "NETCONF".


  o  leaf-list module

The type of this leaf-list is a string with:

  pattern '.+@\d{4}-\d{2}-\d{2}\.yang';

I think the revision needs to be optional, and the suffix ".yang"
dropped, since it doesn't add any value:

  pattern '.+(@\d{4}-\d{2}-\d{2})?';

   (same for inline-spec).


  o  schema-uri

The description says:

  A reference to another YANG instance data file.
  This instance data file will use the same set of target
  YANG modules, revisions, supported features and deviations
  as the referenced YANG instance data file.

   I don't understand what this means.  Does it mean that the schema
   for this document is the same as the schema defined in the
   schema-uri file, or that the schema-uri file defines the schema in
   its content-data?

   I *think* it is the former.  In either case, the name of the leaf
   can perhaps be changed to reflect the semantics, rather than the
   syntax (i.e., don't call it xxx-uri just b/c its type is an uri).
   Perhaps 'same-schema-as-file'.


  o  Data node naming.

The current structure of the model is:

+--rw (content-schema-spec)?
|  +--:(simplified-inline)
| +--rw module* string
|  +--:(inline)
|  |  +--rw inline-spec*string
|  |  +--rw inline-content-schema   
|  +--:(uri)
| +--rw schema-uri?   inet:uri
...
+--rw content-data? 


To make the instance document more understandable, I suggest the
following structure, which adds a wrapping container for the
schema, and renames the inline and uri nodes:

+--rw content-schema
   +--rw (content-schema-spec)?
   |  +--:(simplified-inline)
   | +--rw module* string
   |  +--:(inline)
   |  |  +--rw inline-module*  string
   |  |  +--rw inline-schema   
   |  +--:(uri)
   | +--rw same-schema-as-file?inet:uri
...
+--rw content-data? 


  o  Format the YANG module

I suggest you run the YANG module through:

  pyang -f yang --keep-comments --yang-line-length 69

  o  3.2

The element "" needs a namespace declaration.



/martin





/martin

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

[netmod] IANA registries

[Ladislav Lhotka]

Hi,

some of you have probably seen the discussions around

https://tools.ietf.org/html/draft-lhotka-dnsop-iana-class-type-yang-02

We proposed to adopt it as a work item in the DNSOP WG, but despite some support
this is probably not going to happen. The substantial objections are:

1. It is not good to publish a YANG snapshot of an IANA registry as an RFC
because future implementors will use the module from that RFC and implement
registry entries that may have been deprecated in the mean time. 

2. The meaning of "deprecated" and "obsolete" defined by IANA (RFC 8126) differs
from the definition in RFC 7950.

I already raised #2 in this mailing list, and I think it should be addressed in
the next version of YANG.

Regarding #1, I tried to explain that the RFC is only intended to contain an
initial revision of the corresponding YANG module, but it didn't help. One
suggestion was to avoid representing the registries as enumerations or sets of
identities, and use only integers.

I wonder if we can come up with a reasonable solution. Without having the
important registries as YANG modules, it is difficult to work on other modules -
for DNS, in this case, but it could apply to other areas, too.

Thanks, Lada

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

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

[netmod] YANG 1.0 module uses a grouping from a 1.1 module and the grouping contains 1.1 XPath functions?

[Jernej Tuljak]

Hi,

there is at least one YANG 1.0 standard module that imports and uses 
groupings from a YANG 1.1 standard module and at least one such grouping 
contains must/when statements referencing XPath functions that are not 
available in 1.0 XPath context.


The modules I'm referring to are part of RFC8533 [1] and RFC8532 [2]. 
ietf-connectionless-oam-methods (a 1.0 module) uses cl-oam:tp-address 
from ietf-connectionless-oam (a 1.1 module), which calls 
"derived-from-or-self" in a when expression of a used node. These RFCs 
were published in April.


Our tools complain about "derived-from-or-self" not being defined in 
ietf-connectionless-oam-methods's XPath context:


[Error]; 
ietf-connectionless-oam-methods@2019-04-16:/cloam-methods:continuity-check/cloam-methods:input/cloam-methods:destination-tp/cloam-methods:mac-address/cloam-methods:when; 
XPath function "derived-from-or-self" is not defined in the XPath context


Is this correct? Or are XPath functions expected to be resolved 
statically, like types?


Jernej

[1] - https://tools.ietf.org/html/rfc8533
[2] -https://tools.ietf.org/html/rfc8532

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

Re: [netmod] ?==?utf-8?q? PYANG refine fault ?

[Martin Bjorklund]

Michal Vaško  wrote:
> Hi,
> 
> yanglint actually validates the module just fine (at least the latest
> version) once the grammar errors are fixed. Namely, the spaces before
> ";" on lines 191 and 199 are removed.

These are not errors.  You are allowed to have any number of
whitespace (and comments) before the ';'.


/martin


> 
> Regards,
> Michal
> 
> On Wednesday, October 9, 2019 23:13 CEST, Mahesh Jethanandani
>  wrote:
>  
> > Hi Balasz,
> > 
> > In general support of unions is poor across the tool sets that I have
> > used. It does not help that yanglint gives a completely different
> > error.
> > 
> > I did try yanger, and that did not result in an error.
> > 
> > The other option is to move the default statement inside the grouping,
> > which seems to make the error go away.
> > 
> > Cheers.
> > 
> > > On Oct 9, 2019, at 8:01 AM, Balázs Lengyel
> > >  wrote:
> > > 
> > > Hello,
> > > I was trying to validate the attached model. However pyang keeps
> > > complaining about refining a default for a leaf-list:
> > >  
> > > ietf-notification-capabilit...@2019-10-10.yang
> > > :184: error:
> > > "leaf-list" node
> > > "ietf-notification-capabilities::supported-excluded-change-type"
> > > cannot be refined with "default"
> > >  
> > > Why? According to https://tools.ietf.org/html/rfc7950#section-7.13.2
> > >  “A leaf-list node
> > > may get a set of default values ...”
> > > .
> > > Confdc accepts this. Could this be a bug in pyang ?
> > > Regards Balazs
> > >  
> > > -- 
> > > Balazs Lengyel Senior Specialist Ericsson Hungary Ltd.
> > > Mobile: +36-70-330-7909 email: balazs.leng...@ericsson.com
> > > 
> > >  
> > > ___
> > > netmod mailing list
> > > netmod@ietf.org 
> > > https://www.ietf.org/mailman/listinfo/netmod
> > > 
> > Mahesh Jethanandani
> > mjethanand...@gmail.com
> > 
> > 
> > 
>  
>  
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] PYANG refine fault ?

[Martin Bjorklund]

Hi,

Balázs Lengyel  wrote:
> Hello,
> 
> I was trying to validate the attached model. However pyang keeps complaining
> about refining a default for a leaf-list:
> 
>  
> 
> ietf-notification-capabilit...@2019-10-10.yang:184: error: "leaf-list" node
> "ietf-notification-capabilities::supported-excluded-change-type" cannot be
> refined with "default"
> 
>  
> 
> Why? According to https://tools.ietf.org/html/rfc7950#section-7.13.2 “A
> leaf-list node may get a set of default values ...” 
> 
> ..
> 
> Confdc accepts this. Could this be a bug in pyang ?

Yes, now fixed.


/martin

  
> 
> Regards Balazs
> 
>  
> 
> -- 
> 
> Balazs LengyelSenior Specialist
> Ericsson Hungary Ltd. 
> 
> Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com
> 
>  
> 
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] ?==?utf-8?q? PYANG refine fault ?

[Michal Vaško]

Hi,

yanglint actually validates the module just fine (at least the latest version) 
once the grammar errors are fixed. Namely, the spaces before ";" on lines 191 
and 199 are removed.

Regards,
Michal

On Wednesday, October 9, 2019 23:13 CEST, Mahesh Jethanandani 
 wrote: 
 
> Hi Balasz,
> 
> In general support of unions is poor across the tool sets that I have used. 
> It does not help that yanglint gives a completely different error.
> 
> I did try yanger, and that did not result in an error.
> 
> The other option is to move the default statement inside the grouping, which 
> seems to make the error go away.
> 
> Cheers.
> 
> > On Oct 9, 2019, at 8:01 AM, Balázs Lengyel 
> >  wrote:
> > 
> > Hello,
> > I was trying to validate the attached model. However pyang keeps 
> > complaining about refining a default for a leaf-list:
> >  
> > ietf-notification-capabilit...@2019-10-10.yang 
> > :184: error: 
> > "leaf-list" node 
> > "ietf-notification-capabilities::supported-excluded-change-type" cannot be 
> > refined with "default"
> >  
> > Why? According to https://tools.ietf.org/html/rfc7950#section-7.13.2 
> >  “A leaf-list node may 
> > get a set of default values ...” 
> > .
> > Confdc accepts this. Could this be a bug in pyang ?
> > Regards Balazs
> >  
> > -- 
> > Balazs LengyelSenior Specialist   
> > Ericsson Hungary Ltd. 
> > Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com 
> > 
> >  
> > ___
> > netmod mailing list
> > netmod@ietf.org 
> > https://www.ietf.org/mailman/listinfo/netmod 
> > 
> Mahesh Jethanandani
> mjethanand...@gmail.com
> 
> 
> 
 
 

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