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 protected]
https://www1.ietf.org/mailman/listinfo/int-area
