From nobody Wed Jun 4 12:30:55 2014 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55B121A033B for ; Wed, 4 Jun 2014 12:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham 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 1sU7VEmEtLp9 for ; Wed, 4 Jun 2014 12:30:52 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D9191A02A8 for ; Wed, 4 Jun 2014 12:30:51 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s54JUgAN004180; Wed, 4 Jun 2014 20:30:42 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s54JUfX3004159 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 4 Jun 2014 20:30:42 +0100 From: "Adrian Farrel" To: "'Mahesh Jethanandani'" Date: Wed, 4 Jun 2014 20:30:37 +0100 Message-ID: <086501cf802b$76f43a60$64dcaf20$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0866_01CF8033.D8BBAFA0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac+AK3MUABKs7FhcQjaRaO6agcJ9cQ== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20738.000 X-TM-AS-Result: No--24.452-10.0-31-10 X-imss-scan-details: No--24.452-10.0-31-10 X-TMASE-MatchedRID: pS5owHKhBO0NDmNqb6OmShes/RxhysDbLAnNohUyMa2638ZUY6gSdxEa gYlxo94POUYNXsr1n12+ajoomsCKvONMTcuWvx5285L5JHGOAXDaCn4DqCiXNuJsgXmCsctFrop xmZF4UD3vSTHlSbgM2QzLDqEyu1hQ1QwDBMM4Gey7vYqkCS0dL3+ogtHzaKWZk4cPqhCnOBG3DY GNlagpcAgrUzk34ys53OaIc5xACOrD11TnHAQ1PW0PWqD0pliRGSqdEmeD/nU06dhcpwNHEIZbN Fr3ThNDI1j68AwVJtWHViUtZ9Duft/VfsVgOrak3fn7n/ZHGqYhXHiVbGfuY//o4E70SZ2Yh8Uz juoP0V7Y4mcCOjnnT+UnCn5BOic/O6Fj0OJGfRnRXhA4ma+s3txOVRSUW4iEYHvy8ATgR+T0rkm G2TPGAtaGsc3CbJRZxUvk8kW7jQ7B6kugcU0FsOXP7JqXOmP+6Jj6zYvfFASw5aBPa7nICTxH8t KF9a4gCPnYMmIYXkfdL3pi9TCVtQRpZ0PAS0nmtT4jIeGRd/VBldmDYjwlppuSv4SfxhK37/+9s wuISRVYVA2Tj4cKiIcypU5vI8wyw1hXve9gEVCO0rt0LpQGeRSpYqhygmjp6ygMMToK892nhZyb KoFsXELduO9IO73n36y5gCD1lYkzG8Dg48sJ/vIVL3+KSNgwkTzAgHG5eNKgJH974mpbq6gTkLg TtTggIm6fKcuFyK8oR0K3DJ8mwtZXwwpvfhGVFlT/KggLyj0lWygvtTclwOKYpwtG+wHVRq7NaF miCIDOQf/S1XvtEAC/b4aTkuDFizFhECDuofCeAiCmPx4NwGmRqNBHmBve1kTfEkyaZdxFGCd0S 0NCshJA/WiCmlLA5J7mpKFUklLkKMmDThYc+wjBtep+LgrVWClYJu9r4yY= Archived-At: http://mailarchive.ietf.org/arch/msg/karp/DOqloqmAT_5hdOt38q8SFbuYZBE Cc: karp@ietf.org Subject: Re: [karp] Closing KARP X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 19:30:54 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0866_01CF8033.D8BBAFA0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Mahesh, =20 Do you mean ready for last call? It doesn't seem that the document had = been adopted by the WG. And it seems to have expired a little while ago. =20 A very brief scan of the document suggests that the references are in a = bit of a mess. You need to clean up the things that don't need to be = referenced. Perhaps run idnits? =20 Conversely, I'm a bit surprised that your document doesn't reference = RFC5920 or RFC6941. =20 Tell me whether this document focuses on MPLS-TE, or also covers GMPLS? = What about MPLS-TP? =20 I suggest that the approach is... - polish your document - post a new revision - decide whether you are MPLS-TE only or GMPLS and MPLS-TP as well - approach the chairs of MPLS or CCAMP according to your decision =20 Oh, and consider sending a copy to the RSVP Directorate. =20 Thanks, Adrian =20 =20 From: Mahesh Jethanandani [mailto:mjethanandani@gmail.com]=20 Sent: 31 May 2014 16:01 To: adrian@olddog.co.uk Cc: ; isis-chairs@tools.ietf.org; = pim-chairs@tools.ietf.org; ccamp-chairs@tools.ietf.org Subject: Re: [karp] Closing KARP =20 Adrian, =20 There is one other draft that was reviewed and ready for last call. = draft-mahesh-karp-rsvp-te-analysis. How do you want to proceed on it? Mahesh Jethanandani mjethanandani@gmail.com On May 30, 2014, at 3:32 PM, "Adrian Farrel" = wrote: OK, thanks to those of you who have contacted me about the future of = KARP work. I will ask the Secretariat to close the working group forthwith, and = keep the mailing list open. draft-ietf-karp-ops-model Is on the RFC Editor queue and has completed Auth48 Publication soon draft-ietf-karp-bfd-analysis The I-D has been refreshed and WG last call is complete. The BFD working group has already reviewed the document. Brian is working on a shepherd write-up and I will AD Sponsor the = publication. draft-ietf-karp-isis-analysis Document almost complete.=20 Needs a final push and review by the ISIS WG. I will AD sponsor it when it is ready. Management plane solution to AKM Sam has offered to work on something here. I'm sure he would welcome help if anyone is willing. We can easily find a home for this sort of work. I would start with the = OPSAWG but maybe it will belong in netmod. draft-chunduri-karp-kmp-router-fingerprints Uma has recently posted a new revision. This document can be advanced as AD sponsored when it is ready. draft-bhatia-karp-pim-gap-analysis This document needs work. I'll ask the PIM chairs to run with this in the PIM WG. draft-mahesh-karp-lmp-analysis This document needs work. I'll ask the CCAMP chairs to run with this in the CCAMP WG. New work / other work: - No new or existing work is "banned" or blocked... - Write your I-Ds and polish them - This mailing list remains open for general discussions - Specific work (for example analysis of protocols against the KARP guidelines) should be taken to protocol-owning working groups - Work on TCP/AO for routing protocols (if anyone wishes to pursue it) needs to be distributed to the correct place. Some of it will be = specific to enhancing BGP security and belongs in IDR or SIDR, some of it may be specific to other routing protocols and can be handled there. But obviously, work on TCP/AO must also involve the Security Area and (if it changes the protocol) the Transport Area. We'll handle these on a case-by-case basis as drafts are produced. Finally, I want to thank you all, and especially the chairs, for the = work done by KARP. Thanks, Adrian _______________________________________________ karp mailing list karp@ietf.org https://www.ietf.org/mailman/listinfo/karp ------=_NextPart_000_0866_01CF8033.D8BBAFA0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi Mahesh,

 

Do you mean ready for last call? It doesn't seem that the document = had been adopted by the WG. And it seems to have expired a little while = ago.

 

A very brief scan of the document suggests that the references are in = a bit of a mess. You need to clean up the things that don't need to be = referenced. Perhaps run idnits?

 

Conversely, I'm a bit surprised that your document doesn't reference = RFC5920 or RFC6941.

 

Tell me whether this document focuses on MPLS-TE, or also covers = GMPLS? What about MPLS-TP?

 

I suggest that the approach is...

- polish your document

- post a new revision

- decide whether you are MPLS-TE only or GMPLS and MPLS-TP as = well

- approach the chairs of MPLS or CCAMP according to your = decision

 

Oh, and consider sending a copy to the RSVP = Directorate.

 

Thanks,

Adrian

 

 

From: Mahesh = Jethanandani [mailto:mjethanandani@gmail.com]
Sent: 31 May = 2014 16:01
To: adrian@olddog.co.uk
Cc: = <karp@ietf.org>; isis-chairs@tools.ietf.org; = pim-chairs@tools.ietf.org; = ccamp-chairs@tools.ietf.org
Subject: Re: [karp] Closing = KARP

 

Adrian,

 

There is one other draft that was reviewed and ready for last = call. draft-mahesh-karp-rsvp-te-analysis. How do you want to proceed on = it?

Mahesh Jethanandani


On May 30, 2014, = at 3:32 PM, "Adrian Farrel" <adrian@olddog.co.uk> = wrote:

OK, thanks to those of you who have contacted me about the = future of KARP work.

I will ask the Secretariat to close the = working group forthwith, and keep the
mailing list = open.

draft-ietf-karp-ops-model
Is on the RFC Editor queue and = has completed Auth48
Publication = soon

draft-ietf-karp-bfd-analysis
The I-D has been refreshed = and WG last call is complete.
The BFD working group has already = reviewed the document.
Brian is working on a shepherd write-up and I = will AD Sponsor the = publication.

draft-ietf-karp-isis-analysis
Document almost = complete.
Needs a final push and review by the ISIS WG.
I will AD = sponsor it when it is ready.

Management plane solution to = AKM
Sam has offered to work on something here.
I'm sure he would = welcome help if anyone is willing.
We can easily find a home for this = sort of work. I would start with the OPSAWG
but maybe it will belong = in netmod.

draft-chunduri-karp-kmp-router-fingerprints
Uma has = recently posted a new revision.
This document can be advanced as AD = sponsored when it is = ready.

draft-bhatia-karp-pim-gap-analysis
This document needs = work.
I'll ask the PIM chairs to run with this in the PIM = WG.

draft-mahesh-karp-lmp-analysis
This document needs = work.
I'll ask the CCAMP chairs to run with this in the CCAMP = WG.

New work / other work:
- No new or existing work is = "banned" or blocked...
  - Write your I-Ds and = polish them
- This mailing list remains open for general = discussions
- Specific work (for example analysis of protocols = against the KARP
  guidelines) should be taken to = protocol-owning working groups
- Work on TCP/AO for routing protocols = (if anyone wishes to pursue it)
 needs to be distributed to the = correct place. Some of it will be specific
 to enhancing BGP = security and belongs in IDR or SIDR, some of it may
 be specific = to other routing protocols and can be handled there. = But
 obviously, work on TCP/AO must also involve the Security = Area and
 (if it changes the protocol) the Transport Area. We'll = handle these on
 a case-by-case basis as drafts are = produced.

Finally, I want to thank you all, and especially the = chairs, for the work done
by = KARP.

Thanks,
Adrian

___________________________________= ____________
karp mailing list
karp@ietf.org
https://www.ietf.org/= mailman/listinfo/karp

<= /div> ------=_NextPart_000_0866_01CF8033.D8BBAFA0-- From nobody Tue Jun 17 16:26:38 2014 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC2201A0089; Tue, 17 Jun 2014 16:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 G3CMxoUW9Tqm; Tue, 17 Jun 2014 16:26:34 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 854DC1A001B; Tue, 17 Jun 2014 16:26:34 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 4279D18000E; Tue, 17 Jun 2014 16:25:21 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20140617232521.4279D18000E@rfc-editor.org> Date: Tue, 17 Jun 2014 16:25:21 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/karp/tmCcH-U4SYRPRaDLrb8ETE5wJ0Y Cc: drafts-update-ref@iana.org, karp@ietf.org, rfc-editor@rfc-editor.org Subject: [karp] RFC 7211 on Operations Model for Router Keying X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 23:26:36 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7211 Title: Operations Model for Router Keying Author: S. Hartman, D. Zhang Status: Informational Stream: IETF Date: June 2014 Mailbox: hartmans-ietf@mit.edu, zhangdacheng@huawei.com Pages: 18 Characters: 47824 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-karp-ops-model-10.txt URL: http://www.rfc-editor.org/rfc/rfc7211.txt The IETF is engaged in an effort to analyze the security of routing protocol authentication according to design guidelines discussed in RFC 6518, "Keying and Authentication for Routing Protocols (KARP)Design Guidelines". Developing an operational and management model for routing protocol security that works with all the routing protocols will be critical to the deployability of these efforts. This document gives recommendations to operators and implementors regarding management and operation of router authentication. These recommendations will also assist protocol designers in understanding management issues they will face. This document is a product of the Keying and Authentication for Routing Protocols Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Wed Jun 18 09:25:46 2014 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 625481A00A6 for ; Wed, 18 Jun 2014 02:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 rmYYCH-vt3B1 for ; Wed, 18 Jun 2014 02:54:09 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 2F99B1A0011 for ; Wed, 18 Jun 2014 02:54:09 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id A59CB18000E; Wed, 18 Jun 2014 02:52:54 -0700 (PDT) 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 X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20140618095254.A59CB18000E@rfc-editor.org> Date: Wed, 18 Jun 2014 02:52:54 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/karp/K7cKNb8lV9QGsBanzfsynC4VRMM X-Mailman-Approved-At: Wed, 18 Jun 2014 09:25:40 -0700 Cc: rfc-editor@rfc-editor.org, infrastation@yandex.ru, karp@ietf.org Subject: [karp] [Editorial Errata Reported] RFC7210 (4016) X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 09:54:11 -0000 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 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 From nobody Wed Jun 18 10:48:36 2014 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A5181A01E1 for ; Wed, 18 Jun 2014 10:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 iJ3hbJ0k5eqP for ; Wed, 18 Jun 2014 10:46:51 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 476211A014C for ; Wed, 18 Jun 2014 10:46:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 23A752471FC; Wed, 18 Jun 2014 10:46:51 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from host-78-75-253-21.homerun.telia.com (host-78-75-253-21.homerun.telia.com [78.75.253.21]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 0BA2F2471FB; Wed, 18 Jun 2014 10:46:48 -0700 (PDT) Message-ID: <53A1D08C.5030109@joelhalpern.com> Date: Wed, 18 Jun 2014 13:46:52 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: RFC Errata System , housley@vigilsec.com, tim.polk@nist.gov, hartmans-ietf@mit.edu, zhangdacheng@huawei.com, akatlas@gmail.com, adrian@olddog.co.uk, bew@cisco.com References: <20140618095254.A59CB18000E@rfc-editor.org> In-Reply-To: <20140618095254.A59CB18000E@rfc-editor.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/karp/VzKhTUZJsVkUhTQu9QyszmP-b6A X-Mailman-Approved-At: Wed, 18 Jun 2014 10:48:34 -0700 Cc: infrastation@yandex.ru, karp@ietf.org Subject: Re: [karp] [Editorial Errata Reported] RFC7210 (4016) X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 17:46:53 -0000 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 > > 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 > From nobody Wed Jun 18 11:20:16 2014 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D98561A0280 for ; Wed, 18 Jun 2014 11:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 WYchWT1Lf46a for ; Wed, 18 Jun 2014 11:15:53 -0700 (PDT) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id 6A3831A01CC for ; Wed, 18 Jun 2014 11:15:53 -0700 (PDT) Received: from [IPv6:::1] (bill@poise.encs.concordia.ca [132.205.2.209]) by oldperseverance.encs.concordia.ca (envelope-from william.atwood@concordia.ca) (8.13.7/8.13.7) with ESMTP id s5IIFfIK021081; Wed, 18 Jun 2014 14:15:41 -0400 Message-ID: <53A1D751.8040605@concordia.ca> Date: Wed, 18 Jun 2014 14:15:45 -0400 From: William Atwood Organization: Concordia University, Montreal User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Joel M. Halpern" , RFC Errata System , housley@vigilsec.com, tim.polk@nist.gov, hartmans-ietf@mit.edu, zhangdacheng@huawei.com, akatlas@gmail.com, adrian@olddog.co.uk, bew@cisco.com References: <20140618095254.A59CB18000E@rfc-editor.org> <53A1D08C.5030109@joelhalpern.com> In-Reply-To: <53A1D08C.5030109@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2014/06/18 14:15:44 EDT Archived-At: http://mailarchive.ietf.org/arch/msg/karp/xA2P0DFrRAEcP39gHlFzZH8EUkM X-Mailman-Approved-At: Wed, 18 Jun 2014 11:20:10 -0700 Cc: infrastation@yandex.ru, karp@ietf.org Subject: Re: [karp] [Editorial Errata Reported] RFC7210 (4016) X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 18:15:57 -0000 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 >> >> 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 > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp -- Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046 Distinguished Professor Emeritus fax: +1 (514) 848-2830 Department of Computer Science and Software Engineering Concordia University EV 3.185 email:william.atwood@concordia.ca 1455 de Maisonneuve Blvd. West http://users.encs.concordia.ca/~bill Montreal, Quebec Canada H3G 1M8 From nobody Mon Jun 23 16:02:39 2014 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 104351B2C70; Mon, 23 Jun 2014 16:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.853 X-Spam-Level: X-Spam-Status: No, score=-104.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 AKz9tVTiZ8F5; Mon, 23 Jun 2014 16:02:33 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB321A03B4; Mon, 23 Jun 2014 16:02:33 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id CEB8D1801AE; Mon, 23 Jun 2014 16:01:01 -0700 (PDT) To: infrastation@yandex.ru, housley@vigilsec.com, tim.polk@nist.gov, hartmans-ietf@mit.edu, zhangdacheng@huawei.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20140623230101.CEB8D1801AE@rfc-editor.org> Date: Mon, 23 Jun 2014 16:01:01 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/karp/JsoJcS1MS2mWJuUqS93ZLVoCgKo Cc: rfc-editor@rfc-editor.org, iesg@ietf.org, karp@ietf.org Subject: [karp] [Errata Verified] RFC7210 (4016) X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 23:02:36 -0000 The following errata report has been verified 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 -------------------------------------- Status: Verified Type: Technical Reported by: Denis Ovsienko Date Reported: 2014-06-18 Verified by: Adrian Farrel (IESG) 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 even though the descriptive text indicates it should be included. -------------------------------------- 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