Hi Suresh:
Inline comments (only those that deserve a bit more discussion).
/Miguel
Pyda Srisuresh wrote:
Miguel,
Thank you for the comments. Please see my responses inline.
regards,
suresh
--- Miguel Garcia <[EMAIL PROTECTED]> wrote:
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-behave-nat-icmp-05.txt
Reviewer: Miguel Garcia <[EMAIL PROTECTED]>
Review Date: 2007-10-09
IESG LC end date: 2007-10-11
Summary:
Comments:
- Section 4.1 discusses the checksum of the payload for TCP and UDP
packets that are embeded in ICMP Error messages. What about UDP-lite
(RFC 3828) packets with partial checksum coverage? Applying the same
rules as for UDP would drop legitimate packets. I think the draft
should say what the NAT should do with respect ICMP Error messages
that contain UDP-lite packets.
[suresh] There are a few things to note here.
a) REQ-3d is transport protocol agnostic and is stated as follows. This is
applicable to UDP-lite as well, assuming the NAT device supports UDP-lite.
If the embedded packet contains the entire transport segment,
and the transport protocol of the embedded packet requires the
recipient to validate the transport checksum, and the checksum
fails to validate, drop the error packet.
b) UDP-Lite is an independent transport protocol with a protocol identifier of
its own (136). The Behave WG has not dicussed protocols other than TCP and UDP.
RFC4787 (UDP BEHAVE) does not discuss UDP-lite either.
So, I dont believe, it woudl be necessary to include specific comment about
UDP-lite in this document.
Well, if you think that the checksum validation covers the UDP-lite case
with partial checksums, then I would agree that the draft covers the
case, and there is no action for the document. In my opinion, it is a
hidden from the reader, but that is just my opinion.
I now understand that you don't want to open the can of worms and start
considering all the protocols that are encapsulated in ICMP Error messages.
- Abbreviations should be expanded at the first appearance, e.g., NAT
and ICMP in the title, ICMP in the Abstract as well, etc.
[suresh] OK, I will expand NAT to be "Network Address translator" in the title.
However, I dont believe, it is necessary to expand on well known terms like IP
and ICMP.
Before I wrote this comment I went to the RFC Editor policy web page,
http://www.rfc-editor.org/policy.html#policy.abbrevs and I didn't find
"ICMP" in the list of accepted abbreviations without expansion. You can
try to leave the term unexpanded, then it will be up to the RFC editor
to decide.
/Miguel
--
Miguel A. Garcia tel:+358-50-4804586
Nokia Siemens Networks Espoo, Finland
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art
