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