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
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
