[Gen-art] Re: Gen-ART review of IETF LC draft-ietf-behave-nat-icmp-05.txt
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
[Gen-art] Gen-art review of draft-ietf-crisp-iris-dchk-07.txt
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 wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-crisp-iris-dchk-07.txt Reviewer: Elwyn Davies Review Date: 12 October 2007 IESG Telechat date: 18 October 2007 Summary: The two major points from the gen-art last call review have been cleared up in this version. One minor issue remains and the editorial comments from the previous review have not been addressed. Comments: s3.1.1.1, description bullet: I think the 'must' should be a 'MUST'. Editorial: Title: The acronym 'dchk' appears as DCHK later.. choose one for consistency. Abstract:Expand IRIS acronym (OK, I know it is in the title, but...). s1: Expand DREG acronym. s1. para 2:s/status of domain/status of domain names/ s1, last para: s/effecient/efficient/ s3: Probably good to use the expanded from of DCHK in the section title. s3.1.1: Caption of domain example display: it looks as if XML escapes didn't get substituted. s3.1.1, several bullets: 'period at' doesn't make sense. I think you mean 'duration of grace period at' in each case. s5.4: s/registeried/registered/ ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] (full) review of draft-ietf-nfsv4-nfsdirect-06.txt
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-nfsv4-nfsdirect-06.txt Reviewer: Francis Dupont Review Date: 2007-10-10 IETF LC End Date: 2007-10-12 IESG Telechat date: unknown Summary: Almost ready Comments: I maintain my concern about the abbrevs in the Abstract even I recognize it is more from the way the nfsv4 stuff is cut out in several documents... There are some places where the wording is not so good (the RFC editor should fix them): - 5 page 6: buffers, lest an RDMA - 5 page 7: unbounded - unbound - 7 page 7: are required by that: thhat - this and BTW what is the specification, RFC 3530? - 7 page 8: the two by IANA. Regards [EMAIL PROTECTED] PS: in the batch of IETF LC reviews message I have this warning: This document contains two downward references (downrefs). As required by RFC 3967, the last call message for this document needs to bring these to the attention of the community. The downrefs are to specifications of earlier versions of the NFS protocol, which were published as Informational, because they had been developed outside the IETF: [RFC1094] NFS: Network File System Protocol Specification, (NFS version 2) Informational RFC, 1989. [RFC1813] B. Callaghan, B. Pawlowski, P. Staubach, NFS Version 3 Protocol Specification, Informational RFC, 1995. ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
