Re: [MSEC] [Technical Errata Reported] RFC3830 (4638)

"Dearlove, Christopher (UK)" <chris.dearlove@baesystems.com> Tue, 15 March 2016 12:27 UTC

Return-Path: <chris.dearlove@baesystems.com>
X-Original-To: msec@ietfa.amsl.com
Delivered-To: msec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D40512D9C3 for <msec@ietfa.amsl.com>; Tue, 15 Mar 2016 05:27:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.127
X-Spam-Level:
X-Spam-Status: No, score=-6.127 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RDNS_NONE=0.793] autolearn=ham autolearn_force=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 467Q4QMQRgzW for <msec@ietfa.amsl.com>; Tue, 15 Mar 2016 05:27:34 -0700 (PDT)
Received: from ukmta2.baesystems.com (unknown [20.133.0.56]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8371212D9D8 for <msec@ietf.org>; Tue, 15 Mar 2016 05:27:33 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.24,339,1454976000"; d="scan'208";a="32153907"
Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta2.baesystems.com with ESMTP; 15 Mar 2016 12:27:31 +0000
X-IronPort-AV: E=Sophos;i="5.24,339,1454976000"; d="scan'208";a="110211013"
Received: from glkxh0005v.greenlnk.net ([10.109.2.36]) by baemasmds016.greenlnk.net with ESMTP; 15 Mar 2016 12:27:31 +0000
Received: from GLKXM0002V.GREENLNK.net ([169.254.5.214]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.03.0248.002; Tue, 15 Mar 2016 12:27:31 +0000
From: "Dearlove, Christopher (UK)" <chris.dearlove@baesystems.com>
To: Karl Norrman <karl.norrman@ericsson.com>, RFC Errata System <rfc-editor@rfc-editor.org>, Jari Arkko <jari.arkko@ericsson.com>, "elisabetta.carrara@ericsson.com" <elisabetta.carrara@ericsson.com>, "Fredrik Lindholm" <fredrik.lindholm@ericsson.com>, =?iso-8859-1?Q?Mats_N=E4slund?= <mats.naslund@ericsson.com>, "stephen.farrell@cs.tcd.ie" <stephen.farrell@cs.tcd.ie>, "Kathleen.Moriarty.ietf@gmail.com" <Kathleen.Moriarty.ietf@gmail.com>, "bew@cisco.com" <bew@cisco.com>, "vincent.roca@inria.fr" <vincent.roca@inria.fr>
Thread-Topic: [Technical Errata Reported] RFC3830 (4638)
Thread-Index: AQHRfquFZu6uphRPr0apc0FMEI5iaZ9abioAgAAAPSA=
Date: Tue, 15 Mar 2016 12:27:31 +0000
Message-ID: <B31EEDDDB8ED7E4A93FDF12A4EECD30D9237A8DC@GLKXM0002V.GREENLNK.net>
References: <20160315111128.0D18E18019D@rfc-editor.org> <33E51946CDE71249AF9D86CE4D8966B428B846E7@ESESSMB203.ericsson.se>
In-Reply-To: <33E51946CDE71249AF9D86CE4D8966B428B846E7@ESESSMB203.ericsson.se>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.109.62.6]
Content-Type: text/plain; charset="iso-8859-1"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/msec/nXGDnggCP5fYQLX2B87sZtu10Qc>
X-Mailman-Approved-At: Tue, 15 Mar 2016 08:32:57 -0700
Cc: "msec@ietf.org" <msec@ietf.org>
Subject: Re: [MSEC] [Technical Errata Reported] RFC3830 (4638)
X-BeenThere: msec@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multicast Security List <msec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/msec>, <mailto:msec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/msec/>
List-Post: <mailto:msec@ietf.org>
List-Help: <mailto:msec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/msec>, <mailto:msec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Mar 2016 12:27:36 -0000

That makes sense. I think that suggests that an editorial erratum is in order instead, but I'll leave that to you.

-- 
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
__________________________________________________________________________

T:  +44 (0)1245 242194  |  E: chris.dearlove@baesystems.com

BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai
BAE Systems Applied Intelligence Limited
Registered in England & Wales No: 01337451
Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP

-----Original Message-----
From: Karl Norrman [mailto:karl.norrman@ericsson.com] 
Sent: 15 March 2016 12:25
To: RFC Errata System; Jari Arkko; elisabetta.carrara@ericsson.com; Fredrik Lindholm; Mats Näslund; stephen.farrell@cs.tcd.ie; Kathleen.Moriarty.ietf@gmail.com; bew@cisco.com; vincent.roca@inria.fr
Cc: Dearlove, Christopher (UK); msec@ietf.org
Subject: RE: [Technical Errata Reported] RFC3830 (4638)

----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages.
--------------------------------------------------------

Hello!

My understanding is that the 64-bit timestamp of NTP consists of a 32-bit part giving the number of seconds and another 32-bit part giving fractions of seconds.  That is, even though the timestamp itself is 64 bits, only 32 of those bits represent full seconds. So, I believe the original text is correct.

However, I agree that the formulation after "i.e." is a bit misleading. Read in isolation, it does give the impression that all the 64 bits are used to represent seconds. But given that the sentence start with  "The timestamp is as defined in NTP [NTP], i.e., ...",  I believe it is clear that it is the encoding defined in RFC 1305 that is intended.

BR
Karl

> -----Original Message-----
> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org]
> Sent: den 15 mars 2016 12:11
> To: Jari Arkko; elisabetta.carrara@ericsson.com; Fredrik Lindholm; 
> Mats Näslund; Karl Norrman; stephen.farrell@cs.tcd.ie; 
> Kathleen.Moriarty.ietf@gmail.com; bew@cisco.com; vincent.roca@inria.fr
> Cc: chris.dearlove@baesystems.com; msec@ietf.org; rfc-editor@rfc- 
> editor.org
> Subject: [Technical Errata Reported] RFC3830 (4638)
> 
> The following errata report has been submitted for RFC3830,
> "MIKEY: Multimedia Internet KEYing".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=3830&eid=4638
> 
> --------------------------------------
> Type: Technical
> Reported by: Christopher Dearlove <chris.dearlove@baesystems.com>;
> 
> Section: 4.2.8
> 
> Original Text
> -------------
>    The timestamp is as defined in NTP [NTP], i.e., a 64-bit number in
>    seconds relative to 0h on 1 January 1900.  An implementation MUST be
>    aware of (and take into account) the fact that the counter will
>    overflow approximately every 136th year.  It is RECOMMENDED that the
>    time always be specified in UTC.
> 
> 
> Corrected Text
> --------------
>    The timestamp is as defined in NTP [NTP], i.e., a 64-bit number in
>    seconds relative to 0h on 1 January 1900.  It is RECOMMENDED that the
>    time always be specified in UTC.
> 
> 
> Notes
> -----
> A 32-bt number of seconds overflows in about 136.1 years. A 64-bit 
> number of seconds will, for all practical purposes, not overflow.
> 
> (The use in Section 4.2.3 is of a 64 bit number, not a 32 bit number, 
> so 64 bits is correct.)
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please 
> use "Reply All" to discuss whether it should be verified or rejected. 
> When a decision is reached, the verifying party (IESG) can log in to 
> change the status and edit the report, if necessary.
> 
> --------------------------------------
> RFC3830 (draft-ietf-msec-mikey-08)
> --------------------------------------
> Title               : MIKEY: Multimedia Internet KEYing
> Publication Date    : August 2004
> Author(s)           : J. Arkko, E. Carrara, F. Lindholm, M. Naslund, K. Norrman
> Category            : PROPOSED STANDARD
> Source              : Multicast Security
> Area                : Security
> Stream              : IETF
> Verifying Party     : IESG


********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************