Subject: [Int-area] draft-bonica-internet-icmp-08

From: Pekka Savola <[email-masked]>
Date: Fri, 22 Sep 2006 09:10:54 +0300 (EEST)

Hello all,

As I raised some issues with previous versions of 
draft-bonica-internet-icmp, especially that it should contain v6 
support if it's going for standards track, I re-checked the latest 
version and found it's looking very good.  I found mainly minor 
editorial issues, below.

semi-substantial
----------------

5.1
    So, only those ICMP applications that
    process the 129th octet of the "original datagram" field will be
    adversely effected.  To date, no such applications have been
    identified.

==> Well, I don't know whether this particular check has been widely 
implemented but draft-ietf-tcpm-icmp-attacks-00.txt describes that 
ICMP implementations, in particular when demuxing payloads which 
contain TCP, might verify the correctness of the whole payload.  See 
Appendix C of that draft.

9
    IANA should establish a registry of ICMP extension objects classes
    and class sub-types.  There are no values assigned within this
    document to maintain.  Object classes 0xF7 - 0xFF are reserved for
    private use.  Object class values are assignable on a first-come-
    first-serve.  The policy for assigning sub-type values should be
    defined in the document defining new class values.

==> what do you do when the numbers run out?  FCFS without any kind of 
documentation or review requirement could be exhausted quickly.  If 
you really want FCFS, I'd at least reserve 0xFF for future extension 
(not sure if that would help though).

editorial
---------

4.6
    The ICMP Extension Structure MAY NOT be appended to any of the other
    ICMP messages mentioned in Section 4.

==> "MAY NOT" could be interpreted multiple ways.  I assume you mean 
"MUST NOT" ?

5
   Some ICMP implementations, produced between 1999 and the present, may
    send a non-compliant version of ICMP extensions described in this
    memo.

==> reword "the present" to "as of this writing" or some such.

In the following sections, we
    assume that the ICMP message type is "Time Exceeded".

==> would this be better stated ", we use the ICMP message type "TE" 
as example" ?

5.2
   It is possible that a non-compliant application will parse an ICMPv4
    message incorrectly under the following conditions:
...

==> add "all" before "the" or reword slightly to clarify that all the 
conditions must hold (instead of just one of them).

6
    This memo proposes an optional ICMP Extension Structure that can be
    appended to the ICMP messages referenced in Section 4.6 of this
    document.

==> s/proposes/defines/ (better when this gets to an RFC :-)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
Int-area mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/int-area