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

From: "Richard Draves" <[email-masked]>
Date: Thu, 20 Jun 2002 21:28:40 -0700

> the point is that the host implementation is almost the worst possible
> place to override that default.    the app knows what kind of 
> addresses
> it needs, so it is in a good position to make such decisions.  the 
> user understands his own need for privacy, but he probably doesn't 
> understand the implications of such a decision for his apps,  
> so he's not in the best position.  the host implementor knows 
> even less than the user - unless you are talking about 
> appliance hosts cannot be programmed by the user.  in the 
> latter situation the app implementor and the host implementor 
> can be considered the same, and it's as easy for the app to 
> select the proper kind of address than for the host 
> implementor to do so.

I agree that the app is in the best position - hence the change in 08 to
require the API to give the app the tools to make a decision. It sounds
like you agree with that.

The question is what to do when the app hasn't made a decision. There's
more than one kind of bug. Having an app break because it chose an
address that expires in a week is a bug. Having an app compromise a
user's privacy is also a bug. The implementor must consider what kind of
bug is more important to their user community, how many apps are not
using the API to make a decision, what are the relative likelihoods of a
problem, etc.
 
> as you say, the SHOULD clause already allows an escape in the 
> case where the host implementor clearly understands the 
> implications of the decision - though that tends to require 
> the host implementor to understand what apps will be run on 
> the host, since the implications will vary from one app to another.
> 
> on the other hand the MAY clause doesn't require the host 
> implementor to understand those implications.  it would 
> therefore be better to 
> remove the MAY clause entirely.

The MAY clause is not intended to let implementors prefer temporary
addresses without understanding the implications. The paragraph
containing the MAY discusses the implications. Perhaps you would be more
comfortable if it were "may" instead of "MAY"?

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 00:39:55 -0400

> like you agree with that.

yes.
 
> The question is what to do when the app hasn't made a decision. 

the host has no way of knowing that, since the way that apps have
traditionally (for the past 20 years) asked for a stable address
was by listening on a port or establishing a connection - because
stable addresses were (until recently) all that was available.

> There's
> user's privacy is also a bug. 

right, but surely you're familiar with the phenomenon that a 
significant percentage of bug fixes cause multiple bugs,
often because the "fix" makes unwarranted assumptions. 
to fix the bugs in apps that compromise users' privacy without
creating lots of new bugs in the process you have to fix those
apps.  you can't do it in the host.

> The implementor must consider what kind of

the host implementor is generally not in a good position to consider 
such issues or to make such decisions. this is particularly true
for a host implementation that is used for diverse purposes.

> comfortable if it were "may" instead of "MAY"?

no, because the MAY (or may) clause incorrectly implies that host 
implementors are in a good position to make such a decision.  they're not. 

Keith