Results of IETF-conflict review for <draft-lear-lisp-nerd-09.txt>

[The IESG <[e-mail]>]

The IESG has completed a review of <draft-lear-lisp-nerd> consistent with
RFC5742.

The IESG has concluded that this work is related to IETF work done in
WG lisp, but this relationship does not prevent publication of 'NERD:
A Not-so-novel EID to RLOC Database' <draft-lear-lisp-nerd-09.txt> as
an Experimental RFC.

The IESG would also like the RFC-Editor to review the comments in
the datatracker (http://datatracker.ietf.org/doc/draft-lear-lisp-nerd/)
related to this document and determine whether or not they merit
incorporation into the document. Comments may exist in both the ballot
and the history log.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-lear-lisp-nerd/

The process for such documents is described at
http://www.rfc-editor.org/indsubs.html

Thank you,

The IESG Secretary




Technical Summary

   LISP is a protocol to encapsulate IP packets in order to allow end
   sites to multihome without injecting routes from one end of the
   Internet to another.  This memo 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.  Our analysis
   concludes that transport of of all EID/RLOC mappings scales well to
   at least 10^8 entries.

Working Group Summary

   This document is an ISE submission.

  From the author:

  This draft has a bit of an odd history.  First, NERD is actually the
  FIRST mapping ever defined for LISP.  It had to block for a REALLLY
  long time (some years) on a normative reference.  And let's face it:
  doing NERD without LISP would be using ketchup/vinegar without
  fries/chips (pick your venue).  Then it got caught in the ISE
  changeover, and somehow or another got left in the wrong queue
  somewhere along the way, and blocked for another really long time.

  The reason it didn't go through the working group is that the
  working group didn't exist at the time, and I finished the work
  around the time the working group was being chartered.  And of
  course when it was chartered, there was a quite narrow charter that
  didn't include NERD (and to be fair, I had moved on).

Document Quality

   See the IESG note for suggested RFC 5742 text.

Personnel

   Brian Haberman <[e-mail]> is the responsible AD.

RFC Editor Note

Page 4, Section 1, 1st Paragraph:

OLD:
  state change that occurs on routers within the default-free zone on
  the Internet, while enabling end sites to be multihomed.

NEW:
  state change that occurs on routers within the default-free zone on
  the Internet, while enabling end sites to reach either other end-to-end.

Page 11, Section 3.1, 2nd paragraph:

OLD:
  In order to reduce storage and transmission amounts for IPv6, only
  the necessary number of bytes of an EID as specified by the prefix

NEW:
  NERD assumes that EIDs stored in the database are prefixes, and
  therefore are accompanied with prefix lengths.  In order to reduce
  storage and transmission amounts for IPv6, only the necessary
  number of bytes of an EID as specified by the prefix

Page 12, Section 4.2, 1st paragraph:

OLD:
  version of the database it has.  Its first step for retrieving
  changes is to retrieve the current version of the database.  It does

NEW:
  version number of the database it has.  Its first step for retrieving
               ^^^^^^
  changes is to retrieve the current version of the database.  It does


Page 15, Section 5.2, 1st paragraph;

OLD:
  The length of time it takes to process the database is significant in

NEW
  The length of time it takes to transmit the database across the
network is significant in

Page 21, Section 7, 1st paragraph:

OLD:
  repositories.  However, for reasons mentioned in the previous
  section, CVS is insufficient to the task.

NEW:
  repositories.  However, for reasons mentioned in Section 5.4.1
  CVS is insufficient to the task.

Page 22,  Section 7.1, Title:

OLD:
7.1.  What About DNS as a retrieval model?

NEW:
7.1.  What About DNS as a mapping retrieval model?

IESG Note

   The IESG has concluded that this work is related to IETF work done
   in WG lisp, but this relationship does not prevent publishing.