Skip to main content

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

Request Review of draft-ietf-anima-prefix-management
Requested revision No specific revision (document currently at 07)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2017-10-12
Requested 2017-09-28
Authors Sheng Jiang , Zongpeng Du , Brian E. Carpenter , Qiong Sun
I-D last updated 2017-10-05
Completed reviews Genart Last Call review of -05 by Dan Romascanu (diff)
Rtgdir Last Call review of -05 by Geoff Huston (diff)
Opsdir Last Call review of -06 by Fred Baker (diff)
Secdir Last Call review of -05 by Russ Housley (diff)
Secdir Telechat review of -06 by Catherine Meadows (diff)
Genart Telechat review of -06 by Dan Romascanu (diff)
Assignment Reviewer Dan Romascanu
State Completed
Request Last Call review on draft-ietf-anima-prefix-management by General Area Review Team (Gen-ART) Assigned
Reviewed revision 05 (document currently at 07)
Result Ready w/issues
Completed 2017-10-05
review-ietf-anima-prefix-management-05-genart-lc-romascanu-2017-10-05-00
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'