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

Jari Arkko <> Thu, 18 February 2016 13:30 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 276E41A6F60; Thu, 18 Feb 2016 05:30:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9_yp2Pn0u6tN; Thu, 18 Feb 2016 05:30:45 -0800 (PST)
Received: from ( [IPv6:2a00:1d50:2::130]) by (Postfix) with ESMTP id 6F32D1A8956; Thu, 18 Feb 2016 05:30:45 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4ED872CCBF; Thu, 18 Feb 2016 15:30:44 +0200 (EET) (envelope-from
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nDKxltq5Srdh; Thu, 18 Feb 2016 15:30:43 +0200 (EET)
Received: from [] ( [IPv6:2a00:1d50:2::130]) by (Postfix) with ESMTP id B22B92CC9A; Thu, 18 Feb 2016 15:30:43 +0200 (EET) (envelope-from
Subject: Re: Gen-ART LC review of draft-ietf-lisp-eid-block-mgmnt-06
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: multipart/signed; boundary="Apple-Mail=_ACB1E3B6-4882-4615-8CB9-3A456F9E508A"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.5.2
From: Jari Arkko <>
In-Reply-To: <004001d1608f$ef60e6b0$ce22b410$>
Date: Thu, 18 Feb 2016 15:30:42 +0200
Message-Id: <>
References: <004001d1608f$ef60e6b0$ce22b410$>
To: Peter Yee <>, Luigi Iannone <>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 18 Feb 2016 13:30:48 -0000

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