>>>>> On Tue, 30 Jul 2002 14:29:25 +0900,
>>>>> JINMEI Tatuya <[EMAIL PROTECTED]> 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 PROTECTED]
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
