Re: [Softwires] WGLC for draft-ietf-softwire-yang-04 as Standard Track, closed by 27 June 2018

[Sheng Jiang <[e-mail]>]

Hi, Med,

Thanks for addressing my comments. 06 version looks good from my perspective.

Cheers,

Sheng

From: [e-mail] [mailto:[e-mail]]
Sent: Wednesday, June 27, 2018 4:54 PM
To: Sheng Jiang <[e-mail]>; Softwires WG <[e-mail]>
Cc: [e-mail]
Subject: RE: WGLC for draft-ietf-softwire-yang-04 as Standard Track, closed by 27 June 2018

Hi Sheng,

Many thanks for the careful review.

An updated version which integrates your comments is available online: https://datatracker.ietf.org/doc/draft-ietf-softwire-yang/?include_text=1

See more inline.

Cheers,
Med

De : Softwires [mailto:[e-mail]] De la part de Sheng Jiang
Envoyé : mercredi 27 juin 2018 06:00
À : Softwires WG
Cc : [e-mail]<mailto:[e-mail]>
Objet : Re: [Softwires] WGLC for draft-ietf-softwire-yang-04 as Standard Track, closed by 27 June 2018

As the document shepherd, I have reviewed this document. Document editors and WG chairs should treat these comments just like any other last call comments. In general, I think this document is in a good shape. The YANG model is well defined and clearly described.
Here are some minor issues, mostly editorial, although there is 1 error report by the IETF Yang validation tool. It should be easy to be fixed, I believe

[Med] As you can see in https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/softwire-yang-validation.pdf, the module passes validation. The issue displayed by the tracker is related to [e-mail]<http://www.yangvalidator.com/validator#iana-if-type>.

There are some minor comments below, most of them are editorial.

Section 2.1
It may be better to add the statement names in the description of choice statement:
  a choice statement 'ce-type' is included for ...
  a choice statement 'data-plane' is included to ...

[Med] Fixed.

"For each module, a choice statement is included for either 'binding' or 'algorithmic'."
But in Table 1 it is 'algorithm'. Maybe 'algorithmic' should be changed to 'algorithm'.

[Med] Good catch. Fixed.


Section 2.2
The reference to Appendix A.3 should be Appendix A

[Med] Citing Appendix A.3 is on purpose. It is where NAT and RFC8349 examples are provided.


Section 3.1
"for all of the softwire mechanisms listed in Section 1"
It may be bette to avoid self citation and just list the mechanisms here.

[Med] OK.


"Figure 1 describes the tree structure of the CE softwire YANG module"
It's better to unify the terminology as "Softwire CE YANG Module"

[Med] OK.


Section 3.2
In the paragraph of "softwire-path-mru:":
It's confusing here whether the MRU is for IPv4 or IPv6.

[Med] The text indicates "to set the maximum IPv6 softwire packet size". Furthermore, the description "The path MRU for the softwire (payload + encapsulation
        overhead)" is also clear about the usage. I don't think a change is required.

There are two "br-ipv6-addr" defined. It may be better to add different prefixes or suffixes into the names, but I'm also OK with the current names..
[Med] We could add map or lw prefixes, but as you know adding prefixes is not helpful (and it even not recommended) as a leaf is identified by its parent. I suggest to leave those unmodified.

In the paragraph of "ce-binding-ipv6-addr-change:":
"binding-ipv6-address" is not defined in the whole document. It should be explained.

[Med] changed to "binding IPv6 address"

Section 4.2
"in Figure 1"
should be "in Section 3.2"

[Med] OK.


"for logging/data retention purposes" -> "for logging or data retention purposes"
[Med] OK.

"between 3-tuples, which contains the lwB4's IPv6 address..." -> "between 3-tuples: the lwB4's IPv6 address..."
[Med] Changed to "3-tuples {lwB4's IPv6 address/prefix, the allocated IPv4 address, restricted port-set}"


"softwire-num-threshold"
>From the description, I think it may be better to rename it to "softwire-num-max".
[Med] Makes sense.

In the paratraph of "invalid-entry, added-entry, modified-entry:":
"the client" -> "the NETCONF client"

[Med] OK.

Appendix A.1
"lwB4 IPv6 Address:          123"
What's the "lwB4 IPv6 Address" here?
[Med] Oops. This should be PSID.


Appendix A.2
"for the clients" -> "for the CEs"
[Med] Done.


Appendix A.3
The same "lwB4 IPv6 Address" issue
And the PSID and PSID offset should be provided in the example.
[Med] Idem as above. Should s/lwB4 IPv6 Address/PSID.


Cheers,

Sheng

From: Softwires [mailto:[e-mail]] On Behalf Of Sheng Jiang
Sent: Wednesday, June 13, 2018 5:44 PM
To: Softwires WG <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: [Softwires] WGLC for draft-ietf-softwire-yang-04 as Standard Track, closed by 27 June 2018


This email announces a Softwire Working Group Last Call (WGLC) on:



Since both chairs of softwire WG are the co-authors of this document. I am now acting as the document shepherd for this draft.



YANG Modules for IPv4-in-IPv6 Address plus Port Softwires

draft-ietf-softwire-yang-04

https://tools.ietf.org/html/draft-ietf-softwire-yang-04



This draft is intended to become a Standard Track RFC.



This WGLC will run through the end of the day on Wednesday, June 27, 2018.



Comments should be sent to the [e-mail]<mailto:[e-mail]> list, although purely

editorial comments may be sent directly to the author.



No IPR disclosures have been submitted directly on

draft-ietf-softwire-yang-04



Regards and thanks,



Sheng Jiang (document shepherd)