Subject: [netmod] YANG 1.1 Y60 IETF 93 discussion summary and action items

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 25 Jul 2015 10:25:07 +0200

This is the summary of the discussion of YANG 1.1 issue Y60 at the
IETF 93 meeting in Prague:

 - It is OK for a YANG 1.1 module to import a YANG 1.0 module (which
   will of course be interpreted according to the YANG 1.0 rules).

 - The YANG 1.1 RFC will not obsolete RFC 6020. (RFC 6020 may be
   retired when all published YANG 1.0 data models have been
   converted to YANG 1.1.)

 - The title should be made less NETCONF specific (and the same
   applies to the Abstract and the Introduction). This will not
   affect the NETCONF specific examples that are used throughout
   the text.

 - The IANA considerations text copied from RFC 6020 will be removed
   from the YANG 1.1 specification.

 - The IETF will not run a transition process to retire YANG 1.0; it
   is assumed that this will happen naturally anyway eventually.

 - The NETMOD WG recommends that the IETF will publish only YANG 1.1
   modules as RFCs once the YANG 1.1 RFC has been published.

Action items:

 - AB to check whether there are any loopholes.
 - JS to schedule virtual interim meetings to handle review comments.

/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: Sat, 25 Jul 2015 15:15:45 -0700

>    will of course be interpreted according to the YANG 1.0 rules).

I am not convinced this will be a good idea.
Obviously the compiler has to restrict 1.0 modules to 1.0 syntax,
but the corner-case semantics that have been clarified in 1.1
SHOULD be followed if a 1.1 module imports 1.0, even for augment.

>    affect the NETCONF specific examples that are used throughout

If this is the case then I think the "restconf-media-type" hack
should be a real YANG statement.  The reason it is an extension
is because YANG is NETCONF-only.  A real statement
could support augments and deviations.

Just removing a sentence from the abstract is not going to fix all
NETCONF-specific details in YANG.  (Just ask Lada ;-)  It is
not going to make YANG correct for RESTCONF.

YANG will need to be modified for I2RS anyway.  YANG 1.1 took
too long, and now I2RS is ready.  I strongly object to the idea
of starting on 1.2 while 1.1 is still unpublished.

>    from the YANG 1.1 specification.

Does this mean that YANG 1.1 will have a normative reference to RFC 6020?
Or are the references to the IANA registries?

>    is assumed that this will happen naturally anyway eventually.

If import-without-revision is used in a 1.0 module, and both 1.0 and 1.1
revisions exist of the imported module, a compiler (and server)
have to make sure the default revision a YANG 1.0 revision.

>  - JS to schedule virtual interim meetings to handle review comments.
Andy

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 26 Jul 2015 09:22:10 +0200

> SHOULD be followed if a 1.1 module imports 1.0, even for augment.

Please provide concrete examples what breaks if we allow to import
YANG 1.0 modules (using 1.0 semantics).

> not going to make YANG correct for RESTCONF.

Please provide concrete examples where YANG is incorrect for RESTCONF.
 
> of starting on 1.2 while 1.1 is still unpublished.

Nobody proposed to work on YANG 1.2.

> Or are the references to the IANA registries?

Joel (AD) said this will all be OK. I had my doubts but he said it is
no problem since the registry now exists and won't go away anyway even
if RFC 6020 goes historic. Please check the recording.

/js

---

From: Andy Bierman <[email-masked]>
Date: Sun, 26 Jul 2015 10:12:01 -0700

> YANG 1.0 modules (using 1.0 semantics).

I have not reviewed the YANG 1.1 draft. I am waiting for WGLC.
But from memory --

   -- the handling of default prefixes in XPath in groupings was clarified
   -- the handling of ".." wrt/ top-level nodes in XPath in groupings
      was clarified
  -- I think auto-numbering of enum/bit was clarified

I guess there is no new text to add here.
If this is unspecified in 1.0 then handling it the same as 1.1 is OK

> Please provide concrete examples where YANG is incorrect for RESTCONF.

The XPath context for operations are not correct.
They are not mentioned in RESTCONF at all.

YANG 1.1 should define the XPath contexts in a reusable way,
instead of in terms of NETCONF messages.  NETCONF, RESTCONF,
and CoMI can all map these reusable contexts to their specific protocol
messages.
Lada has been saying this for a long time.

> Nobody proposed to work on YANG 1.2.

A new statement would require the yang-version string to be changed again.
I do not think YANG extensions should be used for ephemeral state because
they are not extensible and (literally) not part of YANG.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 27 Jul 2015 17:19:13 +0200

> If this is unspecified in 1.0 then handling it the same as 1.1 is OK

So are you saying there is no problem with importing a YANG 1.0 module?

> Lada has been saying this for a long time.

I assume you refer to section 6.4.1 in draft-ietf-netmod-rfc6020bis-06.txt.
Can you or Lada rewrite it to be protocol agnostic? I guess the
biggest challenge are the namespace declarations for protocols that do not
use XML encoding. Anything else (except some wording changes)?
 
> they are not extensible and (literally) not part of YANG.

I can envision solutions that do not need YANG 1.1 changes or that
could be done fine with extensions I think.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 29 Jul 2015 10:37:15 +0200

>   -- I think auto-numbering of enum/bit was clarified

Also Y41, Y55 and Y56.

> If this is unspecified in 1.0 then handling it the same as 1.1 is OK

I'd suggest to write errata to RFC 6020 for each of these cases.

Lada

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 29 Jul 2015 10:49:50 +0200

>> [email-masked]> wrote:

...

> use XML encoding. Anything else (except some wording changes)?

I made a few comments related to this in my review of 6020bis. I think we
have to define all properties of the data tree without refering to XML,
and describe in more detail how the data tree maps to the XPath data
model.

The only task for any encoding spec will then be to define how to map encoded
data to the data tree, and vice versa.  

Lada