Subject: Re: [netmod] RFC 7950 - Import without revision

From: Robert Wilton <[email-masked]>
Date: Tue, 7 Mar 2017 10:02:59 +0000

Another place in the draft that appears to be inconsistent with the 
section 5.6.5 text below is in 7.1.5, last sentence of this paragraph:

    When the optional "revision-date" substatement is present, any
    typedef, grouping, extension, feature, and identity referenced by
    definitions in the local module are taken from the specified revision
    of the imported module.  It is an error if the specified revision of
    the imported module does not exist.*If no "revision-date" substatement is present, it is undefined from 
which revision of the module they are taken.*

I think that section 5.6.5 does define which revision is used (as the 
text below). I.e. it is the most recent revision out of all the module 
revisions that are imported or implemented.

Rob

On 27/02/2017 11:15, Robert Wilton wrote:
>
> in RFC 7950, The last paragraph, section 5.1.1 "Import and Include by 
> Revision" states:
>
> "If a module is not imported with a specific revision, it is 
> undefined which revision is used."
>
> But I was wondering if the above text is misleading, since section 
> 5.6.5: "Implementing a Module" has the following two paragraphs:
>
>     If a server implements a module A that imports a module C without
>     specifying the revision date of module C and the server does not
>     implement C (e.g., if C only defines some typedefs), the server MUST
>     list module C in the "/modules-state/module" list from
>     "ietf-yang-library" [RFC7895 <https://tools.ietf.org/html/rfc7895>], and it MUST set the leaf
>     "conformance-type" to "import" for this module.
>
>     If a server lists a module C in the "/modules-state/module" list from
>     "ietf-yang-library" and there are other modules Ms listed that import
>     C without specifying the revision date of module C, the server MUST
>     use the definitions from the most recent revision of C listed for
>     modules Ms.
>
>     The reason for these rules is that clients need to be able to know
>     the specific data model structure and types of all leafs and
>     leaf-lists implemented in a server.
>
> This seems to imply that import without specifying the revision would 
> mean that the latest revision listed in ietf-yang-library must be the 
> one that is imported.  Is that correct, or am I misinterpreting the 
> text?  Hence, should the last paragraph of section 5.1.1 be deleted?
>
> Thanks,
> Rob
>
>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 07 Mar 2017 18:03:33 +0100 (CET)

Robert Wilton <[email-masked]> wrote:
> "If a module is not imported with a specific revision, it is undefined
> which revision is used."
> 
> text?

This is correct.

> Hence, should the last paragraph of section 5.1.1 be deleted?

No I don't think it should.  From the perspective of a given module
that imports another module w/o revision, it is undefined which
revision is used - however in any given server the revision used is
deterministic.

/martin

---

From: Robert Wilton <[email-masked]>
Date: Wed, 8 Mar 2017 10:28:54 +0000

> revision is used - however in any given server the revision used is
I'm not sure what it really means for a YANG module to import another 
module outside the context of a client/server, it seems somewhat abstract.

I still think that the text is misleading (similarly for 7.1.5).  I 
think that the draft would be clearer if these sentences were removed.  
I don't think that it helps to say that something is undefined when that 
is the implicit default of having no text there, and in all normal 
scenarios, the version that would be imported is actually well defined.  
So, I found the text to be misleading and unhelpful.

Rob

> .

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 08 Mar 2017 16:28:19 +0100 (CET)

> module outside the context of a client/server, it seems somewhat

It just means that the importing module has access to defintions in
the imported module.

/martin