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
signature.asc
Description: Message signed with OpenPGP using GPGMail