Hi Med, Please see inline.
Cheers, Ian > On 13. Nov 2017, at 18:28, <[email protected]> > <[email protected]> wrote: > > Re-, > > Please see inline. > > Cheers, > Med > > De : Ian Farrer [mailto:[email protected] <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 > <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 > > <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
