Re: Comments on draft-ietf-6man-udpchecksums-00

["Chimento, Philip F." <[e-mail]>]

Hi Magnus: 
Very good comments, thank you. We'll make the changes and address these.

Marshall: Do you have the latest XML? If you send it to me, I can try to get
these comments addressed by early next week (Mon or Tue).
Thanks. 
Regards, Phil 


On 4/14/11 8:01 AM, "Magnus Westerlund" <[e-mail]>
wrote:

> (resend due to bad author alias address)
> Hi,
> 
> I have made a review of the draft and have some comments on it.
> 
> 1. Needs to indicate that it updates RFC2460 (when approved). This
> usually goes into the header of the front page. The abstract and as part
> of the introduction.
> 
> 2. The abstract is way to meager. It needs to make clear, what it does,
> that there are limitations and that it updates RFC 2460.
> 
> 3. Style of writing. This is a document that updates and will be the
> specification of a change of the IPv6 specification. Currently it still
> reads like a change proposal. From my perspective it needs to be more
> authoritative. This is something we have decided to do. Thus the
> document should be written like:
> 1. Introduction: We are changing the UDP zero checksum rule in IPv6.
> 2. Short motivation why.
> 3. Change to specification. Old text that is replaced. New text.
> 
> Some places where this is evident:
> - Section 1, last paragraph on page 3: Not long term relevant and using
> terms that make less sense in an RFC.
> - Section 1.4 "Recommend Solution": Wrong title. Should be its own main
> section. First paragraph.
> 
> 4. Section 1.4:
>       In cases, where the encapsulating
>       protocol uses a zero checksum for UDP, the receiver of packets in
>       the allowed port range MUST NOT discard packets with a UDP
>       checksum of zero.
> 
> "in the allowed port range" seems wrong, isn't "to a port that has been
> enabled to receive zero checksum" so that the full sentence reads:
> 
> In cases, where the encapsulating protocol uses a zero checksum for UDP,
> the receiver of packets to a port that has been enabled to receive zero
> checksum MUST NOT discard packets with a UDP checksum of zero.
> 
> 5. Section 1.4 bullet 1:
>       1.  IPv6 protocol stack implementations SHOULD NOT by default
>           allow the new method.  The default node receiver behaviour
>           MUST discard all IPv6 packets carrying UDP packets with a zero
>           checksum.
> 
> I think "new method" is unclear in this sentence. Yes, I know it is from
> my draft. However, in the context of actually doing the change it needs
> to be more crisp and clear.
> 
> 6. Section 1.4, bullet 3:
>       3.  RFC 2460 specifies that IPv6 nodes should log UDP datagrams
>           with a zero-checksum.  This should remain the case for any
>           datagram received on a port that does not explicitly enable
>           zero-checksum processing.  A port for which zero-checksum has
>           been enabled MUST NOT log the datagram.
> 
> Should we clarify that it MUST NOT log for the reason of it having a
> zero checksum. It may still be logged but for other reasons. The
> simplest change appears to say:
> 
> A port for which zero-checksum has been enabled MUST NOT log the
> datagram for that reason.
> 
> 7. Section 1.4, bullet 5:
>       5.  UDP Tunnels that encapsulate IP MUST rely on the inner packet
>           integrity checks provided that the tunnel will not
>           significantly increase the rate of corruption of the inner IP
>           packet.  If a significantly increased corruption rate can
>           occur, then the tunnel MUST provide an additional integrity
>           verification mechanism.  An integrity mechanism is always
>           recommended at the tunnel layer to ensure that corruption
>           rates of the inner most packet are not increased.
> 
> I think the first "MUST" is actually not correct. I think "MAY" is
> actually more correct. If you transport IP as inner packet, then you MAY
> rely on that being corruption verified by itself, the outer header
> doesn't need to take that responsibility providing that the corruption
> rate will not be increase. However disallowing additional checks was not
> the intention here.
> 
> 8. Section 1.5 should have its own main section.
> 
> Cheers
> 
> Magnus Westerlund
> 
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  [phone]
> Färögatan 6                | Mobile [phone]
> SE-164 80 Stockholm, Sweden| mailto: [e-mail]
> ----------------------------------------------------------------------

Regards, 
Phil Chimento

JHU/APL
240-228-1743
443-778-1743
[e-mail]
--