Sorry this is very late... don't know if you are updating the draft ... Comments below... essentially go ahead.
Regards elwyn > -----Original Message----- > From: Mukesh Gupta [mailto:[EMAIL PROTECTED] > Sent: 03 February 2005 04:43 > To: [EMAIL PROTECTED] > Cc: ipv6@ietf.org > Subject: GEN-ART comments about ICMPv6 spec > > 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. > ---------- > Fine. > ========= 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? > Not seen any additional comments.. so fine > ========= 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. OK > > ========= 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 :) Havn't seen anything yet. I'll try my own input > > ========= 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. Well.. maybe some new ones might come along so I think it is worth doing:-) > > ========= 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. Good! > > ========= 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. Fine. > > ========= 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. > I think that is OK. > ========= 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 don't think it does any harm. > > 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 --------------------------------------------------------------------
