See inline On 2012-05-21 20:01, Marshall Eubanks wrote: > Dear Magnus; > > On Tue, May 8, 2012 at 3:29 AM, Magnus Westerlund > <magnus.westerl...@ericsson.com> wrote: >> Hi, >> >> I know the WG last call has closed. But I reviewed it anyway and I have >> found some nits and things which the WG chairs anyway will stumble on in >> their ID checklist processing of the document. I also have some more >> substantial comments on how this is written. I am sorry that I am late, >> but I simple missed the WG last call. >> >> I do support this document going forward but I do think it needs to be >> updated prior to submission to the AD. >> >> 1) Abstract contains bracketed references. I would suggest replacing >> RFC2460[RFC2460] with the documents title and RFC number without brackets. >> > > The brackets come from xml2rfc. This nit is will be done. > >> 2) Document header does not contain "Updates:RFC2460" > > OK, will be fixed. > >> >> 3) Section 1, " RFC 2460[RFC2460], " I think this should be "Internet >> Protocol, Version 6 (IPv6) Specification [RFC2460]," >> > > Isn't this just # 1 ? Or am I missing something?
Yes, I just wanted to point out the place where things are going wrong. >> 4. Section 5 >> "However, some protocols, such as lightweight tunneling >> protocols that use UDP as a tunnel encapsulation, MAY omit >> computing the UDP checksum of the encapsulating UDP header and set >> it to zero, subject to the constraints described in >> [I-D.ietf-6man-udpzero]." >> >> I am a bit worried about making [I-D.ietf-6man-udpzero] part of the >> specification text. Especially something that I at least consider being >> normative definition of constraints. Those I think should be part of >> this document. I think the pointers earlier in the document is >> sufficient to establish that part of the inclusion of the constraints in >> this document are based on whats in our document. > > Here is the problem with >> [I-D.ietf-6man-udpzero]." > > The intended reference is to _the current document_. Remember, this > text is part of > > This item should be taken out of the bullet list and should be > modified as follows: > > where "this item" is [RFC2460] Section 8.1, 4th bullet > > What I was worried about was that someone would take our instructions > literally, and create a mashup of 2560 and the current document, as > that is what we tell them to do. Then, you don't want to just say "as > in Section X", as that is ambiguous. Nor do you want > to say "Section X, of this document," for the same reason. Ideally, if > this document was RFC YYYY, you would say "Section X of RFC YYYY." > > However, can a document normatively reference itself ? That might > excite Douglas Hofstadter, but it seems dubious to me. > > It does occur to me that this must have been dealt with previously - > do you know of previous solutions ? Yes, it can reference itself. What is commonly done in RTP Payload Media Types registrations that we want to have the property to be copied and thus reference itself. One inlcude [RFCXXXX] and then write an RFC-editor note requesting to have the RFC-editor replace XXXX with the number your document gets when being published. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerl...@ericsson.com ---------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
