Re-,

Please see inline.

Cheers,
Med

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

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:

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

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





_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires

Reply via email to