Hi Mukesh. Responses in-line...
> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: 05 November 2004 21:32 > To: Davies, Elwyn [HAL02:0S00:EXCH]; [EMAIL PROTECTED]; > [EMAIL PROTECTED] > Subject: RE: Last call comments for draft-ipngwg-icmp-v3-05 > > > Hi Elwyn, > > Sorry for responding late. Please see my comments inline.. > > > Section 1: The first sentence (The Internet Protocol, > > version 6 (IPv6) is a > > new version of IP.) is not really useful for an ongoing > > standards document, > > and could be deleted without loss. > > Sounds reasonable. I will take it off in the next rev. => Fine. > > > Section 2.1 would be better split into three sections and > > reordered - it covers three things rather than just the > > general message format: > > I understand your concern but IMHO this should not be > done at this stage. The reasons is that we will have to > renumber all the sections in section 2 and then we will > have to fix all the cross references. If we miss to > correct a cross reference, it will be bad. > > Also I have seen people referring to sections of RFCs > in code and changing the section numbers will create > some confusion there too. > > Do you (or anyone else in the WG) strongly feels that > we should change this ?? => I see that the renumbering might be a nuisance.. i still think the section would be clearer reordered. i would be happy to divide 2.1 into three 3rd level sections as suggested (ie 2.1.1, ...) > > > Section 2.4 [current numbering scheme] > > > > Many implementations implement the ability to suppress > > responses to pings and some error messages by policy > > choice. Is this something that might be documented > > given that it is considered to be a matter of security? > > I think, policy issues are out of the scope of this spec. > Implementations allow to suppress all the protocols using > policies (ACLs). So ICMP is no different. > > Do you have anything specific to add about this in the > spec ? > => The spec already mentions policy in connection with error messages so we can't totally punt on the 'out of scope' grounds;-). Is an implementation of ICMP that (for example) doesn't generate Echo Responses when it receives Echo Requests under some circumstances compliant with the standard or not? There is a 'MUST' in 4.1. Or are we relying on statements elsewhere that the packets can be filtered (and so we need not generate them in the first place) - like node requirements (although this says nothing about ACLs and filtering at present)? > > Section 2.4(d): > > > > There is another related circumstance in which it may not be > > possible to > > determine the protocol or port numbers: if the errored packet > > has an ESP, it > > would be necessary to decrypt the packet to determine both. > > This may not be > > possible either because the packet is truncated or because > > the encryption > > algorithm does not have the necessary state needed to decrypt > > this packet. > > This situation may become much more relevant than the > > truncation of long > > headers in future. > > Good point. Here is the proposed replacement text. Let me > know what you think.. > > ========== > In the cases where it is not possible to retrieve the > upper-layer protocol type from the ICMPv6 message, the > ICMPv6 message is silently dropped after any IPv6-layer > processing. One example of such a case is an ICMPv6 message > with unusually large amount of extension headers that > does not have the upper-layer protocol type due to truncation > of the original packet to meet the minimum IPv6 MTU [IPv6] > limit. Another example of such a case is an ICMPv6 message > with ESP extension header where it is not possible > to decrypt the original packet due to either truncation or > the unavailability of the state necessary to decrypt the > packet. > ========== > => that seems good. <<snip>> > > > Section 3.4 Parameter Problem message > > > > It might be useful to add a note that (presumably) Code 0 is > > the fallback case in case neither of the other two fit the bill. > > I think it is obvious from the descriptions of the codes. > So unless you feel there is a strong need, I will prefer > not adding anything extra. Echoing the wording in 3.1... "Codes 1 and 2 are more informative subsets of Code 0." > > > The description of code 2 (IPv6 Option) could be improved - it is > > (presumably) about options in hop-by-hop and destination > > extension headers > > from the base standard. Since, in principle, other headers > > of the same kind > > could be defined, would this code be used for options in > > those headers? > > I think, it is consistent with the IPv6 base spec. The base > spec talks about options in section 4.2. If other headers > of the same kind are defined in future, this code will apply > to the options inside them too. I am not able to see what > exactly you want to add/modify here ? => Ok - forget the hypothetical futures. But 'IPv6 options' is not actually *terminology* called out in RFC2460 although it is defined there (maybe it ought to have been). I think putting a ref to RFC2460 (and maybe the section) in at least one of the three places (2.4 (e.3), 3.4, 5.2 (5))where 'IPv6 option' is mentioned would be helpful. Regards, Elwyn > > Regards > Mukesh > > -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
