From wwwrun@rfc-editor.org Wed Feb 1 17:18:20 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B95EB1F0C57; Wed, 1 Feb 2012 17:18:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.309 X-Spam-Level: X-Spam-Status: No, score=-104.309 tagged_above=-999 required=5 tests=[AWL=1.368, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MMHyBDKmMV0x; Wed, 1 Feb 2012 17:18:20 -0800 (PST) Received: from rfc-editor.org (rfcpa.amsl.com [12.22.58.47]) by ietfa.amsl.com (Postfix) with ESMTP id 220EF1F0C56; Wed, 1 Feb 2012 17:18:20 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 41D36B1E00F; Wed, 1 Feb 2012 17:14:22 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20120202011422.41D36B1E00F@rfc-editor.org> Date: Wed, 1 Feb 2012 17:14:22 -0800 (PST) Cc: karp@ietf.org, rfc-editor@rfc-editor.org Subject: [karp] RFC 6518 on Keying and Authentication for Routing Protocols (KARP) Design Guidelines X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 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: Thu, 02 Feb 2012 01:18:21 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6518 Title: Keying and Authentication for Routing Protocols (KARP) Design Guidelines Author: G. Lebovitz, M. Bhatia Status: Informational Stream: IETF Date: February 2012 Mailbox: gregory.ietf@gmail.com, manav.bhatia@alcatel-lucent.com Pages: 30 Characters: 76782 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-karp-design-guide-10.txt URL: http://www.rfc-editor.org/rfc/rfc6518.txt This document is one of a series concerned with defining a roadmap of protocol specification work for the use of modern cryptographic mechanisms and algorithms for message authentication in routing protocols. In particular, it defines the framework for a key management protocol that may be used to create and manage session keys for message authentication and integrity. This document is not an Internet Standards Track specification; it is published for informational purposes. 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/rfcsearch.html. 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 jmh@joelhalpern.com Thu Feb 2 12:06:39 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87A8A21F8668 for ; Thu, 2 Feb 2012 12:06:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.062 X-Spam-Level: X-Spam-Status: No, score=-102.062 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUJk1WCZpZKo for ; Thu, 2 Feb 2012 12:06:38 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id AB97721F867A for ; Thu, 2 Feb 2012 12:06:38 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 874F7CAD0C for ; Thu, 2 Feb 2012 12:06:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id BDE6E180400 for ; Thu, 2 Feb 2012 12:06:37 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.10.10.101] (pool-71-161-52-140.clppva.btas.verizon.net [71.161.52.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id B86DF1803A6 for ; Thu, 2 Feb 2012 12:06:36 -0800 (PST) Message-ID: <4F2AECCA.6050608@joelhalpern.com> Date: Thu, 02 Feb 2012 15:06:34 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "karp@ietf.org" References: <20120202011422.41D36B1E00F@rfc-editor.org> In-Reply-To: <20120202011422.41D36B1E00F@rfc-editor.org> X-Forwarded-Message-Id: <20120202011422.41D36B1E00F@rfc-editor.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [karp] Fwd: RFC 6518 on Keying and Authentication for Routing Protocols (KARP) Design Guidelines X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 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: Thu, 02 Feb 2012 20:06:39 -0000 Congratulations to the authors and the working group. Thank you for your efforts, Joel and Brian -------- Original Message -------- Subject: [karp] RFC 6518 on Keying and Authentication for Routing Protocols (KARP) Design Guidelines Date: Wed, 1 Feb 2012 17:14:22 -0800 (PST) From: rfc-editor@rfc-editor.org To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org CC: karp@ietf.org, rfc-editor@rfc-editor.org A new Request for Comments is now available in online RFC libraries. RFC 6518 Title: Keying and Authentication for Routing Protocols (KARP) Design Guidelines Author: G. Lebovitz, M. Bhatia Status: Informational Stream: IETF Date: February 2012 Mailbox: gregory.ietf@gmail.com, manav.bhatia@alcatel-lucent.com Pages: 30 Characters: 76782 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-karp-design-guide-10.txt URL: http://www.rfc-editor.org/rfc/rfc6518.txt This document is one of a series concerned with defining a roadmap of protocol specification work for the use of modern cryptographic mechanisms and algorithms for message authentication in routing protocols. In particular, it defines the framework for a key management protocol that may be used to create and manage session keys for message authentication and integrity. This document is not an Internet Standards Track specification; it is published for informational purposes. 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/rfcsearch.html. 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 _______________________________________________ karp mailing list karp@ietf.org https://www.ietf.org/mailman/listinfo/karp From glen.kent@gmail.com Fri Feb 3 08:44:40 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58BEC21F855E for ; Fri, 3 Feb 2012 08:44:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8IPiJWFz5F9d for ; Fri, 3 Feb 2012 08:44:39 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id B44C021F855B for ; Fri, 3 Feb 2012 08:44:39 -0800 (PST) Received: by iagf6 with SMTP id f6so6039008iag.31 for ; Fri, 03 Feb 2012 08:44:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=5G84okbj/nw43EKwl176fvx1hv+ow0QtJThbaHonHGc=; b=ukPe1wegd9hJwwjN+eVgD7ddpyklVw/dH6u3Ob73R6OkKY8AJdHERiqyjW289Rvqhn 3UCrenV2VqgTK8uGUAkXIUpHZTe28ssgScQaWg6wWnikwgGCgB7M3FQRBVHmWhqQzjP8 YU55gEDG5fImcIxXEwpzO3FI3C3RXQvH/uevI= MIME-Version: 1.0 Received: by 10.50.208.1 with SMTP id ma1mr11447183igc.4.1328287479260; Fri, 03 Feb 2012 08:44:39 -0800 (PST) Received: by 10.43.44.66 with HTTP; Fri, 3 Feb 2012 08:44:39 -0800 (PST) In-Reply-To: <4F2AECCA.6050608@joelhalpern.com> References: <20120202011422.41D36B1E00F@rfc-editor.org> <4F2AECCA.6050608@joelhalpern.com> Date: Fri, 3 Feb 2012 22:14:39 +0530 Message-ID: From: Glen Kent To: "Joel M. Halpern" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "karp@ietf.org" Subject: Re: [karp] Fwd: RFC 6518 on Keying and Authentication for Routing Protocols (KARP) Design Guidelines X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 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: Fri, 03 Feb 2012 16:44:40 -0000 Congratulations to Gregory, Manav, chairs and all the members of KARP WG for the KARP's first RFC. Time to start working on the KARP threat reqs now! :-) Glen On Fri, Feb 3, 2012 at 1:36 AM, Joel M. Halpern wrote= : > Congratulations to the authors and the working group. > Thank you for your efforts, > Joel and Brian > > > -------- Original Message -------- > Subject: [karp] RFC 6518 on Keying and Authentication for Routing Protoco= ls > (KARP) Design Guidelines > Date: Wed, =A01 Feb 2012 17:14:22 -0800 (PST) > From: rfc-editor@rfc-editor.org > To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org > CC: karp@ietf.org, rfc-editor@rfc-editor.org > > > A new Request for Comments is now available in online RFC libraries. > > > =A0 =A0 =A0 =A0RFC 6518 > > =A0 =A0 =A0 =A0Title: =A0 =A0 =A0Keying and Authentication for Routing > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Protocols (KARP) Design Guidelines > =A0 =A0 =A0 =A0Author: =A0 =A0 G. Lebovitz, M. Bhatia > =A0 =A0 =A0 =A0Status: =A0 =A0 Informational > =A0 =A0 =A0 =A0Stream: =A0 =A0 IETF > =A0 =A0 =A0 =A0Date: =A0 =A0 =A0 February 2012 > =A0 =A0 =A0 =A0Mailbox: =A0 =A0gregory.ietf@gmail.com, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0manav.bhatia@alcatel-lucent.com > =A0 =A0 =A0 =A0Pages: =A0 =A0 =A030 > =A0 =A0 =A0 =A0Characters: 76782 > =A0 =A0 =A0 =A0Updates/Obsoletes/SeeAlso: =A0 None > > =A0 =A0 =A0 =A0I-D Tag: =A0 =A0draft-ietf-karp-design-guide-10.txt > > =A0 =A0 =A0 =A0URL: =A0 =A0 =A0 =A0http://www.rfc-editor.org/rfc/rfc6518.= txt > > This document is one of a series concerned with defining a > roadmap of protocol specification work for the use of modern > cryptographic mechanisms and algorithms for message > authentication in routing protocols. =A0In particular, it defines > the framework for a key management protocol that may be used to > create and manage session keys for message authentication and > integrity. =A0This document is not an Internet Standards Track > specification; it is published for informational purposes. > > 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 > =A0http://www.ietf.org/mailman/listinfo/ietf-announce > =A0http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.htm= l. > 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. =A0Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > > The RFC Editor Team > Association Management Solutions, LLC > > > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp From mjethanandani@gmail.com Fri Feb 3 10:07:14 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7A7421F858E for ; Fri, 3 Feb 2012 10:07:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NclhK0wFF5VP for ; Fri, 3 Feb 2012 10:07:13 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id D14F021F8592 for ; Fri, 3 Feb 2012 10:07:13 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so12925pbc.31 for ; Fri, 03 Feb 2012 10:07:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:mime-version:content-type:subject:date:in-reply-to:to :references:message-id:x-mailer; bh=p8/QOR+sd0DX2A5hn6EC4dzTD1VjQ6z6JdPwfVysglU=; b=DUJHa/qFxqDuHrzZ6FHalP8Y09XsfMeuiNoxDLwrrHDssVV5FEEKkYWBL3yWcqBZDl g9dcmiIGcUNC88i6OJfaa/mwxYZ6w/rrEFRMk8JYCKMu7yoepH6jPDkyydveqdN+caP9 gGWDwbLgfwMf79F7HjiZ8nLLlx7ylu73M1FZk= Received: by 10.68.208.228 with SMTP id mh4mr19381083pbc.13.1328292433667; Fri, 03 Feb 2012 10:07:13 -0800 (PST) Received: from [192.168.1.123] (c-24-6-173-225.hsd1.ca.comcast.net. [24.6.173.225]) by mx.google.com with ESMTPS id t10sm14599181pbb.18.2012.02.03.10.07.11 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 03 Feb 2012 10:07:12 -0800 (PST) From: Mahesh Jethanandani Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-10--54605267 Date: Fri, 3 Feb 2012 10:07:09 -0800 In-Reply-To: <20120202011422.41D36B1E00F@rfc-editor.org> To: karp@ietf.org References: <20120202011422.41D36B1E00F@rfc-editor.org> Message-Id: <31CAB785-1B44-4B18-A028-A06EF217CFF2@gmail.com> X-Mailer: Apple Mail (2.1084) Subject: Re: [karp] RFC 6518 on Keying and Authentication for Routing Protocols (KARP) Design Guidelines X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 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: Fri, 03 Feb 2012 18:07:14 -0000 --Apple-Mail-10--54605267 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Just caught one typo in section 3. IT IS RECOMMENDED that any Phase 1 security update to a Rouing ^^^^^^ On Feb 1, 2012, at 5:14 PM, rfc-editor@rfc-editor.org wrote: >=20 > A new Request for Comments is now available in online RFC libraries. >=20 >=20 > RFC 6518 >=20 > Title: Keying and Authentication for Routing=20 > Protocols (KARP) Design Guidelines=20 > Author: G. Lebovitz, M. Bhatia > Status: Informational > Stream: IETF > Date: February 2012 > Mailbox: gregory.ietf@gmail.com,=20 > manav.bhatia@alcatel-lucent.com > Pages: 30 > Characters: 76782 > Updates/Obsoletes/SeeAlso: None >=20 > I-D Tag: draft-ietf-karp-design-guide-10.txt >=20 > URL: http://www.rfc-editor.org/rfc/rfc6518.txt >=20 > This document is one of a series concerned with defining a > roadmap of protocol specification work for the use of modern > cryptographic mechanisms and algorithms for message > authentication in routing protocols. In particular, it defines > the framework for a key management protocol that may be used to > create and manage session keys for message authentication and > integrity. This document is not an Internet Standards Track=20 > specification; it is published for informational purposes. >=20 > This document is a product of the Keying and Authentication for = Routing Protocols Working Group of the IETF. >=20 >=20 > 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. >=20 > 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 >=20 > For searching the RFC series, see = http://www.rfc-editor.org/rfcsearch.html. > For downloading RFCs, see http://www.rfc-editor.org/rfc.html. >=20 > 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. >=20 >=20 > The RFC Editor Team > Association Management Solutions, LLC >=20 >=20 > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp --Apple-Mail-10--54605267 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Just = caught one typo in section 3.

 IT IS RECOMMENDED that any Phase 1 =
security update to a Rouing
       =
                                                  =
^^^^^^

On Feb 1, 2012, at 5:14 PM, rfc-editor@rfc-editor.org = wrote:


A new Request for Comments is now available in = online RFC libraries.


=        RFC 6518

=        Title: =      Keying and Authentication for Routing
=             &n= bsp;      Protocols (KARP) Design = Guidelines
       Author: =     G. Lebovitz, M. Bhatia
=        Status: =     Informational
=        Stream: =     IETF
=        Date: =       February 2012
=        Mailbox:    gregory.ietf@gmail.com,
=             &n= bsp;      manav.bhatia@alcatel-lucen= t.com
       Pages: =      30
=        Characters: 76782
=        Updates/Obsoletes/SeeAlso: =   None

       I-D = Tag:    draft-ietf-karp-design-guide-10.txt

=        URL: =        http://www.rfc-editor.o= rg/rfc/rfc6518.txt

This document is one of a series concerned = with defining a
roadmap of protocol specification work for the use of = modern
cryptographic mechanisms and algorithms for = message
authentication in routing protocols.  In particular, it = defines
the framework for a key management protocol that may be used = to
create and manage session keys for message authentication = and
integrity.  This document is not an Internet Standards Track =
specification; it is published for informational = purposes.

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.iet= f.org/mailman/listinfo/ietf-announce
 http://ma= ilman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching = the RFC series, see http://www.rfc-editor.or= g/rfcsearch.html.
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


_______________________________________________
karp = mailing list
karp@ietf.org
https://www.ietf.org/ma= ilman/listinfo/karp

= --Apple-Mail-10--54605267-- From hartmans@mit.edu Fri Feb 3 16:25:20 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 745BB21F861C for ; Fri, 3 Feb 2012 16:25:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.063 X-Spam-Level: X-Spam-Status: No, score=-103.063 tagged_above=-999 required=5 tests=[AWL=-0.798, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rY9CIdB4sorR for ; Fri, 3 Feb 2012 16:25:19 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id CD78021F85F1 for ; Fri, 3 Feb 2012 16:25:14 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 6497D20144 for ; Fri, 3 Feb 2012 19:24:11 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 793304690; Fri, 3 Feb 2012 19:24:52 -0500 (EST) From: Sam Hartman To: karp@ietf.org Date: Fri, 03 Feb 2012 19:24:52 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [karp] Comments on draft-ietf-karp-crypto-tables X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 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: Sat, 04 Feb 2012 00:25:20 -0000 Here are some comments on the crypto draft. Below I talk about normal form and first normal form a lot. These are database comments. The wikipedia page is not the worst description ever if you are unfamiliar with the concepts. I want to stress that I don't think we should blindly assume normal form (particularly say 3nf) is good in an information model. In fact, I think that the ideal result for this table will be somewhat denormalized. However I've pointed out cases below where I believe the specific denormalization of the table gets in the way of a quality management/operations experience. I don't think "this isn't 1st normal form," is a valid objection. I do think "this isn't 1st normal form in way x which causes problems y and z," may be a valid objection. > To accommodate manual key management, then formatting of the fields > has been purposefully chosen to allow updates with a plain text > editor. I think this text should be removed and a plain-text editor is not the format I'd expect will be common for updates. Seems to be that CLI operation, netconf schemas or something like XML will be more common, which CLI operation hugely dominating for manual key management. (Often CLI driven by scripts) Updating in text editors has siginificant operational issues. For example it's very eeasy to express invalid combinations of configuration in a manner that a CLI would detect. General: hexadecimal integers. You specify that the integers are hex. Conceptual integers don't seem like they should have a base. It may well be that we want to have textual conventions for representing key IDs and keys and the like in operator interfaces. We could do that in this document or draft-ietf-karp-ops-model. I think hex is a fine convention for some of these values, but I don't think it's appropriate to mix textual conventions and conceptual data type in an information model. Local key ID. In a conceptual table why is it important that the field is 16-bits wide? It seems like this is only desirable if it aligns with something over the wire that is 16-bits wide or for some other interoperability purpose. In a information model--that is a conceptual modeel of management information--it seems poor to have pair-wise vs group key being determined by a bit in the key ID. First, that means that we really have a 15-bit range; 15-bits is even more odd than 16-bits for a conceptual model. However more seriously, why is it a good idea to combine these fields? Why should the domain of this column effectively be tuples of key type and id rather than having two columns? Depending on which definition you take of first normal form, this would count as a denormalization of the table, and many of the problems that can pop up when your database in denormalized do pop up with this example. It makes it more challenging to ask for all group keys. It seems like a fairly bad idea to have a field whose value is sometimes unique and sometimes not. Peer key ID: Again, it seems overly proscriptive to describe this as I have two concerns about this field. First, it is nonsensical. The values "group" and "null" are not 16-bit integers. Mor seriously, though, as you point out, the form of the peer key ID is dependent on the protocol that wil use it. In a conceptual table, we should leave the form up to the protocol and not even specify whether it is an integer or name because that depends on the protocol in question. In a file format, netconf schema, MIB or the like, we'd have to be more concrete. But we're doing a conceptual model here. peers: What is the conceptual format of this field? How is it used? This field is not in first normal form in that it's a repeated group. That's problematic because it seems likely that multiple key rows might share the same set of peers. By having the peers denormalized in this manner it makes it hard to update the appropriate set of peers. That is, I have 3 keys shared between peers a, b, and c. Because the peers field is denormalized it's easy to get to a state where I have two keys with peers a, b and c and a third and fourth key with peers a, b, c and d. protocol-specific, kdf, kdf inputs: It seems kind of haphazard what information is a column in the table and what information is folded into protocol specific. Describing protocol specific as binary also seems wrong in a information model. One thing to think about here is whether aspects of protocol specific will need to be indexes for finding the right record. key lifetimes: As discussed in the meeting I prefer send not before and send not after and prefer to avoid the complexity of receive lifetimes. So, I'd like to object to that change made in the last revision and visit the question of whether the WG has consensus to make that change. The document seems overly proscriptive for the textual convention of a date for a conceptual model. I'd also like to bring up the issues raised in section 3 of draft-ietf-karp-ops-model. The interfaces, peers model of describing which key to work seems rather specific to a protocol. Some of the issues with this model are discussed in section 3 of draft-ietf-karp-ops-model. I suspect that after we discuss my concerns with section 2 I'll have some concerns with section 3, but it will probably be easier to address them later. From mjethanandani@gmail.com Sun Feb 12 22:12:16 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F63421F865C for ; Sun, 12 Feb 2012 22:12:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PSRwmyWs+Mgs for ; Sun, 12 Feb 2012 22:12:11 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 19A0321F8655 for ; Sun, 12 Feb 2012 22:12:06 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so4480444pbc.31 for ; Sun, 12 Feb 2012 22:12:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=kIxe/s+RpMVoHfK3Tc1eONV3YnEEszASPIbP85YZysY=; b=eHcgUrYLcqpoQaCZfmaRO/AQNbfC5v6Lx+FJVbI8SB8AFIqGEvAGUb6Wry2wJ+/8/4 1peArVDyhm1w7t+N4JCJR7vZ1A92uA6glGTSSN48XqDmKEGLIibU/jffGLqwFxY1iAkM q37yGAfud012twWBq8jtRy/LyTkEwTTQjR8Rw= Received: by 10.68.217.72 with SMTP id ow8mr44037612pbc.130.1329113525919; Sun, 12 Feb 2012 22:12:05 -0800 (PST) Received: from [192.168.1.123] (c-24-6-173-225.hsd1.ca.comcast.net. [24.6.173.225]) by mx.google.com with ESMTPS id b4sm34608113pbc.7.2012.02.12.22.12.04 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 12 Feb 2012 22:12:04 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-7-766487545 From: Mahesh Jethanandani In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D029FDD25@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Sun, 12 Feb 2012 22:12:02 -0800 Message-Id: <7F8C7459-EF57-4EF5-8E68-B270431E71F1@gmail.com> References: <7C362EEF9C7896468B36C9B79200D8350D029FDC87@INBANSXCHMBSA1.in.alcatel-lucent.com> <9057F3D6-6F97-46E8-AC9B-E5481CECA955@gmail.com> <7C362EEF9C7896468B36C9B79200D8350D029FDD25@INBANSXCHMBSA1.in.alcatel-lucent.com> To: "Bhatia, Manav (Manav)" X-Mailer: Apple Mail (2.1084) Cc: "karp@ietf.org" Subject: Re: [karp] BFD Gap Analysis X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 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, 13 Feb 2012 06:12:16 -0000 --Apple-Mail-7-766487545 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > We should either remove this sentence or add a short section briefly = explaining what can be done to fix the gaps found. I would vote for the latter. Reading and having written one of the documents doing gap analysis, it = is my feeling that we gelling around a few ways to improve almost all = the protocols. The common requirement is for an ability to rollover the = keys. You already mention it so why not make it part of the solution. = Better encryption and HMAC is clearly another. On Jan 25, 2012, at 3:07 PM, Bhatia, Manav (Manav) wrote: > Hi Mahesh, > =20 > Good Catch. > =20 > Initially the plan was to suggest mechanisms to fix the gaps found, = but then we left that out as we weren't sure if that was in scope for a = gaps analysis document. We should either remove this sentence or add a = short section briefly explaining what can be done to fix the gaps found. = We had left this section since the fixing part should be done in the BFD = WG and this is a KARP document. > =20 > Cheers, Manav >=20 > From: Mahesh Jethanandani [mailto:mjethanandani@gmail.com]=20 > Sent: Thursday, January 26, 2012 1:47 AM > To: Bhatia, Manav (Manav) > Cc: karp@ietf.org > Subject: Re: [karp] BFD Gap Analysis >=20 > Manav, >=20 > Was there a plan to propose mechanisms to address the issues? I did = not see them in the draft. >=20 >> The remainder of this document explains the details of how these >> requirements fail to be met and proposes mechanisms for addressing >> them. >=20 >=20 > On Jan 25, 2012, at 3:34 AM, Bhatia, Manav (Manav) wrote: >=20 >> Hi, >>=20 >> Many many moons ago Dacheng and I had written a short draft doing BFD = gap analysis as part of the KARP Phase 1. The draft was briefly = discussed in the BFD WG and this version incorporates the comments we = received there + some boiler plate changes. >>=20 >> http://tools.ietf.org/id/draft-bhatia-zhang-karp-bfd-analysis-02.txt >>=20 >> Comments on this version are welcome! >>=20 >> Cheers, Manav >> _______________________________________________ >> karp mailing list >> karp@ietf.org >> https://www.ietf.org/mailman/listinfo/karp >=20 --Apple-Mail-7-766487545 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
We should either remove this sentence or add a short section briefly explaining what can be done to fix the gaps found.

I would vote for the latter.

Reading and having written one of the documents doing gap analysis, it is my feeling that we gelling around a few ways to improve almost all the protocols. The common requirement is for an ability to rollover the keys. You already mention it so why not make it part of the solution. Better encryption and HMAC is clearly another.

On Jan 25, 2012, at 3:07 PM, Bhatia, Manav (Manav) wrote:

Hi Mahesh,
 
Good Catch.
 
Initially the plan was to suggest mechanisms to fix the gaps found, but then we left that out as we weren't sure if that was in scope for a gaps analysis document. We should either remove this sentence or add a short section briefly explaining what can be done to fix the gaps found. We had left this section since the fixing part should be done in the BFD WG and this is a KARP document.
 
Cheers, Manav

From: Mahesh Jethanandani [mailto:mjethanandani@gmail.com]
Sent: Thursday, January 26, 2012 1:47 AM
To: Bhatia, Manav (Manav)
Cc: karp@ietf.org
Subject: Re: [karp] BFD Gap Analysis

Manav,

Was there a plan to propose mechanisms to address the issues? I did not see them in the draft.

The remainder of this document explains the details of how these
   requirements fail to be met and proposes mechanisms for addressing
   them.

On Jan 25, 2012, at 3:34 AM, Bhatia, Manav (Manav) wrote:

Hi,

Many many moons ago Dacheng and I had written a short draft doing BFD gap analysis as part of the KARP Phase 1. The draft was briefly discussed in the BFD WG and this version incorporates the comments we received there + some boiler plate changes.

http://tools.ietf.org/id/draft-bhatia-zhang-karp-bfd-analysis-02.txt

Comments on this version are welcome!

Cheers, Manav
_______________________________________________
karp mailing list
karp@ietf.org
https://www.ietf.org/mailman/listinfo/karp


--Apple-Mail-7-766487545-- From manav.bhatia@alcatel-lucent.com Sun Feb 12 23:07:36 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55C2421F855F for ; Sun, 12 Feb 2012 23:07:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.769 X-Spam-Level: X-Spam-Status: No, score=-8.769 tagged_above=-999 required=5 tests=[AWL=1.829, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aCel1E6kovar for ; Sun, 12 Feb 2012 23:07:35 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3B021F8568 for ; Sun, 12 Feb 2012 23:07:35 -0800 (PST) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q1D77U6r018397 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 13 Feb 2012 01:07:33 -0600 (CST) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q1D77U0u002326 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 13 Feb 2012 12:37:30 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Mon, 13 Feb 2012 12:37:30 +0530 From: "Bhatia, Manav (Manav)" To: Mahesh Jethanandani Date: Mon, 13 Feb 2012 12:35:04 +0530 Thread-Topic: [karp] BFD Gap Analysis Thread-Index: AczqFnLW9s5YGhOZSwGxLufpuqagMgAB0qnA Message-ID: <7C362EEF9C7896468B36C9B79200D8350D02B49B9A@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7F8C7459-EF57-4EF5-8E68-B270431E71F1@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7C362EEF9C7896468B36C9B79200D8350D02B49B9AINBANSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "karp@ietf.org" Subject: Re: [karp] BFD Gap Analysis X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 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, 13 Feb 2012 07:07:36 -0000 --_000_7C362EEF9C7896468B36C9B79200D8350D02B49B9AINBANSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yup, this can be easily done. Will update this in the next revision. Cheers, Manav ________________________________ From: Mahesh Jethanandani [mailto:mjethanandani@gmail.com] Sent: Monday, February 13, 2012 11:42 AM To: Bhatia, Manav (Manav) Cc: karp@ietf.org Subject: Re: [karp] BFD Gap Analysis We should either remove this sentence or add a short section briefly explai= ning what can be done to fix the gaps found. I would vote for the latter. Reading and having written one of the documents doing gap analysis, it is m= y feeling that we gelling around a few ways to improve almost all the proto= cols. The common requirement is for an ability to rollover the keys. You al= ready mention it so why not make it part of the solution. Better encryption= and HMAC is clearly another. On Jan 25, 2012, at 3:07 PM, Bhatia, Manav (Manav) wrote: Hi Mahesh, Good Catch. Initially the plan was to suggest mechanisms to fix the gaps found, but the= n we left that out as we weren't sure if that was in scope for a gaps analy= sis document. We should either remove this sentence or add a short section = briefly explaining what can be done to fix the gaps found. We had left this= section since the fixing part should be done in the BFD WG and this is a K= ARP document. Cheers, Manav ________________________________ From: Mahesh Jethanandani [mailto:mjethanandani@gmail.com] Sent: Thursday, January 26, 2012 1:47 AM To: Bhatia, Manav (Manav) Cc: karp@ietf.org Subject: Re: [karp] BFD Gap Analysis Manav, Was there a plan to propose mechanisms to address the issues? I did not see= them in the draft. The remainder of this document explains the details of how these requirements fail to be met and proposes mechanisms for addressing them. On Jan 25, 2012, at 3:34 AM, Bhatia, Manav (Manav) wrote: Hi, Many many moons ago Dacheng and I had written a short draft doing BFD gap a= nalysis as part of the KARP Phase 1. The draft was briefly discussed in the= BFD WG and this version incorporates the comments we received there + some= boiler plate changes. http://tools.ietf.org/id/draft-bhatia-zhang-karp-bfd-analysis-02.txt Comments on this version are welcome! Cheers, Manav _______________________________________________ karp mailing list karp@ietf.org https://www.ietf.org/mailman/listinfo/karp --_000_7C362EEF9C7896468B36C9B79200D8350D02B49B9AINBANSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Yup, this can be easily done. Will update this in = the next=20 revision.
 
Cheers, Manav

From: Mahesh Jethanandani=20 [mailto:mjethanandani@gmail.com]
Sent: Monday, February 13, 20= 12=20 11:42 AM
To: Bhatia, Manav (Manav)
Cc:=20 karp@ietf.org
Subject: Re: [karp] BFD Gap=20 Analysis

We = should=20 either remove this sentence or add a short section briefly explaining w= hat=20 can be done to fix the gaps found.

I would vote for the latter.

Reading and having written one of the documents doing gap analysis, = it is=20 my feeling that we gelling around a few ways to improve almost all the=20 protocols. The common requirement is for an ability to rollover the keys.= You=20 already mention it so why not make it part of the solution. Better encryp= tion=20 and HMAC is clearly another.

On Jan 25, 2012, at 3:07 PM, Bhatia, Manav (Manav) wrote:
Hi Mahesh,
 
Good Catch.
 
Initially the plan was to suggest mechanisms t= o fix the=20 gaps found, but then we left that out as we weren't sure if t= hat=20 was in scope for a gaps analysis document. We should either remove this= =20 sentence or add a short section briefly explaining what can be done to = fix=20 the gaps found. We had left this section since the fixing part should b= e=20 done in the BFD WG and this is a KARP document.
 
Cheers, Manav

From: Mahesh Jethanandani=20 [mailto:mjethanandani@gmail.com]
Sent: Thursday, January 2= 6,=20 2012 1:47 AM
To: Bhatia, Manav (Manav)
Cc: karp@ietf.org
Subject: Re= :=20 [karp] BFD Gap Analysis

Manav,=20

Was there a plan to propose mechanisms to address the issues? I = did=20 not see them in the draft.

The remainder of this document=
 explains the details of how these
   requirements fail to be met and proposes mechanisms for addressing
   them.

On Jan 25, 2012, at 3:34 AM, Bhatia, Manav (Manav) wrote:
<= BR=20 class=3DApple-interchange-newline>
Hi,

Many many moons ago Dacheng and I had written a sho= rt=20 draft doing BFD gap analysis as part of the KARP Phase 1. The draft= was=20 briefly discussed in the BFD WG and this version incorporates the=20 comments we received there + some boiler plate changes.

http://tools.ietf.org/id/draft-bhatia-zhang-karp-bfd-analysis-02= .txt

Comments=20 on this version are welcome!

Cheers,=20 Manav
_______________________________________________
karp ma= iling=20 list
karp@ietf.org
https://www.ietf= .org/mailman/listinfo/karp


--_000_7C362EEF9C7896468B36C9B79200D8350D02B49B9AINBANSXCHMBSA_-- From jmh@joelhalpern.com Thu Feb 23 16:07:33 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8177921F88C6 for ; Thu, 23 Feb 2012 16:07:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.965 X-Spam-Level: X-Spam-Status: No, score=-101.965 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZkHxlTbT4ud for ; Thu, 23 Feb 2012 16:07:33 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 1BBCD21F88BB for ; Thu, 23 Feb 2012 16:07:33 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 158FCCD0C4 for ; Thu, 23 Feb 2012 16:07:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id EAE5F321D89 for ; Thu, 23 Feb 2012 16:07:32 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [172.17.114.244] (207.47.24.2.static.nextweb.net [207.47.24.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id CE542321D83 for ; Thu, 23 Feb 2012 16:07:32 -0800 (PST) Message-ID: <4F46D4C5.8090407@joelhalpern.com> Date: Thu, 23 Feb 2012 19:07:33 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "karp@ietf.org" References: <20120223203052.9020.46440.idtracker@ietfa.amsl.com> In-Reply-To: <20120223203052.9020.46440.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120223203052.9020.46440.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [karp] Fwd: karp - Requested session has been scheduled for IETF 83 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 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: Fri, 24 Feb 2012 00:07:33 -0000 The preliminary IETF Agenda has been announced. We have been given the 2 hour slot on Wednesday afternoon from 1pm-3pm. The details as sent to the chairs are below. Yours, Joel -------- Original Message -------- Subject: karp - Requested session has been scheduled for IETF 83 Date: Thu, 23 Feb 2012 12:30:52 -0800 From: "IETF Secretariat" To: bew@cisco.com CC: karp-ads@tools.ietf.org, karp-chairs@tools.ietf.org, wlo@amsl.com Dear Brian Weis, The sessions that you have requested have been scheduled. Below is the scheduled session information followed by the original request. karp Session 1 (2 hours) Wednesday, Afternoon Session I 1300-1500 Room Name: 242AB --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Keying and Authentication for Routing Protocols Area Name: Routing Area Session Requester: Wanda Lo Number of Sessions: 1 Length of Session(s): 2 hours Number of Attendees: 100 Conflicts to Avoid: First Priority: rtgarea, idr, isis, ospf, pce, pim, rtgwg, sidr, ipsecme, saag, tls, opsec, lisp, tcpm, rrg, grow, mpls, bfd, ccamp, l3vpn Second Priority: ROLL forces savi BOF or IRTF Session: rrg, kidns, armd, nbs, plasma Special Requests: ---------------------------------------------------------