[Gen-art] Gen-ART Last Call review of draft-ietf-ntp-checksum-trailer-04
Paul Kyzivat <pkyzivat@alum.mit.edu> Tue, 23 February 2016 20:41 UTC
Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A7F11B2B4F for <gen-art@ietfa.amsl.com>; Tue, 23 Feb 2016 12:41:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B3TaZQspy_C3 for <gen-art@ietfa.amsl.com>; Tue, 23 Feb 2016 12:40:59 -0800 (PST)
Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 047391A87C4 for <gen-art@ietf.org>; Tue, 23 Feb 2016 12:40:58 -0800 (PST)
Received: from resomta-ch2-03v.sys.comcast.net ([69.252.207.99]) by resqmta-ch2-05v.sys.comcast.net with comcast id MwgR1s00529Cfhx01wgy2J; Tue, 23 Feb 2016 20:40:58 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-03v.sys.comcast.net with comcast id Mwgx1s00T3KdFy101wgxV3; Tue, 23 Feb 2016 20:40:58 +0000
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
To: draft-ietf-ntp-checksum-trailer.all@ietf.org
References: <56818AED.8090909@alum.mit.edu>
Message-ID: <56CCC3D8.7010600@alum.mit.edu>
Date: Tue, 23 Feb 2016 15:40:56 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <56818AED.8090909@alum.mit.edu>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1456260058; bh=B6M+wenmvcbWGCTSNQolhdGlkbsvawUZFaqKNqiTHVI=; h=Received:Received:From:Subject:To:Message-ID:Date:MIME-Version: Content-Type; b=mu/dtbD/+wnMB42HcPAy68lDTAiwHAtJ/OUSAugxTNfxdwVsTOiC/7F8MjdOnbgi5 Q3tFp8aWyfl/7NEyF77DL3E+utQYAB/T6reAUZ2zcsNMi0Ne7xda4i3oVZcBrJn2uV hhNgP3JCb5yJWYscA7VddCErrCpX/R+/vCzv1N/rYsCFmwXoSko/u9zxwwABEbYrok U1ny0+ZmyMuQ+23FBli7tdCQpak2RNUqzFsyeOElvzZA7xNeMxOZbeqtvdDNWovAGF w8Aob/DN26G1sILTrcnVLaVPaBRbg590u7JGLIEf+df/o7IDwm7wC2bak5yk5+WeKj OHPzxeIF8uZHw==
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/hmoyny_gnAST35UQs2tUfhV5HTA>
Cc: General Area Review Team <gen-art@ietf.org>
Subject: [Gen-art] Gen-ART Last Call review of draft-ietf-ntp-checksum-trailer-04
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Feb 2016 20:41:00 -0000
I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-ietf-ntp-checksum-trailer-04 Reviewer: Paul Kyzivat Review Date: 2016-02-23 IETF LC End Date: 2016-03-01 IESG Telechat date: 2016-03-03 Summary: This draft is on the right track but has open issues, described in the review. Major: 2 Minor: 3 Nits: 1 (1) Major: Section 3.3 references [NTP-Ext] (draft-ietf-ntp-extension-field) as justification for why existing implementations won't have any trouble with this extension. But some (most?) existing implementations won't comply with [NTP-Ext], but rather only with RFC5905. This section doesn't explain how *those* implementations will behave. ISTM there is some possibility that they won't behave well. (2) Major: Section 3.2 says: This length guarantees that the host that receives the packet parses it correctly, whether the packet includes a MAC or not. [NTP-Ext] provides further details about the length of an extension field in the absence of a MAC. I am not reviewing [NTP-Ext], but I consulted it in an attempt to understand. I found this logic, and the references, to be confusing and seemingly contradictory: In [NTP-Ext] I find: ... However, a MAC is not mandatory after an extension field; an NTPv4 packet can include one or more extension fields without including a MAC (Section 7.5 of [RFC5905]). While section 7.5 of [RFC5905] contradicts that: In NTPv4, one or more extension fields can be inserted after the header and before the MAC, which is always present when an extension field is present. The text that allows extension fields without a MAC is an update to RFC5905 in section 3 of [NTP-Ext]. But that isn't very clear about how one is expected to decipher this. I *think* the intended logic is: If the packet length is more that 24 bytes in excess of the size of a packet with no extensions or MAC, then it must contain at least one extension. In that case, process extensions until the remaining size of the packet is less or equal to 24. Then, if bytes remain process them as a MAC. IMO this draft should not progress until this is specified *somewhere*, probably in [NTP-Ext]. [IMO this technique is a horrible hack. I hope there was no better backward compatible alternative. But this comment isn't a formal part of this review.] (3) Minor: Section 3.2 says: The extension field includes 22 octets of padding. This field SHOULD be set to 0, and SHOULD be ignored by the recipient. In my experience SHOULD is dangerous when not explained. I would recommend either changing it to MUST or providing an explanation of conditions that would justify violating the SHOULD. (4) Minor: While section 3.2 carefully defines the format of the Checksum Complement option, it never specifies how the content of that field is generated or used. An example of that calculation is shown in appendix A, but that isn't normative. A normative specification of the content of the field is needed. IIUC it is to simply be ignored by the recipient. It would be good to say that too. (4) Minor: This document has a normative reference to RFC5905 and an informative reference to [NTP-Ext]. But [NTP-Ext] has normative updates to RFC5905 and this document has dependencies on those changes, so it needs a normative reference to that document. (6) Nit/Question: In section 3.1, IIUC the timestamp engine will need to know that the Checksum Complement field is present before it updates the packet. Is it assumed that engine will assume that to be so, and will not be invoked unless it is? It might be helpful to say something about this. If not, I don't see how it can work.
- [Gen-art] Gen-ART Last Call review of draft-ietf-… Paul Kyzivat
- Re: [Gen-art] Gen-ART Last Call review of draft-i… Les Ginsberg (ginsberg)
- Re: [Gen-art] Gen-ART Last Call review of draft-i… Paul Kyzivat
- [Gen-art] Gen-ART Telechat review of draft-ietf-i… Paul Kyzivat
- Re: [Gen-art] Gen-ART Last Call review of draft-i… Les Ginsberg (ginsberg)
- Re: [Gen-art] Gen-ART Last Call review of draft-i… Paul Kyzivat
- Re: [Gen-art] Gen-ART Last Call review of draft-i… Les Ginsberg (ginsberg)
- Re: [Gen-art] Gen-ART Last Call review of draft-i… Xuxiaohu
- Re: [Gen-art] Gen-ART Last Call review of draft-i… Paul Kyzivat
- Re: [Gen-art] Gen-ART Last Call review of draft-i… Uma Chunduri
- [Gen-art] Gen-ART Telechat review of draft-ietf-i… Paul Kyzivat
- Re: [Gen-art] Gen-ART Telechat review of draft-ie… Jari Arkko
- [Gen-art] Gen-ART Last Call review of draft-ietf-… Paul Kyzivat
- [Gen-art] Gen-ART Last Call review of draft-ietf-… Paul Kyzivat
- Re: [Gen-art] Gen-ART Last Call review of draft-i… Tal Mizrahi
- Re: [Gen-art] Gen-ART Last Call review of draft-i… Paul Kyzivat
- Re: [Gen-art] Gen-ART Last Call review of draft-i… Tal Mizrahi
- Re: [Gen-art] Gen-ART Last Call review of draft-i… Paul Kyzivat
- Re: [Gen-art] Gen-ART Last Call review of draft-i… Tal Mizrahi
- Re: [Gen-art] Gen-ART Last Call review of draft-i… Paul Kyzivat
- Re: [Gen-art] Gen-ART Last Call review of draft-i… Tal Mizrahi
- Re: [Gen-art] Gen-ART Last Call review of draft-i… Paul Kyzivat
- [Gen-art] Gen-ART Telechat review of draft-ietf-n… Paul Kyzivat
- Re: [Gen-art] Gen-ART Last Call review of draft-i… Jari Arkko
- [Gen-art] Gen-ART Last Call review of draft-alaku… Paul Kyzivat
- Re: [Gen-art] Gen-ART Last Call review of draft-a… Zoltan Szabadka
- Re: [Gen-art] Gen-ART Last Call review of draft-a… Paul Kyzivat
- [Gen-art] Gen-ART Telechat review of draft-alakui… Paul Kyzivat
- [Gen-art] Gen-ART Telechat review of draft-alakui… Paul Kyzivat
- Re: [Gen-art] Gen-ART Telechat review of draft-al… Jari Arkko
- [Gen-art] Gen-ART Telechat review of draft-ietf-b… Paul Kyzivat
- Re: [Gen-art] Gen-ART Telechat review of draft-ie… Jari Arkko