Just FYI, here is a summary of the resolutions for comments on the
scope-arch document, to make it sure that none of them was missed.
But I may have still missed something, in which case please point it
out.
Thanks,
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
============
Comments from Juergen Schoenwaelder
a) I think it would be helpful if the document would refer to
<draft-ietf-ipv6-deprecate-site-local-01.txt>.
=> added the reference.
b) Is there a particular reason why we can not just say that the
default zone is indicated by a zone index which MUST (or SHOULD if we
have to compromise) be zero?
=> made it a SHOULD.
============
Comments from Pekka Savola:
1) the number of authors is too many (6).
=> changed the organization of authors to meet the requirement
2) there is some really, really weird text in section 4 about address
scopes:
...that is, there are no "IPv4 auto-configuration" addresses.
=> adopted the suggested change
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.
=> revised the text (which was agreed in the ML)
4) I'm not sure whether I see the immediate need for the unique subnet
multicast scope assignment, as below:
=> removed "subnet-local" (note: this notion has already been removed
from the base addr-arch spec)
5) In the section 7, "sending packets", IMHO it would be useful to actually
describe the process of how the outgoing interface is identified,
=> do not change anything on this (the issue is addressed in the
original text)
6) In the section 9, "Forwarding", I think the text about picking the
destination address zone could be enhanced a bit:
=> do not change anything on this (this decision was accepted in a
discussion on the ML)
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?
=> clarified this point in the text.
8) multicast routing in section 10 is rather weak.
=> revised the text to address this.
9) I think the EBGP peering example should be removed from section 11.4.
=> removed the example.
10) Similar bad ideas are described in section 11.7, about how to use IPv6
addresses in URL's.
=> adopted the suggested change.
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.
=> addressed by referring to the old RFC with additional notes.
editorial
---------
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" :-)
=> addressed this by referring to section 6.
All other editorial comments were addressed in a straightforward way.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
