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

[Brian E Carpenter <[e-mail]>]

Thanks Geoff. Some responses in line below.

On 17/10/2017 13:55, Geoff Huston wrote:
> 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?

OK, fair enough. Although the scope of ANIMA in general is within a single
admin boundary, we probably need to restate it here.

>   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).

There will be quite a few wording improvements following other reviews,
so I hope that will take care of most of this issue.

> 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.

I think we can do that in not too many words. 
>   Other reviews have noted editorial nits - no point in repeating that work
>   here.

Thanks
    Brian