Subject: Re: [Netmod-ver-dt] Tomorrows meeting - I can only make first half

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Thu, 5 Dec 2019 03:03:39 +0000

I’m also squeezed for time this Thursday. Ok with a plan, we’ll probably have time just for the YANG version selection discussion.

Regards,
Reshad.

From: Netmod-ver-dt <[email-masked]> on behalf of "Rob Wilton (rwilton)" <[email-masked]>
Date: Wednesday, December 4, 2019 at 10:14 AM
To: "[email-masked]" <[email-masked]>
Subject: [Netmod-ver-dt] Tomorrows meeting - I can only make first half

Regarding tomorrows YANG versioning meeting, I can only make the first half an hour, but happy for folks to continue discussions afterwards.

I would suggest that we focus the discussion primarily on the email that I sent out yesterday.  Hopefully looking for progress on the following questions:

A) Yang Version Selection:

  1.  Does the YANG that I proposed for version selection look along the right lines?  Do we think that it is simpler?
  2.  For custom packages, what fields should we allow to be configured (e.g. just a minimal subset, or everything that could be valid)?  Should clients be allowed to select features?
  3.  What allowed modes of version selection do we want to sanction?  Does the current use of capabilities give too much flexibility?
  4.  Is using <pkg-name@version> okay as a schema identifier in RESTCONF?  Would the name need to be encoded beforehand?  Or do we want to force the client to configure a simpler name?

B) For YANG packages:

  1.  Is a revision date a valid version identifier for a package?
  2.  Is having a pkg-identifier (i.e. pkg-name@version) better than separate name and version leaves?  Is it right to have different naming conventions for packages within a file vs on the device?  How far do we go - do we try and apply this convention to identifying modules as well?

C) Discussion on whether features should be allowed to remove nodes when they are enabled - YANG 1.1 does currently allow this - but I’m suggesting that this is bad practice.

Thanks,
Rob