Re: [rrg] Various misunderstandings

[RJ Atkinson <[e-mail]>]

Hi,

First, there was apparent consensus a week or so back that the terms
"CEE" and "CES" are not useful, in part because different people
have very different meanings for them.  Robin continues to use
those terms despite the expressed view of several folks that the
terms aren't useful or helpful within this RG.

First, I object to Robin's "classification" of ILNP using those terms.  
Robin's use the terminology mainly seems to reflect his incomplete
and/or incorrect understanding of several proposals, including ILNP.  
I note that others have had the same objection in the past on the 
RG list with respect to Robin's "classication" of other ideas.

Second, ILNP *does NOT* require any changes to any applications.
Applications that use the existing BSD Sockets API, for example,
can continue to work properly *without modification* even if
ILNP is in use beneath the API.  I've said this before, more than
once, but Robin continues to misrepresent ILNP -- apparently 
because Robin still doesn't understand ILNP.

Robin's table is wrong, at least for ILNP, probably also for
other proposals.  For ILNP, his table should read:

PROPOSAL    IPv4    IPv6     APP CHANGE  STACK CHANGE   ROUTER REWRITES
--------    ----    ----     ----------  ------------   ---------------
ILNP        Yes      Yes          No        Yes            Optional

ILNP neither prohibits nor requires routers to rewrite anything,
which is why "Optional" seems to be the most accurate description.
This, by the way, is a major difference between O'Dell's GSE 
approach, which required site border routers to rewrite 'Routing Goop' 
and kept end systems entirely out of the path selection process.
ILNP does not require router rewriting, and ILNP always involves
end systems in the path-selection process.

Now, someone else in the RG has started to refer to ILNP as a 
"revolutionary architecture".  Nothing could be more wrong than that.  
In the English language, things that are revolutionary are 
by definition not backwards-compatible and always require a
"flag day" transition.  ILNP is both backwards-compatible 
(All ILNP nodes also talk classic IP, so can talk with any/all 
IP nodes just fine) and incrementally deployable (There are several 
different clearly documented ways that an ILNP-capable node dynamically 
and easily can learn whether a particular would-be correspondent node
is ILNP-capable xor can only talk classic IP).  

ILNP is an example of an *evolutionary* architecture, and is NOT 
a "revolutionary architecture".  I object to the mis-characterisation 
of ILNP as revolutionary.  A lot of design effort went into ensuring 
that ILNP is evolutionary.

Yours,

Ran Atkinson