> So if you believe the policy table mechanisms in the draft are too
> inflexible for mobility, then you are free to invent &
> implement more
> powerful mechanisms.
>
> => Will the draft go in the standard track or be published as
> informational?
> In the first case you should not use this kind of answers, in
> the second
> case at least two documents for the standard track (6to4 and
> privacy IID)
> depend on your draft...
It is intended to be standards track.
I view the policy table in my draft to be a conceptual data structure, akin
to the conceptual data structures in the Neighbor Discovery RFC. (The draft
should say this more explicitly.) The policy table mechanism is doing two
things:
1. The rules and the default policy table together specify *default*
behavior. Implementations can achieve this default behavior in many ways; an
implementation might not have anything exactly like the draft's policy table
in it.
2. The policy table mechanism specifies a minimum level of flexibility in
configuration that we think is desirable. But this is a SHOULD; for example,
an implementation for a constrained environment might not be configurable at
all.
I hope this approach is OK for a standards track draft. I'm very happy to be
guided here by those with more IETF experience.
Continuing the Neighbor Discovery analogy: the ND spec talks about data
structures like a Neighbor Cache, Destination Cache, Prefix List, Default
Router List and uses these data structures to specify behavior. But in
practice, many implementations have more flexible & complicated data
structures internally, like a routing table. In the same way, your
implementation of address selection could have a more flexible configuration
mechanism than the simple policy tables in the draft.
This brings me to Christian's comment:
> May I observe that, in attempting to specify a source address
> selection algorithm, the WG goes well beyond the traditional
> IETF role, which is to focus on interoperability issues, not
> implementations? I would expect such algorithms to evolve in
> time, as we learn more on the subject. I would also expect
> them to vary a lot depending on how much a particular station
> knows about its environment, how far in the future it can
> predict the application's behavior, what arbitration is made
> between privacy and performance, etc. Rather than specify an
> actual algorithm, the WG should be content with a list of
> recommendations, in the form of "if you do this, expect that"
> or "don't do X, because it will cause interoperability problem Y."
The draft does try to strike a balance between requirements &
recommendations for implementations. There is a continuum. At one end, not
using a multicast or anycast address as a source address. At the other end,
using longest-matching-prefix to guess at a "good" source address for the
destination.
Issues like mismatched scope (can you use a link-local source to send to a
global destination, or global source to send to a link-local destination)
can certainly affect interoperability. For example, implementor A may decide
to always use the largest possible scope source address, on the grounds that
bigger scope is better. Implementator B may decide that mismatched scope is
bad and will never send such packets. Then A will be unable to open a TCP
connection to B's link-local address.
Choices of preferred vs. deprecated addresses, anonymous vs. public
addresses, home vs. care-of addresses probably aren't going to cause
interoperability problems. (Because the other guy can't tell what kind of
address you are using.) But these choices are important to achieving the
goals of other standards-track documents. For example, RFC 2462 says "new
communication should use a preferred address when possible". How does this
stipulation relate to scope consideration? etc. I think giving concrete
algorithmic guidance to implementors trying to make sense of all this is a
good thing - we'll end up with more useful implementations.
I am willing to relax the draft language for the source address selection
rules for mobility & privacy, so that those rules are more recommendations
and less requirements. (What do others think of this???) The
preferred/deprecated concept is pretty well understood and I view the
avoidance of deprecated addresses to be more of a requirement than a
recommendation.
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 PROTECTED]
--------------------------------------------------------------------
