Thanks, Miguel and Magnus. I will get a revised draft out with the proposed changes. Thanks.
regards, suresh --- Magnus Westerlund <[EMAIL PROTECTED]> wrote: > 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 [email protected] https://www1.ietf.org/mailman/listinfo/gen-art
