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
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
