Subject: Re: [Netmod-ver-dt] Latest doc version

From: Qin Wu <[email-masked]>
Date: Sun, 10 Mar 2019 12:27:40 +0000

Hi, Rob:
Sorry for late reply.
Please see comments inline.
发件人: Netmod-ver-dt [mailto:[email-masked]] 代表 Rob Wilton (rwilton)
发送时间: 2019年3月7日 19:54
收件人: Qin Wu <[email-masked]>; [email-masked]
主题: Re: [Netmod-ver-dt] Latest doc version

Hi Qin,

Thanks for the comments.

From: Netmod-ver-dt <[email-masked]<mailto:[email-masked]>> On Behalf Of Qin Wu
Sent: 01 March 2019 07:10
To: Rob Wilton (rwilton) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Netmod-ver-dt] Latest doc version

Hi, Rob:
A few comments on the latest version

1.       Section 1, paragraph 2, 2nd bullet

      An extension to allow YANG module imports to be restricted to

      modules with particular semantic versions, allowing inter-module

      version dependencies to be captured within YANG module

      definitions.

  [Qin]s/An extension/A YANG extension

[RW]

OK

2.       Section 1.2, paragraph 2

   [Qin]: which requirements have not been addressed, should this be clear in this section?

[RW]

OK.

3.       Section 1.2 paragraph 3

   [Qin]:draft-wang-netmod-module-revision-management-01 section 4.1 is also

   targeted to address requirements 2.1 defined in draft-verdt-netmod-yang-versioning-reqs-02

   and will review details in section 6.

[RW]

We’ve not discussed this draft in the design team at all, so I think that we should find time to discuss this perhaps at IETF 104.

[Qin]:Sure, that will be great, thanks.

4.       Section 2.1

   Q.  Does statement ordering need to be considered as part of the

   comparison?  RW: I think the answer should be no.  RR: ordering

   matters for RPC/action input as per https://tools.ietf.org/html/

   rfc7950#section-7.5.7

   [Qin]: I believe when you compare two modules, statement order in one module

   should be adjusted to follow the same statement order of the other module. But

   not sure automation tool can be built to do this. Manual provision on the statement

   order is needed.

[RW]

For the moment, I am just tracking this issue at https://github.com/netmod-wg/yang-ver-dt/issues/6, and I intend to list this as an open issue in the draft.

[Qin]: Good.

5.       Section 2.2

      Module definitions that follow the semver.org 2.0.0 versioning

      scheme are fully compatible with implementations that understand

      the YANG semantic versioning scheme.

  [Qin]:What about module definitions that follows YANG semantics versioning schema defined in this document?

  are they compatible with implementation that understand YANG semantics version schema defined in this document,

  probably the answer is yes, but it is not clear in the text.

[RW]

Sorry, I don’t understand the question.

[Qin]: I thought we focus on modified semantics version which is different from semver 2.0.0 versioning scheme,

Correct, if I am wrong.

6.       Section 3, paragraph 3 said

“   changing the name of a leaf could break an

   import but frequently would not, ”

[Qin]:frequently changing the name of a leaf would not break an import? Would you clarify this?

[RW]

This just means that in many cases changing the name of a leaf is unlikely to break a module import, but it might (e.g. if another module had a leafref to that leaf).

[Qin]:Thanks for clarification.

7.       Section 3, paragraph 4

   [Qin]: Do we support some import statement contains version statement or

   some import statement contains revision-date? Are these important statement interchangeable?

[RW]

There are 3 choices:

-          Regular import

-          Import by version (which we adding)

-          Import by revision (which is basically broken)

8.       Section 5.1 said:

“

The following rules remove the ambiguity:”

I feel these rules are more related to RFC8407 instead of [I-D.ietf-netconf-rfc7895bis].

So the last rule should be default rule defined in RFC8407

[RW]

RFC8407 only provides guidelines.  We need something stronger than that.  Basically, if want it to be the case that if the server implements semver then it will follow these rules.  So I think that updating 7895bis (RFC 8525) is the right thing to do here.

[Qin]:Okay, understood.

Thanks for your comments.  I’ve incorporated them and updated the draft.

Thanks,
Rob

“

   If a module import statement could resolve to more than one module

   revision defined in the datastore schema, none of those revisions are

   implemented, and none of the modules revisions have a YANG semantic

   version number, then the import MUST resolve to the module that has

   the most recent revision-date.

”

The other two rules are additional rules that can be used to enhance RFC8407, but I didn’t check details.
Will review remaining sections when in convenience.

-Qin
发件人: Netmod-ver-dt [mailto:[email-masked]] 代表 Rob Wilton (rwilton)
发送时间: 2019年2月28日 2:07
收件人: [email-masked]<mailto:[email-masked]>
主题: [Netmod-ver-dt] Latest doc version

Just pushed to the github develop branch.

Latest draft version attached.

Still to do:

-          Update abstract

-          Probably should add some definitions.

-          Resolve comments from Balazs (across the doc)

-          Resolve comments from Reshad on chapter 2.

-          Incorporate text from Balazs on instance data versioning.

-          Chapter 4 needs some serious focus.

-          Add tree output and updates the text around the YANG modules.

Thanks,
Rob

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Sun, 10 Mar 2019 12:51:38 +0000

Hi Qin,

1.      Section 2.2

[RW]

Sorry, I don't understand the question.

Correct, if I am wrong.

[RW]

The YANG semantic versioning scheme is effectively a superset of the semver 2.0.0 rules except for these two rules:

1.     A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version. Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST NOT be empty. Numeric identifiers MUST NOT include leading zeroes. Pre-release versions have a lower precedence than the associated normal version. A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version. Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92.

2.     Build metadata MAY be denoted by appending a plus sign and a series of dot separated identifiers immediately following the patch or pre-release version. Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST NOT be empty. Build metadata SHOULD be ignored when determining version precedence. Thus two versions that differ only in the build metadata, have the same precedence. Examples: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85.

We probably need to decide whether or not we should include these or not, either way our doc should be clear on this point (but won't be in the version that we publish for IETF 104).

Thanks,

Rob

---

From: Qin Wu <[email-masked]>
Date: Sun, 10 Mar 2019 13:05:59 +0000

发件人: Rob Wilton (rwilton) [mailto:[email-masked]]
发送时间: 2019年3月10日 20:52
收件人: Qin Wu <[email-masked]>; [email-masked]
主题: RE: Latest doc version

Hi Qin,

1.       Section 2.2

[RW]

Correct, if I am wrong.

[RW]

We probably need to decide whether or not we should include these or not, either way our doc should be clear on this point (but won’t be in the version that we publish for IETF 104).

[Qin]:Very useful information, agree not put into version for IETF 104 at this moment, since I see last paragraph of section 2.3

“
      YANG module semantic version numbers beginning with 0, i.e "0.X.Y"
      are regarded as beta definitions and need not follow the rules
      above.  Either the MINOR or PATCH version numbers may be updated,
      regardless of whether the changes are non-backwards-compatible,

      backwards-compatible, or editorial.

”

Which is not completely consistent with these two rules.

Track issue on github?

Thanks,

Rob

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Sun, 10 Mar 2019 13:38:45 +0000

From: Qin Wu <[email-masked]>
Sent: 10 March 2019 13:06
To: Rob Wilton (rwilton) <[email-masked]>; [email-masked]
Subject: 答复: Latest doc version

发件人: Rob Wilton (rwilton) [mailto:[email-masked]]
发送时间: 2019年3月10日 20:52
收件人: Qin Wu <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
主题: RE: Latest doc version

Hi Qin,

1.      Section 2.2

[RW]

Correct, if I am wrong.

[RW]

“

”

[RW]

This paragraph does follow semver 2.0.0 rules.  E.g. it is a rewording of rule 4:

Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.

Track issue on github?

[RW]

Already tracked by https://github.com/netmod-wg/yang-ver-dt/issues/9

Thanks,

Rob

Thanks,

Rob

---

From: Qin Wu <[email-masked]>
Date: Sun, 10 Mar 2019 14:58:21 +0000

Thank for clarification, we are good now.

________________________________
吴钦 Qin
M：+86-13914734360<tel:+86-13914734360>(Mobile Number)
E：[email-masked]<mailto:[email-masked]>
发件人： Rob Wilton (rwilton)
收件人： Qin Wu<[email-masked]<mailto:[email-masked]>>;netmod-ver-dt<[email-masked]<mailto:[email-masked]>>
主题： RE: Latest doc version
时间： 2019-03-10 21:38:59

Hi Qin,

1.      Section 2.2

[RW]

Correct, if I am wrong.

[RW]

“

”

[RW]

Track issue on github?

[RW]

Thanks,

Rob

Thanks,

Rob