Subject: [Netmod-ver-dt] Review of packages draft

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Thu, 10 Oct 2019 15:09:50 +0000

Below are some comments I have reviewing the packages draft.  Thanks for working on this, Rob.

Section 3:

"   It has long been acknowledged within the IETF NETMOD community that”

Should this be broader?  Taking into account what Openconfig did, I think we can say that packages are more than just a NETMOD thing.  Plus, you go on to make broader statements below this sentence.  Perhaps just say, “within the YANG community”.

===

Section 5.2:

Are these lists meant to be exhaustive in terms of NBC, BC, and Ed?

===

Section 5.2.2:

Just a note we will/do have a ref for YANG semver.  It seems like we’ll need to change the name of this document, though.  I can speak more to that when we meet.

===

Section 5.3:

Hmmm, while I agree with the semver rule text, one COULD use a version string that is not semver at all.  Then how do these rules apply?  I think we either need to make semver mandatory to implement with a separate revision-label for vendors, or we generalize this text.

===

Section 5.4:

I struggle with this idea of an incomplete package.  What is the use case here?

Joe

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Tue, 15 Oct 2019 13:55:07 +0000

Hi Joe,

Thanks for the review comments, please see inline ...

> -----Original Message-----
> From: Netmod-ver-dt <[email-masked]> On Behalf Of Joe
> Clarke (jclarke)
> Sent: 10 October 2019 16:10
> To: [email-masked]
> Subject: [Netmod-ver-dt] Review of packages draft
> 
> Should this be broader?  Taking into account what Openconfig did, I think
> we can say that packages are more than just a NETMOD thing.  Plus, you go
> on to make broader statements below this sentence.  Perhaps just say,
> “within the YANG community”.
[RW] 

Fixed.

> Are these lists meant to be exhaustive in terms of NBC, BC, and Ed?

[RW] Yes, that was the intention.  Am I missing some?

> ===
> 
> Section 5.2.2:
> 
> Just a note we will/do have a ref for YANG semver.  It seems like we’ll
> need to change the name of this document, though.  I can speak more to
> that when we meet.
[RW] OK.

> 
> ===
> 
> Section 5.3:
> 
> Hmmm, while I agree with the semver rule text, one COULD use a version
> string that is not semver at all.  Then how do these rules apply?  I think
> we either need to make semver mandatory to implement with a separate
> revision-label for vendors, or we generalize this text.
[RW] 
OK, I think that I will try and generalize this text (just tracked as an issue for the moment).

If some vendors don't want to use YANG semver for module versioning, then I suspect that they may not want to use YANG smever for package versioning either.

My intent is that packages sort of follow the approach/split defined by module-versioning + YANG-semver.  A module definition doesn't currently carry the fully revision history, but it does mark whether the version is nbc to the previous version or not, potentially allowing the full revision history to be reconstructed, if required.

> I struggle with this idea of an incomplete package.  What is the use case
[RW] 
Potentially two cases that I can think of:

I believe that the most compelling reason is for software hot fixes or patches to a device that might modify smaller parts of the schema.  It may be useful to define these as a package without resolving all dependencies, because they will always be deployed at the same time as the base software package.

The second case, that I'm less sure about, it whether standard packages will want to bind themselves to specific versions of say iana-if-types.yang.  My thinking is that they would have the option of leaving off this dependency, which would naturally mean that the package is incomplete.  But following this logic probably end up making all IETF packages incomplete, so probably not so useful.  Hence, my probable conclusion is that IETF packages will choose a version of iana-if-types.yang, which would potentially be overridden by an updated version used on a vendors device (if required).

Thanks,
Rob

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

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Tue, 15 Oct 2019 14:59:22 +0000

> [RW] Yes, that was the intention.  Am I missing some?

My question was should we make the text more explicit around saying these are the only types.

> OK, I think that I will try and generalize this text (just tracked as an issue for the moment).

Okay.  Not really sure the best course of action here.

> The second case, that I'm less sure about, it whether standard packages will want to bind themselves to specific versions of say iana-if-types.yang.  My thinking is that they would have the option…

Thanks.  These two use cases are helpful.  I think they’re worth mentioning in the document to help people like me.

Joe