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

From: Sheng Jiang <[email-masked]>
Date: Wed, 13 Jun 2018 09:44:00 +0000

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 [email-masked] 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)

---

From: [email-masked]
Date: Thu, 14 Jun 2018 15:18:04 +0200

Hi Sheng,

Many thanks for agreeing to shepherd this.

As I co-author, I support moving this draft forward. I would like to point out an implementation which we have of the lwAFTR (BR) portion of the YANG model which has been developed alongside the updating of this draft. Code is available from: https://github.com/sysrepo/sysrepo-snabb-plugin.git

This is implemented as a plugin for Sysrepo (https://github.com/sysrepo/sysrepo) for configuring the Snabb based lw4o6 data plane (https://github.com/Igalia/snabb.git).

Thanks,
Ian

> On 13. Jun 2018, at 11:44, Sheng Jiang <[email-masked]> wrote:
> 
> https://tools.ietf.org/html/draft-ietf-softwire-yang-04 <https://tools.ietf.org/html/draft-ietf-softwire-yang-04>
>  
> Comments should be sent to the [email-masked] <mailto:[email-masked]> list, although purely
> _______________________________________________
> Softwires mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/softwires <https://www.ietf.org/mailman/listinfo/softwires>

---

From: Sheng Jiang <[email-masked]>
Date: Fri, 15 Jun 2018 01:32:09 +0000

Hi, Ian,

Thanks for your information. I will make sure it included into the document shepherd. More implementation or interoperation test information would be helpful to prove the matureness of this technology and draft.

Cheers,

Sheng

From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, June 14, 2018 9:18 PM
To: Sheng Jiang <[email-masked]>
Cc: Softwires WG <[email-masked]>; [email-masked]
Subject: Re: [Softwires] WGLC for draft-ietf-softwire-yang-04 as Standard Track, closed by 27 June 2018

Hi Sheng,

Thanks,
Ian

On 13. Jun 2018, at 11:44, Sheng Jiang <[email-masked]<mailto:[email-masked]>> wrote:

Comments should be sent to the [email-masked]<mailto:[email-masked]> list, although purely
editorial comments may be sent directly to the author.

Regards and thanks,

Sheng Jiang (document shepherd)
_______________________________________________
Softwires mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/softwires

---

From: Andy Wingo <[email-masked]>
Date: Fri, 15 Jun 2018 11:14:14 +0200

Hi Sheng,

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

Just wanted to chime in that we have an implementation of the AFTR part
of RFC7596 in the Snabb open source project.  The Snabb lwAFTR exposes
its configuration and state in terms of earlier drafts of
ietf-softwire-br (revision from 2017-10-19).  Some configuration
documentation here:

  https://github.com/Igalia/snabb/blob/lwaftr/src/program/lwaftr/doc/configuration.md

Though we have our own YANG schema, we do support the ietf-softwire-br
version via a translator.  Anyway, I had a look at this revision, and it
looks good to me.  We will be updating our version over the next few
weeks.

I do have one note about this draft: there are a two YANG nodes whose
"description" leaf is literally "...".  Perhaps these should be fleshed
out.

Regards,

Andy

---

From: Sheng Jiang <[email-masked]>
Date: Sat, 16 Jun 2018 09:49:21 +0000

Thanks, Andy. The author would handle your comments together with other WGLC comments. More implementation is a great news.

Sheng

-----Original Message-----
From: Andy Wingo [mailto:[email-masked]] 
Sent: Friday, June 15, 2018 5:14 PM
To: Softwires WG <[email-masked]>
Cc: Sheng Jiang <[email-masked]>
Subject: Re: [Softwires] WGLC for draft-ietf-softwire-yang-04 as Standard Track, closed by 27 June 2018

Hi Sheng,

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

Just wanted to chime in that we have an implementation of the AFTR part of RFC7596 in the Snabb open source project.  The Snabb lwAFTR exposes its configuration and state in terms of earlier drafts of ietf-softwire-br (revision from 2017-10-19).  Some configuration documentation here:

Though we have our own YANG schema, we do support the ietf-softwire-br version via a translator.  Anyway, I had a look at this revision, and it looks good to me.  We will be updating our version over the next few weeks.

I do have one note about this draft: there are a two YANG nodes whose "description" leaf is literally "...".  Perhaps these should be fleshed out.

Regards,

Andy

---

From: Linhui Sun <[email-masked]>
Date: Mon, 18 Jun 2018 22:30:28 +0800

Hi all,

As a co-author, I support it. This document has been reviewed and refined
in several rounds and it seems that it's the right time to move it forward.

BR,
Linhui

2018-06-13 17:44 GMT+08:00 Sheng Jiang <[email-masked]>:

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

---

From: Qi Sun <[email-masked]>
Date: Tue, 19 Jun 2018 17:31:10 +0800

Dear all,

I support moving forward with this draft. This is a missing part for
deploying softwire 4over6 transition mechanisms. The YANG model itself has
been developed for a reasonable period of time and is now mature enough for
being a standard.

// disclosure: I'm one of the co-authors.

Thanks,
Qi

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 27 Jun 2018 03:59:45 +0000

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 blieve

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 ...

"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'.

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

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.

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

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

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.

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

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

"for logging/data retention purposes" -> "for logging or data retention purposes"

"between 3-tuples, which contains the lwB4's IPv6 address..." -> "between 3-tuples: the lwB4's IPv6 address..."

"softwire-num-threshold"
>From the description, I think it may be better to rename it to "softwire-num-max".
In the paratraph of "invalid-entry, added-entry, modified-entry:":
"the client" -> "the NETCONF client"

Appendix A.1
"lwB4 IPv6 Address:          123"
What's the "lwB4 IPv6 Address" here?

Appendix A.2
"for the clients" -> "for the CEs"

Appendix A.3
The same "lwB4 IPv6 Address" issue
And the PSID and PSID offset should be provided in the example.

Cheers,

Sheng

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

Regards and thanks,

---

From: <[email-masked]>
Date: Wed, 27 Jun 2018 08:54:12 +0000

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:[email-masked]] De la part de Sheng Jiang
Envoyé : mercredi 27 juin 2018 06:00
À : Softwires WG
Cc : [email-masked]
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 [email-masked]<http://www.yangvalidator.com/validator#iana-if-type>.

Section 2.1

[Med] Fixed.

[Med] Good catch. Fixed.

Section 2.2

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

Section 3.1

[Med] OK.

[Med] OK.

Section 3.2

[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.

[Med] changed to "binding IPv6 address"

Section 4.2
"in Figure 1"

[Med] OK.

[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.

[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
[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

Regards and thanks,

---

From: <[email-masked]>
Date: Fri, 29 Jun 2018 08:20:27 +0000

Hi Ian,

Works for me. Thanks.

Cheers,
Med

De : [email-masked] [mailto:[email-masked]]
Envoyé : vendredi 29 juin 2018 09:59
À : BOUCADAIR Mohamed IMT/OLN; Sheng Jiang
Cc : Softwires WG; [email-masked]; Andy Wingo
Objet : Re: [Softwires] WGLC for draft-ietf-softwire-yang-04 as Standard Track, closed by 27 June 2018

Hi Sheng /Med,

@Sheng, Thanks for the review.
@Med, Thanks for the quick update.

A couple of other things:

There’s an outstanding comment on model element descriptions given as “…”. Proposed new text:

notification softwire-binding-instance-event description: "The ID of the binding-instance that generated the notification.";

leaf-list modified-entry description "The ID of the the binding-table entry that has been modified.";

------
I just did a quick read through of -05. There are a few small language cleanups that I would like to make:

Section 2.1
s/Provides configuration and monitoring for softwire CE element/Provides configuration and monitoring for the softwire CE element/

s/Provides configuration and monitoring for softwire BR element/Provides configuration and monitoring for the softwire BR element/

Section 2.2
s/be imported here, as needed/be imported, as needed/

ietf-softwire-ce:binding-entry/br-ipv6-addr
description
s/The IPv6 address for of the binding BR./The IPv6 address for the binding BR./

ietf-softwire-br:br-instances/algorithm
description
s/Indicate that the instance supports the MAP-E and MAP-T functions./Indicate that the instance supports the MAP-E and MAP-T functions./

If there’s no objection to the above changes, I’ll update and post later on today.

Cheers,
Ian

On 27. Jun 2018, at 10:54, [email-masked]<mailto:[email-masked]> wrote:

Hi Sheng,

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

---

From: [email-masked]
Date: Fri, 29 Jun 2018 15:54:18 +0200

Hi,

I’ve just posted v06 with the changes proposed below incorporated.

Thanks,
Ian

> On 29. Jun 2018, at 10:20, <[email-masked]> <[email-masked]> wrote:
> 
> Hi Ian,
>  
> Works for me. Thanks.
>  
> Cheers,
> Med
>  
> On 27. Jun 2018, at 10:54, [email-masked] <mailto:[email-masked]> wrote:
>  
> Hi Sheng,
>  
> An updated version which integrates your comments is available online:https://datatracker.ietf.org/doc/draft-ietf-softwire-yang/?include_text=1 <https://datatracker.ietf.org/doc/draft-ietf-softwire-yang/?include_text=1>
>  
> See more inline.
>  
> Cheers,
> Med

---

From: [email-masked]
Date: Fri, 29 Jun 2018 09:59:29 +0200

Hi Sheng /Med,

------

Section 2.1

Section 2.2

Cheers,
Ian

> On 27. Jun 2018, at 10:54, [email-masked] wrote:
> 
> Hi Sheng,
>  
> De : Softwires [mailto:[email-masked] <mailto:[email-masked]>] De la part de Sheng Jiang
> Cc : [email-masked] <mailto:[email-masked]>
> 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.
> [Med] As you can see in https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/softwire-yang-validation.pdf <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 [email-masked] <http://www.yangvalidator.com/validator#iana-if-type>.
>  
>   a choice statement 'data-plane' is included to ....
>  
> [Med] Fixed.
>  
> 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.
>  
> [Med] changed to “binding IPv6 address”
>  
> Section 4.2
> "in Figure 1"
> [Med] Changed to “3-tuples {lwB4's IPv6 address/prefix, the allocated IPv4 address, restricted port-set}”
>  
>  
> "softwire-num-threshold"