WGLC comments about scoping-arch

Hi,

Below are my LC comments on the scoping-arch document.

In general, I think the document is in a pretty good shape, but can be
improved slightly.  I think it should be possible to send the document to
the IESG after a revision.

Two major points to note:
 - the ICMPv6-bis document is stalled and blocks the progress of this 
work as its currently written, and
 - in the usage examples section, we should be double careful not to give
an impression that the applications should need to deal with scope
indexes, etc. stuff beyond the address itself.  There may be some
disagreement about this in the WG, but getting a neutral rewording for
"application assumptions" seems to be necessary.

substantial
-----------

1) the number of authors is too many (6).  No more than 5 is allowed.  I'd
suggest removing one, or putting everyone except the current document editor
as only authors and list only one editor of the document.

2) there is some really, really weird text in section 4 about address
scopes:

   [1] defines IPv6 addresses with embedded IPv4 addresses as part of
   global addresses.  Thus, those addresses have global scope, with
   regards to the IPv6 scoped address architecture.  However, an
   implementation may use those addresses as if they had other type of
   scopes for convenience.  For instance, [7] assigns link-local scope
   to IPv4 auto-configuration addresses, and converts those addresses
   into IPv4-mapped IPv6 addresses in order for destination address
   selection among IPv4 and IPv6 addresses.  This would implicitly mean
   IPv4-mapped addresses correspondent to IPv4 auto-configuration
   addresses have link-local scope.  This document does not preclude
   such a usage, as long as it is limited within the implementation.

==> that is, there are no "IPv4 auto-configuration" addresses.  This
probably tries to refer to DHCP link-local addresses / zeroconf addresses,
but those are actually *very* far from the intent here.  Further, note
that the second-last paragraph is not suitably clear about the connection
of the link-local mapped addresses and the equivalent IPv4 addresses.  
Also note "in order for destination ...", should be "in order to perform
destination...".  This section is probably a result of getting rid of
RFC1918 + site-local scoping, but failing to reword it appropriately.  
I'd suggest e.g. something like:

   [1] defines IPv6 addresses with embedded IPv4 addresses as part of
   global addresses.  Thus, those addresses have global scope, with
   regards to the IPv6 scoped address architecture.  However, an
   implementation may use those addresses as if they had other type of
   scopes for convenience.  For instance, [7] assigns link-local scope
   to IPv4 auto-configured link-local addresses (the addresses
   from the prefix 169.254/16 [X]), and converts those addresses
   into IPv4-mapped IPv6 addresses in order to perform destination address
   selection among IPv4 and IPv6 addresses.  This would implicitly mean
   the IPv4-mapped IPv6 addresses equivalent to the IPv4 link-local 
   auto-configuration addresses have link-local scope.  This document 
   does not preclude such a usage, as long as it is limited within the 
   implementation.

.. where [X] is informational reference to:

   [9]  S. Cheshire, B. Aboba, "Dynamic Configuration of IPv4 Link-local
        Addresses", Work in Progress.

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.

4) I'm not sure whether I see the immediate need for the unique subnet
multicast scope assignment, as below:

   Furthermore, to avoid the need to perform manual configuration in
   most cases, an implementation should, by default, initially assign
   zone indices as follows, and only as follows:
[...]                                                                              
   o  A unique subnet (multicast "scop" value 3) index for each
      interface

==> this seems mostly like a flawed concept anyway, because you don't really
don't have a multicast "subnet" to begin with, because you don't assign
multicast addresses on interfaces anyway.  So, I'd consider removing this
automatic default and requiring the subnet scope be configured manually.

5) In the section 7, "sending packets", IMHO it would be useful to actually
describe the process of how the outgoing interface is identified, or refer
to a section describing this (if it's in the default zone, no problem, but
if you have e.g. two link-local interfaces....):

   Although identification of an outgoing interface is sufficient to
   identify an intended zone (because each interface is attached to no
   more than one zone of each scope), that is more specific than desired
   in many cases.

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 :-)

7) In the section 9, "Forwarding", the second rule about sending an ICMP DU
is specified.  Has it already been considered whether this applies to
multicast destination addresses as well?  In the past, we've been a bit more
hesitant to send replies to the source of multicast packets (e.g. consider
an almost-global multicast scope that leaks and the source would get e.g.
thousands of "beyond the scope" packets..) ?

   o  After the next-hop interface is chosen, the zone of the source
      address is considered.  As with the destination address, the zone
      of the source address is determined by the scope of the address
      and arrival interface of the packet.  If transmitting the packet
      on the chosen next-hop interface would cause the packet to leave
      the zone of the source address, i.e., cross a zone boundary of the
      scope of the source address, then the packet is discarded and an
      ICMP Destination Unreachable message [4] with Code 2 ("beyond
      scope of source address") is sent to the source of the packet.

8) multicast routing in section 10 is rather weak.  This is a direct
resolution of switching from unicast site-locals to multicast 
organization-local addresses.  However, with multicast addresses, it is
appropriate to use the terms "prefixes" to refer to multicast traffic.  The
multicast routing is so different from unicast, and the term is not
qualified to convey the intended message here.  Some rewording is needed,
maybe express this using (*,G) or (S,G) state creation where the limits are
placed on the group G.

   [...]
   information on five interfaces.  The information exchanged is as
   follows (for simplicity, multicast scopes smaller or larger than
   organization except global are not considered here):

   o  Interface 1

      *  All global prefixes

      *  All organization prefixes learned from Interfaces 1, 2, and 3

9) I think the EBGP peering example should be removed from section 11.4.  
It seems just an
incredibly bad idea to use just link-locals in an IX.  This would cause
serious problems e.g. if someone didn't include "next-hop-self" in their
config.  Further, this particular problem has already been solved by making
IX-based addressing available through RIR's.  So, IMHO, the paragraph should
be removed:

   Another example is an EBGP peering.  When two IPv6 ISPs establish an
   EBGP peering, using a particular ISP's global addresses for the peer
   would be unfair, and using their link-local addresses would be better
   in a neutral IX.  In such a case, link-local addresses should be
   specified in a router's configuration file and the link for the
   addresses should be disambiguated, since a router usually connects to
   multiple links.

10) Similar bad ideas are described in section 11.7, about how to use IPv6
addresses in URL's.  The text seems to say that the apps should then strip
the zone index and be able to parse it.. This would imply that apps handling
URL's should be made aware of link-local addresses and the zone index
parsing.  This seems like a very, very wrong way to go:

   The preferred format for literal IPv6 addresses in URL's are also
   defined [9].  When a user types the preferred format for an IPv6 non-
   global address whose zone should be explicitly specified, the user
   could use the format for the non-global address combined with the
   preferred format.

   However, the typed URL is often sent on a wire, and it would cause
   confusion if an application did not strip the <zone_id> portion
   before sending.  Also, the format for non-global addresses might
   conflict with the URI syntax [10], since the syntax defines the
   delimiter character (%') as the escape character.

   Hence, this document does not specify how the format for non-global
   addresses should be combined with the preferred format for literal
   IPv6 addresses.  As for the conflict issue with the URI format, it
   would be better to wait until the relationship between the preferred
   format and the URI syntax is clarified.  In fact, the preferred
   format for IPv6 literal addresses itself has same kind of conflict.
   In any case, it is recommended to use an FQDN instead of a literal
   IPv6 address in a URL, whenever an FQDN is available.

==> suggestion either revise the text significantly or add reword the middle
sentence:

   However, the typed URL is often sent on a wire, and it would cause
   confusion if an application did not strip the <zone_id> portion
   before sending.  Note that the applications should not need to care
   about which kind of addresses they're using, much less parse or strip out
   the <zone_id> portion of the address. Also, the format for non-global 
   addresses might conflict with the URI syntax [10], since the syntax 
   defines the delimiter character (%') as the escape character.

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.

editorial
---------

   Though the current specification [1] defines unicast site-local
   addresses, the IPv6 working group decided to deprecate the syntax and

==> s/current/current address architecture/ (to be clear not to confuse with
this spec :-)

   The terms link, interface, node, host, and router are defined in [3].
   The definitions of unicast address scopes (link-local and global) and
   multicast address scopes (interface-local, link-local, etc.) are
   contained in [1].

==> I'd try to find a different word than "contained", but that's ~OK as
well.

      Two interfaces to the same Ethernet,

==> s/Ethernet/Ethernet link/

   o  The zone of the new destination address is determined by the scope
      of the next address in the Routing Header and arrival interface of
      the packet.  The next-hop interface is chosen just like the first
      bullet of the rules above.

==> reword to something like below, to spell out what the next address was:
(also, add "the" before arrival):

   o  The zone of the new destination address is determined by the scope
      of the next address in the Routing Header (the original destination
      address of the received packet) and the arrival interface of
      the packet.  The next-hop interface is chosen just like the first
      bullet of the rules above.
...

   Note that it is possible, though generally inadvisable, to use a
   Routing Header to convey a non-global address across its associated
   zone boundary.

==> I'd be a bit more explicit than this.. the convey in this case means
that a link-local address is encapsulated in the "next address" field but is
not going to be used.  Try e.g.:

   Note that it is possible, though generally inadvisable, to use a
   Routing Header to convey a non-global address across its associated
   zone boundary in the previously-used next address field, similar as 
   one can convey the information in the protocol payloads as well.

(could also omit from "similar.." not sure if that's good..)

...
                 For example, consider a case where a link-border node
   (e.g., a router) receives a packet with the destination being a link-
   local address.

==> continute the last sentence like:

   local address, and the source address a global address.

   Note: since unicast site-local addresses are deprecated, and link-
   local addresses does not need routing, the discussion in this section

==> s/does/do/

  o  Interface 3
      *  All global prefixes
      *  All organization prefixes learned from Interface 1, 2, and 3

==> s/Interface/Interfaces/

   identify a particular zone of the address' scope.  Although a zone

==> s/address'/address's/

   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" :-)

   Here is a concrete example.  Consider a multi-linked router, called
   "R1", that has at least two point-to-point interfaces (links).  Each
   of the interfaces is connected to another router, called "R2" and
   "R3", respectively.  Also assume that the point-to-point interfaces
   are "unnumbered", that is, they have link-local addresses only.

==> this is an "ipv6-centric" definition of unnumbered.  Classically,
unnumbered interfaces have no addresses *at all*.  So, I'd use a different
wording than "unnumbered", or maybe "globally unnumbered" would be good
enough even though it sounds odd..

   here, since R1 has more than one link and hence the telnet command
   cannot detect which link it should try to connect.  Instead, we
   should type the link-local address with the link index as follows:

==> s/try to connect/try to use for connecting/ !! (one doesn't connect to
a link.. :-)

-- 
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
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------