Thanks Dan. Good comments, and I think we can deal with them all quite easily when the Last Call expires.
Regards Brian On 05/10/2017 20:40, Dan Romascanu wrote: > Reviewer: Dan Romascanu > Review result: Ready with Issues > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > Document: draft-ietf-anima-prefix-management-?? > Reviewer: Dan Romascanu > Review Date: 2017-10-04 > IETF LC End Date: 2017-10-12 > IESG Telechat date: Not scheduled for a telechat > > Summary: > > This document describes an ANIMA solution for IPv6 prefix management at the > edge of large-scale ISP networks sketches an IPv4 solution extension to > support > IPv4 prefixes. It is well written, targeting the operators of ISP networks, > describes the solution in a manner very clear for people familiar with the ANI > framework, with useful deployment examples. There are a few minor issues that > I > recommend to clarify. > > Major issues: > > Minor issues: > > 1. In Section 3: > > ' Roles could be > locally defined or could be generic (edge router, interior router, > etc.).' > > I am a little confused by the locally defined roles concept. Do the brackets > refer only to the generic roles? If so, what would be the examples of locally > defined roles? > > 2. Section 3.2.1 - what does 'Identity of this device' mean in this context? A > clarification may be needed. > > 3. Section 4. The presence of a PrefixManager ASA seems to be a fundamental > requirement for the solution described in the document. Consider using a > capitalized MUST to emphasize this. > > 4. Section 4.1: > > ' It > should decide the length of the requested prefix and request it by > the mechanism described in Section 6.' > > Is not the length of the requested prefix a function of the device role? What > is left to the device to decide? > > 5. Section 7. Related to my previous lack of clarity about device identity > being decided by the device. Is this not a potential threat? It does not seem > to be taken into consideration in the referred security documents. > > 6. [I-D.ietf-cbor-cddl] and [I-D.ietf-core-yang-cbor] seem to be required > reading in case the respective options are being used. Consider moving these > as > Normative References. > > Nits/editorial comments: > > 1. Section 1: > > ' A generic autonomic signaling protocol > (GRASP) is specified by [I-D.ietf-anima-grasp] and would be used by > the proposed autonomic prefix management solution. ' > > I am confused by the use of 'would'. Does it mean that GRASP is just an > example? Are there other to be taken into consideration? If using this > document > to validate the design of GRASP is the principal scope, why the conditional > mode? > > 2. need to expand acronyms at first occurrence - e.g. DHCPv6-PD, CBOR, etc. > > 3. I am not sure what 'Abstract' means in the name of the Appendix section > 'Abstract Deployment Overview' > > > _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
