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

["Wubo (lana)" <[e-mail]>]

Hi Rob,

Sorry for not being able to attend the meeting due to network problem.

For the YANG Version Selection, thanks for giving a much clearer definition, but still need to digest, I will give more comments later in the email.

For the YANG packages and others, please see below.

Thanks,
Bo

发件人: Netmod-ver-dt [mailto:[e-mail]] 代表 Rob Wilton (rwilton)
发送时间: 2019年12月4日 23:14
收件人: [e-mail]
主题: [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?
[Bo] I think revision date should also be a valid version identifier since there is already a convention for the YANG modules.
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?
[Bo] I think the pkg-identifier is better.
For the naming conventions both for the package and the modules, I think for any standard interface interoperability (e.g.  The use of capabilities in Hello, YANG library) are must same.
But what kind of naming conventions the device uses to store the model should fall into the scope of implementation.

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.
[B] I also feel this is bad practice and makes the feature more complicated.

Thanks,
Rob