Re: [lisp] My proposed revisions to the charter

[[e-mail] (Noel Chiappa)]

    > From: Sam Hartman <[e-mail]>

    > Darrel discussed an idea with the authors of expanding EID as end-site
    > identifier.

That's not really correct, though, because an _individual_ LISP EID names an
individual host (well, perhaps even an interface, as Fred Templin pointed
out). So they don't identify "sites".

If the term 'LISP EID' is not acceptable, I suggest you pick a term which i)
recognizes that an individual example names an individual 'something'
(machine or interface), and ii) properly captures the ambiguity, and
potentially changing semantics, of the LISP EID. E.g. something like 'LISP
device name'. (I picked 'device' to be deliberately amniguous as to whether
an LEID names a host or an interface, to avoid semi-endless debates about
what it does name. :-)


Comments on the draft charter:

    > In general, these proposals are based on the "Locator/Identifier
    > separation".

I think 'location and identity separation' is a better term. (I tend to use
'separation of location and identity', actually, preferring the flow of that
version.)

"Locator", as originally defined in RFC-1992, is a particular kind of name,
not a generic concept. (If anyone looks at RFC-1992, the term 'node' in that
document means 'node in an RFC-1992 map', not 'node' in the more generic
sense.)

    > the Internet architecture combines two functions, Routing Locators,
    > (where you are attached to the network) and Endpoint Identifiers (who
    > you are) in one number space: The IP address. 

"Locators" and "Endpoint Identifiers" are particular _kinds_ of name; to
describe "functions", terms like 'location, for the purposes of routing' and
'identity, for use in end-end interactions' would be more apropos.

Also, did you want to mention how the internet architecture also confuses
whether what is being named by an IP address is an interface, or the host
itself ('stack', if one wishes)? Making this point is not necessary, if you
think it will distract.

    > end-site Identifiers (EIDs) 

Same comment as above about "site".


    > LISP EIDs are composed of three parts: a portion that identifies an
    > organization, a portion that identifies a subnet within an
    > organization, and a portion that identifies an interface on that subnet

Ah, one 'organization' might have multiple ETRs, and multiple LEID blocks
(and RLOC sets associated with each one), so I think 'site' is better than
'organization'. Also, not all sites will adopt that two-layer division
internally. I think this would better put as:

  LISP EIDs are composed of two parts: a 'global' portion that uniquely
  identifies a particular site, and a 'local' portion which identifies a
  device within that site. The 'local' portion may be further subdivided
  internal to a site, e.g. to identify a particular physical network within
  that site, and a device on that network, but that division may not be
  visible outside the site.

Again, 'device' is deliberately ambiguous.


    > Generally, the same IP address cannot be used as both an EID and an
    > RLOC, especially if the entities named by the EID and RLOC are
    > different.

I'm not sure about this; if routes are tagged as to whether they are routes
to 'legacy' addresses , LEIDs or RLOCs, (which I claim they will almost
certainly have to be, to enable routing efficiencies by restricting the
scopes over which they are carried), one could indeed have a particular
32-bit value used as both an EID and an RLOC (and in different places).

Do we need to cover this in the charter, or can we just drop this sentence?


    > The LISP WG is chartered to work on the LISP base protocol
    > (draft-farinacci-lisp-12.txt), the LISP+ALT mapping system
    > (draft-fuller-lisp-alt-05.txt), LISP Interworking
    > (draft-lewis-lisp-interworking-02.txt), LISP Map Server
    > (draft-fuller-lisp-ms-00.txt), and LISP multicast
    > (draft-farinacci-lisp-multicast-01.txt)

This wording might be taken to read as saying only these documents can be
produced. I wonder if that will be too limiting (e.g. if we want to split
draft-farinacci-lisp-12.txt into, say a 'LISP Overview' document and a 'LISP
protocol specification' document)? Is there some way to clarify that?

Also, I wonder what will happen if, in the course of deploying testbeds, we
decide we need something else (like the Map Server thing, which is a _very_
recent addition). Would we have to modify the charter if we decide we need
something else to get the test-bed operational?


The rest looks fine.

	Noel