Subject: RE: I-D ACTION:draft-ietf-ipv6-default-addr-select-08.txt

From: "Richard Draves" <[email-masked]>
Date: Thu, 20 Jun 2002 22:31:17 -0700

> but you have no way of knowing whether the app has made that 
> decision.   
> neither does the host.  we have a clear consensus to not change the 
> existing API behavior, which assumes stable addresses by 
> default, and this implies that an app can 'choose' a stable 
> address merely by not taking any special action.  this is as 
> it should be. 

The IETF does not standardize APIs and it's perfectly OK for different
implementations to have different APIs with different assumptions about
address stability. RFC 2553 is Informational.

> > In this case, the
> > host implementor is choosing to prioritize one kind of bug 
> (privacy) 
> > vs another (app-compat).
> 
> host implementors have no business making such decisions.  or 
> at least, IETF shouldn't endorse such brain-damage if they do.

The host implementor *must* make a decision about what to do when there
is no input to override the implementation's default behavior.

> > But I want it to be clearly
> > stated that in some circumstances an implementor may decide that 
> > privacy is more important than app-compat.
> 
> yes I understand what you want.  and it's simply unacceptable.

I guess this consensus will be more rough than most. :-)

Rich

--------------------------------------------------------------------
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]
--------------------------------------------------------------------

---

From: Keith Moore <[email-masked]>
Date: Fri, 21 Jun 2002 02:13:04 -0400

> The IETF does not standardize APIs 

As a categorical statement, this is wrong.  The IETF can and does sometimes 
standardize APIs, it's just that the IETF emphasizes interoperability 
at the "bits on the wire" level rather than at the API level. this is both 
because experience indicates that API-level standards aren't sufficient to 
allow different implementations to interoperate, and because there's no need 
to insist that everyone use the same API - it actually degrades interoperability
to do so.

> and it's perfectly OK for different
> address stability. 

I agree with this part.  If you want to design a new API in which the
default behavior is to assign a temporary address and apps have to ask
for a stable address, I have no problem with that.  However, I have a big 
problem with this document saying it's okay to change the behavior of 
existing APIs to assign temporary addresses to apps that were designed
and coded to expect stable addresses.

> is no input to override the implementation's default behavior.

That's a cumbersome statement; it's like saying tha the host implementor
must have a default behavior when the default behavior isn't specified.

A simpler but equivalent statement is that there must be a default 
behavior for any option for which the API doesn't force an explicit choice.    
That's true on its face, but it really doesn't illuminate the quesiton.  

The real question is whether this document should endorse the idea that the 
host can change existing APIs in such a way that it may alter the behavior
of programs written to those APIs.  The only reasonable answer is "no".

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 21 Jun 2002 14:59:55 +0200

Keith Moore wrote:
...
> of programs written to those APIs.  The only reasonable answer is "no".

The fact is that any implementation *will* have a default behavior in the case
that an app ignores this whole issue, which will be the case for most apps
when first ported to IPv6. The question for the IETF is whether we leave
this open (thereby maximising chaos) or define a default (thereby reducing
chaos). I think we need to define a default to reduce chaos.

I'd argue that the only hosts likely to have temporary addresses are pure clients.
Servers, or hosts trying to play in a genuine peer2peer world, will need permanent 
addresses anyway. Since we care about preserving client privacy, but presumably don't 
care about preserving server privacy, I'd argue for Rich's default, i.e. the document
as it is. 

   Brian

---

From: Keith Moore <[email-masked]>
Date: Fri, 21 Jun 2002 11:29:46 -0400

> care about preserving server privacy, I'd argue for Rich's default, i.e. the document

If we were starting with a brand-new API I'd agree with you.  But we're talking
about APIs which are in some cases 20 years old, and the default has long been
to have stable addresses.  it's too late to change it.

(and yes, there are lots of programs written to the v4 API which have been
ported to v6 with minimal changes - we don't want to break them.)

that, and I don't think there is such a thing as a user-programmable, pure-client
host.  my palm pilot can run a web server, and it's even useful for it to do so.

Keith