Hi Elwyn,
I am trying to address your comments in the IESG
review of the ICMPv6 draft. Please see my comments
inline. Please note that I am on vacation in india
for a month. So I might not be able to respond to
your replies for a while :)
Sorry if the message is not very well formatted.
========= Your comment ===============
Section 2: A particular issue is the proliferation of
sub-protocols of
ICMPv6: There are statements about ICMPv6 being 'fully
implemented' -
the exact meaning of this statement is unclear in the
face of the
existence of the sub-protocols which use ICMPv6
message structure.
Does 'fully implemented' (Section 2, para
1) mean just the stuff in this draft or all the
sub-protocols - some
of the sub-protocols are not necessarily mandatory
(at least parts
of Mobile IPv6, SEND).
=========== My response ===============
I think, this spec should require the implementation
of just
the messages/behaviors specified in this draft.
Requirements
for other sub-protocols should be specified in the
respective
specs. What about replacing the following text
----------
ICMPv6 is an integral part of IPv6 and MUST be fully
implemented by every IPv6 node.
----------
with
----------
ICMPv6 is an integral part of IPv6 and the base
protocol
(all the messages and behavior required by this
specification)
MUST be fully implemented by every IPv6 node.
----------
========= Your comment ===============
Section 2.1: The definition of the error message
packet format does
not explain the relationship between inclusion of the
start of the
offending packet and allowing the packet originator to
notify the
packet sender. This means that the terms 'upper-layer
protocol' and
'upper-layer process' appear without explanation later
in the
document. I suggest a paragraph something like:
Inclusion of, at least, the start of the invoking
packet is
intended to allow the originator of a packet that
has resulted in
an ICMPv6 error message to identify the
upper-layer protocol and
process that sent the packet.
at the end of Section 2.1 would help.
=========== My response ===============
I don't see any problem with adding the suggested
paragraph if it
makes things clear. Does anyone else have any issues
with the
suggested addition?
========= Your comment ===============
Section 2.2(b): The term 'anycast group' is not used
elsewhere in the
mainstream IPv6 RFCs. All the referenced documents
refer to 'anycast
addresses'. The term is used in the title of the
magma WG but
actually is not used in any of their documents either!
Hence: s/sent
to a multicast or anycast group in which the node is a
member/sent to
a multicast group of which the node is a member or an
anycast address
that is implemented by the node/.
=========== My response ==============
I don't see a problem with this change and if no one
else has any issue,
I will update this in next rev.
========= Your comment ===============
Section 2.2: I have noted
previously (in connection with Neighbor Discovery)
that the source
address selection rules can lead to situations in
which the scopes of
the source and destination addresses are
(legitimately) mismatched.
It should be noted here that such packets MUST not be
dropped by the
packet transmission mechanisms in the node. Suggest
adding the
following to the end of the section:
Under some circumstances the scope of the chosen
source address may
not match the scope of the destination address.
ICMPv6 messages MUST NOT
be dropped in the node that generates the ICMPv6
packet on account of
such a mismatch.
However, there are also circumstances under which this
mismatch can
occur and is unhelpful. For example, if an interface
on a router only
has a link local address, rule 2.2(b) may result in an
ICMPv6 response
to a problem with a site or global scope multicast
destination address
being sent with a link-local scope source address. In
the Neighbor
Discovery cases, this is not a problem because all
messages are link
local anyway, but in other cases the ICMPv6 message
may have to
traverse some routers on its way back to the
originator of the
offending message: it is inconvenient to have to make
special cases
for scope checking here, and the message is much less
helpful when it
arrives back at the originator. The problem could be
considered to be
a misalignment between rules 2.2(b) and 2.2(c): some
thought needs to
be put into what is the best solution, but the scope
of the ICMPv6
destination address and the nature of the sub-
protocol need to be
taken into account - 2.2(c) could be allowed to
override 2.2(b) if the
result was unhelpful in the way described, and a
global unicast
address belonging to the node could be used in place
of the link local
if the packet is expected to traverse other routers.
Sections 2.2(c) and 2.2(d): There has been further
discussion on the
mailing list, since I reviewed this document for IETF
LC, of whether
2.2(c) is ever implemented, and suggesting that it
could be deleted.
I would suggest that this is not a good idea, but that
2.2(d) does
need improving to avoid a link local address being
used
inappropriately as discussed regarding 2.2(b).
Section 4.2, para 3 of Description: The potential
issue with
link-local source addresses is reiterated here and
needs to be cleaned
up if 2.2 is altered.
=========== My response ==============
I will try to handle the above comments in a separate
mail later as
this needs a little thought :)
========= Your comment ===============
Section 2.4(a): Three points:
1. It is worth clarifying that this applies only at
the destination.
2. The term upper layer needs expansion: as the draft
stands, this is
first mention of 'upper layer' {See above comment on
Section 2).
3. The caveat of 2.4(d) applies.
Suggest rewording 2.4(a) as follows:
(a) If an ICMPv6 error message of unknown type is
received at its
destination, it MUST be passed to the
upper-layer process that
originated the packet that caused the error,
where this can be
identified (see Section 2.4(d)).
=========== My response ==============
The ICMP protocol has been there for a long long time
and at least the
implementors clearly understand what we mean by that
statement. Though
I don't think this clarification is really needed, I
wouldn't mind
making this change.
========= Your comment ===============
Section 2.1: This section contains three distinct
topics:
1. Grouping of ICMPv6 messages (error messages and
informational
messages) and list of messages defined in this
document.
2. General ICMPv6 packet format (starting at 'Every
ICMPv6
message...')
3. Specialisation of general packet format for error
message group
(starting at 'The subclass of ICMPv6...').
I have previously commented that this section should
be split up but
the authors have resisted (on plausible grounds,
partly related to the
venerable age of the document). However, the current
arrangement is
not helpful to a naive reader: The first topic
contains a forward
reference to the 'Type' field which is not defined
until the second
topic. I think this problem could be solved(without
section
renumbering as I previously suggested) by reordering
the topics in the
order (2,1,3).
=========== My response ==============
Again, IMHO, this change is unnecessary at this point
but changing
the order of these statements doesn't really hurt too
much. So I
will reorganize the text in the next rev.
========= Your comment ===============
Section 2.1, last para: The draft now lists more
message types than
are actually defined in the document (some were added
after this para
was drafted I think): Suggest rewording as:
The following sections describe the message formats
for the
ICMPv6 error message types 1 through 4 and
informational message
types 128 and 129 listed in Section 4.1.
=========== My response ==============
Good point. I will update the text in next rev.
========= Your comment ===============
Sections 3 and 4: Section 3.3 contains the following
(last para):
The rules for selecting the Source Address of this
message are
defined in section 2.2.
The other sub-sections of Sections 3 and 4 don't
mention source
address selection. Suggest either this comment be
moved to the
beginning of Section 3 and added to Section 4 with
'this message'
replaced by 'these messages'. Alternatively, a note
on source
selection can be added in the 'IPv6 Fields' part of
each sub-section.
=========== My response ==============
As we have already talked about the source address
selection in
section 2.2 and it applies to all the messages, I
don't think
we need to repeat in with all the messages again. So
I will
remove that statement from 3.3.
========= Your comment ===============
Section 4.1: Data field specification: Is it desirable
to explicitly
note that there is no limit on the amount of data?
Much of the rest
of the document limits ICMPv6 messages to the
guaranteed minimum MTU,
but these messages are intentionally allowed to be
larger. Presumably
even needing jumbo packet support.
=========== My response ==============
The spec limits the size of the ICMP "error" messages
that are
generated in response to some non-ICMP packet because
of some
error condition. The spec does not limit the size of
the
"informational" ICMP messages that are either
generated by the
node directly or in response to those ICMP messages.
So we
explicitely say when we need to limit the size and we
don't
say anything when there is no limit.
Do you really think we need to explicitely mention
that there
is no size limit for these messages?
I agree with all the other editorial nits and I will
update them
in the next rev.
Regards
Mukesh
__________________________________
Do you Yahoo!?
Read only the mail you want - Yahoo! Mail SpamGuard.
http://promotions.yahoo.com/new_mail
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
