On Mon, 2 Feb 2004, JINMEI Tatuya / [ISO-2022-JP] [EMAIL PROTECTED]@C#:H wrote:
> >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?
Fine with me.
> > 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.
Seems good.
> >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.
I'd add a note like the one you describe, but I'm OK with leaving it
out.
> >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.)
Fine with me.
A few grammar checks; I'm assuming 'semantics' is not a special word
(plural but acting as a singular form):
s/packets/packet's/ ?
s/a different/different/ ?
s/semantics has already been obsolete/semantics are already obsolete/
(or "have already been obsoleted"?
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
