Subject: [netmod] Specifying revision date on import/include

From: William Lupton <[email-masked]>
Date: Sat, 16 Jul 2016 19:17:08 +0200

All,

RFC 6020bis has no recommendation re use of import/include revision-date but makes it clear that if it’s omitted then the revision that will be used is undefined (I believe that pyang will  parse all the revisions that it finds and then use the most recent one). Perhaps that’s a recommendation by implication? RFC 6087bis says that the import/include revision-date SHOULD be used when groupings from the imported/included module/submodule are used.

In discussing this today with people at the hackathon the general opinion was that an omitted revision date means the latest available revision. This matches the pyang behaviour and (I gather) matches the behaviour of most implementations.

In discussion I also said that I didn’t understand why the only groupings are singled out for mention in RFC 6087. Why not types for example?

So should the behaviour when revision-date is omitted be specified? And does the recommendation for using revision-date need to be refined?

Thanks,
William

—— some musings ----

On the one hand, always referencing a specific revision is good because it means that you know exactly what you are getting. But is it always good, especially (perhaps) for low-level modules such ietf-yang-types, ietf-inet-types and (especially?) iana-if-type? Perhaps it’s better to reference low-level files such as these without revision numbers and trusting to rigorous backwards compatibility?

RFC 6020bis is (I think) silent on whether a later revision could remove import/include revision dates but it’s pretty obvious that you could change them to later revisions, so probably this is regarded as “plumbing” that doesn’t need to be mentioned?

---

From: William Lupton <[email-masked]>
Date: Sat, 16 Jul 2016 23:21:26 +0200

On a related topic, I had thought that RFC 6020 Section 5.2 said that a file called <module-name>.yang should contain the latest revision, but it doesn’t actually say that (it says that if the file name includes a revision date then that is the latest revision date). Is there an expectation that <module-name>.yang should contain the latest available revision?

> On 16 Jul 2016, at 19:17, William Lupton <[email-masked]> wrote:
> 
> All,
>

---

From: Nadeau Thomas <[email-masked]>
Date: Mon, 18 Jul 2016 11:45:34 +0200

> On Jul 16, 2016:7:17 PM, at 7:17 PM, William Lupton <[email-masked]> wrote:
> 
> All,
> 

	It is a good idea to explicitly specify whatever the default behavior is in 6020bis - or at least on the wiki - 
so that we have a well-defined behavior here. 

	—Tom

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 19 Jul 2016 11:50:18 +0200

+1 for specifying to use the latest available.

Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: [email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 19 Jul 2016 12:13:38 +0200

We may have to be more explicit. A decent client talking to a
NETCONF/RESTCONF server should pick the latest version of the YANG
modules announced in the server's YANG library. A development tool
should pick the latest version available to the tool. In case the tool
is used to develop code running on the server, then this version
should be announced as the latest version on the server.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Andy Bierman <[email-masked]>
Date: Tue, 19 Jul 2016 03:20:17 -0700

> should be announced as the latest version on the server.
Our tools use a module search path approach, plus pick latest as the
'supported' version.
It is very common (in programming anyway) to control the versions used by
controlling the include and library search paths.

IMO the IETF should not specify how implementations should work
except the normative text in RFCs.  So write a new RFC and get IETF
consensus
on it in order to enforce a rule like this one.

> /js

Andy

> > > RFC 6020bis has no recommendation re use of import/include
> revision-date but makes it clear that if it’s omitted then the revision
> that will be used is undefined (I believe that pyang will  parse all the
> revisions that it finds and then use the most recent one). Perhaps that’s a
> recommendation by implication? RFC 6087bis says that the import/include
> revision-date SHOULD be used when groupings from the imported/included
> module/submodule are used.
> > >
> > > In discussing this today with people at the hackathon the general
> opinion was that an omitted revision date means the latest available
> revision. This matches the pyang behaviour and (I gather) matches the
> behaviour of most implementations.
> > >
> > > In discussion I also said that I didn’t understand why the only
> groupings are singled out for mention in RFC 6087. Why not types for
> example?
> > >
> > > So should the behaviour when revision-date is omitted be specified?
> And does the recommendation for using revision-date need to be refined?
> > >
> > > Thanks,
> > > William
> > >
> > > —— some musings ----
> > >
> > > On the one hand, always referencing a specific revision is good
> because it means that you know exactly what you are getting. But is it
> always good, especially (perhaps) for low-level modules such
> ietf-yang-types, ietf-inet-types and (especially?) iana-if-type? Perhaps
> it’s better to reference low-level files such as these without revision
> numbers and trusting to rigorous backwards compatibility?
> > >
> > > RFC 6020bis is (I think) silent on whether a later revision could
> remove import/include revision dates but it’s pretty obvious that you could
> change them to later revisions, so probably this is regarded as “plumbing”
> that doesn’t need to be mentioned?

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 19 Jul 2016 13:13:58 +0200

> on it in order to enforce a rule like this one.

In case this was not clear, this has been input to the discussion of
RFC 6087bis based on my naive understanding of things.

Note that 'latest version available to the tool' essentially
translates to search paths in typical implementations (at least that
was the intention).

/js

PS: Perhaps replace "A decent client talking to a NETCONF/RESTCONF
    server" with "A client capable of adapting to the data models
    implemented by a NETCONF/RESTCONF server" to phrase things better.

    The key was to point out that using version X to generate the code
    and then announcing version Y later may cause trouble with clients
    that do dynamically adapt based on the versions announced in the
    YANG library.