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

RFC Errata System <rfc-editor@rfc-editor.org> Wed, 18 June 2014 09:54 UTC

To: housley@vigilsec.com, tim.polk@nist.gov, hartmans-ietf@mit.edu, zhangdacheng@huawei.com, akatlas@gmail.com, adrian@olddog.co.uk, bew@cisco.com, jmh@joelhalpern.com
From: RFC Errata System <rfc-editor@rfc-editor.org>
Message-Id: <20140618095254.A59CB18000E@rfc-editor.org>
Date: Wed, 18 Jun 2014 02:52:54 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/karp/K7cKNb8lV9QGsBanzfsynC4VRMM
Cc: rfc-editor@rfc-editor.org, infrastation@yandex.ru, karp@ietf.org
Subject: [karp] [Editorial Errata Reported] RFC7210 (4016)
Precedence: list

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 <infrastation@yandex.ru>

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] [Editorial Errata Reported] RFC7210 (4016) RFC Errata System
Re: [karp] [Editorial Errata Reported] RFC7210 (4… Joel M. Halpern
Re: [karp] [Editorial Errata Reported] RFC7210 (4… William Atwood
[karp] [Errata Verified] RFC7210 (4016) RFC Errata System