Hello,
I'm now (finally) revising draft-ietf-ipv6-scoping-arch-00.txt,
addressing comments received during the WG last call. I've almost
done on the revise work, but want to be sure about some of your
comments (hopefully you remember the comments and follow-up
discussions).
First, I'm still not sure how I can deal with the following point:
> When an implementation interprets the format, it should construct the
> "full" zone ID, which contains the scope type, from the <zone_id>
> part and the scope type specified by the <address> part.
>
>==> unless I have completely misunderstood the spec, the first "scope type"
>should actually be "scope zone" :-)
In response to this comment, I said the first "scope type" was correct
and it corresponds to the following part of Section 6:
Each zone index of a particular scope should contain an information
to represent the scope type, so that all indices of all scopes are
unique within the node and zone indices themselves can be used for a
dedicated purpose.
You then said:
>Reading the first snippet (the first above), I got the feeling "but hey,
>why is full zone ID including the scope type, and the scope type being
>overridden from the <address>". So there probably has to be some revision
>to clarify that?
Why the "full" zone ID is including the scope type is explained in
Section 6 (to make it clear, I myself did not support the idea. But
this was the wg consensus). So are you okay if we refer to section 6
from Section 11?
Except for this particular point, I've addressed all the comments, or
at least have proposals to the comments. The following three may be
controversial, so I'll explicitly propose the resolution here.
>3) I think this statement in section 5 needs to be spelled out a bit more:
>
> Each interface belongs to exactly one zone of each possible scope.
>
>.. that is, this could be read either as it's probably intended ("no
>interface must belong to more than one zone"), or as "each interface must
>be in a zone of each scope, even if it would have no addresses etc. from
>that scope". If the intent is the latter, this needs to be spelled out a
>bit more, if the former, a different wording should be used.
Proposed resolution: revise the text to (i.e, add the second
sentence):
Each interface belongs to exactly one zone of each possible scope.
Note that this means an interface belongs to a scope zone
regardless of what kind of unicast address the interface has or
of which multicast groups the node joins on the interface.
>6) In the section 9, "Forwarding", I think the text about picking the
>destination address zone could be enhanced a bit:
>
> o The zone of the destination address is determined by the scope of
> the address and arrival interface of the packet. The next-hop
> interface is chosen by looking up the destination address in a
> (conceptual) routing table specific to that zone. That routing
> table is restricted to refer only to interfaces belonging to that
> zone.
>==> that is, this does not seem to spell out whether the routing table
>could include more than just the interfaces of destination address zone --
>i.e., in the case of a global destination address, the "interfaces belonging
>to that zone" is a bit confusing :-)
Proposed resolution: do not change anything on this.
Reason: even after reading a follow-up from you, I still don't think
this is a problem. We could add something like "Note that if the
destination address has the global scope, the routing table refers to
all the interfaces of the node". But, IMO, the original wording
includes this, and the additional note seems even redundant to me. I
admit the wording "only" sounds a little bit odd when it actually
means "all", but it doesn't look so strange for me that a formal
specification has this type of wording.
>11) Note that there is a normative reference to the ICMPv6-bis document,
>which has been pretty much stalled for the last 2 years or so. This
>document cannot be published before ICMPv6-bis is also published. The
>ICMPv6-bis seems integral to this specification, so I think the options are
>either to revise the text about sending ICMP DU "beyond the scope of source
address" messages (removing it), or kicking off the effort for getting
>ICMPv6-bis out of the door:
>
> [4] Conta, A. and S. Deering, "Internet Control Message (ICMPv6) for
> the Internet Protocol Version 6 (IPv6)", Internet Draft draft-
> ietf-ipngwg-icmp-v3-02.txt, November 2001.
Proposed resolution: change the reference to the old RFC (2463), and
describe this part as a new feature. More concretely, I'll revise
this part as follows:
...
Moreover, if the packets destination address is a unicast address,
an ICMP Destination Unreachable message [4] with Code 2 ("beyond
scope of source address") is sent to the source of the original
packet. Note: Code 2, as defined in [4], had a different
semantics, but the semantics has already been obsolete and the
IANA is going to re-assign the value for the new purpose.
(where [4] now refers to RFC2463.)
This approach may look like a tricky compromise, but I agree on this
with wg chairs by a local talk, and the chairs said they would soon
ask the IANA for the new assignment. I hope this approach makes sense
to others.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
