Re: [pkix] Last Call: draft-ietf-pkix-tamp (Trust Anchor Management Protocol (TAMP)) to Proposed Standard

David Borman <david.borman@windriver.com> Thu, 28 January 2010 04:52 UTC

Return-Path: <david.borman@windriver.com>
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 167A03A69C4; Wed, 27 Jan 2010 20:52:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.203
X-Spam-Level:
X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8RMgnpvOmv90; Wed, 27 Jan 2010 20:52:48 -0800 (PST)
Received: from mail.windriver.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id 418663A69BD; Wed, 27 Jan 2010 20:52:48 -0800 (PST)
Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.windriver.com (8.14.3/8.14.3) with ESMTP id o0S4r40S003952; Wed, 27 Jan 2010 20:53:04 -0800 (PST)
Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Jan 2010 20:52:08 -0800
Received: from [172.25.44.5] ([172.25.44.5]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Jan 2010 20:52:08 -0800
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset="windows-1252"
From: David Borman <david.borman@windriver.com>
In-Reply-To: <4B571FFB.204@ericsson.com>
Date: Wed, 27 Jan 2010 22:52:07 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <EB0AB31B-D87A-4A8B-BF79-66CFBCEB0AE4@windriver.com>
References: <4B571FFB.204@ericsson.com>
To: "iesg@ietf.org IESG" <iesg@ietf.org>
X-Mailer: Apple Mail (2.1077)
X-OriginalArrivalTime: 28 Jan 2010 04:52:08.0678 (UTC) FILETIME=[A57D4060:01CA9FD5]
X-Mailman-Approved-At: Thu, 28 Jan 2010 12:29:54 -0800
Cc: pkix@ietf.org, TSV Dir <tsv-dir@ietf.org>
Subject: Re: [pkix] Last Call: draft-ietf-pkix-tamp (Trust Anchor Management Protocol (TAMP)) to Proposed Standard
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pkix>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Jan 2010 04:52:49 -0000

I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC tsv-dir@… if you reply to or forward this review.

I have reviewed this document specifically for any transport related issues.  TAMP is primarily a request/response protocol designed to be independent of the underlying transport mechanism, Appendix C documents using TAMP over HTTP.  In that context, TAMP does not have any transport related issues beyond the underlying HTTP.  As long as the transport over which TAMP is being used is reliable, such as HTTP or TCP, TAMP should be fine.  However, TAMP is documented as being transport independent.  As such, it would be useful if the "Implementation Considerations" sections mentioned any assumptions about the underlying transport.  For example, while the definition of TAMP may be fine for HTTP, I doubt TAMP would work reliably over UDP without the need for additional mechanisms to deal with lost packets.  Just stating that TAMP assumes a reliable underlying transport protocol would probably be sufficient.

Beyond that, I did not see any other transport related issues that need to be addressed before this document is published.  

	-David Borman, for the Transport Directorate


> Ämne: Last Call: draft-ietf-pkix-tamp (Trust Anchor Management Protocol
> (TAMP)) to Proposed Standard
> Datum: Thu, 14 Jan 2010 09:34:14 -0800 (PST)
> Från: The IESG <iesg-secretary@ietf.org>
> Svar till: ietf@ietf.org
> Till: IETF-Announce <ietf-announce@ietf.org>
> Kopia: pkix@ietf.org
> 
> The IESG has received a request from the Public-Key Infrastructure
> (X.509) WG (pkix) to consider the following document:
> 
> - 'Trust Anchor Management Protocol (TAMP) '
>   <draft-ietf-pkix-tamp-05.txt> as a Proposed Standard
> 
> This document includes a downref to draft-ietf-pkix-new-asn1, which
> is under consideration by the IESG for publication as an Informational RFC.
> This document updates ASN.1 modules for PKIX specifications to conform to
> the 2002 version of ASN.1, but makes no changes to the bits on the wire.
> The community is specifically requested to consider whether down refs
> to draft-ietf-pkix-new-asn1 are appropriate in the general case,
> in addition to the specific case of draft-ietf-pkix-tamp.
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive comments to the
> ietf@ietf.org mailing lists by 2010-01-28. Exceptionally,
> comments may be sent to iesg@ietf.org instead. In either case, please
> retain the beginning of the Subject line to allow automated sorting.
> 
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-tamp-05.txt
> 
> 
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17760&rfc_flag=0
> 
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce
>