Subject: a new revision of ipv6-scoping-arch-00

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Mon, 02 Feb 2004 22:44:23 +0900

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-masked]

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Markku Savela <[email-masked]>
Date: Mon, 2 Feb 2004 17:12:15 +0200

Wait a minute...

>      IANA is going to re-assign the value for the new purpose.

.. isn't this code still needed/useful if one has <src=link-local,
dst=global>, and packet falls into forwarding to another link?

At least I don't have any special handling for link locals here, they
get automaticly handled by scoping rules, e.g. beyond scope of source...

---

From: Pekka Savola <[email-masked]>
Date: Mon, 2 Feb 2004 19:30:02 +0200 (EET)

> this was the wg consensus).  So are you okay if we refer to section 6

Fine with me.

>    of which multicast groups the node joins on the interface.

Seems good.

> specification has this type of wording.

I'd add a note like the one you describe, but I'm OK with leaving it 
out.

> (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

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Tue, 03 Feb 2004 10:55:29 +0900

>>>>> On Mon, 2 Feb 2004 17:12:15 +0200, 
>>>>> Markku Savela <[email-masked]> said:

> dst=global>, and packet falls into forwarding to another link?

Yes, of course.

Perhaps the revised wording above was confusing, but we are NOT going
to deprecate the new "beyond scope of source address" ICMPv6 error.
We'll need this one, and this draft specifies to use the new semantics
of the code.  The reason for referring to the old RFC (2463) is
simply because we'd have to stop the publication of this document
until ICMPv6-v3 is published.

I'll try to make this point clearer below.  Does this make sense to
you?

 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 is currently left as unassigned in [4]. But the
 IANA is going to re-assign the value for the new purpose, and [4]
 will be revised with this change.

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Tue, 03 Feb 2004 12:14:30 +0900

>>>>> On Mon, 2 Feb 2004 19:30:02 +0200 (EET), 
>>>>> Pekka Savola <[email-masked]> said:

> s/packets/packet's/ ?

Yes, this was a typo.  Thanks for the correction.

> (or "have already been obsoleted"?

Hmm, my Cobuild dictionary says "semantics" is an uncountable noun, so
the original wording should be okay according to the dictionary.

BTW, this part may be rewritten based on a different branch of this
thread, and "semantics" may disappear there.  If the final text still
uses the word, I'll use it as an uncountable noun.  (But I don't have
a particular opinion on this.  If others stronglly encourage to use it
as a plural, I'll follow it.)

					JINMEI, Tatuya