Subject: Re: per-connection config and destination address selection

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Sat, 03 Aug 2002 16:21:09 +0900

>>>>> On Tue, 30 Jul 2002 14:29:25 +0900, 
>>>>> JINMEI Tatuya <[email-masked]> said:

> This may rather be an implementation issue, so I don't think we need a
> major revise of the draft just due to this.  But I also think it would
> be good to add some note about the dependency in Section 8 before
> publishing the draft.

I've locally discussed the issue with some people including the
author, and would like to propose the attached changes based on the
discussion.

The changes do not modify the policy of selection rules, so I believe
we can agree on them.  The author of the draft has already agreed.
I'm posting the changes here to see if there is an objection to the
changes from other wg members.  If not, then the author will revise
the draft once again, and in parallel the IESG will approve the draft.
So please check the followings, and speak up if you have an objection.

There are two changes in Section 5 (Source Address Selection).

Change the last sentence in Rule4:

   Rule 4: Prefer home addresses. 
   If SA is simultaneously a home address and care-of address and SB is 
   not, then prefer SA. Similarly, if SB is simultaneously a home 
   address and care-of address and SA is not, then prefer SB. 
   If SA is just a home address and SB is just a care-of address, then 
   prefer SA. Similarly, if SB is just a home address and SA is just a 
   care-of address, then prefer SB. 
   An implementation may support a per-connection configuration 
   mechanism (for example, a socket option) to reverse the sense of 
   this preference and prefer care-of addresses over home addresses. 

To:   

    An implementation should provide a mechanism allowing an
    application to reverse the sense of this preference and prefer
    care-of addresses over home addresses (e.g., via appropriate API
    extensions).  Use of the mechanism should only affect the
    selection rules for the invoking application.

and change the last sentence in:

   Rule 7: Prefer public addresses. 
   If SA is a public address and SB is a temporary address, then prefer 
   SA. Similarly, if SB is a public address and SA is a temporary 
   address, then prefer SB. 
   An implementation MUST support a per-connection configuration 
   mechanism (for example, a socket option) to reverse the sense of 
   this preference and prefer temporary addresses over public 
   addresses. 
   
to:

   An implementation MUST provide a mechanism allowing an application
   to reverse the sense of this preference and prefer temporary
   addresses over public addresses (e.g., via appropriate API
   extensions).  Use of the mechanism should only affect the selection
   rules for the invoking application.

(end of change)

The rationale of the changes is that the issue is rather than in the
wording in the selection rules.  With this change, we avoided the
wording "per-connection" and "a socket option", so that the draft will
be generic and be independent of implementation details.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
--------------------------------------------------------------------
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: Erik Nordmark <[email-masked]>
Date: Mon, 5 Aug 2002 07:03:08 +0200 (CEST)

> be generic and be independent of implementation details.

I agree with these changes.

But it would also be useful to have a draft (or add to an existing draft?)
the actual API extensions for these knobs, whether they are socket options 
and/or flags passed to getaddrinfo.

Is anybody working on such a draft?

  Erik