NERD: A Not-so-novel Endpoint ID (EID) to Routing Locator (RLOC) Database
draft-lear-lisp-nerd-09

Ralph Droms handed over responsibility for this document to Brian Haberman, because Ralph, the author and the IETF LISP leads all work for the same employer.

The RFC 5742 review was performed by Ralph; to be reviewed and confirmed or updated by Brian.

[Ballot comment]
I support Stewart's DISCUSS. The distinction between this document and the other LISP documents, which are also EXPERIMENTAL, is subtle and likely to be lost on the reader.

[Ballot comment]
- I think a paragraph putting this into context (as per Eliot's
mail) would be very valuable for the reader who might otherwise
think this is the "mainstream" experiment.

- Do you really want to refer to ITU-T x.509 rather than rfc5280 for
certificates?

- I think you could note that key roll-over and key distribution
generally are for future study.

- You could even mention the potential for using DANE if you wanted
as a different PKI as another possibility for future study.

- CMS is widely deployed (all S/MIME clients include it) but you
could still say pkcs#7 is more widely supported by libraries and
tools.

- There doesn't seem to be any way to limit an authority to certain
EIDs and/or RLOCs, such as is done by SIDR. Might be worth noting?

- If you need revocation checks as part of signature validation,
then you probably ought say that that's not included in the analysis
in section 5.

[Ballot discuss]
I am putting a discuss on this because I think that the IESG  needs to talk about this draft. I will clear the discuss on the call.

I think that the document needs some text in the introduction making it clear that the purpose of this draft is to record some early thoughts on this subject by the author. Otherwise the RFC will be too easily confused with the ordinary output of the LISP WG.

The approach described seems a viable way of running LISP and thus I am not sure why this is not being taken through the WG or as AD sponsored. I understand the history is that this work pre-dated the WG, but there is now a WG.

[Ballot comment]

I am surprised that the author did not tackle the database version wrap problem by providing some really large number that could never wrap (128 bits springs to mind). Given the size of the payload, the size of the database header seems unlikely to be an issue.

[Ballot comment]
I agree that this document should be published as a record of one way of doing the LISP mapping.  The following commentary is really meant for the IESG and the ISE...

Given that there does not appear to be any effort to actually implement this specification, does it make sense to publish it as Experimental?  It would seem that Informational would be a fine way to document this approach.  If I follow some of the arguments that Pete and Ron have made recently, I would even support the publication of this document as Historical, but I am not sure if the ISE can do that.

[Ballot discuss]
There is no author action required for this Discuss. The target is the 5742-AD

Per email exchanges with the AD and one of the LISP WG chairs, I believe the IESG response suggested is wrong. I think we should respond to the ISE with RFC 5742 option 2 (related to LISP WG, but no impact).

[Ballot comment]
It would be (would have been) really helpful if the write-up (had) included a description of the history of the interaction with the LISP working group on this I-D, and a summary of why the working group did not believe this work should be either a WG draft or AD sponsored within the IETF stream.

It is not too late to add this information to the write-up, and I think it would be useful for history.

The draft draft-lear-lisp-nerd-08
is ready for publication from the Independent Stream.
Please ask IESG to review it, as set out in RFC 5742.

The following is some background for this draft, please forward it
to IESG along with this request ...

This draft "presents an experimental database and a discussion of
methods to transport the mapping of EIDs to RLOCs to routers in a
reliable, scalable, and secure manner."

It was reviewed (back in Dec 2009) by Joel Halpern, and has been
improved steadily since then. It was dormant when I started as
ISE early last year, and has become active again now that other LISP
drafts are nearing publication.

As far as I can tell, this is work that supports that being done in
the lisp WG, and is well understood by that WG.

Thanks, Nevil (ISE)