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

[Luigi Iannone <[e-mail]>]

Hi Peter,

> On 08 Feb 2016, at 19:35, Peter Yee <[e-mail]> 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.   


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

> 
> 		-Peter
> 
> -----Original Message-----
> From: Luigi Iannone [mailto:[e-mail]] 
> Sent: Monday, February 08, 2016 3:19 AM
> To: Luigi Iannone
> Cc: Peter Yee; [e-mail]; [e-mail]; [e-mail]
> Subject: Re: Gen-ART LC review of draft-ietf-lisp-eid-block-mgmnt-06
> 
> 
>> On 08 Feb 2016, at 12:17, Luigi Iannone <[e-mail]> 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 <[e-mail]> 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
>>> 
>>> 
>>> 
>> 
> 
>