Reviewer: Joel Halpern Review result: Ready Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see https://wiki.ietf.org/en/group/rtg/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-name-version Reviewer: your-name Review Date: date IETF LC End Date: date-if-known Intended Status: copy-from-I-D Summary: Choose from this list... No issues found. This document is ready for publication. I have a few minor comments that should be considered. This is a truly impressive piece of work. The editors have pulled together information from a myriad sources into a usable (if massive) YANG module that addresses the range of needs very well. Major Issues: N/A Minor Issues: I note that section 5.1 in discussing parent relationships specifies that if a parent AC is deleted, all the child ACs MUST be deleted. Given that there is no reference from a parent to its children (unless I missed it), it seems to this reader that it would really help implementors to tell them how this is to be done? Are all children to be delted first, and the client give an error if there are any active children? Is the client to silently find and delete all ACs which point to the deleted AC as a parent? Or some other means? In section 5.2 (References) in describing the groupings the tree diagram shows a number of peer entities. However, unless I am misreading the YANG, they are, in almost all cases, actually nested. Was this a deliberate simplification, on artifact of the tree generation tool, or an error in my reading? I note that the document refers to RIP in multiple places. Unless I missed something, this references RIPv2, but not RIPng (RFC 20808). I can imagine reasons for such an omission. If there is a good reason, then please state it. Otherwise, sorry, please also cover 2080. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
