Subject: RE: comment digest

From: <[email-masked]>
Date: Wed, 27 Aug 2003 10:26:08 +0300

Hi Keith,

I've been scratching my head over this whole (collective) discussion, and at
the end of the day, I find myself collecting the arguments into a few boxes,
some of the boxes are clearly out of scope for the IETF:

1) OS support - current POSIX OSs have a certain model for handling IP
   addresses, and address ambiguity creates problems for existing
   applications (& application writers).  Application milage may 
   vary with different OSs.  I can think of other OSs that may do 
   better or worse.

2) UI support - how do applications (& users) understand the difference
   between global & local (addresses & operations).  How do we map 
   these properties onto interfaces, links, etc. UI I mean in a broad sense,
   as how the user (human, silicon or code) of an address uses the address

3) Creating mechanisms for unambiguous addresses that may have additional
   properties like local and global.

4) Religious support - this is a rather large box that I'm going to toss
   much of the discussion for topics like need or non-need of local addressing;
   any sentence that contains the word NAT, and so forth.

Clearly ignoring point 4, what I am left is that point 3 is clearly within
the IETF's scope.  I'd like for us to define a mechanism that clearly supports
mechanisms for creating unambigious addresses that can have both global and
local properties. Point 2 may have relevance to the IETF, but I think
we would create some guidelines to applications developers, APIs, etc.  I think
that point 1 is clearly outside of the IETF's mandate, so we shouldn't go there.

From the various mails, there seem to be a sizable group of people who
want to have the option of some sort of local addressing.  I think we should
provide a mecahism that supports that need/desire but also allows applications
to disregard local addresses if they want to.

br,
John

> II. On the "need" for "local addressing"
> 
> Several people maintain that network admins will insist on local addressing. 
> A few have countered that network admins are quite aware of the problems
> associated with local addressing and NATs in IPv4.
> 
> I'm wondering if this is essentially a tools and/or a marketing problem.  That
> is, maybe we need to
> 
> a. standardize the addressing solution that makes the most sense for support
>    of applications and actual operations,
> 
> b. provide tools that make it easy and foolproof to restrict access and/or
>    hide networks that aren't supposed to be externally visible, and
> 
> c. market these addresses and tools in such a way that they'll sound like "the
>    right thing" to network admins, and especially, their bosses.
> 
> Of course, IETF is not a marketing organization, but that doesn't mean
> we have to ignore human nature. 
> 
> So if we need to slap the words "local addresses" in some document title, and
> then explain how GUPIs or PUPIs or whatever serve that need, for the sake of
> appearances, let's do so.  And if we can find a way to make it easy to get the
> configuration right at the borders of a network beyond which PUPIs aren't
> supposed to be visible, fine - as long as we're not placing a huge burden on
> hosts or apps.  
> 
> But when we're talking among ourselves, it seems (on a technical level) better
> to avoid the complexity that comes with firmly associating a single specific
> and fairly arbitrary network boundary with an address format.  And it seems
> clearer if we use a less-loaded term than "local addresses" when talking among
> ourselves - even while we acknowledge that blocks of these addresses will
> sometimes (perhaps often) be confined to enclaves.
> 
> (Personally I suspect the idea of the "site" with definite boundaries is
> something of an anachronism - since I'm increasingly hearing of cases where
> people are pulling their hair out trying to glue together separate "sites"
> with NATs and make the result look seamless.  But I don't want to overlook
> the hazards of poor marketing.)

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------