Miguel Garcia skrev: > 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. >
I think that we can live with the present text. > >>> - 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. > I would leave the title and expand it in the abstract. I expect an updated draft before progressing this. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: [EMAIL PROTECTED] ---------------------------------------------------------------------- _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
