Re: Gen-ART LC review of draft-ietf-lisp-eid-block-mgmnt-06

Peter Yee <peter@akayla.com> Wed, 06 April 2016 19:17 UTC

Return-Path: <peter@akayla.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F30BA12D52F; Wed, 6 Apr 2016 12:17:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Level:
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fg8yvecPufZT; Wed, 6 Apr 2016 12:17:15 -0700 (PDT)
Received: from p3plsmtpa08-09.prod.phx3.secureserver.net (p3plsmtpa08-09.prod.phx3.secureserver.net [173.201.193.110]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF49112D13D; Wed, 6 Apr 2016 12:17:15 -0700 (PDT)
Received: from [31.133.177.150] ([31.133.177.150]) by p3plsmtpa08-09.prod.phx3.secureserver.net with id f7H71s00M3F4iKB017HCay; Wed, 06 Apr 2016 12:17:14 -0700
User-Agent: Microsoft-MacOutlook/14.6.2.160219
Date: Wed, 06 Apr 2016 12:17:06 -0700
Subject: Re: Gen-ART LC review of draft-ietf-lisp-eid-block-mgmnt-06
From: Peter Yee <peter@akayla.com>
To: Luigi Iannone <ggx@gigix.net>
Message-ID: <D32AADA8.1668E%peter@akayla.com>
Thread-Topic: Gen-ART LC review of draft-ietf-lisp-eid-block-mgmnt-06
References: <004001d1608f$ef60e6b0$ce22b410$@akayla.com> <30DBBD82-6F32-4D05-B1D6-0E2564855ED7@gigix.net> <B3384C62-EE51-4E80-9A75-B49AD16172C9@gigix.net> <00a701d1629f$7a9719a0$6fc54ce0$@akayla.com> <474E4613-8EB5-47AE-806E-086BE920855B@gigix.net> <1F7BB12F-63A0-4FA2-AAA5-79110671355B@gigix.net> <007401d17c27$783d0a10$68b71e30$@akayla.com> <296CE5D3-A607-4715-9D9D-DDEA9AB9AA5B@gigix.net>
In-Reply-To: <296CE5D3-A607-4715-9D9D-DDEA9AB9AA5B@gigix.net>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/ZsYII1aZR1io8wU7L9zJvmTtD1U>
Cc: draft-ietf-lisp-eid-block-mgmnt.all@tools.ietf.org, IETF Gen-ART <gen-art@ietf.org>, IETF <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Apr 2016 19:17:19 -0000

Luigi,
	Given the RIPE situation, I think we are all good to go.  I see that the
IESG has approved moving the document forward.  Congratulations. :-)

		Kind regards,
		-Peter

On 4/6/16, 8:11 AM, "Luigi Iannone" <ggx@gigix.net> wrote:

>Hi Peter,
>
>Sorry for taking some time look at your comments.
>
>Thanks again for the time you spend on the draft, I think it has improved
>a lot.
>
>I as well that the proposed change address your comments (see my answers
>inline)
>
>ciao
>
> 
>
>> On 12 Mar 2016, at 03:21, Peter Yee <peter@akayla.com> wrote:
>> 
>> Luigi,
>> 	Please see my responses below prefixed with PEY>.
>> 
>> 	Thanks.
>> 
>> 		Kind regards,
>> 		-Peter
>> 
>> -----Original Message-----
>> From: Luigi Iannone [mailto:ggx@gigix.net]
>> Sent: Wednesday, February 24, 2016 8:31 AM
>> To: Peter Yee
>> Cc: draft-ietf-lisp-eid-block-mgmnt.all@tools.ietf.org;
>>gen-art@ietf.org; ietf@ietf.org
>> Subject: Re: Gen-ART LC review of draft-ietf-lisp-eid-block-mgmnt-06
>> 
>> Hi Peter,
>> 
>> since we cleared the minor issues we can move to the major issues.
>> 
>> The IANA Consideration section was not exactly an example of clarity.
>> So better to rewrite it….
>> 
>> Hereafter  you can find my replies to your comments and at the end
>>you’ll find the proposed text for the new IANA Consideration Section.
>> 
>> Let me know if it works for you.
>> 
>> ciao
>> 
>> L.
>> 
>> 
>>> Major issues: 
>>> 
>>> This draft does not give much management perspective nor many
>>> procedures, perhaps because it calls itself a framework for management.
>> 
>> Indeed, it is a guideline document.
>> Having said that, RIPE had no difficulties in implementing the
>>registration service.
>> 
>> PEY>Sure, but that may well be because this draft is retrospective
>>rather than prescriptive.  Meaning that it documents what was already
>>done or expected to be, rather than telling a naïve registrar your
>>expectations of them.  As I noted earlier, given that you only expect
>>one registrar and this is all being done as part of an experiment, I
>>don't think we'll actually have a problem here.
>
>OK thanks.
>
>
>
>
>> 
>>> It mostly lists
>>> data to be captured and discusses renewals periods.  It does not
>>> discuss how requests are vetted or what would cause one to be
>>> disapproved, if that's even a possibility.
>> 
>> In Section 5, last bullet, and point 4 of section 6 there is
>>information on what should be provided in order to have a soul
>>registration request.
>> 
>> PEY>That still doesn't address whether requests are vetted, it simply
>>says that any can be an applicant, that they must explain why the
>>parameters of why they want the registration, and that the details will
>>be made public.  That's still not much in the way of guidance to the
>>registrar.
>
>I think the current proposed text fixes the issue:
>
>       Anyone can obtain an entry in the EID prefix registry, on the
>       understanding that the prefix so registered is for the exclusive
>       use in the LISP experimental network, and that their registration
>       details (as specified in Section 6) are openly published in the
>       EID prefix registry.
>
>
>Anyone can have it. Just provide some information and this is done. ;-)
>
>> 
>>> It does not give any recourse for disapproved requests.
>>> It does not specify how a request (whether pending or approved) is
>>> abandoned or surrendered.  Consider section 3 of RFC 5226 as possibly
>>> being useful, for example.
>> 
>> In the new IANA Considerations section FCFS policy is now spelled out.
>> 
>> PEY>That's a helpful start and sort of implies that that all requests
>>are granted and granted in the order received.  If that's the case, it
>>would be useful to say so.
>
>This is IMHO implicit in FCFS. RFC 5226 reads:
>
>	    First Come First Served - Assignments are made to anyone on a
>            first come, first served basis.  There is no substantive
>            review of the request, other than to ensure that it is
>            well-formed and doesn't duplicate an existing assignment.
>
>
>
>
>> 
>>> Given the details that the draft does discuss, it really needs to
>>> have an actual discussion of management procedures
>> 
>> Can you be more specific on whether something else is missing?
>> 
>> PEY>Pretend you are a naïve registrar who has been hired to manage the
>>EID prefix requests.  Does this document tell you enough to do your job
>>successfully?  Does it tell registrants what they can expect of the
>>process?  The document is titled "LISP EID Block Management Guidelines",
>>yet it doesn't really say much about the management processes.
>
>You might be right on the “naive registar”. But we are lucky enough and
>RIPE is not a naive registar.
>Hence, may be is not worth to go in further details on this point.
>
>> 
>>> or give a pointer as
>>> to where these are discussed or how they are to be executed in concert
>>> with the framework.
>>> 
>>> Section 10 (IANA Considerations): This section seems inadequate from
>>> an RFC
>>> 5226 perspective as well as simply throwing a lot on IANA to provide
>>> the lookup mechanism without giving any further guidance than a bunch
>>> of protocols (RDAP, WHOIS, HTTP, etc.)  Also see RFC 5226, Section 4.2.
>>> Specific requirements for IANA need to be clearly spelled out in this
>>> section, especially as there are potentially multiple registry
>>> operators that are somehow involved in prefix allocation requests.
>> 
>> As for the latest agreement with RIPE, actually IANA does not need to
>>do anything.
>> This is now speed out in the new reviewed section.
>> 
>> PEY>That helps, but only on the assumption that RIPE already has an
>>idea of what is expected of them.  Which seems to be the case.
>
>Indeed. AFAIK they already implemented the registry. They just need the
>go ahead to open it.
>
>> 
>>> This is not at all
>>> made clear in the document how coordination between registry operators
>>> and IANA is to be carried out.
>> 
>> Since RIPE takes over all of the service, and will be the only one,
>>there is no specific coordination to be performed.
>> 
>> PEY>Good.  Removing the text about multiple registry operators also
>>helps clear that point up.
>> 
>>> It's not even clear whether users are supposed to be directly
>>> requesting prefixes from IANA or whether IANA should reject such
>>> requests.
>> 
>> In the latest version is spelled out that requests have to go to RIPE.
>> 
>> PEY>So, do requests from users go directly to RIPE?  Replace IANA in my
>>comments with RIPE and then see if they are covered.
>
>I think everything is ok.
>
>> 
>>> There's no guidance on how IANA recognizes valid requests.
>> 
>> Valid request are the ones respecting the content of this document.
>> This is now spelled out in the new text.
>> 
>> PEY>Okay.
>> 
>>> There's no guidance on whether there is a limit to the number of
>>> requests that may be made by an organization or individual.
>> 
>> There is no limit. This is now spelled out in the new text.
>> 
>> PEY>Good.
>> 
>>> The document notes a
>>> hierarchical distribution of the address space but gives no further
>>> guidance to IANA on how this hierarchy is to be organized and how
>>> registration requests impact the hierarchy.
>> 
>> The second bullet of section 5 has been deleted (as you also suggested
>>elsewhere).
>> Due to the limited duration of the experiment one single registration
>>operator (RIPE) is sufficient.
>> 
>> PEY>See?  I couldn't even tell that the hierarchy was organized around
>>the registrars, or that's what seems to be implied by your statement
>>above. Does going to a single registrar eliminate the hierarchy?  If
>>not, along what lines does the registrar assign requests to the
>>hierarchy?  Again, I go back to the naïve registrar.  Reading this
>>document, if I were that registrar, I would be wondering about those
>>details.
>> 
>
>Good. Problem is solved.
>
>>> In short, a whole lot more needs to appear in this section and in the
>>> text leading up to it.
>> 
>> Hopefully the proposed text fills the holes….
>> 
>>> 
>>> Then again, I'm no LISP expert, so I could be completely off-base
>>> here.  :-)
>>> 
>> 
>> At this point actually more than you think ;-)
>> 
>> 
>> %%%%%% NEW IANA SECTION PROPOSED TEXT %%%%%
>> 
>> IANA Considerations
>> 
>>   IANA allocated the following IPv6 address block for experimental use
>>   as LISP EID prefix [I-D.ietf-lisp-eid-block]:
>> 
>>   o  Address Block: 2001:5::/32
>> 
>>   o  Name: EID Space for LISP
>> 
>>   o  RFC: [I-D.ietf-lisp-eid-block]
>> 
>>   o  Further Details at: http://www.iana.org/assignments/
>>      iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml
>> 
>>   In order to grant requesting organisations and individuals exclusive
>>   use of EID prefixes out of such reserved block (limited to the
>>   duration of the LISP experiment as outlined in Section 7) there is an
>>   operational requirement for an EID registration service.
>> 
>>   Provided that the policies and requirements outlined in Section 4,
>>   Section 5, and Section 6 are respected, EID prefix registration is
>>   accorded based on a "First Come First Served" basis.
>>   There is no hard limit in the number of registrations an organization
>>   or individual can submit as long as information described in
>>   Section 6 is provided, in particular point 4: "Experiment
>>   Description".
>> 
>>   IANA and RIPE NCC agreed for the latter to run such service on behalf
>>   of the former, for the duration of the experiment and following the
>>   procedures outlined in Section 10.  Therefore, this document has no
>>   IANA actions.
>> 
>> PEY>That helps to coalesce the disparate information given in sections
>>4, 5, and 6 a bit.  It might not completely assist the naïve registrar
>>in managing the assignments, but I suspect RIPE already has this in
>>hand.  Don't let my comments stand in the way of advancing this document
>>if RIPE already knows what it's going to be doing and isn't looking for
>>full-blown guidance.  I reviewed the document without regard to RIPE's
>>background in it.  It seems obvious that there's additional knowledge
>>that's borne outside of the document.  Placing that knowledge within the
>>document would be nice for the historical record, but probably isn't
>>necessary to run the experiment.
>> 
>
>As I said above, you might be right about the naive registar, but RIPE
>already did the job.
>Certainly your comments are helpful if in the future we go for a
>permanent allocation.
>
>Thanks a lot again for your help.
>
>ciao
>
>L.
>
>
>
>> 
>>> On 20 Feb 2016, at 04:29, Peter Yee <peter@akayla.com> wrote:
>>> 
>>> Luigi,
>>> 	Sorry for the tardy reply.  My comments below are prefaced with PEY>.
>>> 
>>> 	Kind regards,
>>> 	-Peter
>>> 
>>> -----Original Message-----
>>> From: Luigi Iannone [mailto:ggx@gigix.net]
>>> Sent: Friday, February 12, 2016 3:06 AM
>>> To: Peter Yee
>>> Cc: draft-ietf-lisp-eid-block-mgmnt.all@tools.ietf.org;
>>> gen-art@ietf.org; ietf@ietf.org
>>> Subject: Re: Gen-ART LC review of draft-ietf-lisp-eid-block-mgmnt-06
>>> 
>>> Hi Peter,
>>> 
>>>> On 08 Feb 2016, at 19:35, Peter Yee <peter@akayla.com> wrote:
>>>> 
>>>> No problem, Luigi.  I'll just be happy if my feedback proves helpful.
>>> 
>>> It actually is and I realise that we did a pretty poor job in handling
>>>your review. Sorry for that.
>>> 
>>> In order to progress, let me propose a incremental approach:
>>> 
>>> Hereafter I put and comment everything that is minor issues.
>>> Let me know if you are OK.
>>> 
>>> Once we clear them we will go to the beefy stuff (aka major issues).
>>> 
>>> ciao
>>> 
>>> Luigi
>>> 
>>> 
>>>>> Minor issues:
>>>>> 
>>>>> Page 1, Abstract, 2nd sentence, "sub-prefixes": This term is not
>>>>> defined and suffers from the same problem as ietf-lisp-eid-block in
>>>>> that is also used once in that document but not further described.
>>>>> There appears to be some confusion between the use of prefix and
>>>>>sub-prefix that should be rectified.
>>>>> Prefix in this document appears to generally mean sub-prefix with
>>>>> regards to the experimental block, but this is not made clear.
>>>>> 
>>> 
>>> What about the following text:
>>> 
>>> 	This document proposes a framework for the management of the
>>> 	LISP EID Address Block. The framework described relies on
>>>hierarchical 
>>> 	distribution of the address space, granting temporary usage of
>>>prefixes of
>>>       such space to requesting organizations.
>>> 
>>> PEY> I think that will finesse the prefix/sub-prefix issue.
>>> 
>>> 
>>>>> Page 4, Section 5, items 1 and 2: considering that multiple
>>>>> registries may be assigning these (sub-)prefixes and that they must
>>>>> be globally unique, is there a mechanism to ensure this other than
>>>>> waiting for the inevitable IANA clash between simultaneous
>>>>>registrations?
>>>>> 
>>> 
>>> Fair enough. This was a degree of freedom we left to IANA. The
>>>requirement is globally uniqueness, how IANA, registries, or anybody
>>>else running the “Registry" want to sync to respect the requirement is
>>>something left as “implementation specific”.
>>> 
>>> My personal take on this point is that since the experiment has a
>>>limited duration and because it is very likely that the only registry
>>>running the service will be RIPE NCC, there is no need to over-engineer
>>>this point.
>>> 
>>> PEY> Somewhat agreed in that the actual usage should not cause any
>>>conflicts.  Note that S5 item 2 raises the concept of additional
>>>registries, and hence my concerns.  However, do note that Jari Arkko
>>>has raised concerns with the registry as well, so you may want to add
>>>language (and even consider removing S5 item 2) in order to reduce the
>>>confusion.
>>> 
>>> 
>>>>> Nits:
>>>>> 
>>>>> Page 3, Section 2, 1st paragraph, 1st sentence: change "separates"
>>>>> to "separate”.
>>> Thanks, will be fixed in -07.
>>> 
>>>>> 
>>>>> Page 3, Section 2, 3rd paragraph: change "organisation" to
>>>>>"organization".
>>>>> All other uses of the word in the document have been spelled
>>>>> "organization", so make this usage consistent with the others.  Or
>>>>> change them all to "organisation" if that's preferred.  Pick one.
>>> Thanks, will be fixed in -07.
>>> 
>>>>> 
>>>>> Page 3, Section 3, 1st sentence: delete an extraneous space after
>>>>> the open parenthesis.
>>> Thanks, will be fixed in -07.
>>> 
>>>>> 
>>>>> Page 3, Section 4, 1st sentence: insert "for" between "request" and
>>>>> "registration".
>>> Thanks, will be fixed in -07.
>>> 
>>>>> 
>>>>> Page 4, 1st full paragraph, 4th sentence: insert "be" between
>>>>> "should" and "no”.
>>> Does not apply anymore.
>>> 
>>>>> Page 4, Section 5, item 3: insert a comma after "information".
>>>>> Change "though" to "through”.
>>> Thanks, will be fixed in -07.
>>> 
>>>>> Change "I-D.ietf-weirds-rdap-sec" to RFC 7481.
>>> This is already fixed in -06.
>>> 
>>>>> Change "whois" to "WHOIS".  Change "http" to "HTTP”.
>>> Thanks, will be fixed in -07.
>>> 
>>>>> 
>>>>> Page 5, Section 6, 2nd paragraph: delete the comma after "registry".
>>>>> 
>>>>> Page 5, Section 6, item 1: insert "the" between "In" and "case".
>>>>> Append a comma after "prefix”.
>>> Thanks, will be fixed in -07.
>>> 
>>>>> 
>>>>> Page 5, Section 6, item 1: despite being based on the IANA PEN form,
>>>>> how about adding a sub-item (d) for the organization's website?
>>>>> This might allow for user disambiguation of registrants with similar
>>>>>names.
>>> It does not harm actually. Will be added in -07.
>>> 
>>>>> 
>>>>> Page 7, 1st partial paragraph, 1st partial sentence: insert "as"
>>>>> between "so" and "to”.
>>> Thanks, will be fixed in -07.
>>> 
>>>>> 
>>>>> Page 7, 1st full paragraph: delete the comma after "allocation”.
>>> Thanks, will be fixed in -07.
>>> 
>>>>> Page 7, Section 8, 2nd paragraph: delete the comma after "reasons”.
>>> Thanks, will be fixed in -07.
>>> 
>>>>> Page 7, Section 10, 2nd paragraph, 2nd sentence: insert "an" between
>>>>>"for"
>>>>> and "EID”.
>>> This is already fixed in -06.
>>> 
>>>>> Page 8, Section 11.1, [I-D.ietf-lisp-eid-block]: change the "-09" to
>>>>>"-11”.
>>> We are now at -12 and will keep the reference updated.
>>> 
>>>>> Page 9, Appendix A: This appendix is almost wholly superfluous and
>>>>> unnecessary to understanding the core of the document.  Most terms
>>>>> that appear in the appendix make no other appearance in the body of
>>>>> the document and the definition of these terms does not inform a
>>>>> reading of the body of the document.  I'd recommend dropping the
>>>>> appendix and elsewhere in the document throwing in a pointer to RFC
>>>>>6830.
>>>>> 
>>>>> 
>>> 
>>> This is a fair point and it has been raised also by other.
>>> Let me answer in the same way: What is the aim in having such appendix?
>>> - It is an appendix so its content is clearly optional.
>>> - It clearly spells out that is not normative content but only to
>>>avoid the reader digging around to find the definitions.
>>> - Some readers that do not know LISP might find it handy to have it
>>>around.
>>> 
>>> PEY>I might suggest a separate Informational RFC that provides the
>>>information contained in the appendix for reference when using all of
>>>the LISP documents rather than burying it in a management framework.
>>>But I also recognize that this may not be an expeditious way to
>>>progress things, so do no more than take my thoughts under advisement.
>>> 
>>> ciao
>>> 
>>> Luigi
>>> 
>>>> 
>>>> 		-Peter
>>>> 
>>>> -----Original Message-----
>>>> From: Luigi Iannone [mailto:ggx@gigix.net]
>>>> Sent: Monday, February 08, 2016 3:19 AM
>>>> To: Luigi Iannone
>>>> Cc: Peter Yee; draft-ietf-lisp-eid-block-mgmnt.all@tools.ietf.org;
>>>> gen-art@ietf.org; ietf@ietf.org
>>>> Subject: Re: Gen-ART LC review of draft-ietf-lisp-eid-block-mgmnt-06
>>>> 
>>>> 
>>>>> On 08 Feb 2016, at 12:17, Luigi Iannone <ggx@gigix.net> wrote:
>>>>> 
>>>>> Hi Peter,
>>>>> 
>>>>> Back in April we indeed did not sent you a specific feedback.
>>>>> Reason is that we received several comments/reviews and batched
>>>>>everything in a new I-D, with sending specific feedback to all.
>>>>> 
>>>> 
>>>> The correct sentence is: “without sending specific feedback to all”
>>>> 
>>>> I should really start to proofread my mails before hitting the send
>>>> button  ;-)
>>>> 
>>>> ciao
>>>> 
>>>> L.
>>>> 
>>>>> Yet, if you are unsatisfied on how we addressed the issues we
>>>>>certainly need to do more work.
>>>>> 
>>>>> Give me some time to go again thoroughly through your first review
>>>>>and I’ll get back to you with a specific feedback.
>>>>> 
>>>>> Thanks for your time spent on this document.
>>>>> 
>>>>> ciao
>>>>> 
>>>>> L.
>>>>> 
>>>>> 
>>>>> 
>>>>>> On 06 Feb 2016, at 04:39, Peter Yee <peter@akayla.com> wrote:
>>>>>> 
>>>>>> 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 comment.  For background on
>>>>>> Gen-ART, please see the FAQ at
>>>>>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>
>>>>>> 
>>>>>> Document: draft-ietf-lisp-eid-block-mgmnt-06
>>>>>> Reviewer: Peter Yee
>>>>>> Review Date: February 5, 2016
>>>>>> IETF LC End Date: February 5, 2016
>>>>>> IESG Telechat date: February 18, 2016
>>>>>> 
>>>>>> Summary: This draft has serious issues, described in the review,
>>>>>> and needs to be rethought. [Not ready]
>>>>>> 
>>>>>> The draft attempts to specify the framework for the management of
>>>>>> experimental LISP EID sub-prefixes, but really could use some
>>>>>> additional work to flesh out the management aspects that are left
>>>>>>unsaid.
>>>>>> 
>>>>>> This draft fixes only two minor nits I raised in my review of the
>>>>>> -04 version.  Nothing else has been addressed, nor have I received
>>>>>> any feedback on that review.  In light of this, I have little new
>>>>>>to add.
>>>>>> It is possible that the agreement between the IANA and the RIPE NCC
>>>>>> will alleviate the major concern I had with the draft, but not
>>>>>> being privy to that agreement, I can't make that determination.
>>>>>> 
>>>>>> My original review with the unaddressed comments can be found here:
>>>>>> https://www.ietf.org/mail-archive/web/gen-art/current/msg11620.html
>
>