Re: [karp] [Editorial Errata Reported] RFC7210 (4016)

[William Atwood <[e-mail]>]

This error was pointed out to the authors, but only after the IESG Last
Call had (more than) completed, and so it was not acted on.  As Joel
says, the text is clear as to the WG intent, even though the details are
wrong.

This erratum should be accepted.

  Bill

On 18/06/2014 1:46 PM, Joel M. Halpern wrote:
> He seems to be quite correct.  The HHSS should have been HHMMSS in
> both cases.  The text is clear as to the WG intent.
>
> Yours,
> Joel
>
> On 6/18/14, 5:52 AM, RFC Errata System wrote:
>> The following errata report has been submitted for RFC7210,
>> "Database of Long-Lived Symmetric Cryptographic Keys".
>>
>> --------------------------------------
>> You may review the report below and at:
>> http://www.rfc-editor.org/errata_search.php?rfc=7210&eid=4016
>>
>> --------------------------------------
>> Type: Editorial
>> Reported by: Denis Ovsienko <[e-mail]>
>>
>> Section: 2
>>
>> Original Text
>> -------------
>>        SendLifetimeStart
>>           The SendLifetimeStart field specifies the earliest date and
>>           time in Coordinated Universal Time (UTC) at which this key
>>           should be considered for use when sending traffic.  The format
>>           is YYYYMMDDHHSSZ, where four digits specify the year, two
>>           digits specify the month, two digits specify the day, two
>>           digits specify the hour, two digits specify the minute, and
>> two
>>           digits specify the second.  The "Z" is included as a clear
>>           indication that the time is in UTC.
>>
>>        SendLifeTimeEnd
>>           The SendLifeTimeEnd field specifies the latest date and
>> time at
>>           which this key should be considered for use when sending
>>           traffic.  The format is the same as the SendLifetimeStart
>>           field.
>>
>>        AcceptLifeTimeStart
>>           The AcceptLifeTimeStart field specifies the earliest date and
>>           time in Coordinated Universal Time (UTC) at which this key
>>           should be considered for use when processing received traffic.
>>           The format is YYYYMMDDHHSSZ, where four digits specify the
>>           year, two digits specify the month, two digits specify the
>> day,
>>           two digits specify the hour, two digits specify the minute,
>> and
>>           two digits specify the second.  The "Z" is included as a clear
>>           indication that the time is in UTC.
>>
>>
>> Corrected Text
>> --------------
>>        SendLifetimeStart
>>           The SendLifetimeStart field specifies the earliest date and
>>           time in Coordinated Universal Time (UTC) at which this key
>>           should be considered for use when sending traffic.  The format
>>           is YYYYmmddHHMMSSZ, where four digits specify the year, two
>>           digits specify the month, two digits specify the day, two
>>           digits specify the hour, two digits specify the minute, and
>> two
>>           digits specify the second.  The "Z" is included as a clear
>>           indication that the time is in UTC.
>>
>>        SendLifeTimeEnd
>>           The SendLifeTimeEnd field specifies the latest date and
>> time at
>>           which this key should be considered for use when sending
>>           traffic.  The format is the same as the SendLifetimeStart
>>           field.
>>
>>        AcceptLifeTimeStart
>>           The AcceptLifeTimeStart field specifies the earliest date and
>>           time in Coordinated Universal Time (UTC) at which this key
>>           should be considered for use when processing received traffic.
>>           The format is YYYYmmddHHMMSSZ, where four digits specify the
>>           year, two digits specify the month, two digits specify the
>> day,
>>           two digits specify the hour, two digits specify the minute,
>> and
>>           two digits specify the second.  The "Z" is included as a clear
>>           indication that the time is in UTC.
>>
>>
>> Notes
>> -----
>> The date and time format in the original document omits minute.
>>
>> Instructions:
>> -------------
>> This errata 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.
>>
>> --------------------------------------
>> RFC7210 (draft-ietf-karp-crypto-key-table-10)
>> --------------------------------------
>> Title               : Database of Long-Lived Symmetric Cryptographic
>> Keys
>> Publication Date    : April 2014
>> Author(s)           : R. Housley, T. Polk, S. Hartman, D. Zhang
>> Category            : PROPOSED STANDARD
>> Source              : Keying and Authentication for Routing Protocols
>> Area                : Routing
>> Stream              : IETF
>> Verifying Party     : IESG
>>
>
> _______________________________________________
> karp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/karp

-- 
Dr. J.W. Atwood, Eng.             tel:   [phone] x3046
Distinguished Professor Emeritus  fax:   [phone]
Department of Computer Science
   and Software Engineering
Concordia University EV 3.185     email:[e-mail]
1455 de Maisonneuve Blvd. West    http://users.encs.concordia.ca/~bill
Montreal, Quebec Canada H3G 1M8