[RTG-DIR] RtgDir review: draft-ietf-anima-prefix-management-05

[Geoff Huston <[e-mail]>]

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
​http://trac.tools.ietf.org/area/rtg/trac/wiki/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.txt 
Reviewer: your-name 
Review Date: date 
IETF LC End Date: date-if-known 
Intended Status: copy-from-I-D

Summary: 

  I have some minor concerns about this document that I think should be
  resolved before publication

Comments:

  This document describes an "autonomic solution for IPv6 prefix
  management at the edge of large-scale ISP networks".

  The document contains a description of a mechanism to request and receive
  an IPv6 prefix, which is just one part of an overall process of address
  management in a network. The document could benefit from some
  considerations of the interplay between this address assignment mechanism
  and the routing system used within the network. The document also does not
  explicitly address issues of address prefix reuse, and the relative
  advantages and disadvantages between an address management mechanism that
  attempts to define a long lived association between a device a particular
  address prefix, and a dynamic pool management system that admits for high
  levels of prefix reuse. The document also does not define the intended scope 
  applicability - for example is this mechanism intended to operate across
  network administrative boundaries? If not, how are such adminis boundaries
  defined?

  This is intended for publication as an informational document, so there is
  no requirement to meet strict standards of precision and clarity. That
  said, there are areas where the language is speculative and vague, and
  some assertions are clearly untested (and somewhat dubious in the way in
  which they are stated).


Comments on quality and readability.

  I don't believe that the document clearly achieves what it intended to
  achieve.

  The document describes a problem space, and then jumps immediately into a
  way to define an ANIMA scheme that could be set up to perform a prefix
  assignment function. It would help in an informational document to provide
  a bridge between problem and solution specifics, namely a design overview
  of they overall approach being described in this document.
  
  Other reviews have noted editorial nits - no point in repeating that work
  here.