From iesg-secretary@ietf.org Wed Jan 2 06:43:04 2013 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B01FE21F857C; Wed, 2 Jan 2013 06:43:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.492 X-Spam-Level: X-Spam-Status: No, score=-102.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25tjrXxUntoJ; Wed, 2 Jan 2013 06:43:04 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4DE021F856D; Wed, 2 Jan 2013 06:43:03 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130102144303.25143.30944.idtracker@ietfa.amsl.com> Date: Wed, 02 Jan 2013 06:43:03 -0800 Cc: nea@ietf.org Subject: [Nea] Last Call: (PT-EAP: Posture Transport (PT) Protocol For EAP Tunnel Methods) to Proposed Standard X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 14:43:05 -0000 The IESG has received a request from the Network Endpoint Assessment WG (nea) to consider the following document: - 'PT-EAP: Posture Transport (PT) Protocol For EAP Tunnel Methods' as Proposed Standard 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 2013-01-16. 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. Abstract This document specifies PT-EAP, an Extensible Authentication Protocol (EAP) based Posture Transport (PT) protocol designed to be used only inside a TLS protected EAP tunnel method. The document also describes the intended applicability of PT-EAP. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-nea-pt-eap/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-nea-pt-eap/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1889/ From iesg-secretary@ietf.org Wed Jan 2 12:46:24 2013 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20B2321F8716; Wed, 2 Jan 2013 12:46:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.494 X-Spam-Level: X-Spam-Status: No, score=-102.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yqpfXQI-LtfM; Wed, 2 Jan 2013 12:46:23 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3146121F87D4; Wed, 2 Jan 2013 12:46:22 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130102204622.15305.3505.idtracker@ietfa.amsl.com> Date: Wed, 02 Jan 2013 12:46:22 -0800 Cc: nea mailing list , nea chair , RFC Editor Subject: [Nea] Protocol Action: 'PT-TLS: A TLS-based Posture Transport (PT) Protocol' to Proposed Standard (draft-ietf-nea-pt-tls-08.txt) X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 20:46:24 -0000 The IESG has approved the following document: - 'PT-TLS: A TLS-based Posture Transport (PT) Protocol' (draft-ietf-nea-pt-tls-08.txt) as Proposed Standard This document is the product of the Network Endpoint Assessment Working Group. The IESG contact persons are Stephen Farrell and Sean Turner. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-nea-pt-tls/ Technical Summary PT-TLS is a protocol that carries NEA messages over TLS. By supporting a TLS transport, PT-TLS permits easy and efficient and monitoring of endpoint posture after an endpoint has been assigned an IP address. This contrasts with PT-EAP, which is more suitable for use before an endpoint has been assigned an IP address. Working Group Summary PT-TLS was carefully prepared and thoroughly reviewed within the NEA WG over a period of more than two years. After a call for proposals in October 2009, two proposals for a TLS-based transport were submitted to the NEA WG. The two were merged, taking the best features of each and removing unneeded features and elements. The resulting protocol received a careful review in the NEA WG including two WGLCs with comments from more than five people, some from industry and some from academia. There was clear WG consensus in favor of the resulting document with no cases of substantial disagreement. Document Quality While there are no known implementations of this exact protocol, NEA WG members have many years of implementation experience with other TLS-based posture protocols and brought their experience to bear in designing this protocol. Personnel The Document Shepherd is Steve Hanna. The Iresponsible Area Director is Stephen Farrell. RFC Editor Note Please delete the last paragraph of section 6, just before the start of 6.1 on the end of page 39. The paragraph to be deleted reads: This delegation of namespace is analogous to the technique used for OIDs. It can result in interoperability problems if vendors require support for particular vendor-specific values. However, such behavior is explicitly prohibited by this specification, which dictates that "Posture Transport Clients and Posture Transport Servers MUST NOT require support for particular vendor-specific PT-TLS Error Codes in order to interoperate with other PT-TLS compliant implementations (although implementations MAY permit administrators to configure them to require support for specific PT-TLS error codes)." Similar requirements are included for PT-TLS Message Types. From sm@resistor.net Tue Jan 8 23:31:20 2013 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5988921F86F6; Tue, 8 Jan 2013 23:31:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qEcz1Yg5bcXS; Tue, 8 Jan 2013 23:31:19 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 81AD621F878F; Tue, 8 Jan 2013 23:31:18 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r097VCPu007191; Tue, 8 Jan 2013 23:31:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1357716678; bh=G7d/Yxa+9TLn8tyYk07NNZajk1dfZUFm1cTgpKzYAwI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=GeAtWcw3RfRfTcHU6GBRRYVLP/dS3NTqcsm+o35nBnzSiPDIbpnqzILQqvECFfeoy kxDQiMxbt+STQK/P8EVAvJt5zt77Lh0Z4VLRD9QHveLSv8qduWCiZmuH4kM/hy3LUN coqK+CeNwHP7qSzuTYzzQ27Naddgc2h6lipEzPgE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1357716678; i=@resistor.net; bh=G7d/Yxa+9TLn8tyYk07NNZajk1dfZUFm1cTgpKzYAwI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=HqNDDH8qShpT8Xh1Pg2mLyucCHjG+vjAXaMJitsVJOGndeu+hw5KoG1JlJFe2pwMQ dFK2au3DyC8BqVaij0g4Wwq+AiY+DAMibgbayPmniEatJpBlTsGEXGuv5GUrc4WAuc uTF9CccIV6YBvcNFdCD4LbrZwQyftuDfK7+2i1cg= Message-Id: <6.2.5.6.2.20130108225436.0b31f008@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 08 Jan 2013 23:25:24 -0800 To: ietf@ietf.org From: SM In-Reply-To: <20130102144303.25143.30944.idtracker@ietfa.amsl.com> References: <20130102144303.25143.30944.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailman-Approved-At: Wed, 09 Jan 2013 03:20:51 -0800 Cc: nea@ietf.org Subject: Re: [Nea] Last Call: (PT-EAP: Posture Transport (PT) Protocol For EAP Tunnel Methods) to Proposed Standard X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 07:31:20 -0000 At 06:43 02-01-2013, The IESG wrote: >The IESG has received a request from the Network Endpoint Assessment WG >(nea) to consider the following document: >- 'PT-EAP: Posture Transport (PT) Protocol For EAP Tunnel Methods' > as Proposed Standard > >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 2013-01-16. Exceptionally, comments may be This is a quick comment. In Section 1: "The PT-EAP protocol MUST be protected by an outer TLS-based EAP tunnel method to ensure the exchanged messages are protected from a variety of threats from hostile intermediaries." The RFC 2119 boilerplate is after that "MUST". In Section 1.1: "This document does not define an architecture or reference model. Instead, it defines a protocol that works within the reference model described in the NEA Requirements specification [RFC5209]." The reference is informative. In Section 6: "PT-EAP does not directly utilize or require direct knowledge of any personally identifiable information (PII). PT-EAP will typically be used in conjunction with other EAP methods that provide for the user authentication (if bi-directional authentication is used), so the user's credentials are not directly seen by the PT-EAP inner method." Section 9 RFC 5209 mentions that: "However, in situations where the endpoint is owned by the user or where local laws protect the rights of the user even when using endpoints owned by another party, it is critical that the NEA implementation enable the user to control what endpoint information is shared with the network." I didn't find any information in the draft to assess the privacy implications. Are there any such implications? Regards, -sm From ncamwing@cisco.com Mon Jan 14 12:29:53 2013 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C35B21F8B25; Mon, 14 Jan 2013 12:29:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFqiXnyGZqT2; Mon, 14 Jan 2013 12:29:52 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id A6AC721F8AE3; Mon, 14 Jan 2013 12:29:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2440; q=dns/txt; s=iport; t=1358195392; x=1359404992; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=11LZnwKUd//44mubDxCSZptScAc9JcFyUfSSkf3QNhs=; b=O38Xc4E72J1cZfp5wetWDE8HLQpysCYwSPWXagGIHpqRGyTF0MH6wGW0 jcVOSfNKcLOdk2Fo4710+pIcMr8ISbeYXuOZY8+N/jDlIoJQzlm8laBvQ HTr+IPkD9nCJCTyQ6WnbMulWRQLAPBoewzwECU2D0K5qfDB07taRSrYJJ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAMRp9FCtJXG9/2dsb2JhbAA7CbpEgzYWc4IeAQEBBDo0CxIBCBIGChQFPRQDDgIEAQ0FCIgRtUWMfYNQYQOmVIJ1giQ X-IronPort-AV: E=Sophos;i="4.84,468,1355097600"; d="scan'208";a="162296379" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 14 Jan 2013 20:29:52 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r0EKTqM9007998 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 14 Jan 2013 20:29:52 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.197]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Mon, 14 Jan 2013 14:29:51 -0600 From: "Nancy Cam-Winget (ncamwing)" To: SM , "ietf@ietf.org" Thread-Topic: Last Call: (PT-EAP: Posture Transport (PT) Protocol For EAP Tunnel Methods) to Proposed Standard Thread-Index: AQHN8pXnKHR1ECWe3UGYdb6j/BleQw== Date: Mon, 14 Jan 2013 20:29:51 +0000 Message-ID: In-Reply-To: <6.2.5.6.2.20130108225436.0b31f008@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.154.12.73] Content-Type: text/plain; charset="us-ascii" Content-ID: <74F017BB889D714E8604217F4D7665FA@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nea@ietf.org" Subject: Re: [Nea] Last Call: (PT-EAP: Posture Transport (PT) Protocol For EAP Tunnel Methods) to Proposed Standard X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 20:29:53 -0000 Hi SM, Thanks for the thorough review of the draft. Please see comments below: On 1/8/13 11:25 PM, "SM" wrote: >At 06:43 02-01-2013, The IESG wrote: >>The IESG has received a request from the Network Endpoint Assessment WG >>(nea) to consider the following document: >>- 'PT-EAP: Posture Transport (PT) Protocol For EAP Tunnel Methods' >> as Proposed Standard >> >>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 2013-01-16. Exceptionally, comments may be > >This is a quick comment. > >In Section 1: > > "The PT-EAP protocol MUST be protected by an outer > TLS-based EAP tunnel method to ensure the exchanged messages are > protected from a variety of threats from hostile intermediaries." > >The RFC 2119 boilerplate is after that "MUST". [NCW] I can change it to a lower case "must", ok? > >In Section 1.1: > > "This document does not define an architecture or reference model. > Instead, it defines a protocol that works within the reference model > described in the NEA Requirements specification [RFC5209]." > >The reference is informative. [NCW] We can move the reference to be normative. > >In Section 6: > > "PT-EAP does not directly utilize or require direct knowledge of > any personally identifiable information (PII). PT-EAP will > typically be used in conjunction with other EAP methods > that provide for the user authentication (if bi-directional > authentication is used), so the user's credentials are not > directly seen by the PT-EAP inner method." > >Section 9 RFC 5209 mentions that: > > "However, in situations where the endpoint is owned by the user > or where local laws protect the rights of the user even when > using endpoints owned by another party, it is critical that the NEA > implementation enable the user to control what endpoint information > is shared with the network." > >I didn't find any information in the draft to assess the privacy >implications. Are there any such implications? [NCW] I don't think there are specifically for PT-EAP. The sections you reference Were to (in section 6) addressing the general EAP identity as PT-EAP is really not An "authentication" method. > >Regards, >-sm=20 > From shanna@juniper.net Mon Jan 14 14:19:00 2013 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 490B921F8B47; Mon, 14 Jan 2013 14:19:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.467 X-Spam-Level: X-Spam-Status: No, score=-103.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1lv2jHYUTg6q; Mon, 14 Jan 2013 14:18:59 -0800 (PST) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id B8F2721F84BC; Mon, 14 Jan 2013 14:18:57 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKUPSETDx/Xh4zV2B62sLV74McbkbAQXho@postini.com; Mon, 14 Jan 2013 14:18:57 PST Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 14 Jan 2013 14:18:05 -0800 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Mon, 14 Jan 2013 14:18:05 -0800 Received: from db3outboundpool.messaging.microsoft.com (213.199.154.144) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 14 Jan 2013 14:26:12 -0800 Received: from mail111-db3-R.bigfish.com (10.3.81.229) by DB3EHSOBE002.bigfish.com (10.3.84.22) with Microsoft SMTP Server id 14.1.225.23; Mon, 14 Jan 2013 22:18:00 +0000 Received: from mail111-db3 (localhost [127.0.0.1]) by mail111-db3-R.bigfish.com (Postfix) with ESMTP id 3CB9540092; Mon, 14 Jan 2013 22:18:00 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.234.117; KIP:(null); UIP:(null); (null); H:SN2PRD0510HT004.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -26 X-BigFish: PS-26(zz98dI9371I936eI542I1432I4015Izz1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL8275dhz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h1155h) Received: from mail111-db3 (localhost.localdomain [127.0.0.1]) by mail111-db3 (MessageSwitch) id 135820187838073_26643; Mon, 14 Jan 2013 22:17:58 +0000 (UTC) Received: from DB3EHSMHS013.bigfish.com (unknown [10.3.81.248]) by mail111-db3.bigfish.com (Postfix) with ESMTP id 0626318087C; Mon, 14 Jan 2013 22:17:58 +0000 (UTC) Received: from SN2PRD0510HT004.namprd05.prod.outlook.com (157.56.234.117) by DB3EHSMHS013.bigfish.com (10.3.87.113) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 14 Jan 2013 22:17:57 +0000 Received: from SN2PRD0510MB372.namprd05.prod.outlook.com ([169.254.9.200]) by SN2PRD0510HT004.namprd05.prod.outlook.com ([10.255.116.39]) with mapi id 14.16.0257.004; Mon, 14 Jan 2013 22:17:57 +0000 From: Stephen Hanna To: SM , "Nancy Cam-Winget (ncamwing)" Thread-Topic: Last Call: (PT-EAP: Posture Transport (PT) Protocol For EAP Tunnel Methods) to Proposed Standard Thread-Index: AQHN8qFy2guu4upU5k6s0KIIdnd2+phJYd4g Date: Mon, 14 Jan 2013 22:17:57 +0000 Message-ID: References: <6.2.5.6.2.20130108225436.0b31f008@resistor.net> <6.2.5.6.2.20130114123552.0a8fb9e8@resistor.net> In-Reply-To: <6.2.5.6.2.20130114123552.0a8fb9e8@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%RESISTOR.NET$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "ietf-privacy@ietf.org" , "nea@ietf.org" , "ietf@ietf.org" Subject: Re: [Nea] Last Call: (PT-EAP: Posture Transport (PT) Protocol For EAP Tunnel Methods) to Proposed Standard X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 22:19:00 -0000 Changing our reference to RFC 5209 to be normative may cause more problems than it solves. As RFC 3967 (BCP 97) says, > IETF procedures generally require that a standards track RFC > may not have a normative reference to another standards track > document at a lower maturity level or to a non standards track > specification (other than specifications from other standards > bodies). For example, a standards track document may not have > a normative reference to an informational RFC. Generally, documents that contain use cases or architectures are Informational. References to such documents in a standards track document are informative because referring to the use cases is not required in order to implement the standard. RFC 5209 lists use cases for NEA, describes a reference model for NEA, and includes requirements that the NEA protocols must meet. None of the requirements in RFC 5209 are requirements on implementations of the NEA protocols. Therefore, the PT-EAP spec should not include a normative reference to RFC 5209. And that's good, because RFC 5209 is an Informational RFC. If I've missed something (e.g. a reason why the reference should be normative), please explain it more clearly. Thanks, Steve > -----Original Message----- > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of > SM > Sent: Monday, January 14, 2013 4:34 PM > To: Nancy Cam-Winget (ncamwing) > Cc: ietf-privacy@ietf.org; nea@ietf.org; ietf@ietf.org > Subject: Re: Last Call: (PT-EAP: Posture > Transport (PT) Protocol For EAP Tunnel Methods) to Proposed Standard >=20 > Hi Nancy, > At 12:29 14-01-2013, Nancy Cam-Winget (ncamwing) wrote: > >[NCW] I can change it to a lower case "must", ok? >=20 > That's ok. >=20 > >[NCW] We can move the reference to be normative. >=20 > Ok. >=20 > >[NCW] I don't think there are specifically for PT-EAP. The sections > you > >reference > >Were to (in section 6) addressing the general EAP identity as PT-EAP > is > >really not > >An "authentication" method. >=20 > If I understood the above correctly PT-EAP does not transport any > information which could be used to identify an individual. That's > different from PT-EAP not being an "authenticated" method. Therefore, > there isn't much to say in terms of privacy considerations. >=20 > I suggest not including the following then: >=20 > "As a transport protocol, PT-EAP does not directly utilize or > require direct knowledge of any personally identifiable > information (PII)." >=20 > The draft can leverage the second paragraph of Section 6 as "privacy > considerations" instead of making a statement about PII. I'll copy > this message to ietf-privacy@ to get a better opinion. >=20 > In Section 6: >=20 > "Therefore, it is important for deployers to leverage these > protections in order to prevent disclosure of PII potentially > contained within PA-TNC or PB-TNC within the PT-EAP payload." >=20 > I suggest "information about an individual" instead of PII [1]. >=20 > Regards, > -sm >=20 > 1. I used the wording from draft-iab-privacy-considerations-06 >=20 From shanna@juniper.net Mon Jan 14 15:43:32 2013 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C26A321F8B8A for ; Mon, 14 Jan 2013 15:43:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.467 X-Spam-Level: X-Spam-Status: No, score=-103.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqIN6xjEX495 for ; Mon, 14 Jan 2013 15:43:31 -0800 (PST) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id CE13A21F8B7D for ; Mon, 14 Jan 2013 15:43:31 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKUPSYI7+9fQrJYBcHReIwg0fOpCbkVkXs@postini.com; Mon, 14 Jan 2013 15:43:31 PST Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 14 Jan 2013 15:41:12 -0800 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Mon, 14 Jan 2013 15:41:11 -0800 Received: from ch1outboundpool.messaging.microsoft.com (216.32.181.186) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 14 Jan 2013 15:49:18 -0800 Received: from mail152-ch1-R.bigfish.com (10.43.68.241) by CH1EHSOBE018.bigfish.com (10.43.70.68) with Microsoft SMTP Server id 14.1.225.23; Mon, 14 Jan 2013 23:41:10 +0000 Received: from mail152-ch1 (localhost [127.0.0.1]) by mail152-ch1-R.bigfish.com (Postfix) with ESMTP id 52F03602ED for ; Mon, 14 Jan 2013 23:41:10 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.234.117; KIP:(null); UIP:(null); (null); H:SN2PRD0510HT005.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -26 X-BigFish: PS-26(zz98dI9371I936eI542I1432I4015Izz1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033ILz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h1155h) Received: from mail152-ch1 (localhost.localdomain [127.0.0.1]) by mail152-ch1 (MessageSwitch) id 1358206869740159_10420; Mon, 14 Jan 2013 23:41:09 +0000 (UTC) Received: from CH1EHSMHS022.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.232]) by mail152-ch1.bigfish.com (Postfix) with ESMTP id B1701340126; Mon, 14 Jan 2013 23:41:09 +0000 (UTC) Received: from SN2PRD0510HT005.namprd05.prod.outlook.com (157.56.234.117) by CH1EHSMHS022.bigfish.com (10.43.70.22) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 14 Jan 2013 23:41:08 +0000 Received: from SN2PRD0510MB372.namprd05.prod.outlook.com ([169.254.9.200]) by SN2PRD0510HT005.namprd05.prod.outlook.com ([10.255.116.40]) with mapi id 14.16.0257.004; Mon, 14 Jan 2013 23:41:07 +0000 From: Stephen Hanna To: SM Thread-Topic: Last Call: (PT-EAP: Posture Transport (PT) Protocol For EAP Tunnel Methods) to Proposed Standard Thread-Index: AQHN8qkVhCoz431ACkeihi2vSxeV5phJd8hg Date: Mon, 14 Jan 2013 23:41:06 +0000 Message-ID: References: <6.2.5.6.2.20130108225436.0b31f008@resistor.net> <6.2.5.6.2.20130114123552.0a8fb9e8@resistor.net> <6.2.5.6.2.20130114143302.0a375f30@resistor.net> In-Reply-To: <6.2.5.6.2.20130114143302.0a375f30@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%RESISTOR.NET$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "nea@ietf.org" Subject: Re: [Nea] Last Call: (PT-EAP: Posture Transport (PT) Protocol For EAP Tunnel Methods) to Proposed Standard X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 23:43:32 -0000 SM wrote: > It's a matter of mentioning the down-ref in the Last Call announcement. I understand that we COULD request approval for a downward reference. We'd need to restart the IETF Last Call in order to do so but if that's the right thing to do, we can do it. I just don't see why we need a downref. Yes, you should understand the NEA reference model while building an implementation of PT-EAP. You also should understand the EAP architecture and PB-TNC and lots of other things. That doesn't mean that all those things should be normative references. RFC 5209 doesn't include ANY normative text that would affect implementers of PT-EAP. An informative reference seems more appropriate to me. And that's what we did for all the other NEA specs (PA-TNC, PB-TNC, and PT-TLS). PB-TNC (RFC 5793) includes basically the same language as PT-EAP: 1.1. Prerequisites This document does not define an architecture or reference model. Instead, it defines a protocol that works within the reference model described in the NEA Requirements specification [8]. The reader is assumed to be thoroughly familiar with that document. No familiarity with TCG specifications is assumed. Still, I know that the IETF process can be unpredictable. If we now think that we need to have a normative reference in this spec, we can change it and run the IETF Last Call process again, requesting approval for a downref to RFC 5209. What is the sense of the Working Group? Any guidance from the ADs? Thanks, Steve > -----Original Message----- > From: SM [mailto:sm@resistor.net] > Sent: Monday, January 14, 2013 5:47 PM > To: Stephen Hanna > Cc: nea@ietf.org; Nancy Cam-Winget (ncamwing) > Subject: RE: Last Call: (PT-EAP: Posture > Transport (PT) Protocol For EAP Tunnel Methods) to Proposed Standard >=20 > Hi Stephen, > At 14:17 14-01-2013, Stephen Hanna wrote: > >Changing our reference to RFC 5209 to be normative may cause > >more problems than it solves. As RFC 3967 (BCP 97) says, >=20 > Yes. >=20 > From Section 1.1: >=20 > "The reader is assumed to be thoroughly familiar with that > document." (RFC 5209) >=20 > > > IETF procedures generally require that a standards track RFC > > > may not have a normative reference to another standards track > > > document at a lower maturity level or to a non standards track > > > specification (other than specifications from other standards > > > bodies). For example, a standards track document may not have > > > a normative reference to an informational RFC. >=20 > It's a matter of mentioning the down-ref in the Last Call announcement. >=20 > >If I've missed something (e.g. a reason why the reference should > >be normative), please explain it more clearly. >=20 > See above. I flagged it as the matter may be raised as an issue. I > am ok with whatever the WG decides. >=20 > Regards, > -sm >=20 From stephen.farrell@cs.tcd.ie Mon Jan 14 16:07:33 2013 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B53421F8B75 for ; Mon, 14 Jan 2013 16:07:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 66n5aqORfCYB for ; Mon, 14 Jan 2013 16:07:31 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5453F21F8B70 for ; Mon, 14 Jan 2013 16:07:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9207EBE47; Tue, 15 Jan 2013 00:07:09 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vc3J2YuHUM2x; Tue, 15 Jan 2013 00:07:08 +0000 (GMT) Received: from [10.87.48.11] (unknown [86.41.50.151]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0AFCBBE3F; Tue, 15 Jan 2013 00:07:07 +0000 (GMT) Message-ID: <50F49DAB.9080909@cs.tcd.ie> Date: Tue, 15 Jan 2013 00:07:07 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Stephen Hanna References: <6.2.5.6.2.20130108225436.0b31f008@resistor.net> <6.2.5.6.2.20130114123552.0a8fb9e8@resistor.net> <6.2.5.6.2.20130114143302.0a375f30@resistor.net> In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: SM , "nea@ietf.org" Subject: Re: [Nea] Last Call: (PT-EAP: Posture Transport (PT) Protocol For EAP Tunnel Methods) to Proposed Standard X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 00:07:33 -0000 Hiya, On 01/14/2013 11:41 PM, Stephen Hanna wrote: > SM wrote: >> It's a matter of mentioning the down-ref in the Last Call announcement. > > I understand that we COULD request approval for a downward reference. > We'd need to restart the IETF Last Call in order to do so but if that's > the right thing to do, we can do it. > > I just don't see why we need a downref. Yes, you should understand the > NEA reference model while building an implementation of PT-EAP. You also > should understand the EAP architecture and PB-TNC and lots of other things. > That doesn't mean that all those things should be normative references. > RFC 5209 doesn't include ANY normative text that would affect implementers > of PT-EAP. An informative reference seems more appropriate to me. And > that's what we did for all the other NEA specs (PA-TNC, PB-TNC, and > PT-TLS). PB-TNC (RFC 5793) includes basically the same language as PT-EAP: > > 1.1. Prerequisites > > This document does not define an architecture or reference model. > Instead, it defines a protocol that works within the reference model > described in the NEA Requirements specification [8]. The reader is > assumed to be thoroughly familiar with that document. No familiarity > with TCG specifications is assumed. > > Still, I know that the IETF process can be unpredictable. If we > now think that we need to have a normative reference in this spec, > we can change it and run the IETF Last Call process again, requesting > approval for a downref to RFC 5209. > > What is the sense of the Working Group? Any guidance from the ADs? I bet you know:-) Ignore it and push on. If we get stuck then we go back to IETF LC then and fix. The precedent in the WG should be enough to see it through I'd say esp since PT-TLS is so recent (still in the RFC editor queue) with precisely the same reference. Neither IETF LC called out this out as a downref. SM does have a point, but OTOH so do you, and yes the IESG is fickle about stuff like this, and BCP97 doesn't really deal with requirement or framework RFCs (I guess those are a subsequent fad;-). And in this case, 5209 is requirements plus the overview and I think you can credibly say that in reality a coder who's gotten as far as coding up PT-EAP already does know the overview, and the reqiurements are not relevant for that coder, so this is a purely process problem if it is a problem of any sort and does no harm to the Internet. S. > > Thanks, > > Steve > >> -----Original Message----- >> From: SM [mailto:sm@resistor.net] >> Sent: Monday, January 14, 2013 5:47 PM >> To: Stephen Hanna >> Cc: nea@ietf.org; Nancy Cam-Winget (ncamwing) >> Subject: RE: Last Call: (PT-EAP: Posture >> Transport (PT) Protocol For EAP Tunnel Methods) to Proposed Standard >> >> Hi Stephen, >> At 14:17 14-01-2013, Stephen Hanna wrote: >>> Changing our reference to RFC 5209 to be normative may cause >>> more problems than it solves. As RFC 3967 (BCP 97) says, >> >> Yes. >> >> From Section 1.1: >> >> "The reader is assumed to be thoroughly familiar with that >> document." (RFC 5209) >> >>>> IETF procedures generally require that a standards track RFC >>>> may not have a normative reference to another standards track >>>> document at a lower maturity level or to a non standards track >>>> specification (other than specifications from other standards >>>> bodies). For example, a standards track document may not have >>>> a normative reference to an informational RFC. >> >> It's a matter of mentioning the down-ref in the Last Call announcement. >> >>> If I've missed something (e.g. a reason why the reference should >>> be normative), please explain it more clearly. >> >> See above. I flagged it as the matter may be raised as an issue. I >> am ok with whatever the WG decides. >> >> Regards, >> -sm >> > > > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www.ietf.org/mailman/listinfo/nea > > From shanna@juniper.net Mon Jan 14 16:24:42 2013 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D24B921F8824 for ; Mon, 14 Jan 2013 16:24:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.467 X-Spam-Level: X-Spam-Status: No, score=-103.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ord4YJKQGP2c for ; Mon, 14 Jan 2013 16:24:42 -0800 (PST) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id 04CED21F8780 for ; Mon, 14 Jan 2013 16:24:41 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKUPShyUhafFWWLiKYl+b5q+qREcEgc5lm@postini.com; Mon, 14 Jan 2013 16:24:42 PST Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 14 Jan 2013 16:21:15 -0800 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Mon, 14 Jan 2013 16:21:15 -0800 Received: from va3outboundpool.messaging.microsoft.com (216.32.180.30) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 14 Jan 2013 16:29:22 -0800 Received: from mail271-va3-R.bigfish.com (10.7.14.246) by VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id 14.1.225.23; Tue, 15 Jan 2013 00:21:14 +0000 Received: from mail271-va3 (localhost [127.0.0.1]) by mail271-va3-R.bigfish.com (Postfix) with ESMTP id 39770800105 for ; Tue, 15 Jan 2013 00:21:14 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.234.117; KIP:(null); UIP:(null); (null); H:SN2PRD0510HT001.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -29 X-BigFish: PS-29(zzbb2dI98dI9371I936eI1102I542I1432I4015I1447Izz1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL8275dhz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h1155h) Received: from mail271-va3 (localhost.localdomain [127.0.0.1]) by mail271-va3 (MessageSwitch) id 135820927233591_25729; Tue, 15 Jan 2013 00:21:12 +0000 (UTC) Received: from VA3EHSMHS020.bigfish.com (unknown [10.7.14.250]) by mail271-va3.bigfish.com (Postfix) with ESMTP id ED026A80090; Tue, 15 Jan 2013 00:21:11 +0000 (UTC) Received: from SN2PRD0510HT001.namprd05.prod.outlook.com (157.56.234.117) by VA3EHSMHS020.bigfish.com (10.7.99.30) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 15 Jan 2013 00:21:11 +0000 Received: from SN2PRD0510MB372.namprd05.prod.outlook.com ([169.254.9.200]) by SN2PRD0510HT001.namprd05.prod.outlook.com ([10.255.116.36]) with mapi id 14.16.0257.004; Tue, 15 Jan 2013 00:21:10 +0000 From: Stephen Hanna To: Stephen Farrell Thread-Topic: [Nea] Last Call: (PT-EAP: Posture Transport (PT) Protocol For EAP Tunnel Methods) to Proposed Standard Thread-Index: AQHN8rRM/ZgvNLI/EUSEcjy0HBvFdZhJhZHg Date: Tue, 15 Jan 2013 00:21:10 +0000 Message-ID: References: <6.2.5.6.2.20130108225436.0b31f008@resistor.net> <6.2.5.6.2.20130114123552.0a8fb9e8@resistor.net> <6.2.5.6.2.20130114143302.0a375f30@resistor.net> <50F49DAB.9080909@cs.tcd.ie> In-Reply-To: <50F49DAB.9080909@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%CS.TCD.IE$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%RESISTOR.NET$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: SM , "nea@ietf.org" Subject: Re: [Nea] Last Call: (PT-EAP: Posture Transport (PT) Protocol For EAP Tunnel Methods) to Proposed Standard X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 00:24:42 -0000 Stephen, Thanks for the guidance. As you recommend, we'll proceed without this change for now. If it becomes a problem, we'll cycle back and do the downref thing. Take care, Steve > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Monday, January 14, 2013 7:07 PM > To: Stephen Hanna > Cc: SM; nea@ietf.org > Subject: Re: [Nea] Last Call: (PT-EAP: > Posture Transport (PT) Protocol For EAP Tunnel Methods) to Proposed > Standard >=20 >=20 > Hiya, >=20 > On 01/14/2013 11:41 PM, Stephen Hanna wrote: > > SM wrote: > >> It's a matter of mentioning the down-ref in the Last Call > announcement. > > > > I understand that we COULD request approval for a downward reference. > > We'd need to restart the IETF Last Call in order to do so but if > that's > > the right thing to do, we can do it. > > > > I just don't see why we need a downref. Yes, you should understand > the > > NEA reference model while building an implementation of PT-EAP. You > also > > should understand the EAP architecture and PB-TNC and lots of other > things. > > That doesn't mean that all those things should be normative > references. > > RFC 5209 doesn't include ANY normative text that would affect > implementers > > of PT-EAP. An informative reference seems more appropriate to me. And > > that's what we did for all the other NEA specs (PA-TNC, PB-TNC, and > > PT-TLS). PB-TNC (RFC 5793) includes basically the same language as > PT-EAP: > > > > 1.1. Prerequisites > > > > This document does not define an architecture or reference model. > > Instead, it defines a protocol that works within the reference > model > > described in the NEA Requirements specification [8]. The reader > is > > assumed to be thoroughly familiar with that document. No > familiarity > > with TCG specifications is assumed. > > > > Still, I know that the IETF process can be unpredictable. If we > > now think that we need to have a normative reference in this spec, > > we can change it and run the IETF Last Call process again, requesting > > approval for a downref to RFC 5209. > > > > What is the sense of the Working Group? Any guidance from the ADs? >=20 > I bet you know:-) >=20 > Ignore it and push on. If we get stuck then we go back to IETF LC > then and fix. The precedent in the WG should be enough to see it > through I'd say esp since PT-TLS is so recent (still in the RFC > editor queue) with precisely the same reference. Neither IETF > LC called out this out as a downref. >=20 > SM does have a point, but OTOH so do you, and yes the IESG is > fickle about stuff like this, and BCP97 doesn't really deal with > requirement or framework RFCs (I guess those are a subsequent > fad;-). And in this case, 5209 is requirements plus the > overview and I think you can credibly say that in reality a > coder who's gotten as far as coding up PT-EAP already does > know the overview, and the reqiurements are not relevant > for that coder, so this is a purely process problem if it > is a problem of any sort and does no harm to the Internet. >=20 > S. >=20 > > > > Thanks, > > > > Steve > > > >> -----Original Message----- > >> From: SM [mailto:sm@resistor.net] > >> Sent: Monday, January 14, 2013 5:47 PM > >> To: Stephen Hanna > >> Cc: nea@ietf.org; Nancy Cam-Winget (ncamwing) > >> Subject: RE: Last Call: (PT-EAP: > Posture > >> Transport (PT) Protocol For EAP Tunnel Methods) to Proposed Standard > >> > >> Hi Stephen, > >> At 14:17 14-01-2013, Stephen Hanna wrote: > >>> Changing our reference to RFC 5209 to be normative may cause > >>> more problems than it solves. As RFC 3967 (BCP 97) says, > >> > >> Yes. > >> > >> From Section 1.1: > >> > >> "The reader is assumed to be thoroughly familiar with that > >> document." (RFC 5209) > >> > >>>> IETF procedures generally require that a standards track RFC > >>>> may not have a normative reference to another standards track > >>>> document at a lower maturity level or to a non standards track > >>>> specification (other than specifications from other standards > >>>> bodies). For example, a standards track document may not have > >>>> a normative reference to an informational RFC. > >> > >> It's a matter of mentioning the down-ref in the Last Call > announcement. > >> > >>> If I've missed something (e.g. a reason why the reference should > >>> be normative), please explain it more clearly. > >> > >> See above. I flagged it as the matter may be raised as an issue. I > >> am ok with whatever the WG decides. > >> > >> Regards, > >> -sm > >> > > > > > > _______________________________________________ > > Nea mailing list > > Nea@ietf.org > > https://www.ietf.org/mailman/listinfo/nea > > > > From stephen.farrell@cs.tcd.ie Mon Jan 14 16:27:28 2013 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB4B21F8B62 for ; Mon, 14 Jan 2013 16:27:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6EGhtybvuvn for ; Mon, 14 Jan 2013 16:27:27 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 37F7F21F8824 for ; Mon, 14 Jan 2013 16:27:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 10000BE47; Tue, 15 Jan 2013 00:27:05 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5+hCkJsP2-r; Tue, 15 Jan 2013 00:27:02 +0000 (GMT) Received: from [10.87.48.8] (unknown [86.41.50.151]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A8FD0BE3F; Tue, 15 Jan 2013 00:27:02 +0000 (GMT) References: <6.2.5.6.2.20130108225436.0b31f008@resistor.net> <6.2.5.6.2.20130114123552.0a8fb9e8@resistor.net> <6.2.5.6.2.20130114143302.0a375f30@resistor.net> <50F49DAB.9080909@cs.tcd.ie> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (10A523) From: Stephen Farrell Date: Tue, 15 Jan 2013 00:27:00 +0000 To: Stephen Hanna Cc: SM , "nea@ietf.org" Subject: Re: [Nea] Last Call: (PT-EAP: Posture Transport (PT) Protocol For EAP Tunnel Methods) to Proposed Standard X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 00:27:28 -0000 On 15 Jan 2013, at 00:21, Stephen Hanna wrote: > Stephen, > > Thanks for the guidance. As you recommend, we'll proceed > without this change for now. If it becomes a problem, > we'll cycle back and do the downref thing. Grand. SM - I can put a note on the ballot so other ADs know about it. S > > Take care, > > Steve > >> -----Original Message----- >> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] >> Sent: Monday, January 14, 2013 7:07 PM >> To: Stephen Hanna >> Cc: SM; nea@ietf.org >> Subject: Re: [Nea] Last Call: (PT-EAP: >> Posture Transport (PT) Protocol For EAP Tunnel Methods) to Proposed >> Standard >> >> >> Hiya, >> >> On 01/14/2013 11:41 PM, Stephen Hanna wrote: >>> SM wrote: >>>> It's a matter of mentioning the down-ref in the Last Call >> announcement. >>> >>> I understand that we COULD request approval for a downward reference. >>> We'd need to restart the IETF Last Call in order to do so but if >> that's >>> the right thing to do, we can do it. >>> >>> I just don't see why we need a downref. Yes, you should understand >> the >>> NEA reference model while building an implementation of PT-EAP. You >> also >>> should understand the EAP architecture and PB-TNC and lots of other >> things. >>> That doesn't mean that all those things should be normative >> references. >>> RFC 5209 doesn't include ANY normative text that would affect >> implementers >>> of PT-EAP. An informative reference seems more appropriate to me. And >>> that's what we did for all the other NEA specs (PA-TNC, PB-TNC, and >>> PT-TLS). PB-TNC (RFC 5793) includes basically the same language as >> PT-EAP: >>> >>> 1.1. Prerequisites >>> >>> This document does not define an architecture or reference model. >>> Instead, it defines a protocol that works within the reference >> model >>> described in the NEA Requirements specification [8]. The reader >> is >>> assumed to be thoroughly familiar with that document. No >> familiarity >>> with TCG specifications is assumed. >>> >>> Still, I know that the IETF process can be unpredictable. If we >>> now think that we need to have a normative reference in this spec, >>> we can change it and run the IETF Last Call process again, requesting >>> approval for a downref to RFC 5209. >>> >>> What is the sense of the Working Group? Any guidance from the ADs? >> >> I bet you know:-) >> >> Ignore it and push on. If we get stuck then we go back to IETF LC >> then and fix. The precedent in the WG should be enough to see it >> through I'd say esp since PT-TLS is so recent (still in the RFC >> editor queue) with precisely the same reference. Neither IETF >> LC called out this out as a downref. >> >> SM does have a point, but OTOH so do you, and yes the IESG is >> fickle about stuff like this, and BCP97 doesn't really deal with >> requirement or framework RFCs (I guess those are a subsequent >> fad;-). And in this case, 5209 is requirements plus the >> overview and I think you can credibly say that in reality a >> coder who's gotten as far as coding up PT-EAP already does >> know the overview, and the reqiurements are not relevant >> for that coder, so this is a purely process problem if it >> is a problem of any sort and does no harm to the Internet. >> >> S. >> >>> >>> Thanks, >>> >>> Steve >>> >>>> -----Original Message----- >>>> From: SM [mailto:sm@resistor.net] >>>> Sent: Monday, January 14, 2013 5:47 PM >>>> To: Stephen Hanna >>>> Cc: nea@ietf.org; Nancy Cam-Winget (ncamwing) >>>> Subject: RE: Last Call: (PT-EAP: >> Posture >>>> Transport (PT) Protocol For EAP Tunnel Methods) to Proposed Standard >>>> >>>> Hi Stephen, >>>> At 14:17 14-01-2013, Stephen Hanna wrote: >>>>> Changing our reference to RFC 5209 to be normative may cause >>>>> more problems than it solves. As RFC 3967 (BCP 97) says, >>>> >>>> Yes. >>>> >>>> From Section 1.1: >>>> >>>> "The reader is assumed to be thoroughly familiar with that >>>> document." (RFC 5209) >>>> >>>>>> IETF procedures generally require that a standards track RFC >>>>>> may not have a normative reference to another standards track >>>>>> document at a lower maturity level or to a non standards track >>>>>> specification (other than specifications from other standards >>>>>> bodies). For example, a standards track document may not have >>>>>> a normative reference to an informational RFC. >>>> >>>> It's a matter of mentioning the down-ref in the Last Call >> announcement. >>>> >>>>> If I've missed something (e.g. a reason why the reference should >>>>> be normative), please explain it more clearly. >>>> >>>> See above. I flagged it as the matter may be raised as an issue. I >>>> am ok with whatever the WG decides. >>>> >>>> Regards, >>>> -sm >>> >>> >>> _______________________________________________ >>> Nea mailing list >>> Nea@ietf.org >>> https://www.ietf.org/mailman/listinfo/nea > > From sm@resistor.net Mon Jan 14 13:42:09 2013 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB34321F88C4; Mon, 14 Jan 2013 13:42:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6eAt+uc28D9; Mon, 14 Jan 2013 13:42:06 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 33C5621F888C; Mon, 14 Jan 2013 13:42:06 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r0ELfwQk015885; Mon, 14 Jan 2013 13:42:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1358199724; bh=4tFNIUI0YQa3tG2dr+E8nheKffWwn8ncoviWILR2i9o=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=rd2rvXJ0vL0p5RWgX9wb2g0RbVdi2tMZA6EbKHDFdz1jSIp94ULp9SrGThMMUUCON 3i+qlyw5Hln6FSP8JUdUH65gkPMPZZw/gzhDngAh9hphdqYOcxCzKxDiBf3IaqpMmK w48IhyzeLqF8XWJ/L9hEjAqxVOq2I0f/Kva0DsW8= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1358199724; i=@resistor.net; bh=4tFNIUI0YQa3tG2dr+E8nheKffWwn8ncoviWILR2i9o=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=RffMZ2pKrof4JRPTJFqvENZNUFqYs0Qh/Cf6t0tm6fsKXPeZxloSvjTZVW8MqrSVU G0X1OgOh/aVBL3sPlcGTHWydQZB4ZJ0Gwt6IStpr2CChZyxKAu8XhCqrW2PzBgSCty LAMJApQ6XsUktEBhI7ryfpYUHlgt4exSPyjacE4E= Message-Id: <6.2.5.6.2.20130114123552.0a8fb9e8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 14 Jan 2013 13:34:09 -0800 To: "Nancy Cam-Winget (ncamwing)" From: SM In-Reply-To: References: <6.2.5.6.2.20130108225436.0b31f008@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailman-Approved-At: Mon, 14 Jan 2013 17:45:23 -0800 Cc: ietf-privacy@ietf.org, nea@ietf.org, ietf@ietf.org Subject: Re: [Nea] Last Call: (PT-EAP: Posture Transport (PT) Protocol For EAP Tunnel Methods) to Proposed Standard X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 21:42:09 -0000 Hi Nancy, At 12:29 14-01-2013, Nancy Cam-Winget (ncamwing) wrote: >[NCW] I can change it to a lower case "must", ok? That's ok. >[NCW] We can move the reference to be normative. Ok. >[NCW] I don't think there are specifically for PT-EAP. The sections you >reference >Were to (in section 6) addressing the general EAP identity as PT-EAP is >really not >An "authentication" method. If I understood the above correctly PT-EAP does not transport any information which could be used to identify an individual. That's different from PT-EAP not being an "authenticated" method. Therefore, there isn't much to say in terms of privacy considerations. I suggest not including the following then: "As a transport protocol, PT-EAP does not directly utilize or require direct knowledge of any personally identifiable information (PII)." The draft can leverage the second paragraph of Section 6 as "privacy considerations" instead of making a statement about PII. I'll copy this message to ietf-privacy@ to get a better opinion. In Section 6: "Therefore, it is important for deployers to leverage these protections in order to prevent disclosure of PII potentially contained within PA-TNC or PB-TNC within the PT-EAP payload." I suggest "information about an individual" instead of PII [1]. Regards, -sm 1. I used the wording from draft-iab-privacy-considerations-06 From sm@resistor.net Mon Jan 14 14:46:46 2013 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE5DF21F8B46 for ; Mon, 14 Jan 2013 14:46:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vGKBQY8cusig for ; Mon, 14 Jan 2013 14:46:46 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3615921F8B38 for ; Mon, 14 Jan 2013 14:46:46 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r0EMkdgs018664; Mon, 14 Jan 2013 14:46:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1358203604; bh=Grn4qF0mAoEUpoEE3ho9YZJpkYwYX0PwOfxLPpbjEYY=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=rI5XsScd1DjMgUFMtuwURiOJCqXReEynqs8lWuwn5PJ6sTWrY9zjEOB5pt5MXdbeY REGUmTbny+QZSZNSS+2b33tj7ug6i5sRC84cLGgA8oiGbvExX/im2UeW1JVBKEzKJy LgbwAUzqltnIqHmkArPGAsIcQnd+mj5urPq0NPBo= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1358203604; i=@resistor.net; bh=Grn4qF0mAoEUpoEE3ho9YZJpkYwYX0PwOfxLPpbjEYY=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=41D0KpoPvg2mpXdceCj5FBHUZORdImKVhng0SjxyAkBvZJ5MZA9VTfKHhhEaGuwfK kbUPJDrMKusW0eQEwt++1kKwXrREolfU2aV9kWehy9jSvVaVzt0qsaC6AR9ESTerUs Pc+bfHUjb2wNZHQ1JzRE/wJcQ63OW15cncP+vi2Y= Message-Id: <6.2.5.6.2.20130114143302.0a375f30@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 14 Jan 2013 14:46:30 -0800 To: Stephen Hanna From: SM In-Reply-To: References: <6.2.5.6.2.20130108225436.0b31f008@resistor.net> <6.2.5.6.2.20130114123552.0a8fb9e8@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailman-Approved-At: Mon, 14 Jan 2013 17:45:23 -0800 Cc: nea@ietf.org Subject: Re: [Nea] Last Call: (PT-EAP: Posture Transport (PT) Protocol For EAP Tunnel Methods) to Proposed Standard X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 22:46:46 -0000 Hi Stephen, At 14:17 14-01-2013, Stephen Hanna wrote: >Changing our reference to RFC 5209 to be normative may cause >more problems than it solves. As RFC 3967 (BCP 97) says, Yes. From Section 1.1: "The reader is assumed to be thoroughly familiar with that document." (RFC 5209) > > IETF procedures generally require that a standards track RFC > > may not have a normative reference to another standards track > > document at a lower maturity level or to a non standards track > > specification (other than specifications from other standards > > bodies). For example, a standards track document may not have > > a normative reference to an informational RFC. It's a matter of mentioning the down-ref in the Last Call announcement. >If I've missed something (e.g. a reason why the reference should >be normative), please explain it more clearly. See above. I flagged it as the matter may be raised as an issue. I am ok with whatever the WG decides. Regards, -sm From sm@resistor.net Mon Jan 14 17:13:35 2013 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC37B21F87AB for ; Mon, 14 Jan 2013 17:13:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l65kIrm1rJS4 for ; Mon, 14 Jan 2013 17:13:32 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id EEC2821F8B46 for ; Mon, 14 Jan 2013 17:13:31 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r0F1C70L005569; Mon, 14 Jan 2013 17:12:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1358212333; bh=oL/ki5qidsMZkVWLAl4aU7CYUydr8DcaGNbS8QfFLQw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=SeFCZ554hMWxuQTVulFv52qXsxGnCYAh1OueBt5PWw+ZcnFrUVzJUCBbvpiupVXvE wBwoEAN7odHFxR9rYLGz746KT4IgTWkxsm+be70B83xI9EYLOI08a25zalYuu+hIyw tq0xltNZ3zpJZyVTBos3BfRECSmKk+LJOdF2AWBg= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1358212333; i=@resistor.net; bh=oL/ki5qidsMZkVWLAl4aU7CYUydr8DcaGNbS8QfFLQw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=fQ96SpuHseNYCLSfccwn/CK6ZWoeeQQhWy6XNDOhIlAe58QTZ7M8nlVmeAmx1B579 /LkQ8YS37+fT/m4gGYdoadat+VI+I1x906GZ+ZwiXtKNbiO9ryexV1hKvZ9Mp2gfoA sf9vXWcH3bNbZp6USRSTuc5i89NcZen0TItYpMJs= Message-Id: <6.2.5.6.2.20130114165839.0939d640@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 14 Jan 2013 17:11:52 -0800 To: Stephen Farrell From: SM In-Reply-To: References: <6.2.5.6.2.20130108225436.0b31f008@resistor.net> <6.2.5.6.2.20130114123552.0a8fb9e8@resistor.net> <6.2.5.6.2.20130114143302.0a375f30@resistor.net> <50F49DAB.9080909@cs.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailman-Approved-At: Mon, 14 Jan 2013 17:45:23 -0800 Cc: nea@ietf.org Subject: Re: [Nea] Last Call: (PT-EAP: Posture Transport (PT) Protocol For EAP Tunnel Methods) to Proposed Standard X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 01:13:35 -0000 Hi Stephen, At 16:27 14-01-2013, Stephen Farrell wrote: >Grand. SM - I can put a note on the ballot so other ADs know about it. I suggest waiting for the AppsDir review. Regards, -sm From internet-drafts@ietf.org Fri Jan 25 19:43:19 2013 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD9221F842F; Fri, 25 Jan 2013 19:43:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.505 X-Spam-Level: X-Spam-Status: No, score=-102.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VwfcH2VcivjA; Fri, 25 Jan 2013 19:43:18 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3F2D21F843A; Fri, 25 Jan 2013 19:43:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130126034318.16067.98459.idtracker@ietfa.amsl.com> Date: Fri, 25 Jan 2013 19:43:18 -0800 Cc: nea@ietf.org Subject: [Nea] I-D Action: draft-ietf-nea-pt-eap-07.txt X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jan 2013 03:43:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network Endpoint Assessment Working Group= of the IETF. Title : PT-EAP: Posture Transport (PT) Protocol For EAP Tunnel M= ethods Author(s) : Nancy Cam-Winget Paul Sangster Filename : draft-ietf-nea-pt-eap-07.txt Pages : 20 Date : 2013-01-25 Abstract: This document specifies PT-EAP, an Extensible Authentication Protocol (EAP) based Posture Transport (PT) protocol designed to be used only inside a TLS protected EAP tunnel method. The document also describes the intended applicability of PT-EAP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-nea-pt-eap There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-nea-pt-eap-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-nea-pt-eap-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Sun Jan 27 20:27:08 2013 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0051021F871F; Sun, 27 Jan 2013 20:27:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.518 X-Spam-Level: X-Spam-Status: No, score=-102.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pi5SZnC-XWCD; Sun, 27 Jan 2013 20:27:07 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9263A21F853A; Sun, 27 Jan 2013 20:27:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130128042707.12596.94379.idtracker@ietfa.amsl.com> Date: Sun, 27 Jan 2013 20:27:07 -0800 Cc: nea@ietf.org Subject: [Nea] I-D Action: draft-ietf-nea-pt-eap-08.txt X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 04:27:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network Endpoint Assessment Working Group= of the IETF. Title : PT-EAP: Posture Transport (PT) Protocol For EAP Tunnel M= ethods Author(s) : Nancy Cam-Winget Paul Sangster Filename : draft-ietf-nea-pt-eap-08.txt Pages : 20 Date : 2013-01-27 Abstract: This document specifies PT-EAP, an Extensible Authentication Protocol (EAP) based Posture Transport (PT) protocol designed to be used only inside a TLS protected EAP tunnel method. The document also describes the intended applicability of PT-EAP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-nea-pt-eap There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-nea-pt-eap-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-nea-pt-eap-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From shanna@juniper.net Mon Jan 28 05:46:28 2013 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A1B721F8444 for ; Mon, 28 Jan 2013 05:46:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.467 X-Spam-Level: X-Spam-Status: No, score=-103.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVONEgHks9Xs for ; Mon, 28 Jan 2013 05:46:27 -0800 (PST) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id 9F23F21F842B for ; Mon, 28 Jan 2013 05:46:27 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKUQaBM92lGENTSyealdYRWgW258oxLGxk@postini.com; Mon, 28 Jan 2013 05:46:27 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 28 Jan 2013 05:43:47 -0800 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Mon, 28 Jan 2013 05:43:46 -0800 Received: from CH1EHSOBE020.bigfish.com (216.32.181.184) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 28 Jan 2013 05:51:42 -0800 Received: from mail228-ch1-R.bigfish.com (10.43.68.241) by CH1EHSOBE020.bigfish.com (10.43.70.77) with Microsoft SMTP Server id 14.1.225.23; Mon, 28 Jan 2013 13:43:46 +0000 Received: from mail228-ch1 (localhost [127.0.0.1]) by mail228-ch1-R.bigfish.com (Postfix) with ESMTP id E49CC8C0084 for ; Mon, 28 Jan 2013 13:43:45 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.236.101; KIP:(null); UIP:(null); (null); H:BY2PRD0510HT005.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -26 X-BigFish: PS-26(zz9371I936eI1b0bI542I1432I4015Izz1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL17326ah8275dhz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1155h) Received: from mail228-ch1 (localhost.localdomain [127.0.0.1]) by mail228-ch1 (MessageSwitch) id 1359380623603233_5894; Mon, 28 Jan 2013 13:43:43 +0000 (UTC) Received: from CH1EHSMHS025.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.238]) by mail228-ch1.bigfish.com (Postfix) with ESMTP id 8DFBB20055 for ; Mon, 28 Jan 2013 13:43:43 +0000 (UTC) Received: from BY2PRD0510HT005.namprd05.prod.outlook.com (157.56.236.101) by CH1EHSMHS025.bigfish.com (10.43.70.25) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 28 Jan 2013 13:43:38 +0000 Received: from BY2PRD0510MB366.namprd05.prod.outlook.com ([169.254.5.169]) by BY2PRD0510HT005.namprd05.prod.outlook.com ([10.255.84.40]) with mapi id 14.16.0263.000; Mon, 28 Jan 2013 13:43:37 +0000 From: Stephen Hanna To: "nea@ietf.org" Thread-Topic: Latest Updates to PT-EAP Thread-Index: AQHN/V15jLWGpjAhjUOK3zZfWHOpHg== Date: Mon, 28 Jan 2013 13:43:37 +0000 Message-ID: References: <20130128042707.12596.94379.idtracker@ietfa.amsl.com> In-Reply-To: <20130128042707.12596.94379.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Subject: [Nea] Latest Updates to PT-EAP X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 13:46:28 -0000 In case it's not clear, the two updates to PT-EAP over the last few days were made to address IETF LC comments. This latest draft will now go to the IESG. FYI. Thanks, Steve > -----Original Message----- > From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Sunday, January 27, 2013 11:27 PM > To: i-d-announce@ietf.org > Cc: nea@ietf.org > Subject: [Nea] I-D Action: draft-ietf-nea-pt-eap-08.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Network Endpoint Assessment Working > Group of the IETF. >=20 > Title : PT-EAP: Posture Transport (PT) Protocol For EAP > Tunnel Methods > Author(s) : Nancy Cam-Winget > Paul Sangster > Filename : draft-ietf-nea-pt-eap-08.txt > Pages : 20 > Date : 2013-01-27 >=20 > Abstract: > This document specifies PT-EAP, an Extensible Authentication > Protocol > (EAP) based Posture Transport (PT) protocol designed to be used only > inside a TLS protected EAP tunnel method. The document also > describes the intended applicability of PT-EAP. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-nea-pt-eap >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-nea-pt-eap-08 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-nea-pt-eap-08 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www.ietf.org/mailman/listinfo/nea