Keith Moore wrote: ... > > > > 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. > > 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".
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 -------------------------------------------------------------------- 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 PROTECTED] --------------------------------------------------------------------
