Ian, I fixed both points in -09.
Cheers, Med De : Ian Farrer [mailto:[email protected]] Envoyé : lundi 13 novembre 2017 13:16 À : BOUCADAIR Mohamed IMT/OLN Cc : [email protected]; [email protected]; Softwires list Objet : Re: Tags changed for draft-ietf-softwire-dslite-yang Hi Med, Please see inline. Cheers, Ian On 13. Nov 2017, at 18:28, <[email protected]<mailto:[email protected]>> <[email protected]<mailto:[email protected]>> wrote: 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]<mailto:[email protected]>; [email protected]<mailto:[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. [if - It was only cited as an informative reference in 07, so there shouldn’t be a dependency problem] --- 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. [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."; ] Cheers, Ian
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
