Subject: WGLC comments about scoping-arch

From: Pekka Savola <[email-masked]>
Date: Mon, 3 Nov 2003 11:26:55 +0200 (EET)

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

---

From: Markku Savela <[email-masked]>
Date: Mon, 3 Nov 2003 12:19:44 +0200

Minor comment on comments..

> From: Pekka Savola <[email-masked]>

> automatic default and requiring the subnet scope be configured manually.

I need this default, because I have zone ids are implemented as an
array of 16 id's on the interface, and each much have sensible
default, without requiring manual configuration (yes, the delivered
code has full support of site locals, or any other scope you might
want). This may be left as implementation issue, but any text with
"MUST" and manual configuration won't do.

Besides, I'm experimenting with a kind of "multilink subnets", and I'm
using this scope to indicate group of interfaces that need to be
"bridged". Thus, the subnet index must by default be different, or
bridging starts to happen... (if I manage to get it to work :-)

---

From: Pekka Savola <[email-masked]>
Date: Mon, 3 Nov 2003 12:32:35 +0200 (EET)

Clarifying two comments (maybe I should have proof-read them more
carefully)..

>       scope of source address") is sent to the source of the packet.

Actually, the scenario I described above should not be a problem, as this
bullet is about the scope of the _source_ address, not the destination
address..  and as the only non-global source address is the link-local,
sending back a message should not be a problem.  Could still be spelled
out explicitly though..

> appropriate to use the terms "prefixes" to refer to multicast traffic.  The

this should have been "it is *NOT* appropriate"..

.. sorry..

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Thu, 06 Nov 2003 07:47:20 +0900

>>>>> On Mon, 3 Nov 2003 11:26:55 +0200 (EET), 
>>>>> Pekka Savola <[email-masked]> said:

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

Thanks for the careful reading and detailed comments.  From a quick
glance, it seems to me most (or probably all) of your points are
reasonable.  I'll try to make a detailed response point by point
later.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Tue, 11 Nov 2003 11:37:12 +0900

Again, thanks for the detailed comments.

> as only authors and list only one editor of the document.

Sorry, I don't understand the latter suggestion.  Could you reword
this one please?

Anyway, I see your point, but I don't have a good idea on how to deal
with this.  I don't even know if the "no more than 5" rule must
strictly be applied here (I guess you meant the third paragraph of
Section 2.12(1), draft-rfc-editor-rfc2223bis-07.txt).  I'm open to
suggestions from wg.

> but those are actually *very* far from the intent here.

Hmm, it seems that the term "IPv4 auto-configuration" was simply
copied from "[7]" (RFC3484).  But in any event, you're correct.  The
wording should be revised appropriately.

> Further, note

I guess you meant the "second-last sentence" here.  And honestly, I
don't see a significant difference between the current text and your
suggestion, but I'm fine with revising the text as suggested.

>    does not preclude such a usage, as long as it is limited within the 

This looks fine, thanks for the suggestion.  I'll basically replace
the paragraph with this one, with one exception: we may need to be
consistent about the terms between
  - IPv4 auto-configured link-local addresses
and
  - IPv4 link-local auto-configuration addresses

I'm not sure if the difference was intentional, but I'll probably be
consistent by using the former one only.

> bit more, if the former, a different wording should be used.

Hmm, I think it is Steve who can answer this question with confidence,
but I believe the intention is the latter (including the former one,
of course).  For example, I believe the latter intention is more
consistent with Section 6.

I don't know if this is so substantial that we need to revise the
text, but I'll think about it more and try to propose a better wording.

In any event, I think this is rather an editorial issue and does not
cause a significant problem.

> multicast scope assignment, as below:

This one has a follow-up, so I'll answer separately in the follow-up
thread.

>    more than one zone of each scope), that is more specific than desired

Sorry, I don't really understand the point...did you mean "how the
outgoing *zone* is identified", not "how the outgoing *interface* is
identified"?

> to that zone" is a bit confusing :-)

Hmm, perhaps I was too familiar with the concept, but I don't see the
problem.  In the case of a global destination address, the zone for
the destination address is the single global zone, and the "interfaces
belonging to that zone" are all the interfaces that the receiving node
has.  What is confusing here?

> thousands of "beyond the scope" packets..) ?

Ah, good catch.  I don't think anyone ever thought this ICMPv6 error
message should be sent against a packet with a multicast destination
address.  And, in fact, draft-ietf-ipngwg-icmp-v3-02.txt almost
explicitly prohibits the error message from being sent in this case.

I'll revise the text to make it clear that the error message should be
applied to a packet with a unicast destination address only.  (I saw
your second message saying that this is typically a non-issue, which I
agree on.  But I also agree that it's better to clarify this point.)

> not appropriate to use the terms "prefixes" to refer to multicast traffic.  The

(in the citation I've corrected the lack of "not" pointed out in your
2nd message)

I see your point.  But it seems to me too much to use the term like
(*, G) or (S, G).  At least (*, G) is a notion very specific to a
particular type of multicast routing protocols such as PIM-SM.

Isn't it enough to revise the text here using "group" instead of
"prefix(es)"?  For example,

say

       *  All global groups

instead of

       *  All global prefixes

> IX-based addressing available through RIR's.  So, IMHO, the paragraph should

I don't think this is "an incredibly bad idea", but I admit the sense on
this example might be controversial.  In addition, I agree on your
second point (this example was written long before the RIR's
introduced IX-based addressing, and has not been revised since then.
This is probably a good timing to revisit it.)

As a conclusion, I agree on removing this example from the document.

> parsing.  This seems like a very, very wrong way to go:

At least I didn't intend to give an impression that applications need
to parse/strip the format with a zone ID.  I see the point, however,
and I'm willing to revise the text if it makes the point clearer.

>    defines the delimiter character (%') as the escape character.

I don't see a problem with the suggested text.  Do you think if it is
enough to make the point clear?  If so, I'll simply use the rewording.

>         ietf-ipngwg-icmp-v3-02.txt, November 2001.

Another good catch.  I think you're talking about the rule described
in the 3rd paragraph of draft-rfc-editor-rfc2223bis-07.txt, Section
2.7.  Hmm, we have an agenda item on icmp-v3-02 in the 1st ipv6 wg
meeting tomorrow, so for now I'll see what happens on this.

 
> ==> s/current/current address architecture/ (to be clear not to confuse with

Okay.  Fixed in my local copy.

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

Hmm, considering poor vocabulary of my own, I'd leave this as is.  If
some one can suggest a better wording, I'll use it.

> ==> s/Ethernet/Ethernet link/

Okay, fixed.                                                                                

>       bullet of the rules above.

This "the next address in the Routing Header" should now be in the
destination address of the IPv6 header (swapped with the original
destination address of the received packet).  Did you mean "(swapped
with the original destination address of the received packet)"?

Perhaps we can simply say "the next address" (removing "in the Routing
Header").

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

I don't see the need for the "similar..." part.  So I'll revise the
text as follows:

    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.

>    local address, and the source address a global address.

Hmm, not sure if this is a necessary fix, but I'll change the text
as suggested.

> ==> s/does/do/

Fixed, thanks.

> ==> s/Interface/Interfaces/

Thanks.  I also noticed "Interfaces 5" which should be "Interface 5".
Both were fixed in my local copy.

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

Changed.

> should actually be "scope zone" :-)

I don't think you misunderstand the spec, but the first "scope type"
is correct.  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.

So, at least one person read this to mean differently than originally
intended...do we need to be clearer by revising the text?

> unnumbered interfaces have no addresses *at all*.

Correct, and that's why I used double-quotations followed by the
concrete meaning.  So, ...

> So, I'd use a different

I don't need to revise the text, but we might just remove the
"unnumbered", and say

    Also assume that the point-to-point interfaces have link-local
    addresses only.

The removal of the possibly confusing word doesn't matter, IMO,
particularly because this is the only occurrence of "unnumbered".
Does this change make sense.

> ==> s/try to connect/try to use for connecting/ !! (one doesn't connect to

Okay, I don't think "one does connect to a link" is always odd, but I
agree the text in this case is not correct.  I'll revise the text as
suggested.

					JINMEI, Tatuya

---

From: Pekka Savola <[email-masked]>
Date: Tue, 11 Nov 2003 06:14:56 +0200 (EET)

Hi,

Thanks for very careful and thoughful responses.  This is the kind of 
editing we need! :-)

Comments to remaining issues inline..

> Section 2.12(1), draft-rfc-editor-rfc2223bis-07.txt).  I'm open to

This issue comes from:

http://www.ietf.org/ID-nits.html
http://www.rfc-editor.org/policy.html#policy.auth2

The documents with >5 authors at the header need to be specially agreed to 
with the IESG.

So, I think the options are either:

 1) get the special agreement with the IESG (would't bother trying)
 
 2) strike off 1-2 most inactive authors and put them in a "Contributors" 
section

 3) replace all the authors with just one entry, like "J. Tatuya (Ed.)" 
and put everybody down in an "Authors" section

.. obviously 2) would IMHO be a best choice if we/you could just decide 
who to strike off..
 
> suggestion, but I'm fine with revising the text as suggested.

Yes, I meant the sentence, sorry.  The my text pointed out the prefix 
explicitly, and tries to use a better name to properly describe the 
addresses..

> consistent by using the former one only.

It was unintentional; good catch.  Consistency doesn't hurt :-)
 
> cause a significant problem.

Ok.
 
> outgoing *zone* is identified", not "how the outgoing *interface* is

Not sure, because interface implies the zone.  Reading this again, it 
seems this problem is actually already resolved in the next sentences in 
the same paragraph.

> has.  What is confusing here?

The last sentence.

I guess this is more of the specific global case, that is, referring 
_only_ to the interfaces belonging to zone X is a bit misnomer, because if 
you have a global address, all the interfaces are already there, i.e., 
that "only" is redundant in this case?

(I don't feel strongly about this though.)
 
> "prefix(es)"?  For example,

This would probably make sense, seems reasonable here at least.
 
> and I'm willing to revise the text if it makes the point clearer.

Yes, I thought the impression was not intentional, but that's how it could 
be read, so if an alternative text can be thought of to be less ambiguous, 
it would probably be best..
 
> enough to make the point clear?  If so, I'll simply use the rewording.

This is probably good enough.
 
> meeting tomorrow, so for now I'll see what happens on this.

Agreed.
 
> with the original destination address of the received packet)"?

Yes.
 
> Perhaps we can simply say "the next address" (removing "in the Routing

OK.
 
>     zone boundary in the previously-used next address field.

OK.
 
> intended...do we need to be clearer by revising the text?

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?
 
> Does this change make sense.

The proposal you stated above seems very good to me.

---

From: Atsushi Onoe <[email-masked]>
Date: Mon, 10 Nov 2003 23:37:13 -0600 (CST)

>  2) strike off 1-2 most inactive authors and put them in a "Contributors" 

I think there is only a histrical reason why my name is listed in authors,
as an author of combined I-D (draft-ietf-ipngwg-scopedaddr-format).
Feel free to remove me from authors if it helps proceeding the document
quickly.

Atsushi Onoe

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Wed, 12 Nov 2003 05:56:55 +0900

>>>>> On Mon, 3 Nov 2003 12:19:44 +0200, 
>>>>> Markku Savela <[email-masked]> said:

>> automatic default and requiring the subnet scope be configured manually.

Hmm, I was not very careful to realize that "subnet-local" scope was
not adopted in RFC3513 (it was in
draft-ietf-ipngwg-addr-arch-v3-10.txt).
draft-ietf-ipv6-addr-arch-v4-00.txt still does not have it.

I don't remember the discussion, if any, on why this concept was
removed from the address architecture, but I agree the concept is not
very clear at best.  I guess the most reasonable way to deal with this
point is to remove the concept of "subnet-local" scope from this
document as well.

I hope this makes sense for everyone.

					JINMEI, Tatuya