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@xxxxxxxxx> 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@xxxxxxxxxx> wrote: >> >> Luigi, >> Please see my responses below prefixed with PEY>. >> >> Thanks. >> >> Kind regards, >> -Peter >> >> -----Original Message----- >> From: Luigi Iannone [mailto:ggx@xxxxxxxxx] >> Sent: Wednesday, February 24, 2016 8:31 AM >> To: Peter Yee >> Cc: draft-ietf-lisp-eid-block-mgmnt.all@xxxxxxxxxxxxxx; >>gen-art@xxxxxxxx; ietf@xxxxxxxx >> 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@xxxxxxxxxx> wrote: >>> >>> Luigi, >>> Sorry for the tardy reply. My comments below are prefaced with PEY>. >>> >>> Kind regards, >>> -Peter >>> >>> -----Original Message----- >>> From: Luigi Iannone [mailto:ggx@xxxxxxxxx] >>> Sent: Friday, February 12, 2016 3:06 AM >>> To: Peter Yee >>> Cc: draft-ietf-lisp-eid-block-mgmnt.all@xxxxxxxxxxxxxx; >>> gen-art@xxxxxxxx; ietf@xxxxxxxx >>> 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@xxxxxxxxxx> 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@xxxxxxxxx] >>>> Sent: Monday, February 08, 2016 3:19 AM >>>> To: Luigi Iannone >>>> Cc: Peter Yee; draft-ietf-lisp-eid-block-mgmnt.all@xxxxxxxxxxxxxx; >>>> gen-art@xxxxxxxx; ietf@xxxxxxxx >>>> Subject: Re: Gen-ART LC review of draft-ietf-lisp-eid-block-mgmnt-06 >>>> >>>> >>>>> On 08 Feb 2016, at 12:17, Luigi Iannone <ggx@xxxxxxxxx> 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@xxxxxxxxxx> 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 > >