Subject: [Gen-art] Gen-ART LC review of draft-ietf-lisp-eid-block-mgmnt-06

From: "Peter Yee" <[email-masked]>
Date: Fri, 5 Feb 2016 19:39:07 -0800

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

---

From: Luigi Iannone <[email-masked]>
Date: Mon, 8 Feb 2016 12:17:11 +0100

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.

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 <[email-masked]> wrote:
>

---

From: Luigi Iannone <[email-masked]>
Date: Mon, 8 Feb 2016 12:19:03 +0100

> On 08 Feb 2016, at 12:17, Luigi Iannone <[email-masked]> wrote:
> 
> Hi Peter,
> 

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.

---

From: "Peter Yee" <[email-masked]>
Date: Mon, 8 Feb 2016 10:35:25 -0800

No problem, Luigi.  I'll just be happy if my feedback proves helpful.

		-Peter

-----Original Message-----
From: Luigi Iannone [mailto:[email-masked]] 
Sent: Monday, February 08, 2016 3:19 AM
To: Luigi Iannone
Cc: Peter Yee; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Gen-ART LC review of draft-ietf-lisp-eid-block-mgmnt-06

ciao

L.

>> 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>
>> 
>> Summary: This draft has serious issues, described in the review, and 
>> needs to be rethought. [Not ready]
>> 
>> experimental LISP EID sub-prefixes, but really could use some 
>> additional work to flesh out the management aspects that are left unsaid.
>> 
>> 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.
>>

---

From: Luigi Iannone <[email-masked]>
Date: Fri, 12 Feb 2016 12:06:04 +0100

Hi Peter,

> On 08 Feb 2016, at 19:35, Peter Yee <[email-masked]> wrote:
> 

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.   

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

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

ciao

Luigi

---

From: Jari Arkko <[email-masked]>
Date: Thu, 18 Feb 2016 15:30:42 +0200

Thanks for your review, Peter. And thank you Luigi for your attention on the matter.

I’d like to ensure that we work with Luigi to resolve these issues. From my perspective, I think the document is in better shape than the impression one would get just from the listed issues. It is an experimental setup, and some “soft state” approach for instance may be sufficient. However, I do think the following changes should be considered:

1. Add some language to Section 4 to explain if there are things that the registry team should check, and if a failure in those checks is grounds for refusing the request. Even if the check is just to ensure that the request looks reasonable in an expert or the team’s opinion, and that the contact information is valid.

2. Could we be firmer on the expiration and re-registration timeouts? Couldn’t you just say MUST be renewed in 12 months or else after 12+N months the registration will be recycled for other purposes?

3. Section 9 needs to have a more IANA considerations style to it. While you can mostly refer to the rest of the document, I would have expected at least to start with a very basic rule, such as FCFS or Expert Review. Also, start with “The following new registry should be maintained…”.

4. I think the end of the second paragraph of Section 9 was a bit confusing. What “EID registration service” do you mean? The ability to reserve EIDs as outlined earlier in the document? Or something else, like an automated, programmatic lookup service? Can’t you just say “RIPE needs to maintain a registry of EIDs, including facilities for interested LISP users to request registrations, and for others to see the granted registrations and the associated contact information”?

Jari

---

From: Luigi Iannone <[email-masked]>
Date: Wed, 24 Feb 2016 17:30:51 +0100

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.

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

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

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

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

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

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

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

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

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

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

> On 20 Feb 2016, at 04:29, Peter Yee <[email-masked]> wrote:
> 
> Luigi,
> 	Sorry for the tardy reply.  My comments below are prefaced with PEY>.
> 
> 	Kind regards,
> 	-Peter
> 
> Sent: Friday, February 12, 2016 3:06 AM
> To: Peter Yee
> Cc: [email-masked]; [email-masked]; [email-masked]
>>> 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.
>>> 
> 
> 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:
>>> 
>>> 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.
>>> Page 3, Section 3, 1st sentence: delete an extraneous space after the 
>>> open parenthesis.
>>> 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”.
>>> Page 5, Section 6, item 1: insert "the" between "In" and "case".  
>>> Append a comma after "prefix”.
>>> 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.
>>> Page 7, 1st partial paragraph, 1st partial sentence: insert "as" 
>>> between "so" and "to”.
>>> 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.
>>> 
>>> 
> 
> Let me answer in the same way: What is the aim in having such appendix?
> 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
>> 
>>>> 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.