From shanna@juniper.net Mon Apr 6 07:20:18 2009 Return-Path: X-Original-To: nea@core3.amsl.com Delivered-To: nea@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F5393A6C8E for ; Mon, 6 Apr 2009 07:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.518 X-Spam-Level: X-Spam-Status: No, score=-6.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 78B6Dw4axD8i for ; Mon, 6 Apr 2009 07:20:17 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id 963453A6C96 for ; Mon, 6 Apr 2009 07:20:17 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKSdoP4+nNdqNx0QD1B9zEuVMubLnvqpF4@postini.com; Mon, 06 Apr 2009 07:21:23 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Mon, 6 Apr 2009 07:20:24 -0700 Received: from p-emsmtp03.jnpr.net ([66.129.254.54]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Apr 2009 07:20:24 -0700 Received: from antipi.jnpr.net ([10.10.2.34]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Apr 2009 07:20:24 -0700 Received: from proton.jnpr.net ([10.10.2.37]) by antipi.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Apr 2009 10:20:23 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 6 Apr 2009 10:20:22 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Verifying WG consensus on spec changes Thread-Index: Acmx/2D6Ka/MshsOR/yW0StaTaD/8gEwjr1w From: Stephen Hanna To: X-OriginalArrivalTime: 06 Apr 2009 14:20:23.0257 (UTC) FILETIME=[D2C16490:01C9B6C2] Subject: [Nea] Verifying WG consensus on spec changes X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 14:20:18 -0000 PA-TNC and PB-TNC recently completed WG LC. The only comments received were from Susan Thomson. These comments have been discussed on the email list and the NEA WG F2F meeting at IETF 74. So far, the WG seems to have consensus for the changes listed below. I'd like to verify this consensus on the mailing list. Please review the changes listed below and respond within one week (by 11 AM EDT on Monday, April 13). Indicate in your response whether you support the changes. If you support the changes, a one word response ("Support") is sufficient. If not, please explain your concerns and suggest how they could be resolved. Thanks for your prompt and careful attention to this matter. Once we agree on changes, we can revise these specs and send them to the IESG. Thanks, Steve ---------- Proposed Changes to PA-TNC In the description of the Version field in section 3.7, change the text that says "Implementations responding to a PA-TNC message containing a supported version SHOULD use the same Version number" to say MUST instead. Remove the first two sentences of the next paragraph. These describe using version 0 for version discovery. The WG has decided to remove that feature. Merge the remaining sentence of this paragraph with the previous paragraph and emphasize that the Version Not Supported=20 error code must go in a PA-TNC message with version 1. This point is already mentioned in section 4.2.8.2 but it's a good idea to mention it here, too. In section 4.2.8.2, change both instances of SHOULD to MUST in the fourth paragraph to remove needless ambiguity. In the description of the Message Identifier field in section 3.7, change the second sentence to be "This value can be included in the payload of a response message to indicate which message was received and caused the response." Change the third sentence to say "This value is included in the payload of PA-TNC error messages so the party who receives the error message can determine which of the messages they had sent caused the error." Proposed Changes to PB-TNC In section 3.1, clarify the second sentence of the second paragraph by changing "batches of messages" to "a single batch of messages". The resulting sentence will read "In this mode, the Posture Broker Client and Posture Broker Server take turns sending a single batch of messages to each other." Change version handling to match PA-TNC. Among other changes, the Version field will become one byte long and a Version Not Supported error code will be added. Some differences will remain. For example, certain PB-TNC version numbers are reserved to ensure that PB-TNC batches can be distinguished from similar protocols previously defined by other parties. The version number defined for the initial version of PB-TNC will remain 2. Reserved version numbers will be listed. In section 4.6, say that the Posture Broker Server MUST NOT include a message of type PB-Assessment-Result in a batch whose type is not RESULT. This was a SHOULD NOT. Also, fix a typo in this section where PB-Access-Recommendation should be PB-Assessment-Result. In section 4.7, say that the Posture Broker Server MUST NOT include a message of type PB-Access-Recommendation in a batch whose type is not RESULT. This was a SHOULD NOT. Also, say that the Posture Broker Server MAY include one message of this type in any batch of type RESULT. That was a SHOULD. From sethomso@cisco.com Wed Apr 8 16:06:40 2009 Return-Path: X-Original-To: nea@core3.amsl.com Delivered-To: nea@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A502C3A6B74 for ; Wed, 8 Apr 2009 16:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 p8uWwF7Psgpo for ; Wed, 8 Apr 2009 16:06:39 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 4FED03A6B2E for ; Wed, 8 Apr 2009 16:06:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,157,1238976000"; d="scan'208";a="41353217" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 08 Apr 2009 23:07:46 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n38N7kio015758; Wed, 8 Apr 2009 19:07:46 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n38N7kiD026958; Wed, 8 Apr 2009 23:07:46 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Apr 2009 19:07:46 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 8 Apr 2009 19:07:45 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Verifying WG consensus on spec changes Thread-Index: Acmx/2D6Ka/MshsOR/yW0StaTaD/8gEwjr1wAHcFnZA= References: From: "Susan Thomson (sethomso)" To: "Stephen Hanna" , X-OriginalArrivalTime: 08 Apr 2009 23:07:46.0152 (UTC) FILETIME=[D4377E80:01C9B89E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4236; t=1239232066; x=1240096066; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sethomso@cisco.com; z=From:=20=22Susan=20Thomson=20(sethomso)=22=20 |Subject:=20RE=3A=20[Nea]=20Verifying=20WG=20consensus=20on =20spec=20changes |Sender:=20 |To:=20=22Stephen=20Hanna=22=20,=20; bh=NVyaUJ/D8PZL2n9M/TB6f+7jWiY0zHn0omXZMypje8E=; b=YPDRhIj6YcFUfVud8EgMoy+nQaVegDxx007yF5YhvNeE3Gv/dsfxm9LOyt H06D64W4jDpFkPxsCOTOSg4n8ERtmL6Tq7w4VfTWTBsYPtmkm9ERoctaG9Z7 GjHciP2mtl; Authentication-Results: rtp-dkim-1; header.From=sethomso@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: Re: [Nea] Verifying WG consensus on spec changes X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 23:06:40 -0000 Thanks for verifying these changes. I support them.=20 Susan > -----Original Message----- > From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On=20 > Behalf Of Stephen Hanna > Sent: Monday, April 06, 2009 10:20 AM > To: nea@ietf.org > Subject: [Nea] Verifying WG consensus on spec changes >=20 > PA-TNC and PB-TNC recently completed WG LC. The only comments=20 > received were from Susan Thomson. > These comments have been discussed on the email list and the=20 > NEA WG F2F meeting at IETF 74. > So far, the WG seems to have consensus for the changes listed below. >=20 > I'd like to verify this consensus on the mailing list. Please=20 > review the changes listed below and respond within one week=20 > (by 11 AM EDT on Monday, April 13). Indicate in your response=20 > whether you support the changes. If you support the changes,=20 > a one word response ("Support") is sufficient. > If not, please explain your concerns and suggest how they=20 > could be resolved. >=20 > Thanks for your prompt and careful attention to this matter.=20 > Once we agree on changes, we can revise these specs and send=20 > them to the IESG. >=20 > Thanks, >=20 > Steve >=20 > ---------- >=20 > Proposed Changes to PA-TNC >=20 > In the description of the Version field in section 3.7,=20 > change the text that says "Implementations responding to a=20 > PA-TNC message containing a supported version SHOULD use the=20 > same Version number" to say MUST instead. >=20 > Remove the first two sentences of the next paragraph. > These describe using version 0 for version discovery. > The WG has decided to remove that feature. Merge the=20 > remaining sentence of this paragraph with the previous=20 > paragraph and emphasize that the Version Not Supported error=20 > code must go in a PA-TNC message with version 1. > This point is already mentioned in section 4.2.8.2 but it's a=20 > good idea to mention it here, too. >=20 > In section 4.2.8.2, change both instances of SHOULD to MUST=20 > in the fourth paragraph to remove needless ambiguity. >=20 > In the description of the Message Identifier field in section=20 > 3.7, change the second sentence to be "This value can be=20 > included in the payload of a response message to indicate=20 > which message was received and caused the response." > Change the third sentence to say "This value is included in=20 > the payload of PA-TNC error messages so the party who=20 > receives the error message can determine which of the=20 > messages they had sent caused the error." >=20 > Proposed Changes to PB-TNC >=20 > In section 3.1, clarify the second sentence of the second=20 > paragraph by changing "batches of messages" to "a single=20 > batch of messages". The resulting sentence will read "In this=20 > mode, the Posture Broker Client and Posture Broker Server=20 > take turns sending a single batch of messages to each other." >=20 > Change version handling to match PA-TNC. Among other changes,=20 > the Version field will become one byte long and a Version Not=20 > Supported error code will be added. Some differences will=20 > remain. For example, certain PB-TNC version numbers are=20 > reserved to ensure that PB-TNC batches can be distinguished=20 > from similar protocols previously defined by other parties. > The version number defined for the initial version of PB-TNC=20 > will remain 2. Reserved version numbers will be listed. >=20 > In section 4.6, say that the Posture Broker Server MUST NOT=20 > include a message of type PB-Assessment-Result in a batch=20 > whose type is not RESULT. This was a SHOULD NOT. Also, fix a=20 > typo in this section where PB-Access-Recommendation should be=20 > PB-Assessment-Result. >=20 > In section 4.7, say that the Posture Broker Server MUST NOT=20 > include a message of type PB-Access-Recommendation in a batch=20 > whose type is not RESULT. This was a SHOULD NOT. Also, say=20 > that the Posture Broker Server MAY include one message of=20 > this type in any batch of type RESULT. That was a SHOULD. > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www.ietf.org/mailman/listinfo/nea >=20 From Paul_Sangster@symantec.com Wed Apr 8 20:36:27 2009 Return-Path: X-Original-To: nea@core3.amsl.com Delivered-To: nea@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 351553A68CC for ; Wed, 8 Apr 2009 20:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 2JyYfGR9Cm28 for ; Wed, 8 Apr 2009 20:36:26 -0700 (PDT) Received: from extu-mxob-2.symantec.com (extu-mxob-2.symantec.com [216.10.194.135]) by core3.amsl.com (Postfix) with ESMTP id 517AA3A68B1 for ; Wed, 8 Apr 2009 20:36:26 -0700 (PDT) Received: from tus1opsmtapin02.ges.symantec.com (tus1opsmtapin02.ges.symantec.com [192.168.214.44]) by extu-mxob-2.symantec.com (8.14.1/8.14.1) with ESMTP id n393bXs2022005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Apr 2009 20:37:33 -0700 Received: from reserved-155-64-230-20.ges.symantec.com ([155.64.230.20] helo=TUS1XCHECNPIN03.enterprise.veritas.com) by tus1opsmtapin02.ges.symantec.com with esmtp (Exim 4.67) (envelope-from ) id 1Lrl53-0002vU-DZ; Wed, 08 Apr 2009 20:37:33 -0700 Received: from TUS1XCHEVSPIN05.enterprise.veritas.com ([155.64.231.27]) by TUS1XCHECNPIN03.enterprise.veritas.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 8 Apr 2009 20:37:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 8 Apr 2009 20:37:30 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Verifying WG consensus on spec changes Thread-Index: Acmx/2D6Ka/MshsOR/yW0StaTaD/8gEwjr1wAICyzJA= References: From: "Paul Sangster" To: "Stephen Hanna" , X-OriginalArrivalTime: 09 Apr 2009 03:37:33.0312 (UTC) FILETIME=[84841800:01C9B8C4] Subject: Re: [Nea] Verifying WG consensus on spec changes X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 03:36:27 -0000 The changes look like an improvement to me. I support these modifications.=20 > -----Original Message----- > From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On=20 > Behalf Of Stephen Hanna > Sent: Monday, April 06, 2009 7:20 AM > To: nea@ietf.org > Subject: [Nea] Verifying WG consensus on spec changes >=20 > PA-TNC and PB-TNC recently completed WG LC. The only comments=20 > received were from Susan Thomson. > These comments have been discussed on the email list and the=20 > NEA WG F2F meeting at IETF 74. > So far, the WG seems to have consensus for the changes listed below. >=20 > I'd like to verify this consensus on the mailing list. Please=20 > review the changes listed below and respond within one week=20 > (by 11 AM EDT on Monday, April 13). Indicate in your response=20 > whether you support the changes. If you support the changes,=20 > a one word response ("Support") is sufficient. > If not, please explain your concerns and suggest how they=20 > could be resolved. >=20 > Thanks for your prompt and careful attention to this matter.=20 > Once we agree on changes, we can revise these specs and send=20 > them to the IESG. >=20 > Thanks, >=20 > Steve >=20 > ---------- >=20 > Proposed Changes to PA-TNC >=20 > In the description of the Version field in section 3.7,=20 > change the text that says "Implementations responding to a=20 > PA-TNC message containing a supported version SHOULD use the=20 > same Version number" to say MUST instead. >=20 > Remove the first two sentences of the next paragraph. > These describe using version 0 for version discovery. > The WG has decided to remove that feature. Merge the=20 > remaining sentence of this paragraph with the previous=20 > paragraph and emphasize that the Version Not Supported error=20 > code must go in a PA-TNC message with version 1. > This point is already mentioned in section 4.2.8.2 but it's a=20 > good idea to mention it here, too. >=20 > In section 4.2.8.2, change both instances of SHOULD to MUST=20 > in the fourth paragraph to remove needless ambiguity. >=20 > In the description of the Message Identifier field in section=20 > 3.7, change the second sentence to be "This value can be=20 > included in the payload of a response message to indicate=20 > which message was received and caused the response." > Change the third sentence to say "This value is included in=20 > the payload of PA-TNC error messages so the party who=20 > receives the error message can determine which of the=20 > messages they had sent caused the error." >=20 > Proposed Changes to PB-TNC >=20 > In section 3.1, clarify the second sentence of the second=20 > paragraph by changing "batches of messages" to "a single=20 > batch of messages". The resulting sentence will read "In this=20 > mode, the Posture Broker Client and Posture Broker Server=20 > take turns sending a single batch of messages to each other." >=20 > Change version handling to match PA-TNC. Among other changes,=20 > the Version field will become one byte long and a Version Not=20 > Supported error code will be added. Some differences will=20 > remain. For example, certain PB-TNC version numbers are=20 > reserved to ensure that PB-TNC batches can be distinguished=20 > from similar protocols previously defined by other parties. > The version number defined for the initial version of PB-TNC=20 > will remain 2. Reserved version numbers will be listed. >=20 > In section 4.6, say that the Posture Broker Server MUST NOT=20 > include a message of type PB-Assessment-Result in a batch=20 > whose type is not RESULT. This was a SHOULD NOT. Also, fix a=20 > typo in this section where PB-Access-Recommendation should be=20 > PB-Assessment-Result. >=20 > In section 4.7, say that the Posture Broker Server MUST NOT=20 > include a message of type PB-Access-Recommendation in a batch=20 > whose type is not RESULT. This was a SHOULD NOT. Also, say=20 > that the Posture Broker Server MAY include one message of=20 > this type in any batch of type RESULT. That was a SHOULD. > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www.ietf.org/mailman/listinfo/nea >=20 From kaushik@cisco.com Thu Apr 9 08:23:38 2009 Return-Path: X-Original-To: nea@core3.amsl.com Delivered-To: nea@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BC823A6BD3 for ; Thu, 9 Apr 2009 08:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 uuTv-apbBLei for ; Thu, 9 Apr 2009 08:23:37 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 1A07E3A6A4D for ; Thu, 9 Apr 2009 08:23:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,161,1238976000"; d="scan'208";a="152980181" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 09 Apr 2009 15:24:45 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n39FOjHo002721; Thu, 9 Apr 2009 08:24:45 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n39FOjfW009166; Thu, 9 Apr 2009 15:24:45 GMT Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Apr 2009 08:24:45 -0700 Received: from 10.21.116.236 ([10.21.116.236]) by xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) with Microsoft Exchange Server HTTP-DAV ; Thu, 9 Apr 2009 15:24:44 +0000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Thu, 09 Apr 2009 08:24:42 -0700 From: kaushik To: Stephen Hanna , Message-ID: Thread-Topic: [Nea] Verifying WG consensus on spec changes Thread-Index: Acmx/2D6Ka/MshsOR/yW0StaTaD/8gEwjr1wAJlsg/E= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 09 Apr 2009 15:24:45.0187 (UTC) FILETIME=[4FE26530:01C9B927] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3900; t=1239290685; x=1240154685; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kaushik@cisco.com; z=From:=20kaushik=20 |Subject:=20Re=3A=20[Nea]=20Verifying=20WG=20consensus=20on =20spec=20changes |Sender:=20; bh=K6zGEaZXqI0KChSZpytJTrvKH47afZY97QcveEHu4Vc=; b=EZcdpV1e1HFwfygEg18gjU05OSEnRMYyLPwNjNdRJNAyj5ko2T3KrkDSyQ BxypdzczdyuzDxH8RtZLbxv2KG9ItYd6JRaJw7+l1Kk98e26wLTqKnlk0cNU U+VceScXml; Authentication-Results: sj-dkim-4; header.From=kaushik@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [Nea] Verifying WG consensus on spec changes X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 15:23:38 -0000 Hi Steve, I support these changes. Regards, kaushik On 4/6/09 7:20 AM, "Stephen Hanna" wrote: > PA-TNC and PB-TNC recently completed WG LC. The > only comments received were from Susan Thomson. > These comments have been discussed on the email > list and the NEA WG F2F meeting at IETF 74. > So far, the WG seems to have consensus for the > changes listed below. > > I'd like to verify this consensus on the mailing > list. Please review the changes listed below and > respond within one week (by 11 AM EDT on Monday, > April 13). Indicate in your response whether you > support the changes. If you support the changes, > a one word response ("Support") is sufficient. > If not, please explain your concerns and suggest > how they could be resolved. > > Thanks for your prompt and careful attention to > this matter. Once we agree on changes, we can > revise these specs and send them to the IESG. > > Thanks, > > Steve > > ---------- > > Proposed Changes to PA-TNC > > In the description of the Version field in section 3.7, > change the text that says "Implementations responding > to a PA-TNC message containing a supported version SHOULD > use the same Version number" to say MUST instead. > > Remove the first two sentences of the next paragraph. > These describe using version 0 for version discovery. > The WG has decided to remove that feature. Merge the > remaining sentence of this paragraph with the previous > paragraph and emphasize that the Version Not Supported > error code must go in a PA-TNC message with version 1. > This point is already mentioned in section 4.2.8.2 but > it's a good idea to mention it here, too. > > In section 4.2.8.2, change both instances of SHOULD to > MUST in the fourth paragraph to remove needless ambiguity. > > In the description of the Message Identifier field in > section 3.7, change the second sentence to be "This value > can be included in the payload of a response message to > indicate which message was received and caused the response." > Change the third sentence to say "This value is included > in the payload of PA-TNC error messages so the party who > receives the error message can determine which of the > messages they had sent caused the error." > > Proposed Changes to PB-TNC > > In section 3.1, clarify the second sentence of the second > paragraph by changing "batches of messages" to "a single > batch of messages". The resulting sentence will read > "In this mode, the Posture Broker Client and Posture > Broker Server take turns sending a single batch of messages > to each other." > > Change version handling to match PA-TNC. Among other changes, > the Version field will become one byte long and a Version > Not Supported error code will be added. Some differences > will remain. For example, certain PB-TNC version numbers > are reserved to ensure that PB-TNC batches can be distinguished > from similar protocols previously defined by other parties. > The version number defined for the initial version of PB-TNC > will remain 2. Reserved version numbers will be listed. > > In section 4.6, say that the Posture Broker Server MUST NOT > include a message of type PB-Assessment-Result in a batch > whose type is not RESULT. This was a SHOULD NOT. Also, fix > a typo in this section where PB-Access-Recommendation should > be PB-Assessment-Result. > > In section 4.7, say that the Posture Broker Server MUST NOT > include a message of type PB-Access-Recommendation in a batch > whose type is not RESULT. This was a SHOULD NOT. Also, say > that the Posture Broker Server MAY include one message of > this type in any batch of type RESULT. That was a SHOULD. > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www.ietf.org/mailman/listinfo/nea From ayinhan@huawei.com Thu Apr 9 18:27:14 2009 Return-Path: X-Original-To: nea@core3.amsl.com Delivered-To: nea@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A8EF3A6D21 for ; Thu, 9 Apr 2009 18:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.39 X-Spam-Level: X-Spam-Status: No, score=0.39 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RDNS_NONE=0.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 yTDQEDgPJnCy for ; Thu, 9 Apr 2009 18:27:13 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 942023A6D23 for ; Thu, 9 Apr 2009 18:27:12 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KHV00JIV2QXSF@szxga01-in.huawei.com> for nea@ietf.org; Fri, 10 Apr 2009 09:28:10 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KHV0043T2QXMW@szxga01-in.huawei.com> for nea@ietf.org; Fri, 10 Apr 2009 09:28:09 +0800 (CST) Received: from y34728h ([10.111.194.67]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KHV002RW2QXGF@szxml04-in.huawei.com> for nea@ietf.org; Fri, 10 Apr 2009 09:28:09 +0800 (CST) Date: Fri, 10 Apr 2009 09:28:07 +0800 From: han yin To: Stephen Hanna , nea@ietf.org Message-id: <00ab01c9b97b$9a4c2fd0$43c26f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: multipart/alternative; boundary="Boundary_(ID_wzj7+xKg6xmAjdK+Rzcv8w)" X-Priority: 3 X-MSMail-priority: Normal References: Subject: Re: [Nea] Verifying WG consensus on spec changes X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 01:27:14 -0000 This is a multi-part message in MIME format. --Boundary_(ID_wzj7+xKg6xmAjdK+Rzcv8w) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT I support these modifications. . Regards ----- Original Message ----- From: Stephen Hanna To: nea@ietf.org Sent: Monday, April 06, 2009 10:20 PM Subject: [Nea] Verifying WG consensus on spec changes PA-TNC and PB-TNC recently completed WG LC. The only comments received were from Susan Thomson. These comments have been discussed on the email list and the NEA WG F2F meeting at IETF 74. So far, the WG seems to have consensus for the changes listed below. I'd like to verify this consensus on the mailing list. Please review the changes listed below and respond within one week (by 11 AM EDT on Monday, April 13). Indicate in your response whether you support the changes. If you support the changes, a one word response ("Support") is sufficient. If not, please explain your concerns and suggest how they could be resolved. Thanks for your prompt and careful attention to this matter. Once we agree on changes, we can revise these specs and send them to the IESG. Thanks, Steve ---------- Proposed Changes to PA-TNC In the description of the Version field in section 3.7, change the text that says "Implementations responding to a PA-TNC message containing a supported version SHOULD use the same Version number" to say MUST instead. Remove the first two sentences of the next paragraph. These describe using version 0 for version discovery. The WG has decided to remove that feature. Merge the remaining sentence of this paragraph with the previous paragraph and emphasize that the Version Not Supported error code must go in a PA-TNC message with version 1. This point is already mentioned in section 4.2.8.2 but it's a good idea to mention it here, too. In section 4.2.8.2, change both instances of SHOULD to MUST in the fourth paragraph to remove needless ambiguity. In the description of the Message Identifier field in section 3.7, change the second sentence to be "This value can be included in the payload of a response message to indicate which message was received and caused the response." Change the third sentence to say "This value is included in the payload of PA-TNC error messages so the party who receives the error message can determine which of the messages they had sent caused the error." Proposed Changes to PB-TNC In section 3.1, clarify the second sentence of the second paragraph by changing "batches of messages" to "a single batch of messages". The resulting sentence will read "In this mode, the Posture Broker Client and Posture Broker Server take turns sending a single batch of messages to each other." Change version handling to match PA-TNC. Among other changes, the Version field will become one byte long and a Version Not Supported error code will be added. Some differences will remain. For example, certain PB-TNC version numbers are reserved to ensure that PB-TNC batches can be distinguished from similar protocols previously defined by other parties. The version number defined for the initial version of PB-TNC will remain 2. Reserved version numbers will be listed. In section 4.6, say that the Posture Broker Server MUST NOT include a message of type PB-Assessment-Result in a batch whose type is not RESULT. This was a SHOULD NOT. Also, fix a typo in this section where PB-Access-Recommendation should be PB-Assessment-Result. In section 4.7, say that the Posture Broker Server MUST NOT include a message of type PB-Access-Recommendation in a batch whose type is not RESULT. This was a SHOULD NOT. Also, say that the Posture Broker Server MAY include one message of this type in any batch of type RESULT. That was a SHOULD. _______________________________________________ Nea mailing list Nea@ietf.org https://www.ietf.org/mailman/listinfo/nea --Boundary_(ID_wzj7+xKg6xmAjdK+Rzcv8w) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT
I support these modifications.
.
 
Regards

----- Original Message -----
Sent: Monday, April 06, 2009 10:20 PM
Subject: [Nea] Verifying WG consensus on spec changes

PA-TNC and PB-TNC recently completed WG LC. The
only comments received were from Susan Thomson.
These comments have been discussed on the email
list and the NEA WG F2F meeting at IETF 74.
So far, the WG seems to have consensus for the
changes listed below.

I'd like to verify this consensus on the mailing
list. Please review the changes listed below and
respond within one week (by 11 AM EDT on Monday,
April 13). Indicate in your response whether you
support the changes. If you support the changes,
a one word response ("Support") is sufficient.
If not, please explain your concerns and suggest
how they could be resolved.

Thanks for your prompt and careful attention to
this matter. Once we agree on changes, we can
revise these specs and send them to the IESG.

Thanks,

Steve

----------

Proposed Changes to PA-TNC

In the description of the Version field in section 3.7,
change the text that says "Implementations responding
to a PA-TNC message containing a supported version SHOULD
use the same Version number" to say MUST instead.

Remove the first two sentences of the next paragraph.
These describe using version 0 for version discovery.
The WG has decided to remove that feature. Merge the
remaining sentence of this paragraph with the previous
paragraph and emphasize that the Version Not Supported
error code must go in a PA-TNC message with version 1.
This point is already mentioned in section 4.2.8.2 but
it's a good idea to mention it here, too.

In section 4.2.8.2, change both instances of SHOULD to
MUST in the fourth paragraph to remove needless ambiguity.

In the description of the Message Identifier field in
section 3.7, change the second sentence to be "This value
can be included in the payload of a response message to
indicate which message was received and caused the response."
Change the third sentence to say "This value is included
in the payload of PA-TNC error messages so the party who
receives the error message can determine which of the
messages they had sent caused the error."

Proposed Changes to PB-TNC

In section 3.1, clarify the second sentence of the second
paragraph by changing "batches of messages" to "a single
batch of messages". The resulting sentence will read
"In this mode, the Posture Broker Client and Posture
Broker Server take turns sending a single batch of messages
to each other."

Change version handling to match PA-TNC. Among other changes,
the Version field will become one byte long and a Version
Not Supported error code will be added. Some differences
will remain. For example, certain PB-TNC version numbers
are reserved to ensure that PB-TNC batches can be distinguished
from similar protocols previously defined by other parties.
The version number defined for the initial version of PB-TNC
will remain 2. Reserved version numbers will be listed.

In section 4.6, say that the Posture Broker Server MUST NOT
include a message of type PB-Assessment-Result in a batch
whose type is not RESULT. This was a SHOULD NOT. Also, fix
a typo in this section where PB-Access-Recommendation should
be PB-Assessment-Result.

In section 4.7, say that the Posture Broker Server MUST NOT
include a message of type PB-Access-Recommendation in a batch
whose type is not RESULT. This was a SHOULD NOT. Also, say
that the Posture Broker Server MAY include one  message of
this type in any batch of type RESULT. That was a SHOULD.
_______________________________________________
Nea mailing list
Nea@ietf.org
https://www.ietf.org/mailman/listinfo/nea
--Boundary_(ID_wzj7+xKg6xmAjdK+Rzcv8w)-- From ravi.sahita@intel.com Fri Apr 10 10:41:44 2009 Return-Path: X-Original-To: nea@core3.amsl.com Delivered-To: nea@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BE963A6947 for ; Fri, 10 Apr 2009 10:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 M1E1VN0HsM0x for ; Fri, 10 Apr 2009 10:41:43 -0700 (PDT) Received: from mga14.intel.com (mga14.intel.com [143.182.124.37]) by core3.amsl.com (Postfix) with ESMTP id 8F3923A6997 for ; Fri, 10 Apr 2009 10:41:43 -0700 (PDT) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga102.ch.intel.com with ESMTP; 10 Apr 2009 10:42:45 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.40,168,1239001200"; d="scan'208";a="130186271" Received: from orsmsx603.amr.corp.intel.com ([10.22.226.49]) by azsmga001.ch.intel.com with ESMTP; 10 Apr 2009 10:42:44 -0700 Received: from orsmsx506.amr.corp.intel.com ([10.22.226.44]) by orsmsx603.amr.corp.intel.com ([10.22.226.49]) with mapi; Fri, 10 Apr 2009 10:42:44 -0700 From: "Sahita, Ravi" To: "nea@ietf.org" Date: Fri, 10 Apr 2009 10:42:43 -0700 Thread-Topic: Verifying WG consensus on spec changes Thread-Index: Acmx/2D6Ka/MshsOR/yW0StaTaD/8gEwjr1wANB0dlA= Message-ID: <0496741B13AE3740BC2D48B4A501D80D62DC900F@orsmsx506.amr.corp.intel.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Nea] Verifying WG consensus on spec changes X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 17:41:44 -0000 I agree with these changes. Thanks for the clear proposed change report Steve. -Ravi=20 -----Original Message----- From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of Steph= en Hanna Sent: Monday, April 06, 2009 7:20 AM To: nea@ietf.org Subject: [Nea] Verifying WG consensus on spec changes PA-TNC and PB-TNC recently completed WG LC. The only comments received were from Susan Thomson. These comments have been discussed on the email list and the NEA WG F2F meeting at IETF 74. So far, the WG seems to have consensus for the changes listed below. I'd like to verify this consensus on the mailing list. Please review the changes listed below and respond within one week (by 11 AM EDT on Monday, April 13). Indicate in your response whether you support the changes. If you support the changes, a one word response ("Support") is sufficient. If not, please explain your concerns and suggest how they could be resolved. Thanks for your prompt and careful attention to this matter. Once we agree on changes, we can revise these specs and send them to the IESG. Thanks, Steve ---------- Proposed Changes to PA-TNC In the description of the Version field in section 3.7, change the text that says "Implementations responding to a PA-TNC message containing a supported version SHOULD use the same Version number" to say MUST instead. Remove the first two sentences of the next paragraph. These describe using version 0 for version discovery. The WG has decided to remove that feature. Merge the remaining sentence of this paragraph with the previous paragraph and emphasize that the Version Not Supported=20 error code must go in a PA-TNC message with version 1. This point is already mentioned in section 4.2.8.2 but it's a good idea to mention it here, too. In section 4.2.8.2, change both instances of SHOULD to MUST in the fourth paragraph to remove needless ambiguity. In the description of the Message Identifier field in section 3.7, change the second sentence to be "This value can be included in the payload of a response message to indicate which message was received and caused the response." Change the third sentence to say "This value is included in the payload of PA-TNC error messages so the party who receives the error message can determine which of the messages they had sent caused the error." Proposed Changes to PB-TNC In section 3.1, clarify the second sentence of the second paragraph by changing "batches of messages" to "a single batch of messages". The resulting sentence will read "In this mode, the Posture Broker Client and Posture Broker Server take turns sending a single batch of messages to each other." Change version handling to match PA-TNC. Among other changes, the Version field will become one byte long and a Version Not Supported error code will be added. Some differences will remain. For example, certain PB-TNC version numbers are reserved to ensure that PB-TNC batches can be distinguished from similar protocols previously defined by other parties. The version number defined for the initial version of PB-TNC will remain 2. Reserved version numbers will be listed. In section 4.6, say that the Posture Broker Server MUST NOT include a message of type PB-Assessment-Result in a batch whose type is not RESULT. This was a SHOULD NOT. Also, fix a typo in this section where PB-Access-Recommendation should be PB-Assessment-Result. In section 4.7, say that the Posture Broker Server MUST NOT include a message of type PB-Access-Recommendation in a batch whose type is not RESULT. This was a SHOULD NOT. Also, say that the Posture Broker Server MAY include one message of this type in any batch of type RESULT. That was a SHOULD. _______________________________________________ Nea mailing list Nea@ietf.org https://www.ietf.org/mailman/listinfo/nea From shanna@juniper.net Mon Apr 13 09:07:14 2009 Return-Path: X-Original-To: nea@core3.amsl.com Delivered-To: nea@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 025C83A6C90 for ; Mon, 13 Apr 2009 09:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.779 X-Spam-Level: X-Spam-Status: No, score=-5.779 tagged_above=-999 required=5 tests=[AWL=-0.669, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] 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 UcbrkGl+CMrw for ; Mon, 13 Apr 2009 09:07:13 -0700 (PDT) Received: from chip3og62.obsmtp.com (chip3og62.obsmtp.com [64.18.14.201]) by core3.amsl.com (Postfix) with ESMTP id C08C63A677C for ; Mon, 13 Apr 2009 09:07:12 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by chip3ob62.postini.com ([64.18.6.12]) with SMTP ID DSNKSeNjd7MvvvUXit7gi1D9pv+/Vwhiw4P7@postini.com; Mon, 13 Apr 2009 09:08:24 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.1.340.0; Mon, 13 Apr 2009 09:03:30 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Mon, 13 Apr 2009 12:03:29 -0400 From: Stephen Hanna To: "nea@ietf.org" Date: Mon, 13 Apr 2009 12:03:29 -0400 Thread-Topic: Verifying WG consensus on spec changes Thread-Index: Acmx/2D6Ka/MshsOR/yW0StaTaD/8gEwjr1wAWPQKdA= Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Nea] Verifying WG consensus on spec changes X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 16:07:14 -0000 I saw six emails supporting these changes. No concerns were raised. Therefore, I declare WG consensus to make these changes. Editors, please make these changes and post revised drafts of PA-TNC and PB-TNC. At that point, we should be ready to send those drafts to the IESG since we have addressed all the comments that came up during WGLC. Thanks, Steve > -----Original Message----- > From: Stephen Hanna=20 > Sent: Monday, April 06, 2009 10:20 AM > To: nea@ietf.org > Subject: Verifying WG consensus on spec changes >=20 > PA-TNC and PB-TNC recently completed WG LC. The > only comments received were from Susan Thomson. > These comments have been discussed on the email > list and the NEA WG F2F meeting at IETF 74. > So far, the WG seems to have consensus for the > changes listed below. >=20 > I'd like to verify this consensus on the mailing > list. Please review the changes listed below and > respond within one week (by 11 AM EDT on Monday, > April 13). Indicate in your response whether you > support the changes. If you support the changes, > a one word response ("Support") is sufficient. > If not, please explain your concerns and suggest > how they could be resolved. >=20 > Thanks for your prompt and careful attention to > this matter. Once we agree on changes, we can > revise these specs and send them to the IESG. >=20 > Thanks, >=20 > Steve >=20 > ---------- >=20 > Proposed Changes to PA-TNC >=20 > In the description of the Version field in section 3.7, > change the text that says "Implementations responding > to a PA-TNC message containing a supported version SHOULD > use the same Version number" to say MUST instead. >=20 > Remove the first two sentences of the next paragraph. > These describe using version 0 for version discovery. > The WG has decided to remove that feature. Merge the > remaining sentence of this paragraph with the previous > paragraph and emphasize that the Version Not Supported=20 > error code must go in a PA-TNC message with version 1. > This point is already mentioned in section 4.2.8.2 but > it's a good idea to mention it here, too. >=20 > In section 4.2.8.2, change both instances of SHOULD to > MUST in the fourth paragraph to remove needless ambiguity. >=20 > In the description of the Message Identifier field in > section 3.7, change the second sentence to be "This value > can be included in the payload of a response message to > indicate which message was received and caused the response." > Change the third sentence to say "This value is included > in the payload of PA-TNC error messages so the party who > receives the error message can determine which of the > messages they had sent caused the error." >=20 > Proposed Changes to PB-TNC >=20 > In section 3.1, clarify the second sentence of the second > paragraph by changing "batches of messages" to "a single > batch of messages". The resulting sentence will read > "In this mode, the Posture Broker Client and Posture > Broker Server take turns sending a single batch of messages > to each other." >=20 > Change version handling to match PA-TNC. Among other changes, > the Version field will become one byte long and a Version > Not Supported error code will be added. Some differences > will remain. For example, certain PB-TNC version numbers > are reserved to ensure that PB-TNC batches can be distinguished > from similar protocols previously defined by other parties. > The version number defined for the initial version of PB-TNC > will remain 2. Reserved version numbers will be listed. >=20 > In section 4.6, say that the Posture Broker Server MUST NOT > include a message of type PB-Assessment-Result in a batch > whose type is not RESULT. This was a SHOULD NOT. Also, fix > a typo in this section where PB-Access-Recommendation should > be PB-Assessment-Result. >=20 > In section 4.7, say that the Posture Broker Server MUST NOT > include a message of type PB-Access-Recommendation in a batch > whose type is not RESULT. This was a SHOULD NOT. Also, say > that the Posture Broker Server MAY include one message of > this type in any batch of type RESULT. That was a SHOULD. > = From root@core3.amsl.com Fri Apr 17 03:45:01 2009 Return-Path: X-Original-To: nea@ietf.org Delivered-To: nea@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id CF50C3A6A3F; Fri, 17 Apr 2009 03:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090417104501.CF50C3A6A3F@core3.amsl.com> Date: Fri, 17 Apr 2009 03:45:01 -0700 (PDT) Cc: nea@ietf.org Subject: [Nea] I-D Action:draft-ietf-nea-pb-tnc-04.txt X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 10:45:01 -0000 --NextPart 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. Title : PB-TNC: A Posture Broker Protocol (PB) Compatible with TNC Author(s) : R. Sahita, et al. Filename : draft-ietf-nea-pb-tnc-04.txt Pages : 78 Date : 2009-04-17 This document specifies PB-TNC, a Posture Broker Protocol identical to the Trusted Computing Group's IF-TNCCS 2.0 protocol. The document then evaluates PB-TNC against the requirements defined in the NEA Requirements specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nea-pb-tnc-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-nea-pb-tnc-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-17033405.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Fri Apr 17 16:00:01 2009 Return-Path: X-Original-To: nea@ietf.org Delivered-To: nea@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 55B613A6E28; Fri, 17 Apr 2009 16:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090417230001.55B613A6E28@core3.amsl.com> Date: Fri, 17 Apr 2009 16:00:01 -0700 (PDT) Cc: nea@ietf.org Subject: [Nea] I-D ACTION:draft-ietf-nea-pa-tnc-04.txt X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 23:00:01 -0000 --NextPart 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. Title : PA-TNC: A Posture Attribute Protocol (PA) Compatible with TNC Author(s) : K. Narayan Filename : draft-ietf-nea-pa-tnc-04.txt Pages : 85 Date : 2009-4-17 This document specifies PA-TNC, a Posture Attribute Protocol identical to the Trusted Computing Group's IF-M 1.0 protocol. The document then evaluates PA-TNC against the requirements defined in the NEA Requirements specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nea-pa-tnc-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-nea-pa-tnc-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-4-17155953.I-D@ietf.org> --NextPart-- From sethomso@cisco.com Fri Apr 24 11:52:19 2009 Return-Path: X-Original-To: nea@core3.amsl.com Delivered-To: nea@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC4DD28C24B for ; Fri, 24 Apr 2009 11:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 NujT52PXIZwA for ; Fri, 24 Apr 2009 11:52:18 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 2223E28C2CD for ; Fri, 24 Apr 2009 11:51:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,243,1238976000"; d="scan'208";a="176530431" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 24 Apr 2009 18:52:44 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n3OIqiXl000725 for ; Fri, 24 Apr 2009 11:52:44 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3OIqDtZ011575 for ; Fri, 24 Apr 2009 18:52:43 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Apr 2009 14:52:43 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 24 Apr 2009 14:52:41 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft minutes for IETF74 Thread-Index: AcnFDdiQMFPJ2efhRpO6nkGfZQRafQ== From: "Susan Thomson (sethomso)" To: X-OriginalArrivalTime: 24 Apr 2009 18:52:43.0511 (UTC) FILETIME=[D9BDC870:01C9C50D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=11929; t=1240599164; x=1241463164; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sethomso@cisco.com; z=From:=20=22Susan=20Thomson=20(sethomso)=22=20 |Subject:=20Draft=20minutes=20for=20IETF74 |Sender:=20; bh=E5Bi62vKg9EEyS9ZE9H55ex/n/hT/SUSenOWsoxflnk=; b=BPOpQDCodHZbltszCeMLy5dLc9guBPszxhRq2VFuSiHFXD2H9FPmgULV6L 9wJ0CM0AKJ8Fg6ry/p2nmWrse1VYNnUP2Y04AWi85vNcLxGlOlCJGJurXZ9n c24GjlNnBy; Authentication-Results: sj-dkim-4; header.From=sethomso@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: [Nea] Draft minutes for IETF74 X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 18:52:19 -0000 Draft minutes for IETF74 have been posted at the WG web site http://tools.ietf.org/wg/nea. Also included below. Please send revisions to me by Wed Apr 29. Thanks Susan ---------------------------- These notes do not attempt to duplicate the content of the slides. Instead, they summarize the material presented, and focus on comments=20 and discussion. Agenda =3D=3D=3D=3D=3D=3D Date: Monday, March 23, 2009 Time: 1300-1500 PDT (GMT-0700) WG Charter: http://www.ietf.org/html.charters/nea-charter.html WG Tools: http://tools.ietf.org/wg/nea WG email: nea@ietf.org 1300 Administrivia Blue Sheets Jabber & Minute scribes Agenda bashing 1305 WG Status 1310 Discuss PA-TNC (recent changes and WGLC comments) http://www.ietf.org/internet-drafts/draft-ietf-nea-pb-tnc-03.txt 1350 Discuss PB-TNC (recent changes and WGLC comments) http://www.ietf.org/internet-drafts/draft-ietf-nea-pa-tnc-03.txt 1430 Open Mic 1450 Review Milestones and Next Steps 1500 Adjourn WG Status =3D=3D=3D=3D=3D=3D=3D=3D=3D The PA-TNC and PB-TNC were updated based on changes discussed at the=20 last IETF.=20 Working Group Last Call for comments on the documents ended prior to=20 the IETF with one comment. Changes to -03 version of PA-TNC I-D: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Kaushik Narayan reviewed the changes made to the -03 version of PA-TNC. There were the following changes: 1. IANA Considerations no longer require a RFC. Expert Review with=20 Specification is required. The specification must be permanently and=20 publicly available and likely to ensure interoperability. IETF standard=20 values must be useful and not harmful to the Internet. 2. The section on evaluating the PA-TNC protocol against NEA=20 requirements per RFC 5209 has been moved to the Appendix 3. Pre-RFC 5378 text has been added to the first page WGLC Comments on -03 version of PA-TNC I-D: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D WGLC Comments included the following proposed changes: 1. SHOULD to MUST: A message recipient MUST use the same version number=20 in a response if the version is supported. If the version is not=20 supported, a message recipient MUST respond to the message with a=20 Version Not Supported error message using version 1.=20 2. Version Discovery: The -03 version of the I-D specifies that a=20 sender can use a special-purpose message with version 0 for version=20 discovery. This is in addition to the ability to send a message, and,=20 if the version is not supported, receive a Version Not Supported=20 error message containing the min-max range of versions supported by the=20 recipient. In the interests of simplicity and to avoid redundancy, the=20 proposal is to remove the version 0 mechanism since it is not deemed=20 necessary to have two ways of performing version discovery. Steve pointed out that the motivation for having the two mechanisms in=20 the first place was to provide a means of performing version discovery=20 without triggering an error. Kaushik asked for those in favor of retaining Version 0 discovery to=20 comment. Nobody did. 3. The WGLC comments also proposed some minor wording changes. All of the above proposed changes to be confirmed on the mailing list. Changes to -03 version of PB-TNC I-D: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Steve Hanna reviewed changes to the PB-TNC specification. The changes included the following: 1. IANA Considerations were changed in the same way as for PA-TNC=20 described above. 2. The section on evaluating the PB-TNC protocol against NEA=20 requirements has been moved to an Appendix 3. Pre-RFC 5378 text has been added to the first page 4. State machine change has been simplified Steve reviewed the history of changes to the state machine.=20 The -01 version of the state machine allowed the client and server to=20 re-try in the middle of an assessment, but only the client could=20 trigger a posture assessment after an assessment had completed. The -02 version of the state machine made changes to allow the server=20 to trigger an assessment after the completion of an assessment, but it=20 led to synchronization errors when both the client and server trigger a=20 re-assessment at the same time.=20 The -03 version of the state machine addresses the issues with the -02=20 version. However, this version only supports triggering re-assessment=20 after an assessment has finished. WGLC Comments on -03 version of PB-TNC I-D: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D WGLC Comments included the following proposed changes: 1. Make PB-TNC version handling the same as PA-TNC: Unlike PA-TNC, the=20 -03 version of the specification has no support for version discovery.=20 The proposal is for PB-TNC to adopt the proposal described above for=20 PA-TNC. However, there will be some differences in the version numbers=20 that can be used. Some version numbers will be reserved to accommodate=20 prior usage. 2. PB-Assessment-Result and PB-Access-Recommendation MUST NOT appear in=20 a batch of type other than Result (was SHOULD NOT) 3. PB-Access-Recommendation MAY appear in a batch of type Result (was=20 SHOULD) Steve asked whether these proposals seemed reasonable. There were no=20 objections. Susan asked for confirmation that an implication of the version=20 handling above is that the version number field in PB-TNC would be=20 modified to be the same size as that used in PA-TNC.=20 Steve confirmed that the current size of 4 bits would be expanded to 8=20 bits to be the same as PA-TNC. Milestones =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The above proposals will be confirmed on the mailing list and -04=20 versions of the protocol specs published in late March or early April.=20 After that the specifications will be submitted for IETF Last Call. Once the specifications have passed IETF Last Call and IESG=20 consideration, the milestones in the charter are complete. Next Steps =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D To kick off the discussion, Steve described the 3-layer NEA framework=20 for the benefit of those in the meeting who were not familiar with it.=20 The PA protocol reports information about the environment of a NEA=20 client (OS version, AV status etc) to the NEA server. The PB protocol encapsulates this information in batches between client=20 and server. The PT protocol encapsulates the PB protocol for transport across the=20 network. The PA and PB protocols have been the subject of the working group=20 charter to date. The WG needs to consult with the ADs regarding PT=20 since the charter text and milestones need to be updated. Tim Polk said that once the PA-TNC and PB-TNC specifications are done,=20 re-chartering is likely to occur. The WG needs to define new text and=20 milestones to accomplish this work. It is reasonable to expect that=20 this work can proceed before the PA-TNC and PB-TNC I-Ds are fully=20 approved by the IETF and IESG. Stephen Farrell asked whether this can be accomplished prior to the=20 next meeting. Tim Polk said yes, this was possible. The charter needs to be approved=20 by the IESG. The precise timing depends on the IESG meeting schedule,=20 but it should be doable within a month. It is not unreasonable to=20 expect that this can be done prior to the Stockholm meeting. Susan asked whether the charter updates would be submitted to the IESG=20 if the IETF Last Call did not go smoothly.=20 Tim replied that he does not expect there to be problems during the=20 IETF Last Call, but if there are, the charter updates will not be=20 submitted to the IESG until the IETF Last Call comments are resolved.=20 Steve asked whether the revised charter would be considered if the IETF=20 Last Call went smoothly, but the IESG had comments.=20 Tim said that he would be prepared to consider re-chartering in this=20 case, but it would depend on what the IESG comments were. He does not=20 want the WG to lose momentum between now and the Stockholm meeting. The=20 intent is for the charter revisions to trail closely behind the RFC=20 approval process.=20 Jerry Thrasher referred to a sentence in the charter that indicates=20 that PT is a deliverable. There is wording in the current charter that=20 says that the WG will identify and specify the use of one mandatory to=20 implement PT protocol that is fully documented in an RFC.=20 Steve explained that the intent of this wording was to say that the WG=20 was not in the business of specifying a new transport protocol, and=20 that the WG would identify one that already exists.=20 Kaushik pointed out that it is likely there will be multiple PTs=20 needed, e.g. one pre-access control, and one post-access control. Many=20 existing implementations implement multiple protocols already. The=20 charter currently specifies one mandatory to implement posture=20 transport protocol. Would it be acceptable to have multiple? Tim answered that it is better to have a minimal set of mandatory to=20 implement protocols. It makes sense for there to be one, unless there=20 are strong reasons to the contrary. Kaushik said that different PTs are optimal in different circumstances. He asked whether it would be acceptable for the WG to specify more than=20 one PT, even if only one was mandatory to implement. Tim said yes, he would be comfortable with that. Yaron Sheffer asked whether the TNC documents would be updated to match=20 that of the IETF documents. Steve said that the TNC documents are in public review status, which=20 mean they are in draft form. The goal is to make them semantically=20 equivalent to that of the IETF, even though the text of the=20 specifications may be different. There was a question whether IF-MAP as defined in the TNC would be part=20 of the revised charter.=20 Steve responded that this is not currently within the scope of the=20 charter and will probably not be part of the updated charter at this=20 time. Kaushik asked whether the charter would be opened up for other items=20 such as a protocol between the Posture Broker Server and Posture=20 Validation Server. Tim answered that there is nothing to preclude other work items from=20 being considered during the re-chartering process, but he is not=20 inclined to support opening up the kitchen sink at this point in time=20 unless there is strong WG consensus to do so. Rather, the working group=20 should focus on defining a PT. Kaushik asked whether it would cause problems to re-charter again to=20 include new work items, if the WG found that this was necessary in the=20 near future.=20 Tim said he would be open to re-chartering again, adding that WGs=20 should probably re-charter more often than they do. It does not have to=20 be done serially as has been the case so far. Kaushik said that assertion attributes and data acquisition mechanisms=20 are two examples of work items that have been discussed in the WG, but=20 have been deferred to date.=20 Tim said we should not get ahead of ourselves until there is WG=20 consensus to do so. Kaushik asked whether there is a problem with the fact that the=20 protocol name contains the name of a non-IETF organization, and whether=20 there is precedent for this. Tim did not believe this was a problem, but should verify it.=20 Discussion is to be continued on the mailing list. Meeting adjourned.