Last Call Review of draft-ietf-anima-prefix-management-05
review-ietf-anima-prefix-management-05-genart-lc-romascanu-2017-10-05-00

• Status
• Email expansions
• History

• Versions
• 00

Review
review-ietf-anima-prefix-management-05-genart-lc-romascanu-2017-10-05

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'