Subject: [Anima] Genart last call review of draft-ietf-anima-prefix-management-05

From: Dan Romascanu <[email-masked]>
Date: Thu, 05 Oct 2017 00:40:31 -0700

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'

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 6 Oct 2017 14:19:49 +1300

Thanks Dan. Good comments, and I think we can deal with them
all quite easily when the Last Call expires.

Regards
   Brian