Re: Last Call: 'What's In A Name:Thoughts from the NSRG' to Informational RFC

[Keith Moore <moore@cs.utk.edu>]

Basically I have two problems with this document:

1. it claims to be "Thoughts from the NSRG" but does not represent a
consensus opinion of the NSRG.  and when it tries to represent both
sides of a discussion it grossly misrepresents the other side.

2. even though it only claims to be "thoughts", I'm concerned that by
publishing this document as an RFC - without suitable and prominent
disclaimers and without a few other wording changes - it will give 
those "thoughts" more appearance of legitimacy than they deserve.  I
don't see anything wrong with "opinion" RFCs from respected and
experienced members of the community but they need to be clearly
labelled as such.

basically I think that it's useful to publish some account of the NSRG's
deliberations, and this document certainly reflects some of those.  but
it shouldn't be billed as "from the NSRG".  perhaps "from some of the 
NSRG's participants" would be more appropriate.  

after trying for several years now, I've given up trying to get this
document to reflect either a consensus opinion or a balanced view.  
while the authors have changed some of their wording in what I assume is
an attempt to address my concerns (and perhaps those of others), 
IMHO they still misrepresent the situation.

I'm going to attempt to collect my own thoughts about this and submit
those as a separate draft.  If IESG saw fit to publish those also,
the combination of the two drafts might present a more accurate overall 
picture.  (I started to write "clearer overall picture" but I'm not
sure it's possible to produce a clear picture of such a muddy
situation.)

at any rate I'd like to see this draft modified to clearly indicate
that it doesn't represent NSRG as a whole, or for that matter IRTF or
IETF.  and some additional clarifications might also be in order.

Keith

---

I'll list specific examples below, not as request for changes, but to
illustrate some of my concerns:

1. from section 1:

   The overall addressing model on the Internet has shifted to one of
   dynamic binding between a host and its address.

This strikes me as a gross overgeneralization.  Few services that are
in use can tolerate dynamic rebinding of arbitrary IP addresses of their
participating hosts.    And while there are a lot of mobile computers
these days, we generally expect them to only support a limited range of
services - e.g. web clients, email user agents, IM user agents.
dynamic dns exists but is not universally used.  and at least some 
components (e.g. "servers") of many widely-used applications are
dependent on stable addresses.  Indeed in the IPv6 WG we have recently
had people arguing that the need for stable addresses is so great that
it even justifies site-locals.  I don't happen to agree with that
argument, but it illustrates that we are hardly to the point where "the
overall addressing model" is one of dynamic binding between host and
address.

A better description is that the nature of host-to-address binding on
the internet has become more diverse, and therefore less predictable,
more challenging for applications, etc.   but whether a host can support
certain kinds of applications (or certain roles within those
applications) has a lot to do with the network's ability to provide a
stable address- to-host bindign for that host.


2. section 1.1:

   The absence of a name space that uniquely identifies a host has
   created problems in the design of ESP and AH (IPsec).

I think this misses the point.  It's worthwhile to ask "how often is 
it appropriate to authenticate to a host (rather than to a user, an
application, or a service), or to authenticate a host (rather than
some other kind of principal) to another party?"  My belief is that
the early design of IPsec emerged from a world-view in which hosts
were expensive (thus few in number), served several users,
required professional administration, and were often confined to 
physically secure areas.  This made it easy to think of hosts as 
something akin to what we would now call trust domains or CAs.  

3. section 1.2

   As mentioned earlier, the nature of addressing in the Internet has
   changed.  One important change in the Internet addressing model comes
   from the use of NAT [13][14][15].

to claim that the model has changed is to give it more legitimacy than 
it deserves - it implies that the original model of address uniqueness
has been replaced by a different model.  in the case of NAT, it's fairer
to say that the original model has not been adhered to, and that no new
model has replaced it.  indeed, this is the problem in a nutshell -
since we don't have a workable way (model) to cope with NAT, different
applications make different assumptions (or impose different
constraints) that strike different compromises between the level of
support they need from the network on one hand and their ability to run
in diverse environments  on the other. 


The authors (Eliot in particular I think) keep wanting to make
statements  to the effect that the model has changed, or worse, that the
architecture has changed (section 3, 3rd paragraph).  It's certainly
fair to say that the Internet has changed as a result of these various
pressures, but what I don't want to see is an RFC that claims that there
is a new model - implying that the model has been vetted.  And the word
"architecture" implies not only that there is a model but that it was
consciously chosen to meet certain criteria.

4. section 4

   The NSRG was not able to come to unanimity as to whether an
   architectural change is needed.  There are two views.  The
   first is simply that IP is just fine the way it is, and MIPv6's
   shortcuts allow for it to remain the end point identifier.  The
   second view is that we could use a better architectural separation
   between end point identifier and locator.  HIP is such an example.

I don't think this accurately represents either side.  Nobody in NSRG
would claim that IP is just fine the way it is - it was obvious to 
everyone that IP wasn't handling the strain of growth and diversity
very well.   The problem is that when you try to separate endpoint
identifier and locator you find that (a) it's a considerable engineering
challenge to do that (a challenge which is often ignored by those who
claim that it's necessary) and (b) you realize that there are lots of
kinds of endpoint identifier and it's difficult to make a single
solution that meets everyone's need for such an identifier (which is
often ignored by people who claim that their solution for part of the
problem is "the" solution).   

It's often claimed that the problem is that IP addresses are overloaded
as both locators and endpoint identifiers.  When you dig a bit deeper,
you find that IP addresses are a lot more overloaded than that, and you
also find that it's not feasable to get rid of overloading.  Avoidance
of overloading then becomes not a firm architectural principle so much
as an engineering compromise - you have to decide what degree of
overloading is acceptable and what amount causes too much harm.