Subject: Re: 6MAN WG Last Call: <draft-ietf-6man-udpchecksum-02>

From: Magnus Westerlund <[email-masked]>
Date: Tue, 8 May 2012 09:29:09 +0200

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.

2) Document header does not contain "Updates:RFC2460"

3) Section 1, " RFC 2460[RFC2460], " I think this should be "Internet
Protocol, Version 6 (IPv6) Specification [RFC2460],"

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.

5. Section 6. "It is now 2011." Can the authors confirm if there has
been no more analysis and maybe indicate the current year.

In general when I read this document it reads to much like a discussion
paper rather than a normative specification. I think it is late in the
process and do not require any changes now. However, I have raised this
earlier (on the 00 wg version) and the authors have not addressed this.

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: [email-masked]
----------------------------------------------------------------------

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 21 May 2012 14:01:42 -0400

Dear Magnus;

> 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.

> Protocol, Version 6 (IPv6) Specification [RFC2460],"

Isn't this just # 1 ? Or am I missing something?
> 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 ?

> been no more analysis and maybe indicate the current year.

Will do.

> earlier (on the 00 wg version) and the authors have not addressed this.

I actually did change a bunch of text based on that. I agree it is a
bit late to do more.

Marshall

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 22 May 2012 12:03:48 +0200

See inline

> Isn't this just # 1 ? Or am I missing something?

Yes, I just wanted to point out the place where things are going wrong.

> 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