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

[Balázs Lengyel <[e-mail]>]

See below!    Balazs

 

From: netmod <[e-mail]> On Behalf Of Andy Bierman
Sent: 2019. október 10., csütörtök 17:34
To: Martin Bjorklund <[e-mail]>
Cc: NetMod WG <[e-mail]>
Subject: Re: [netmod] comments on draft-ietf-netmod-yang-instance-file-format-04

 

 

 

On Thu, Oct 10, 2019 at 5:06 AM Martin Bjorklund <[e-mail] <mailto:[e-mail]> > wrote:


  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

BALAZS: It does follow the pattern except that I made the revision date mandatory. It is needed to properly understand the instance data.

 

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.

BALAZS: The leaf-list lists not the instance data files but the content defining YANG modules, so IMO “.yang” is an appropriate extension. It is really a YANG schema file we are listing.



  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   <anydata>
        |  +--:(uri)
        |     +--rw schema-uri?           inet:uri
        ...
        +--rw content-data?         <anydata>


    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           <anydata>
           |  +--:(uri)
           |     +--rw same-schema-as-file?    inet:uri
        ...
        +--rw content-data?         <anydata>



 

+1, except not in favor of so many ways to specify schema.

That means the file reader MUST support all of them.

 

BALAZS: All 3 formats have been explicitly requested by earlier commenters. I see a rational for each:

Simplified-inline: it is simple and usually enough

Inline: if you need to specify not just the modules but also the supported features and deviations you need this full format

Uri: if you don’t really want to specify the content-schema in detail, e.g., because you are generating many files with the same schema, all you need is reference that identifies the content-schema

 

Which one would you like to implementing? Maybe we could make the inline method optional with a feature (feature if-feature),

 

Andy
_______________________________________________
netmod mailing list
[e-mail] <mailto:[e-mail]> 
https://www.ietf.org/mailman/listinfo/netmod