Re: Last Call: <draft-gont-intarea-obsolete-eid-option-01.txt> (Obsoleting the Endpoint Identifier (EID) Option) to Proposed Standard

[[e-mail] (Noel Chiappa)]

    > From: "Eggert, Lars" <[e-mail]>

    >> The IESG has received a request from an individual submitter to
    >> consider the following document:
    >> - 'Obsoleting the Endpoint Identifier (EID) Option'
    >>  <draft-gont-intarea-obsolete-eid-option-01.txt> as Proposed Standard

    > Have the original authors [sic - JNC] been contacted? 

Alas, the author of the ID which defines this option, Charlie Lynn, is no
longer with us:

  http://www.postel.org/pipermail/end2end-interest/2004-June/004195.html

I can probably give as good a judgement on it as anyone, though.


Looking at the ID defining the option:

  http://ana-3.lcs.mit.edu/~jnc/nimrod/eidoption.txt

(dunno why the obsoletion ID doesn't give a URL for it), the obsoletion ID is
slightly inaccurate: it wasn't just "meant to be used with the Nimrod routing
architecture", but rather the endpoint name format supported by that option
is totally general, allowing any endpoint name format to be used.

(In fact, one large faction of the Namespace Research Group wanted to use a
format for endpoint names which would have made use of the 'variable length'
capability of this option, but I digress..)

I don't see any particular reason to not obsolete this option, though; no
recent proposal uses a separate header option for endpoint identification in
IPv6. Recent work on adding endpoint names has either i) used part of the
IPv6 address as an EID (e.g. ILNP), or interpreted the existing IPvN address
as an EID (e.g. LISP).

And, in any event, if we decide we need it, we can always bring it back
(according to the obsoletion ID, it's merely to be marked "obsolete",
not re-assigned).

	Noel