Subject: Re: [Softwires] Tags changed for draft-ietf-softwire-dslite-yang

From: Ian Farrer <[email-masked]>
Date: Mon, 13 Nov 2017 16:59:53 +0800

Hi Med,

Thanks for the update. I’ve just checked through this version. For some reason, section 1.2 has reverted to an earlier version with explicit instructions for the tree diagram (this wasn’t the case in 07). This was from Mahesh’s YANG doctor review, and your response from 9th October:

---
> Section 1.2 Tree Diagram
> 
> Please refer to
> https://tools.ietf.org/html/draft-ietf-netmod-yang-tree-diagrams-01 <https://tools.ietf.org/html/draft-ietf-netmod-yang-tree-diagrams-01>
> instead of
> defining the nomenclature for tree diagram in the document.

[Med] Done. Thanks.
—

For my comment about rate limiting changes to the b4-ipv6-address. There is now a node for setting the permitted change interval, but I don’t see how I can use the model to check if a new address offered by a client is allowable. My thinking is that if there was a ‘last-address-change yang:date-and-time’ leaf under leaf b4-ipv6-address, then it is easy to use the model to see if an address change is permitted, or even raise a notification if it is not.

My point is, if a client is trying to change its address more regularly than the policy allows, then they probably don’t have IPv4 service from when their address has changed until the AFTR policy allows the source address change. If this is happening en-masse (either from a single or many clients) for any reason, an operator probably wants to know about it.

Cheers,
Ian

---

From: <[email-masked]>
Date: Mon, 13 Nov 2017 10:28:33 +0000

Re-,

Please see inline.

Cheers,
Med

De : Ian Farrer [mailto:[email-masked]]
Envoyé : lundi 13 novembre 2017 10:00
À : BOUCADAIR Mohamed IMT/OLN
Cc : [email-masked]; [email-masked]; Softwires list
Objet : Re: Tags changed for draft-ietf-softwire-dslite-yang

Hi Med,

[Med] I have implemented the change because I thought that document is advanced in the publication process. But when I recently checked, I found the document is not that advanced in the process. I removed citing that document to avoid a normative dependency which can be avoided by explicitly inserting the appropriate text.

---
Section 1.2 Tree Diagram

Please refer to
https://tools.ietf.org/html/draft-ietf-netmod-yang-tree-diagrams-01
instead of
defining the nomenclature for tree diagram in the document.

[Med] Done. Thanks.
—

For my comment about rate limiting changes to the b4-ipv6-address. There is now a node for setting the permitted change interval, but I don’t see how I can use the model to check if a new address offered by a client is allowable.
My thinking is that if there was a ‘last-address-change yang:date-and-time’ leaf under leaf b4-ipv6-address, then it is easy to use the model to see if an address change is permitted, or even raise a notification if it is not.

[Med] Are you asking for something similar to: https://github.com/boucadair/draft-ietf-softwire-dslite-yang/commit/5f37cf90ddadeec544e8087c1643d3bf923e7d5d?

Cheers,
Ian

---

From: Ian Farrer <[email-masked]>
Date: Mon, 13 Nov 2017 20:15:55 +0800

Hi Med,

Please see inline.

Cheers,
Ian

> On 13. Nov 2017, at 18:28, <[email-masked]> <[email-masked]> wrote:
> 
> Re-,
>  
> Please see inline.
>  
> Cheers,
> Med
>  
> De : Ian Farrer [mailto:[email-masked] <mailto:[email-masked]>] 
> Cc : [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; Softwires list

[if - It was only cited as an informative reference in 07, so there shouldn’t be a dependency problem]

> [Med] Are you asking for something similar to: https://github.com/boucadair/draft-ietf-softwire-dslite-yang/commit/5f37cf90ddadeec544e8087c1643d3bf923e7d5d <https://github.com/boucadair/draft-ietf-softwire-dslite-yang/commit/5f37cf90ddadeec544e8087c1643d3bf923e7d5d>?
>  

[if - Yes. Looks good. Can I propose the following change to the name and description:

Old:
 notification too-fast-b4-address-change-event {
   description
     "Notifications must be generated when a B4's IPv6 address change
      is discarded because of b4-address-change-limit.";

New:
 notification  b4-address-change-limit-policy-violation {
   description
     “Generates notifications when a B4 unsuccessfully attempts to change IPv6 address
      in a time shorter than the value of 'b4-address-change-limit.";

]

---

From: <[email-masked]>
Date: Mon, 13 Nov 2017 13:13:45 +0000

Re-,

Please see inline.

Cheers,
Med

Envoyé : lundi 13 novembre 2017 13:16

Hi Med,

Please see inline.

Cheers,
Ian

On 13. Nov 2017, at 18:28, <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>> wrote:

Re-,

Please see inline.

Cheers,
Med

Cc : [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Softwires list

Hi Med,

[if - It was only cited as an informative reference in 07, so there shouldn’t be a dependency problem]
[Med] The point is that I’m questioning that citation as an informative reference. Because a reader must look at that document to understand the meaning of the symbols, it should be cited as a normative reference. Unless you have a strong objection, I suggest to maintain the current text.

---
Section 1.2 Tree Diagram

Please refer to

[Med] Done. Thanks.
—

Old:

New:

]

[Med] Looks good to me. Thanks.

Cheers,
Ian

---

From: Ian Farrer <[email-masked]>
Date: Mon, 13 Nov 2017 21:56:31 +0800

Hi Med,

> [Med] The point is that I’m questioning that citation as an informative reference. Because a reader must look at that document to understand the meaning of the symbols, it should be cited as a norm…

The comment was originally raised by Mahesh, you agreed and put it in the 07 update. If you think this needs to be changed now then Mahesh should be consulted first.

Cheers,
Ian

---

From: <[email-masked]>
Date: Tue, 14 Nov 2017 11:38:45 +0000

Ian,

I fixed both points in -09.

Cheers,
Med

Hi Med,

Please see inline.

Cheers,
Ian

Re-,

Please see inline.

Cheers,
Med

Hi Med,

---
Section 1.2 Tree Diagram

Please refer to

[Med] Done. Thanks.
—

Old:

New:

]

Cheers,
Ian