|
Re: Gen-ART LC review of draft-ietf-lisp-eid-block-mgmnt-06
2016-04-06 14:17:38
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(_at_)gigix(_dot_)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(_at_)akayla(_dot_)com> wrote:
Luigi,
Please see my responses below prefixed with PEY>.
Thanks.
Kind regards,
-Peter
-----Original Message-----
From: Luigi Iannone [mailto:ggx(_at_)gigix(_dot_)net]
Sent: Wednesday, February 24, 2016 8:31 AM
To: Peter Yee
Cc:
draft-ietf-lisp-eid-block-mgmnt(_dot_)all(_at_)tools(_dot_)ietf(_dot_)org;
gen-art(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)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(_at_)akayla(_dot_)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(_at_)gigix(_dot_)net]
Sent: Friday, February 12, 2016 3:06 AM
To: Peter Yee
Cc:
draft-ietf-lisp-eid-block-mgmnt(_dot_)all(_at_)tools(_dot_)ietf(_dot_)org;
gen-art(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)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(_at_)akayla(_dot_)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(_at_)gigix(_dot_)net]
Sent: Monday, February 08, 2016 3:19 AM
To: Luigi Iannone
Cc: Peter Yee;
draft-ietf-lisp-eid-block-mgmnt(_dot_)all(_at_)tools(_dot_)ietf(_dot_)org;
gen-art(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)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(_at_)gigix(_dot_)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(_at_)akayla(_dot_)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
|
|