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

["Dearlove, Christopher (UK)" <[e-mail]>]

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:  [phone]  |  E: [e-mail]

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:[e-mail]] 
Sent: 15 March 2016 12:25
To: RFC Errata System; Jari Arkko; [e-mail]; Fredrik Lindholm; Mats Näslund; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Cc: Dearlove, Christopher (UK); [e-mail]
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:[e-mail]]
> Sent: den 15 mars 2016 12:11
> To: Jari Arkko; [e-mail]; Fredrik Lindholm; 
> Mats Näslund; Karl Norrman; [e-mail]; 
> [e-mail]; [e-mail]; [e-mail]
> Cc: [e-mail]; [e-mail]; 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 <[e-mail]>
> 
> 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.
********************************************************************