From nea-bounces@ietf.org Sat Mar 04 16:42:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFeVp-0007au-CS; Sat, 04 Mar 2006 16:42:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFdeR-0008I1-Ct for nea@ietf.org; Sat, 04 Mar 2006 15:46:55 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFdeP-0005A4-RH for nea@ietf.org; Sat, 04 Mar 2006 15:46:55 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 04 Mar 2006 12:46:54 -0800 X-IronPort-AV: i="4.02,164,1139212800"; d="txt'?scan'208,217"; a="1781944203:sNHT80330548" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k24KkqGv006272 for ; Sat, 4 Mar 2006 12:46:53 -0800 (PST) Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 4 Mar 2006 15:46:52 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C63FCC.C412A1E9" Date: Sat, 4 Mar 2006 15:46:51 -0500 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Updated problem statement I-D Thread-Index: AcY/zMO5h4OHW3KdStesitCHo6sDbg== From: "Susan Thomson $sethomso$" To: X-OriginalArrivalTime: 04 Mar 2006 20:46:52.0556 (UTC) FILETIME=[C447DCC0:01C63FCC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 510197464235b7be9252a74662931ef9 X-Mailman-Approved-At: Sat, 04 Mar 2006 16:42:04 -0500 Subject: [Nea] Updated problem statement I-D X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C63FCC.C412A1E9 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C63FCC.C412A1E9" ------_=_NextPart_002_01C63FCC.C412A1E9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have sent the updated problem statement I-D to the IETF secretariat for publication. In the meantime, have attached the document for your review. =20 The I-D has been updated to be consistent with the proposed WG charter and to take into account comments received on the mailing list. (The proposed charter will need to be tweaked to reflect new names for some of the interfaces).=20 =20 Main Changes: --- Terminology changed to that suggested by Mauricio Sanchez in his comments to mailing list --- Emphasized throughout that focus not on new architecture, but interoperability=20 --- Put an explicit stake in the ground that the initial focus is on an EAP/Radius instantiation of an NEA architecture --- Identified the 2 EAP protocols at IF-PT layer as IF-PTT (EAP tunneling method) and IF-PTC (EAP carrier protocol).=20 --- For convenience, mapped NEA terminology with that used in 3 existing architectures: TNC, NAP, NAC --- References added=20 =20 Feedback appreciated, especially where there may be lack of clarity or disagreement that may preclude a successful BoF. Better to air these on the mailing list now so that we can attempt to address them prior to the BoF. =20 Thanks Steve & Susan ------_=_NextPart_002_01C63FCC.C412A1E9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have = sent the=20 updated problem statement I-D to the IETF secretariat for publication. = In the=20 meantime, have attached the document for your = review.

The = I-D has been=20 updated to be consistent with the proposed WG charter and to take = into=20 account comments received on the mailing list. (The proposed = charter=20 will need to be tweaked to reflect new names for some of the=20 interfaces).

Main=20 Changes:

---=20 Terminology changed to that suggested by Mauricio=20 Sanchez in his comments to mailing = list

--- = Emphasized=20 throughout that focus not on new = architecture, but interoperability

--- = Put an=20 explicit stake in the ground that the initial focus is on an EAP/Radius=20 instantiation of an NEA architecture

--- = Identified the 2=20 EAP protocols at IF-PT layer as IF-PTT (EAP tunneling method) and IF-PTC = (EAP=20 carrier protocol).

--- For convenience, mapped NEA = terminology with=20 that used in 3 existing architectures: TNC, NAP,=20 NAC

--- = References added=20

Feedback appreciated, especially where there = may be=20 lack of clarity or disagreement that may preclude a successful BoF. = Better to=20 air these on the mailing list now so that we can attempt to address them = prior=20 to the BoF.

Thanks

Steve &=20 Susan

------_=_NextPart_002_01C63FCC.C412A1E9-- ------_=_NextPart_001_01C63FCC.C412A1E9 Content-Type: text/plain; name="draft-thomson-nea-problem-statement-01.txt" Content-Transfer-Encoding: base64 Content-Description: draft-thomson-nea-problem-statement-01.txt Content-Disposition: attachment; filename="draft-thomson-nea-problem-statement-01.txt" CgoKCk5ldHdvcmsgV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBTLiBIYW5uYQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIEp1bmlwZXIgTmV0d29ya3MKRXhwaXJlczogU2VwdGVtYmVyIDUs IDIwMDYgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFQuIEhhcmRqb25vCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU2ln bmFjZXJ0IEluYwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgUy4gVGhvbXNvbgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIENpc2NvIFN5c3RlbXMKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBNYXJjaCA0LCAyMDA2 CgoKICAgICAgICAgIE5ldHdvcmsgRW5kcG9pbnQgQXNzZXNzbWVudCAoTkVBKSBQcm9ibGVtIFN0 YXRlbWVudAogICAgICAgICAgICAgICBkcmFmdC10aG9tc29uLW5lYS1wcm9ibGVtLXN0YXRlbWVu dC0wMS50eHQKClN0YXR1cyBvZiB0aGlzIE1lbW8KCiAgIEJ5IHN1Ym1pdHRpbmcgdGhpcyBJbnRl cm5ldC1EcmFmdCwgZWFjaCBhdXRob3IgcmVwcmVzZW50cyB0aGF0IGFueQogICBhcHBsaWNhYmxl IHBhdGVudCBvciBvdGhlciBJUFIgY2xhaW1zIG9mIHdoaWNoIGhlIG9yIHNoZSBpcyBhd2FyZQog ICBoYXZlIGJlZW4gb3Igd2lsbCBiZSBkaXNjbG9zZWQsIGFuZCBhbnkgb2Ygd2hpY2ggaGUgb3Ig c2hlIGJlY29tZXMKICAgYXdhcmUgd2lsbCBiZSBkaXNjbG9zZWQsIGluIGFjY29yZGFuY2Ugd2l0 aCBTZWN0aW9uIDYgb2YgQkNQIDc5LgoKICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRv Y3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcKICAgVGFzayBGb3JjZSAoSUVURiks IGl0cyBhcmVhcywgYW5kIGl0cyB3b3JraW5nIGdyb3Vwcy4gIE5vdGUgdGhhdAogICBvdGhlciBn cm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC0K ICAgRHJhZnRzLgoKICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQg Zm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzCiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFj ZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55CiAgIHRpbWUuICBJdCBp cyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlCiAgIG1h dGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiIK CiAgIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBh dAogICBodHRwOi8vd3d3LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0cy50eHQuCgogICBUaGUg bGlzdCBvZiBJbnRlcm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0b3JpZXMgY2FuIGJlIGFjY2Vzc2Vk IGF0CiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwuCgogICBUaGlzIEludGVybmV0 LURyYWZ0IHdpbGwgZXhwaXJlIG9uIFNlcHRlbWJlciA1LCAyMDA2LgoKQ29weXJpZ2h0IE5vdGlj ZQoKICAgQ29weXJpZ2h0IChDKSBUaGUgSW50ZXJuZXQgU29jaWV0eSAoMjAwNikuCgpBYnN0cmFj dAoKICAgQXJjaGl0ZWN0dXJlcyBoYXZlIGJlZW4gaW1wbGVtZW50ZWQgaW4gdGhlIGluZHVzdHJ5 IHRvIGFzc2VzcyB0aGUKICAgc29mdHdhcmUgb3IgaGFyZHdhcmUgY29uZmlndXJhdGlvbiBvZiBl bmRwb2ludCBkZXZpY2VzIGZvciB0aGUKICAgcHVycG9zZXMgb2YgbW9uaXRvcmluZyBvciBlbmZv cmNpbmcgY29tcGxpYW5jZSBvZiBlbmRwb2ludHMgdG8gYW4KICAgb3JnYW5pemF0aW9uJ3MgcG9s aWN5IG9uIGFjY2VzcyB0byB0aGUgbmV0d29yay4gIFRoZXNlIGFyY2hpdGVjdHVyZXMKICAgYXJl IG5vdCBmdWxseSBpbnRlcm9wZXJhYmxlIHNpbmNlIHNvbWUgb2YgdGhlIHByb3RvY29scyB1c2Vk IHRvCgoKCkhhbm5hLCBldCBhbC4gICAgICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDUsIDIwMDYg ICAgICAgICAgICAgICBbUGFnZSAxXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgTkVBIFBy b2JsZW0gU3RhdGVtZW50ICAgICAgICAgICAgICAgTWFyY2ggMjAwNgoKCiAgIGltcGxlbWVudCB0 aGUgYXJjaGl0ZWN0dXJlIGFyZSBub3Qgc3RhbmRhcmRzLgoKICAgVGhpcyBkb2N1bWVudCBkZXNj cmliZXMgdGhlIHByb2JsZW0gdGhlc2UgYXJjaGl0ZWN0dXJlcyBhcmUgaW50ZW5kaW5nCiAgIHRv IGFkZHJlc3MsIGRlZmluZXMgY29tbW9uIHRlcm1pbm9sb2d5IGFuZCBjb25jZXB0cywgYW5kIGlk ZW50aWZpZXMKICAgaW50ZXJmYWNlcyB0aGF0IGFyZSBjYW5kaWRhdGVzIGZvciBzdGFuZGFyZGl6 YXRpb24uCgoKUmVxdWlyZW1lbnRzIExhbmd1YWdlCgogICBUaGUga2V5IHdvcmRzICJNVVNUIiwg Ik1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsCiAgICJTSE9VTEQi LCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0 aGlzCiAgIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gUkZD IDIxMTkgW1JGQzIxMTldLgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpI YW5uYSwgZXQgYWwuICAgICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciA1LCAyMDA2ICAgICAgICAg ICAgICAgW1BhZ2UgMl0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgIE5FQSBQcm9ibGVtIFN0 YXRlbWVudCAgICAgICAgICAgICAgIE1hcmNoIDIwMDYKCgpUYWJsZSBvZiBDb250ZW50cwoKICAg MS4gIEludHJvZHVjdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICA0CiAgIDIuICBUZXJtaW5vbG9neSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNAogICAzLiAgUHJvYmxlbSBTdGF0ZW1lbnQgIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDUKICAgNC4gIEdvYWxz ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICA2CiAgIDUuICBEZXBsb3ltZW50IFNjZW5hcmlvcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgNwogICAgIDUuMS4gIFdpcmVkIExBTiBhY2Nlc3MgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDcKICAgICA1LjIuICBXaXJlbGVzcyBM QU4gQWNjZXNzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA3CiAgICAg NS4zLiAgUmVtb3RlIGFjY2VzcyBWUE4gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgOAogICAgIDUuNC4gIEdhdGV3YXkgQWNjZXNzIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDgKICAgNi4gIENvbXBvbmVudHMgYW5kIEludGVyZmFj ZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA4CiAgICAgNi4xLiAgTWFw cGluZyB0byBleGlzdGluZyBhcmNoaXRlY3R1cmVzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg OQogICAgIDYuMi4gIENvbXBvbmVudHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gMTAKICAgICAgIDYuMi4xLiAgTkVBIENsaWVudCAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEwCiAgICAgICA2LjIuMi4gIE5ldHdvcmsg ZW5mb3JjZXIgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMQogICAgICAg Ni4yLjMuICBORUEgc2VydmVyIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gMTIKICAgICA2LjMuICBJbnRlcmZhY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEzCiAgICAgICA2LjMuMS4gIFBvc3R1cmUgQXR0cmlidXRl IGludGVyZmFjZSAoSUYtUEEpICAuIC4gLiAuIC4gLiAuIC4gLiAxMwogICAgICAgNi4zLjIuICBQ b3N0dXJlIEJyb2tlciBJbnRlcmZhY2UgKElGLVBCKSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTMK ICAgICAgIDYuMy4zLiAgUG9zdHVyZSBUcmFuc3BvcnQgSW50ZXJmYWNlIChJRi1QVCkgIC4gLiAu IC4gLiAuIC4gLiAuIDEzCiAgICAgICA2LjMuNC4gIE5ldHdvcmsgQWNjZXNzIEVuZm9yY2VtZW50 IEludGVyZmFjZSAoSUYtTkFFKSAgLiAuIC4gLiAxMwogICAgICAgNi4zLjUuICBQb3N0dXJlIFZh bGlkYXRpb24gSW50ZXJmYWNlIChJRi1QVikgLiAuIC4gLiAuIC4gLiAuIC4gMTQKICAgNy4gIFNj b3BlIG9mIFN0YW5kYXJkaXphdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIDE0CiAgIDguICBJQU5BIENvbnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAxNQogICA5LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTUKICAgICA5LjEuICBTZWN1cmUg Y2hhbm5lbCBiZXR3ZWVuIHRoZSBDbGllbnQgQnJva2VyIGFuZCBTZXJ2ZXIKICAgICAgICAgICBC cm9rZXIgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IDE2CiAgICAgOS4yLiAgQXV0aG9yaXphdGlvbiBmb3IgUGx1Zy1pbi9Ccm9rZXIgaW50ZXJhY3Rp b24gLiAuIC4gLiAuIC4gLiAxNgogICAgIDkuMy4gIFNlbGYtSW50ZWdyaXR5IG9mIHRoZSBORUEg Q2xpZW50IGFuZCBORUEgU2VydmVyICAuIC4gLiAuIC4gMTYKICAgICA5LjQuICBQcm90ZWN0aW9u IG9mIHBhcmFtZXRlcnMgZXhjaGFuZ2VkIGFjcm9zcyBJbnRlcmZhY2VzIC4gLiAuIDE2CiAgICAg OS41LiAgSWRlbnRpdHkgYXV0aGVudGljYXRpb24gb2YgY29tbXVuaWNhdGluZyBlbmQtcG9pbnRz ICAuIC4gLiAxNwogICAxMC4gQWNrbm93bGVkZ2VtZW50cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTcKICAgMTEuIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE3CiAgICAgMTEuMS4gTm9y bWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAx NwogICAgIDExLjIuIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gMTgKICAgQXV0aG9ycycgQWRkcmVzc2VzIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE5CiAgIEludGVsbGVjdHVhbCBQcm9wZXJ0 eSBhbmQgQ29weXJpZ2h0IFN0YXRlbWVudHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAyMAoKCgoKCgoK CgoKCgoKSGFubmEsIGV0IGFsLiAgICAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgNSwgMjAwNiAg ICAgICAgICAgICAgIFtQYWdlIDNdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICBORUEgUHJv YmxlbSBTdGF0ZW1lbnQgICAgICAgICAgICAgICBNYXJjaCAyMDA2CgoKMS4gIEludHJvZHVjdGlv bgoKICAgQXJjaGl0ZWN0dXJlcyBoYXZlIGJlZW4gaW1wbGVtZW50ZWQgaW4gdGhlIGluZHVzdHJ5 LCBlLmcuICBbVE5DLCBOQVAsCiAgIE5BQ10sIHRvIGFzc2VzcyB0aGUgc29mdHdhcmUgb3IgaGFy ZHdhcmUgY29uZmlndXJhdGlvbiBvZiBlbmRwb2ludAogICBkZXZpY2VzIGZvciB0aGUgcHVycG9z ZXMgb2YgbW9uaXRvcmluZyBvciBlbmZvcmNpbmcgY29tcGxpYW5jZSBvZgogICBlbmRwb2ludHMg dG8gYW4gb3JnYW5pemF0aW9uJ3MgcG9saWN5IG9uIGFjY2VzcyB0byB0aGUgbmV0d29yay4KICAg VGhlc2UgYXJjaGl0ZWN0dXJlcyBhcmUgbm90IGZ1bGx5IGludGVyb3BlcmFibGUgc2luY2Ugc29t ZSBvZiB0aGUKICAgcHJvdG9jb2xzIHVzZWQgdG8gaW1wbGVtZW50IHRoZSBhcmNoaXRlY3R1cmUg YXJlIG5vdCBzdGFuZGFyZHMuCgogICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyB0aGUgcHJvYmxl bSB0aGVzZSBhcmNoaXRlY3R1cmVzIGFyZSBpbnRlbmRpbmcKICAgdG8gYWRkcmVzcywgZGVmaW5l cyBjb21tb24gdGVybWlub2xvZ3kgYW5kIGNvbmNlcHRzLCBhbmQgaWRlbnRpZmllcwogICBpbnRl cmZhY2VzIHRoYXQgYXJlIGNhbmRpZGF0ZXMgZm9yIHN0YW5kYXJkaXphdGlvbi4KCiAgIE5vdGUg dGhhdCB0aGlzIGRvY3VtZW50IGlzIG5vdCBpbnRlbmRlZCB0byBkZWZpbmUgYSBuZXcgYXJjaGl0 ZWN0dXJlCiAgIG9yIGZyYW1ld29yayBmb3IgbmV0d29yayBlbmRwb2ludCBhc3Nlc3NtZW50LiAg VGhlcmUgYXJlIGFscmVhZHkKICAgc2V2ZXJhbCBleGlzdGluZyBhcmNoaXRlY3R1cmVzIGZvciB0 aGlzIHB1cnBvc2UuICBUaGUgbmV0d29yawogICBlbmRwb2ludCBhc3Nlc3NtZW50IGVmZm9ydCBh aW1zIG9ubHkgdG8gaWRlbnRpZnkgY29tbW9uIGludGVyZmFjZXMKICAgdGhhdCBhcmUgdXNlZCBp biB0aGVzZSBhcmNoaXRlY3R1cmVzLCBhbmQgZGVmaW5lIHN0YW5kYXJkIHByb3RvY29scwogICB0 aGF0IGNhbiBiZSB1c2VkIGJ5IHRoZSBleGlzdGluZyBhcmNoaXRlY3R1cmVzIHRvIHJlZHVjZSBk dXBsaWNhdGlvbgogICBhbmQgYWNoaWV2ZSBpbnRlcm9wZXJhYmlsaXR5LgoKCjIuICBUZXJtaW5v bG9neQoKICAgRW5kcG9pbnQ6IEFuIGVuZHBvaW50IGlzIGEgaG9zdCBjb25uZWN0ZWQgdG8gdGhl IG5ldHdvcmsuICBUaGlzIGJyb2FkCiAgIGRlZmluaXRpb24gaW5jbHVkZXMgKGJ1dCBpcyBub3Qg bGltaXRlZCB0bykgZGVza3RvcCBvciBsYXB0b3AKICAgY29tcHV0ZXJzLCBzZXJ2ZXJzLCBwaG9u ZXMsIHByaW50ZXJzLgoKICAgUG9zdHVyZTogUG9zdHVyZSByZWZlcnMgdG8gdGhlIGhhcmR3YXJl IG9yIHNvZnR3YXJlIGNvbmZpZ3VyYXRpb24gb2YKICAgYW4gZW5kcG9pbnQgYXMgaXQgcGVydGFp bnMgdG8gYW4gb3JnYW5pemF0aW9uJ3Mgc2VjdXJpdHkgcG9saWN5LgogICBQb3N0dXJlIG1heSBp bmNsdWRlIGtub3dsZWRnZSBhYm91dCB0aGUgdHlwZXMgb2YgaGFyZHdhcmUgYW5kCiAgIHNvZnR3 YXJlIGluc3RhbGxlZCBhbmQgdGhlaXIgY29uZmlndXJhdGlvbnMsIGUuZy4gIE9TIG5hbWUgYW5k CiAgIHZlcnNpb24sIGFwcGxpY2F0aW9uIHBhdGNoIGxldmVscywgYW5kIGFudGktdmlydXMgc2ln bmF0dXJlIGZpbGUKICAgdmVyc2lvbi4KCiAgIE5FQSBjbGllbnQ6IFRoZSBORUEgY2xpZW50IGlz IGEgc2V0IG9mIHNvZnR3YXJlIGNvbXBvbmVudHMgb24gdGhlCiAgIGVuZHBvaW50IHRoYXQgcmVx dWVzdCBhY2Nlc3MgdG8gdGhlIG5ldHdvcmsuICBUaGUgTkVBIGNsaWVudAogICBjb21wcmlzZXMg dGhyZWUgbG9naWNhbCBjb21wb25lbnRzOiBQb3N0dXJlIGNvbGxlY3RvciwgQ2xpZW50IGJyb2tl cgogICBhbmQgTmV0d29yayBhY2Nlc3MgcmVxdWVzdG9yLgoKICAgUG9zdHVyZSBjb2xsZWN0b3I6 IEEgUG9zdHVyZSBjb2xsZWN0b3IgaXMgdGhlIGNvbXBvbmVudCBvZiB0aGUgTkVBCiAgIGNsaWVu dCB0aGF0IGlzIHJlc3BvbnNpYmxlIGZvciBjb2xsZWN0aW5nIGFuZCBtYWludGFpbmluZyBwb3N0 dXJlCiAgIGluZm9ybWF0aW9uIGFib3V0IHRoZSBlbmRwb2ludCBkZXZpY2UuICBUaGVyZSBtYXkg YmUgbXVsdGlwbGUgTkVBCiAgIFBvc3R1cmUgY29sbGVjdG9ycyBvbiBhbiBlbmRwb2ludCBkZXZp Y2UgZWFjaCB0YXJnZXRlZCBhdCBhCiAgIHBhcnRpY3VsYXIgc2VjdXJpdHkgYXBwbGljYXRpb24g ZnJvbSBhIHBhcnRpY3VsYXIgdmVuZG9yLgoKICAgQ2xpZW50IGJyb2tlcjogQSBDbGllbnQgYnJv a2VyIGlzIHRoZSBjb21wb25lbnQgb2YgdGhlIE5FQSBjbGllbnQKICAgdGhhdCBhZ2dyZWdhdGVz IHBvc3R1cmUgaW5mb3JtYXRpb24gZnJvbSBtdWx0aXBsZSBQb3N0dXJlIGNvbGxlY3RvcnMuCgoK Ckhhbm5hLCBldCBhbC4gICAgICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDUsIDIwMDYgICAgICAg ICAgICAgICBbUGFnZSA0XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgTkVBIFByb2JsZW0g U3RhdGVtZW50ICAgICAgICAgICAgICAgTWFyY2ggMjAwNgoKCiAgIE5ldHdvcmsgYWNjZXNzIHJl cXVlc3RvcjogVGhlIE5ldHdvcmsgYWNjZXNzIHJlcXVlc3RvciBpcyB0aGUKICAgY29tcG9uZW50 IG9mIHRoZSBORUEgY2xpZW50IHJlc3BvbnNpYmxlIGZvciByZXF1ZXN0aW5nIGFjY2VzcyB0byB0 aGUKICAgbmV0d29yay4KCiAgIE5ldHdvcmsgZW5mb3JjZXI6IFRoZSBOZXR3b3JrIGVuZm9yY2Vy IGlzIGEgbmV0d29yayBjb21wb25lbnQgdGhhdAogICBjb250cm9scyBlbmRwb2ludCBhY2Nlc3Mg dG8gdGhlIHVwc3RyZWFtIG5ldHdvcmsuICBJdCBlbmZvcmNlcwogICBuZXR3b3JrIGF1dGhvcml6 YXRpb24gZGVjaXNpb25zIGZyb20gdGhlIG5ldHdvcmsgYWNjZXNzIGF1dGhvcml0eS4KCiAgIE5F QSBzZXJ2ZXI6IFRoZSBORUEgc2VydmVyIGlzIGEgc2VydmVyIHRoYXQgZXZhbHVhdGVzIHRoZSBw b3N0dXJlIG9mCiAgIGFuIGVuZHBvaW50IGRldmljZSBhbmQgcHJvdmlkZXMgbmV0d29yayBhdXRo b3JpemF0aW9uIGRlY2lzaW9ucy4gIFRoZQogICBORUEgc2VydmVyIGNvbXByaXNlcyB0aHJlZSBs b2dpY2FsIGNvbXBvbmVudHM6IFBvc3R1cmUgdmFsaWRhdG9yLAogICBTZXJ2ZXIgYnJva2VyIGFu ZCBOZXR3b3JrIGFjY2VzcyBhdXRob3JpdHkuCgogICBQb3N0dXJlIHZhbGlkYXRvcjogQSBQb3N0 dXJlIHZhbGlkYXRvciBpcyB0aGUgbG9naWNhbCBjb21wb25lbnQgb2YKICAgdGhlIE5FQSBzZXJ2 ZXIgdGhhdCBhc3Nlc3NlcyBwb3N0dXJlIGluZm9ybWF0aW9uIGZyb20gYSBQb3N0dXJlCiAgIGNv bGxlY3RvciBhbmQgZGV0ZXJtaW5lcyB0aGUgcmVzdWx0IG9mIHRoZSBhc3Nlc3NtZW50LiAgVGhl cmUgbWF5IGJlCiAgIG11bHRpcGxlIFBvc3R1cmUgdmFsaWRhdG9ycyBlYWNoIHRhcmdldGVkIGF0 IGEgcGFydGljdWxhciBzZWN1cml0eQogICBhcHBsaWNhdGlvbiBmcm9tIGEgcGFydGljdWxhciB2 ZW5kb3IuCgogICBTZXJ2ZXIgYnJva2VyOiBBIFNlcnZlciBicm9rZXIgaXMgdGhlIGNvbXBvbmVu dCBvZiB0aGUgTkVBIHNlcnZlcgogICB0aGF0IGFnZ3JlZ2F0ZXMgcG9zdHVyZSBpbmZvcm1hdGlv biBmcm9tIG11bHRpcGxlIHBvc3R1cmUgc2VydmVycy4KCiAgIE5ldHdvcmsgYWNjZXNzIGF1dGhv cml0eTogVGhlIE5ldHdvcmsgYWNjZXNzIGF1dGhvcml0eSBpcyB0aGUKICAgY29tcG9uZW50IG9m IHRoZSBORUEgc2VydmVyIHRoYXQgYXV0aG9yaXplcyBlbmRwb2ludHMgYmFzZWQgb24gYQogICBu dW1iZXIgb2YgY3JpdGVyaWEgaW5jbHVkaW5nIHRoZSBpZGVudGl0eSBvZiBhbiBlbmRwb2ludCBt YWNoaW5lCiAgIGFuZC9vciB1c2VyIGFzIHdlbGwgYXMgdGhlIHJlc3VsdHMgb2YgcG9zdHVyZSBh c3Nlc3NtZW50LgoKCjMuICBQcm9ibGVtIFN0YXRlbWVudAoKICAgTmV0d29yayBlbmRwb2ludCBh c3Nlc3NtZW50IChORUEpIGFyY2hpdGVjdHVyZXMgYXJlIHN5c3RlbXMgdGhhdAogICBlbmFibGUg dGhlIG5ldHdvcmsgdG8gbGVhcm4gdGhlIHBvc3R1cmUgb2YgYW4gZW5kcG9pbnQgZGV2aWNlLCBh bmQKICAgb3B0aW9uYWxseSB1c2UgdGhhdCBpbmZvcm1hdGlvbiBpbiBhZGRpdGlvbiB0byBtYWNo aW5lIG9yIHVzZXIKICAgYXV0aGVudGljYXRpb24gdG8gaW5mbHVlbmNlIGEgbmV0d29yayBhZG1p c3Npb24gZGVjaXNpb24uICBFbmRwb2ludAogICBwb3N0dXJlIG1heSBpbmNsdWRlIGluZm9ybWF0 aW9uIGFib3V0IHRoZSBvcGVyYXRpbmcgc3lzdGVtIGFzIHdlbGwgYXMKICAgaW5mb3JtYXRpb24g YWJvdXQgc2VjdXJpdHkgYXBwbGljYXRpb25zIHJ1bm5pbmcgb24gdGhlIGVuZHBvaW50IHN1Y2gK ICAgYXMgYW50aS12aXJ1cyBzb2Z0d2FyZSwgcGVyc29uYWwgZmlyZXdhbGxzIGFuZCBob3N0IGlu dHJ1c2lvbgogICBwcm90ZWN0aW9uIHN5c3RlbXMuCgogICBORUEgdGVjaG5vbG9neSBtYXkgYmUg dXNlZCBmb3Igc2V2ZXJhbCBwdXJwb3Nlcy4gIE9uZSBwdXJwb3NlIGlzIHRvCiAgIG1vbml0b3Ig b3IgZW5mb3JjZSBjb21wbGlhbmNlIG9mIGVuZHBvaW50cyB0byB0aGUgb3JnYW5pemF0aW9uJ3MK ICAgc2VjdXJpdHkgcG9saWN5LiAgT3JnYW5pemF0aW9ucyBvZnRlbiByZXF1aXJlIGVuZHBvaW50 cyB0aGF0IGFyZQogICB2dWxuZXJhYmxlIHRvIGF0dGFjayB0aHJvdWdoIHZpcnVzZXMsIHdvcm1z IGFuZCBvdGhlciBleHBsb2l0cyB0byBydW4KICAgYW4gSVQtc3BlY2lmaWVkIE9TIGNvbmZpZ3Vy YXRpb24gYW5kIGhhdmUgY2VydGFpbiBzZWN1cml0eQogICBhcHBsaWNhdGlvbnMgZW5hYmxlZCwg ZS5nLiBhbnRpLXZpcnVzIHNvZnR3YXJlLCBob3N0IGludHJ1c2lvbgogICBwcm90ZWN0aW9uIHN5 c3RlbXMsIHBlcnNvbmFsIGZpcmV3YWxscywgYW5kIHBhdGNoIG1hbmFnZW1lbnQKICAgc29mdHdh cmUuICBXaXRob3V0IE5FQSB0ZWNobm9sb2d5LCBlbnN1cmluZyBjb21wbGlhbmNlIG9mIGVuZHBv aW50cwogICB0byBjb3Jwb3JhdGUgcG9saWN5IGlzIGEgdGltZS1jb25zdW1pbmcgYW5kIGRpZmZp Y3VsdCB0YXNrLiAgTm90IGFsbAoKCgpIYW5uYSwgZXQgYWwuICAgICAgICAgICBFeHBpcmVzIFNl cHRlbWJlciA1LCAyMDA2ICAgICAgICAgICAgICAgW1BhZ2UgNV0KDApJbnRlcm5ldC1EcmFmdCAg ICAgICAgICAgIE5FQSBQcm9ibGVtIFN0YXRlbWVudCAgICAgICAgICAgICAgIE1hcmNoIDIwMDYK CgogICBlbmRwb2ludHMgYXJlIG1hbmFnZWQgYnkgYSBjb3Jwb3JhdGlvbidzIElUIG9yZ2FuaXph dGlvbiwgZS5nLiBsYWIKICAgYXNzZXRzLCBndWVzdCBtYWNoaW5lcy4gIEV2ZW4gZm9yIGFzc2V0 cyB0aGF0IGFyZSBtYW5hZ2VkLCB0aGV5IG1heQogICBub3QgcmVjZWl2ZSB1cGRhdGVzIGluIGEg dGltZWx5IGZhc2hpb24gYmVjYXVzZSB0aGV5IGFyZSBub3QKICAgcGVybWFuZW50bHkgYXR0YWNo ZWQgdG8gdGhlIGNvcnBvcmF0ZSBuZXR3b3JrLCBlLmcuIGxhcHRvcHMuICBXaXRoCiAgIE5FQSB0 ZWNobm9sb2d5LCB0aGUgbmV0d29yayBpcyBhYmxlIHRvIGFzc2VzcyBhbiBlbmRwb2ludCB3aGVu IGl0CiAgIGFjY2Vzc2VzIHRoZSBuZXR3b3JrIGFuZCB3aGlsZSBjb25uZWN0ZWQsIHByb3ZpZGlu ZyBhbiBvcHBvcnR1bml0eSB0bwogICBtb25pdG9yIGNvbXBsaWFuY2Ugb2YgYWxsIGVuZHBvaW50 cyB1c2luZyB0aGUgbmV0d29yayBhcyB3ZWxsIGFzCiAgIHByb3ZpZGluZyB0aGUgb3Bwb3J0dW5p dHkgdG8gaW1wcm92ZSBlbmRwb2ludCBjb21wbGlhbmNlLiAgVGhlCiAgIGRlY2lzaW9uIGZvciBo b3cgdG8gaGFuZGxlIG5vbi1jb21wbGlhbnQgZW5kcG9pbnRzIGlzIHVwIHRvIHRoZQogICBuZXR3 b3JrIGFkbWluaXN0cmF0b3IuICBSZW1lZGlhdGlvbiBpbnN0cnVjdGlvbnMgb3Igd2FybmluZ3Mg bWF5IGJlCiAgIHNlbnQgdG8gdGhlIGVuZHBvaW50LiAgQWxzbywgbmV0d29yayBhY2Nlc3MgbWF5 IGJlIHJlc3RyaWN0ZWQgdG8KICAgcHJvdGVjdCB0aGUgZW5kcG9pbnQgZnJvbSBpbmZlY3Rpb24g YW5kIHRvIHByb3RlY3QgdGhlIG5ldHdvcmsgaW4KICAgY2FzZSB0aGUgZW5kcG9pbnQgaXMgYWxy ZWFkeSBpbmZlY3RlZC4KCiAgIEFub3RoZXIgdXNlIG9mIE5FQSB0ZWNobm9sb2d5IG1heSBiZSB0 byBzdXBwbGVtZW50IGluZm9ybWF0aW9uIGluCiAgIGludmVudG9yeSBkYXRhYmFzZXMuICBJbiBv cmdhbml6YXRpb25zIHRoYXQgYXR0ZW1wdCB0byBrZWVwIHRyYWNrIG9mCiAgIHRoZWlyIGFzc2V0 cywgaW52ZW50b3J5IGRhdGFiYXNlcyB0ZW5kIHRvIGJlIGluY29tcGxldGUgYW5kIG91dC1vZi0K ICAgZGF0ZS4gIE5FQSB0ZWNobm9sb2d5IG1heSBiZSB1c2VkIHRvIHZlcmlmeSBvciBzdXBwbGVt ZW50IGluZm9ybWF0aW9uCiAgIHN0b3JlZCBhYm91dCBhbiBvcmdhbml6YXRpb24ncyBhc3NldHMu CgogICBBcyBoYXMgYmVlbiBtZW50aW9uZWQsIG1hbnkgTkVBIGFyY2hpdGVjdHVyZXMgaGF2ZSBi ZWVuIGRldmVsb3BlZCBpbgogICB0aGUgaW5kdXN0cnkgdG8gYWRkZXNzIHRoZSBhYm92ZSBwdXJw b3Nlcy4gIENlcnRhaW4gaW5zdGFudGlhdGlvbnMgb2YKICAgdGhlc2UgYXJjaGl0ZWN0dXJlcyBs ZXZlcmFnZSB0aGUgRUFQIGZyYW1ld29yayB0byBlbmFibGUgbmV0d29yawogICBhZG1pc3Npb24g ZGVjaXNpb25zIHRvIGJlIGJhc2VkIG9uIGJvdGggYXV0aGVudGljYXRpb24gYW5kIHBvc3R1cmUK ICAgYXNzZXNzbWVudC4gIEhvd2V2ZXIsIHdoaWxlIHRoZXNlIGluc3RhbnRpYXRpb25zIGxldmVy YWdlIHN0YW5kYXJkCiAgIHByb3RvY29scyB0byB0aGUgZXh0ZW50IHBvc3NpYmxlLCBlLmcuIDgw Mi4xWFs4MDIuMVhdLCBFQVBbRUFQXSBhbmQKICAgUkFESVVTW1JBRElVU10sIHRoZXNlIGFyY2hp dGVjdHVyZXMgYXJlIHN0aWxsIG5vdCBmdWxseSBpbnRlcm9wZXJhYmxlCiAgIGJlY2F1c2Ugb3Ro ZXIgbmVlZGVkIHByb3RvY29scyBoYXZlIG5vdCBiZWVuIHN0YW5kYXJkaXplZC4gIFRoZQogICBp bnRlbnQgb2YgdGhlIHByb3Bvc2VkIE5FQSBlZmZvcnQgaXMgdG8gaWRlbnRpZnkgdGhvc2UgaW50 ZXJmYWNlcwogICB3aGVyZSBzdGFuZGFyaXphdGlvbiBpcyBuZWVkZWQgaW4gdGhlIElFVEYsIGRl ZmluZSByZXF1aXJlbWVudHMgZm9yCiAgIHRoZXNlIGludGVyZmFjZXMsIGFuZCB3b3JrIHdpdGhp biB0aGUgSUVURiB0byBkZWZpbmUgc3RhbmRhcmRzIHRvCiAgIG1lZXQgdGhlc2UgcmVxdWlyZW1l bnRzLgoKCjQuICBHb2FscwoKICAgVGhlIGdvYWxzIG9mIGFyY2hpdGVjdHVyZXMgdGhhdCBzdXBw b3J0IG5ldHdvcmsgYXNzZXNzbWVudCB0ZWNobm9sb2d5CiAgIGluY2x1ZGUgc29tZSBvciBhbGwg b2YgdGhlIGZvbGxvd2luZzoKCiAgIG8gIFN1cHBvcnQgYXNzZXNzbWVudCBvZiBlbmRwb2ludHMg YWNyb3NzIGEgcmFuZ2Ugb2YgbmV0d29yayBhY2Nlc3MKICAgICAgdGVjaG5vbG9naWVzLCBsZXZl cmFnaW5nIGV4aXN0aW5nIHRlY2hub2xvZ3kgdG8gdGhlIGV4dGVudAogICAgICBwb3NzaWJsZQoK ICAgbyAgU3VwcG9ydCBhdXRob3JpemF0aW9uIGRlY2lzaW9ucyBiYXNlZCBvbiBhdXRoZW50aWNh dGlvbiBvZiB1c2VyIG9yCiAgICAgIGVuZHBvaW50IGRldmljZSwgYXNzZXNzbWVudCBvZiB0aGUg c3RhdGUgb2YgdGhlIGVuZHBvaW50IGRldmljZSwKICAgICAgb3IgYm90aAoKCgoKCkhhbm5hLCBl dCBhbC4gICAgICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDUsIDIwMDYgICAgICAgICAgICAgICBb UGFnZSA2XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgTkVBIFByb2JsZW0gU3RhdGVtZW50 ICAgICAgICAgICAgICAgTWFyY2ggMjAwNgoKCiAgIG8gIFN1cHBvcnQgZW5kcG9pbnQgYXNzZXNz bWVudCBhdCB2YXJpb3VzIGxvY2F0aW9ucyBpbiB0aGUgbmV0d29yawogICAgICBpLmUuIGF0IGEg TDIgaG9wIG9yIGEgTDMgaG9wLCBib3RoIG9mIHdoaWNoIG1heSBiZSBhIHNpbmdsZSBob3Agb3IK ICAgICAgbXVsdGlwbGUgaG9wcyBhd2F5IGZyb20gdGhlIGVuZHBvaW50LgoKICAgbyAgU3VwcG9y dCBlbmRwb2ludCBhc3Nlc3NtZW50IGF0IHBvc3NpYmx5IG11bHRpcGxlIGhvcHMgb24gYSBwYXRo CiAgICAgIGUuZy4gYXQgYm90aCBhIEwyIGFuZCBhIEwzIGhvcAoKICAgbyAgU3VwcG9ydCBuZXR3 b3JrIGlzb2xhdGlvbiBvZiBub24tY29tcGxpYW50IGVuZHBvaW50cyBmcm9tCiAgICAgIGNvbXBs aWFudCBlbmRwb2ludHMgZm9yIHJlbWVkaWF0aW9uIG9yIG90aGVyIHB1cnBvc2VzCgogICBvICBT dXBwb3J0IGVuZHBvaW50IHJlLWFzc2Vzc21lbnQgd2hlbiBzdGF0ZSBvZiBlbmRwb2ludHMgY2hh bmdlLCBvcgogICAgICBydWxlcyBpbiB0aGUgTkVBIHNlcnZlciBjaGFuZ2UKCiAgIG8gIEVuYWJs ZSBpbnRlZ3JhdGlvbiBvZiAzcmQtcGFydHkgc2VjdXJpdHkgYXBwbGljYXRpb25zIHNvIHRoYXQg b25lCiAgICAgIG9yIG1vcmUgYXBwbGljYXRpb25zIGNhbiBhc3Nlc3MgdGhlIHBvc3R1cmUgb2Yg YW4gZW5kcG9pbnQgYW5kIHRoZQogICAgICBhZ2dyZWdhdGUgb2YgYWxsIHJlc3VsdHMgY2FuIGJl IHVzZWQgaW4gbmV0d29yayBhZG1pc3Npb24KICAgICAgZGVjaXNpb25zLgoKICAgbyAgU3VwcG9y dCBlbmRwb2ludHMgd2l0aCBhIE5FQSBjbGllbnQgYW5kIHdpdGhvdXQgYSBjbGllbnQKCgo1LiAg RGVwbG95bWVudCBTY2VuYXJpb3MKCiAgIE5ldHdvcmsgYXNzZXNzbWVudCBhcmNoaXRlY3R1cmVz IGhhdmUgYmVlbiB0YXJnZXRlZCBwcmltYXJpbHkgYXQKICAgZW50ZXJwcmlzZSBkZXBsb3ltZW50 IHNjZW5hcmlvcyB0byBkYXRlLlRoZSBkZXBsb3ltZW50IHNjZW5hcmlvcwogICBpbmNsdWRlOgoK NS4xLiAgV2lyZWQgTEFOIGFjY2VzcwoKICAgSW4gdGhpcyBkZXBsb3ltZW50IHNjZW5hcmlvLCBu ZXR3b3JrIGFkbWlzc2lvbiBjb250cm9sIHdvdWxkCiAgIHR5cGljYWxseSB0YWtlIHBsYWNlIGF0 IHRoZSBmaXJzdCBMMiBob3AgZnJvbSB0aGUgZW5kcG9pbnQgaS5lLiBhCiAgIHN3aXRjaCBwb3J0 LiAgSG93ZXZlciwgdGhlcmUgYXJlIGNhc2VzIHdoZXJlIHRoZSBmaXJzdCBMMiBkZXZpY2UgbWF5 CiAgIG5vdCBzdXBwb3J0IG5ldHdvcmsgZW5kcG9pbnQgYXNzZXNzbWVudCBmb3Igc29tZSByZWFz b24sIGFuZCBuZXR3b3JrCiAgIGVuZHBvaW50IGFzc2Vzc21lbnQgbWF5IGhhcHBlbiBiZWhpbmQg dGhlIGZpcnN0IGhvcCwgZS5nLiBhIHN3aXRjaAogICBiZWhpbmQgYSB3aXJlbGVzcyBhY2Nlc3Mg cG9pbnQuCgogICBXaXJlZCBMQU4gYWNjZXNzIGRlcGxveW1lbnQgc2NlbmFyaW9zIG1heSBuZWVk IHRvIHN1cHBvcnQgc2luZ2xlIG9yCiAgIG11bHRpcGxlIGhvc3RzIHBlciBzd2l0Y2ggcG9ydC4g IERlcGxveW1lbnQgc2NlbmFyaW9zIHdpdGggbXVsdGlwbGUKICAgaG9zdHMgcGVyIHBvcnQgaW5j bHVkZSBJUCBwaG9uZXMgKyBQQywgb3IgbXVsdGlwbGUgUENzIGNvbm5lY3RlZAogICBiZWhpbmQg YSBodWIuCgogICA4MDIuMVggaXMgYW4gZXhhbXBsZSBvZiBhIHN0YW5kYXJkcy1iYXNlZCBuZXR3 b3JrIGFjY2VzcyB0ZWNobm9sb2d5CiAgIHRoYXQgc3VwcG9ydHMgYWNjZXNzIGNvbnRyb2wgYmFz ZWQgb24gYXV0aGVudGljYXRpb24gZm9yIGEgc2luZ2xlCiAgIGhvc3QgcGVyIHBvcnQgaW4gZmly c3QgTDIgaG9wIGRlcGxveW1lbnQgc2NlbmFyaW9zLgoKNS4yLiAgV2lyZWxlc3MgTEFOIEFjY2Vz cwoKICAgSW4gdGhpcyBkZXBsb3ltZW50IHNjZW5hcmlvLCBuZXR3b3JrIGFkbWlzc2lvbiBjb250 cm9sIHdvdWxkCgoKCkhhbm5hLCBldCBhbC4gICAgICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDUs IDIwMDYgICAgICAgICAgICAgICBbUGFnZSA3XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAg TkVBIFByb2JsZW0gU3RhdGVtZW50ICAgICAgICAgICAgICAgTWFyY2ggMjAwNgoKCiAgIHR5cGlj YWxseSB0YWtlIHBsYWNlIGF0IHRoZSBmaXJzdCBMMiBob3AgZnJvbSB0aGUgZW5kcG9pbnQgaS5l LiBhCiAgIHdpcmVsZXNzIGFjY2VzcyBwb2ludC4gIFdpcmVsZXNzIExBTiBhY2Nlc3Mgc3VwcG9y dHMgbXVsdGlwbGUgaG9zdHMKICAgcGVyIHdpcmVsZXNzIGFjY2VzcyBwb2ludC4KCiAgIDgwMi4x MSBpcyBhIHN0YW5kYXJkcy1iYXNlZCBuZXR3b3JrIGFjY2VzcyB0ZWNobm9sb2d5IHRoYXQgc3Vw cG9ydHMKICAgd2lyZWxlc3MgYWNjZXNzIGNvbnRyb2wgYmFzZWQgb24gYXV0aGVudGljYXRpbmcg dGhlIGVuZHBvaW50LgoKNS4zLiAgUmVtb3RlIGFjY2VzcyBWUE4KCiAgIEluIHRoaXMgZGVwbG95 bWVudCBzY2VuYXJpbywgbmV0d29yayBhZG1pc3Npb24gY29udHJvbCBpcyBkb25lIGF0IHRoZQog ICBWUE4gY29uY2VudHJhdG9yIHRoYXQgYWN0cyBhcyB0aGUgZ2F0ZXdheSBiZXR3ZWVuIHJlbW90 ZSB1c2VycyBhbmQKICAgYWNjZXNzIHRvIHRoZSBlbnRlcnByaXNlIG5ldHdvcmsuCgogICBJUFNF QyBWUE4gYW5kIFNTTCBWUE4gYXJlIGV4YW1wbGUgb2YgbmV0d29yayBhY2Nlc3MgdGVjaG5vbG9n aWVzIHRoYXQKICAgc3VwcG9ydCByZW1vdGUgYWNjZXNzIFZQTiBkZXBsb3ltZW50IHNjZW5hcmlv cy4KCjUuNC4gIEdhdGV3YXkgQWNjZXNzCgogICBJbiB0aGlzIGRlcGxveW1lbnQgc2NlbmFyaW8s IG5ldHdvcmsgYWRtaXNzaW9uIGNvbnRyb2wgaXMgZW5mb3JjZWQgYXQKICAgYSBMMyBib3VuZGFy eSBpbiBhIGRpc3RyaWJ1dGVkIGNhbXB1cyBuZXR3b3JrLiAgVGhlIEwzIGJvdW5kYXJ5IG1heQog ICBiZSBvbmUgb3IgbW9yZSBMMyBob3BzIGF3YXkgZnJvbSB0aGUgZW5kcG9pbnQuCgogICBUaGlz IGRlcGxveW1lbnQgc2NlbmFyaW8gbWF5IGJlIHVzZWQgZHVyaW5nIHRoZSB0cmFuc2l0aW9uIHBl cmlvZAogICB3aGlsZSBhbiBvcmdhbml6YXRpb24gZ3JhZHVhbGx5IHVwZ3JhZGVzIG5ldHdvcmsg ZXF1aXBtZW50IHRvIHN1cHBvcnQKICAgbmV0d29yayBlbmRwb2ludCBhc3Nlc3NtZW50LiAgSW4g c29tZSBjYXNlcywgdGhlIHRlY2hub2xvZ3kgbWF5IG5vdAogICBiZSBhdmFpbGFibGUgaW1tZWRp YXRlbHkgZm9yIGZpcnN0LWhvcCBMMiBvciBMMyBkZXBsb3ltZW50cyBhbmQgYQogICBnZW5lcmFs LXB1cnBvc2UgZ2F0ZXdheSBkZXBsb3ltZW50IGUuZy4gYXQgYSByb3V0ZXIgYmVoaW5kIGEgVlBO CiAgIGNvbmNlbnRyYXRvciwgbWF5IGJlIGEgcmVhc29uYWJsZSBmaXJzdCBzdGVwLgoKICAgVGhp cyBkZXBsb3ltZW50IHNjZW5hcmlvIG1heSBhbHNvIGJlIHVzZWQgYmV0d2VlbiBuZXR3b3JrIHNl Y3VyaXR5CiAgIGRvbWFpbnMgZS5nLiBhdCB0aGUgYm9yZGVyIGJldHdlZW4gYSBsZXNzIHRydXN0 ZWQvbWFuYWdlZCBicmFuY2gKICAgb2ZmaWNlIGFuZCBtYWluIGNhbXB1cywgYXQgdGhlIGJvcmRl ciBiZXR3ZWVuIG1haW4gY2FtcHVzIG9yIGEKICAgdmlzaXRvciBzaXRlIGFuZCBhY2Nlc3MgdG8g dGhlIEludGVybmV0LCBhdCB0aGUgYm9yZGVyIGJldHdlZW4KICAgZXh0cmFuZXQgYW5kIGludHJh bmV0LCBhbmQgb24gYWNjZXNzIHRvIHByb3RlY3RlZCBzZXJ2ZXJzIGluIGEgZGF0YQogICBjZW50 ZXIuCgogICBJdCBmb2xsb3dzIGZyb20gdGhpcyBkZXBsb3ltZW50IHNjZW5hcmlvIHRoYXQgdGhl cmUgbWF5IGJlIG11bHRpcGxlCiAgIE5ldHdvcmsgZW5mb3JjZXJzIG9uIGFueSBwYXRoIHRoYXQg YW4gZW5kcG9pbnQgbWF5IHVzZSBpbiBhIG5ldHdvcmssCiAgIHRodXMgcmVzdWx0aW5nIGluIGl0 IGJlaW5nIGF1dGhvcml6ZWQgbW9yZSB0aGFuIG9uY2UuICBJdCBpcyBhbHNvCiAgIHBvc3NpYmxl IHRoYXQgZGlmZmVyZW50IHBvc3R1cmUgcnVsZXMgbWF5IGJlIGFzc2Vzc2VkIGF0IGRpZmZlcmVu dAogICBuZXR3b3JrIGxvY2F0aW9ucyBhbmQgYSBkaWZmZXJlbnQgYXV0aG9yaXphdGlvbiBkZWNp c2lvbiBtYWRlLgoKCjYuICBDb21wb25lbnRzIGFuZCBJbnRlcmZhY2VzCgogICBUaGlzIHNlY3Rp b24gcHJvdmlkZXMgYSBnZW5lcmFsIG92ZXJ2aWV3IG9mIE5FQSBhcmNoaXRlY3R1cmVzLCB3aXRo IGEKICAgcGFydGljdWxhciBlbXBoYXNpcyBvbiB0aGUgRUFQL1JBRElVUyBpbnN0YW50YW50aWF0 aW9uIG9mIHRoZXNlCiAgIGFyY2hpdGVjdHVyZXMsIHNpbmNlIHRoaXMgaXMgdGhlIGZvY3VzIG9m IHRoZSBpbml0aWFsIHN0YW5kYXJkcwoKCgpIYW5uYSwgZXQgYWwuICAgICAgICAgICBFeHBpcmVz IFNlcHRlbWJlciA1LCAyMDA2ICAgICAgICAgICAgICAgW1BhZ2UgOF0KDApJbnRlcm5ldC1EcmFm dCAgICAgICAgICAgIE5FQSBQcm9ibGVtIFN0YXRlbWVudCAgICAgICAgICAgICAgIE1hcmNoIDIw MDYKCgogICBlZmZvcnQuICAoT3RoZXIgaW5zdGFudGlhdGlvbnMgb2YgdGhlIGhpZ2gtbGV2ZWwg YXJjaGl0ZWN0dXJlIG1heSBiZQogICBzdGFuZGFyZGl6ZWQgaW4gZnV0dXJlLikKCiAgIEZpZ3Vy ZSAxIHNob3dzIHRoZSBjb21wb25lbnRzIG9mIGFuIE5FQSBzeXN0ZW0gYW5kIGlkZW50aWZpZXMK ICAgc3BlY2lmaWMgaW50ZXJmYWNlcy4KCgogICB8LS0tLS0tLS0tLS0tLXwgICAgICAgICAgICAg ICAgICAgICAgICAgIHwtLS0tLS0tLS0tLS0tLS0tfAogICB8IFBvc3R1cmUgICAgIHwgIDwtLS0t LS0tSUYtUEEtLS0tLS0tPiAgIHwgICBQb3N0dXJlICAgICAgfAogICB8IENvbGxlY3RvcnMgIHwg ICAgICAgICAgICAgICAgICAgICAgICAgIHwgICBWYWxpZGF0b3JzICAgfAogICB8ICgxIC4uLk4p ICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAoMSAuLi5OKSAgICAgfAogICB8LS0t LS0tLS0tLS0tLXwgICAgICAgICAgICAgICAgICAgICAgICAgIHwtLS0tLS0tLS0tLS0tLS0tfAog ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAg ICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8LS0tLS0tSUYtUFYtLS0tLS0t LT4KICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwK ICAgfC0tLS0tLS0tLS0tLS18ICAgICAgICAgICAgICAgICAgICAgICAgICB8LS0tLS0tLS0tLS0t LS0tLXwKICAgfCAgIENsaWVudCAgICB8ICA8LS0tLS0tLUlGLVBCLS0tLS0tLT4gICB8ICAgICBT ZXJ2ZXIgICAgIHwKICAgfCAgIEJyb2tlciAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICB8 ICAgICBCcm9rZXIgICAgIHwKICAgfC0tLS0tLS0tLSAtLS18ICAgICAgICAgICAgICAgICAgICAg ICAgICB8LS0tLS0tLS0tLS0tLS0tLXwKICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwKICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwKICAgfC0tLS0tLS0tLS0tLS18ICA8LS0tLS0tSUYtUFQtLS0tLS0t PiAgICB8LS0tLS0tLS0tLS0tLS0tLXwKICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg ICAgICAgICAgICB8ICAgICAgICAgICAgICAgIHwKICAgfCBOZXR3b3JrICAgICB8ICAgIHwtLS0t LS0tLXwgICAgICAgICAgICB8ICAgTmV0d29yayAgICAgIHwKICAgfCBBY2Nlc3MgICAgICB8LS0t LXxOZXR3b3JrIHwtLS0tLS0tLS0tLS18ICAgQWNjZXNzICAgICAgIHwKICAgfCBSZXF1ZXN0b3Ig ICB8ICAgIHxFbmZvcmNlcnwgPC1JRi1OQUUtPiB8ICAgQXV0aG9yaXR5ICAgIHwKICAgfC0tLS0t LS0tLS0tLS18ICAgIHwtLS0tLS0tLXwgICAgICAgICAgICB8LS0tLS0tLS0tLS0tLS0tLXwKCiAg ICAgIE5FQSBDTElFTlQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTkVBIFNFUlZF UgogICBGaWd1cmUgMTogTkVBIENvbXBvbmVudHMgYW5kIEludGVyZmFjZXMKCjYuMS4gIE1hcHBp bmcgdG8gZXhpc3RpbmcgYXJjaGl0ZWN0dXJlcwoKICAgRm9yIGNvbnZlbmllbmNlLCB3ZSBtYXAg dGhlIHRlcm1zIHVzZWQgaW4gdGhpcyBkb2N1bWVudCB3aXRoIHRoYXQgb2YKICAgdGhyZWUgYXJj aGl0ZWN0dXJlcyBkZXZlbG9wZWQgaW4gdGhlIGluZHVzdHJ5IDogVHJ1c3RlZCBOZXR3b3JrCiAg IENvbm5lY3QgKFROQykgYXJjaGl0ZWN0dXJlIFtUTkNdLCBNaWNyb3NvZnQncyBOZXR3b3JrIEFj Y2VzcwogICBQcm90ZWN0aW9uIChOQVApIGFyY2hpdGVjdHVyZSBbTkFQXSwgYW5kIENpc2NvJ3Mg TmV0d29yayBBZG1pc3Npb24KICAgQ29udHJvbCAoTkFDKSBhcmNoaXRlY3R1cmUgW05BQ10uCgoK CgoKCgoKCgoKCgpIYW5uYSwgZXQgYWwuICAgICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciA1LCAy MDA2ICAgICAgICAgICAgICAgW1BhZ2UgOV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgIE5F QSBQcm9ibGVtIFN0YXRlbWVudCAgICAgICAgICAgICAgIE1hcmNoIDIwMDYKCgogICBUYWJsZSAx OiBUZXJtaW5vbG9neSB1c2VkIGluIHZhcmlvdXMgYXJjaGl0ZWN0dXJlcwogICAgICBORUEgICAg ICAgICAgVE5DICAgICAgICAgICAgIE5BUCAgICAgICAgICAgICBOQUMKCiAgIFBvc3R1cmUgICAg ICAgSW50ZWdyaXR5ICAgICAgIFN5c3RlbSAgICAgICAgICAgUG9zdHVyZQogICBDb2xsZWN0b3Ig ICAgIE1lYXN1cmVtZW50ICAgICBIZWFsdGggICAgICAgICAgIFBsdWctaW4KICAgICAgICAgICAg ICAgICBDb2xsZWN0b3IgICAgICAgQWdlbnQKCiAgIENsaWVudCAgICAgICAgVE5DICAgICAgICAg ICAgIE5BUCAgICAgICAgICAgICAgUG9zdHVyZQogICBCcm9rZXIgICAgICAgIENsaWVudCAgICAg ICAgICBBZ2VudCAgICAgICAgICAgIEFnZW50CgogICBOZXR3b3JrICAgICAgIE5ldHdvcmsgICAg ICAgICBOQVAgICAgICAgICAgICAgIFBvc3R1cmUKICAgQWNjZXNzICAgICAgICBBY2Nlc3MgICAg ICAgICAgRW5mb3JjZW1lbnQgICAgICBBZ2VudAogICBSZXF1ZXN0b3IgICAgIFJlcXVlc3RvciAg ICAgICBDbGllbnQKCiAgIE5ldHdvcmsgICAgICAgUG9saWN5ICAgICAgICAgIE5BUCAgICAgICAg ICAgICAgTmV0d29yawogICBFbmZvcmNlciAgICAgIEVuZm9yY2VtZW50ICAgICBFbmZvcmNlbWVu dCAgICAgIEFjY2VzcwogICAgICAgICAgICAgICAgIFBvaW50ICAgICAgICAgICBTZXJ2ZXIgICAg ICAgICAgIERldmljZQoKICAgUG9zdHVyZSAgICAgICBJbnRlZ3JpdHkgICAgICAgU3lzdGVtICAg ICAgICAgICBQb3N0dXJlCiAgIFZhbGlkYXRvciAgICAgTWVhc3VyZW1lbnQgICAgIEhlYWx0aCAg ICAgICAgICAgVmFsaWRhdGlvbgogICAgICAgICAgICAgICAgIFZlcmlmaWVyICAgICAgICBWYWxp ZGF0b3IgICAgICAgIFNlcnZlcgoKICAgU2VydmVyICAgICAgICBUTkMgICAgICAgICAgICAgTkFQ ICAgICAgICAgICAgICBBY2Nlc3MKICAgQnJva2VyICAgICAgICBTZXJ2ZXIgICAgICAgICAgQWRt aW5pc3RyYXRpb24gICBDb250cm9sCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFNl cnZlciAgICAgICAgICAgU2VydmVyCgogICBOZXR3b3JrICAgICAgIE5ldHdvcmsgICAgICAgICBO ZXR3b3JrICAgICAgICAgIEFjY2VzcwogICBBY2Nlc3MgICAgICAgIEFjY2VzcyAgICAgICAgICBQ b2xpY3kgICAgICAgICAgIENvbnRyb2wKICAgQXV0aG9yaXR5ICAgICBBdXRob3JpdHkgICAgICAg U2VydmVyICAgICAgICAgICBTZXJ2ZXIKCgo2LjIuICBDb21wb25lbnRzCgo2LjIuMS4gIE5FQSBD bGllbnQKCiAgIFRoZSBORUEgY2xpZW50IHJlc2lkZXMgb24gYW4gZW5kcG9pbnQgZGV2aWNlIGFu ZCBjb21wcmlzZXMgdGhlCiAgIGZvbGxvd2luZyBjb21wb25lbnRzOgoKICAgbyAgUG9zdHVyZSBj b2xsZWN0b3IKCiAgIG8gIENsaWVudCBicm9rZXIKCiAgIG8gIE5ldHdvcmsgYWNjZXNzIHJlcXVl c3RvcgoKNi4yLjEuMS4gIFBvc3R1cmUgQ29sbGVjdG9yCgogICBUaGUgUG9zdHVyZSBjb2xsZWN0 b3IgaXMgc29mdHdhcmUgdGhhdCBwcm92aWRlcyBwb3N0dXJlIGluZm9ybWF0aW9uCiAgIGFib3V0 IHRoZSBlbmRwb2ludCBkZXZpY2UgdG8gdGhlIENsaWVudCBicm9rZXIuICBUaGVyZSBtYXkgYmUg bWFueQoKCgpIYW5uYSwgZXQgYWwuICAgICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciA1LCAyMDA2 ICAgICAgICAgICAgICBbUGFnZSAxMF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgIE5FQSBQ cm9ibGVtIFN0YXRlbWVudCAgICAgICAgICAgICAgIE1hcmNoIDIwMDYKCgogICBQb3N0dXJlIGNv bGxlY3RvcnMgb24gYW4gZW5kcG9pbnQsIG9uZSBwZXIgdmVuZG9yIGFuZCBhcHBsaWNhdGlvbgog ICB0eXBlLiAgRXhhbXBsZXMgb2YgUG9zdHVyZSBjb2xsZWN0b3JzIGluY2x1ZGUgYSBob3N0IFBv c3R1cmUKICAgY29sbGVjdG9yIHRoYXQgcHJvdmlkZXMgaW5mb3JtYXRpb24gYWJvdXQgdGhlIE9T IGFuZCBwYXRjaCBsZXZlbHMsCiAgIGFudGktdmlydXMgUG9zdHVyZSBjb2xsZWN0b3IgdGhhdCBw cm92aWRlcyBpbmZvcm1hdGlvbiBhYm91dCB0aGUKICAgYW50aS12aXJ1cyBhcHBsaWNhdGlvbiwg ZmlyZXdhbGwgUG9zdHVyZSBjb2xsZWN0b3IgdGhhdCBwcm92aWRlcwogICBpbmZvcm1hdGlvbiBh Ym91dCB0aGUgY29uZmlndXJhdGlvbiBvZiB0aGUgcGVyc29uYWwgZmlyZXdhbGwuCgogICBBIFBv c3R1cmUgY29sbGVjdG9yIGlzIHJlc3BvbnNpYmxlIGZvcjoKCiAgIG8gIFJlY2VpdmluZyBhbmQg cmVzcG9uZGluZyB0byByZXF1ZXN0cyBmb3IgcG9zdHVyZSBpbmZvcm1hdGlvbiBvbiBhCiAgICAg IHBlciB2ZW5kb3IgYW5kIGFwcGxpY2F0aW9uIHR5cGUgYmFzaXMKCiAgIG8gIFJlY2VpdmluZyBh IG5vdGlmaWNhdGlvbiBvZiB0aGUgcmVzdWx0IG9mIHRoZSBwb3N0dXJlIGFzc2Vzc21lbnQKICAg ICAgYW5kIGluZm9ybWF0aW9uIGFib3V0IGFueSBhY3Rpb25zIHRvIHBlcmZvcm0sIGUuZy4gIFVS TCBvZiBhCiAgICAgIHJlbWVkaWF0aW9uIHNlcnZlcgoKICAgbyAgSW5kaWNhdGluZyB3aGVuIHRo ZSBwb3N0dXJlIG9mIHRoZSBob3N0IGhhcyBjaGFuZ2VkCgo2LjIuMS4yLiAgQ2xpZW50IEJyb2tl cgoKICAgVGhlIENsaWVudCBicm9rZXIgYWdncmVnYXRlcyBwb3N0dXJlIGluZm9ybWF0aW9uIGZy b20gbXVsdGlwbGUKICAgUG9zdHVyZSBjb2xsZWN0b3JzLiAgVGhlIENsaWVudCBicm9rZXIgaXMg cmVzcG9uc2libGUgZm9yOgoKICAgbyAgTWFpbnRhaW5pbmcgYSByZWNvcmQgb2YgUG9zdHVyZSBj b2xsZWN0b3JzCgogICBvICBNdWx0aXBsZXhpbmcgYW5kIGRlbXVsdGlwbGV4aW5nIHBvc3R1cmUg bWVzc2FnZXMgYmV0d2VlbiB0aGUgTkVBCiAgICAgIHNlcnZlciBhbmQgdGhlIHJlbGV2YW50IFBv c3R1cmUgY29sbGVjdG9ycwoKICAgbyAgRGV0ZXJtaW5pbmcgZnJvbSBQb3N0dXJlIGNvbGxlY3Rv cnMgd2hlbiBwb3N0dXJlIGhhcyBjaGFuZ2VkIGFuZAogICAgICB0cmlnZ2VyaW5nIHJlLWFzc2Vz c21lbnQgd2hlcmUgc3VwcG9ydGVkIGJ5IHRoZSB1bmRlcmx5aW5nCiAgICAgIHRyYW5zcG9ydAoK ICAgbyAgUHJvdmlkaW5nIHVzZXIgbm90aWZpY2F0aW9ucwoKNi4yLjEuMy4gIE5ldHdvcmsgYWNj ZXNzIHJlcXVlc3RvcgoKICAgVGhlIE5ldHdvcmsgYWNjZXNzIHJlcXVlc3RvciBpcyByZXNwb25z aWJsZSBmb3IgY29tbXVuaWNhdGluZyB3aXRoCiAgIHRoZSBORUEgc2VydmVyIHRvIHRyYW5zcG9y dCB0aGUgbmVjZXNzYXJ5IGluZm9ybWF0aW9uIHRvIGdhaW4gYWNjZXNzCiAgIHRvIHRoZSBuZXR3 b3JrIGFuZCBmb3Igc3Vic2VxdWVudCByZS1hc3Nlc3NtZW50LiAgVGhlcmUgbWF5IGJlCiAgIG11 bHRpcGxlIE5ldHdvcmsgYWNjZXNzIHJlcXVlc3RvcnMgb24gYW4gZW5kcG9pbnQgcmVwcmVzZW50 aW5nCiAgIGRpZmZlcmVudCB0ZWNobm9sb2dpZXMgZm9yIGFjY2Vzc2luZyB0aGUgbmV0d29yay4K CjYuMi4yLiAgTmV0d29yayBlbmZvcmNlcgoKICAgVGhlIE5ldHdvcmsgZW5mb3JjZXIgaXMgYSBu ZXR3b3JrIGNvbXBvbmVudCB0aGF0IGNvbnRyb2xzIGFjY2VzcyBvZgogICBlbmRwb2ludHMgdG8g dGhlIHVwc3RyZWFtIG5ldHdvcmsuICBUaGUgTmV0d29yayBlbmZvcmNlciBtYXkgYmUgYQogICBu ZXR3b3JrIGRldmljZSBvciBhIGxvZ2ljYWwgY29tcG9uZW50IG9uIGFuIGVuZHBvaW50LiAgVGhl IE5FQQogICBlbmZvcmNlciBlbmZvcmNlcyBuZXR3b3JrIGF1dGhvcml6YXRpb24gZGVjaXNpb25z IGZyb20gdGhlIE5ldHdvcmsKCgoKSGFubmEsIGV0IGFsLiAgICAgICAgICAgRXhwaXJlcyBTZXB0 ZW1iZXIgNSwgMjAwNiAgICAgICAgICAgICAgW1BhZ2UgMTFdCgwKSW50ZXJuZXQtRHJhZnQgICAg ICAgICAgICBORUEgUHJvYmxlbSBTdGF0ZW1lbnQgICAgICAgICAgICAgICBNYXJjaCAyMDA2CgoK ICAgYWNjZXNzIGF1dGhvcml0eS4gIFRoZXJlIGFyZSBkaWZmZXJlbnQgdHlwZXMgb2YgTmV0d29y ayBlbmZvcmNlcnMKICAgc3VwcG9ydGluZyBkaWZmZXJlbnQgdGVjaG5vbG9naWVzIGZvciBhY2Nl c3NpbmcgdGhlIG5ldHdvcmsuCgo2LjIuMy4gIE5FQSBzZXJ2ZXIKCiAgIFRoZSBORUEgc2VydmVy IGNvbXByaXNlcyB0aGUgZm9sbG93aW5nIGxvZ2ljYWwgY29tcG9uZW50czoKCiAgIG8gIE5ldHdv cmsgYWNjZXNzIGF1dGhvcml0eQoKICAgbyAgU2VydmVyIGJyb2tlcgoKICAgbyAgUG9zdHVyZSB2 YWxpZGF0b3IKCjYuMi4zLjEuICBOZXR3b3JrIGFjY2VzcyBhdXRob3JpdHkKCiAgIFRoZSBOZXR3 b3JrIGFjY2VzcyBhdXRob3JpdHkgaXMgcmVzcG9uc2libGUgZm9yIGF1dGhvcml6aW5nIGVuZHBv aW50cwogICBiYXNlZCBvbiBhIG51bWJlciBvZiBjcml0ZXJpYSBpbmNsdWRpbmcgdGhlIGlkZW50 aXR5IG9mIGFuIGVuZHBvaW50CiAgIGFuZC9vciB1c2VyIGFzIHdlbGwgYXMgdGhlIHJlc3VsdHMg b2YgcG9zdHVyZSBhc3Nlc3NtZW50IGZyb20gdGhlCiAgIFNlcnZlciBicm9rZXIuCgo2LjIuMy4y LiAgU2VydmVyIGJyb2tlcgoKICAgVGhlIFNlcnZlciBicm9rZXIgYWdncmVnYXRlcyBwb3N0dXJl IGluZm9ybWF0aW9uIGZyb20gcG90ZW50aWFsbHkKICAgbXVsdGlwbGUgUG9zdHVyZSB2YWxpZGF0 b3JzIGludG8gYW4gb3ZlcmFsbCBzeXN0ZW0gcmVzdWx0LCBhbmQKICAgcHJvdmlkZXMgdGhpcyBp bmZvcm1hdGlvbiB0byB0aGUgTmV0d29yayBhY2Nlc3MgYXV0aG9yaXR5LgogICBSZXNwb25zaWJp bGl0aWVzIG9mIHRoZSBTZXJ2ZXIgYnJva2VyIGluY2x1ZGU6CgogICBvICBNYWludGFpbmluZyBh IHJlY29yZCBvZiBQb3N0dXJlIHZhbGlkYXRvcnMKCiAgIG8gIE11bHRpcGxleGluZyBhbmQgZGVt dWx0aXBsZXhpbmcgcG9zdHVyZSBtZXNzYWdlcyBiZXR3ZWVuIHRoZSBORUEKICAgICAgY2xpZW50 IGFuZCB0aGUgcmVsZXZhbnQgUG9zdHVyZSB2YWxpZGF0b3JzCgogICBvICBBZ2dyZWdhdGluZyBw b3N0dXJlIGFzc2Vzc21lbnQgcmVzdWx0cyBmcm9tIGFsbCBQb3N0dXJlIHZhbGlkYXRvcnMKICAg ICAgaW50byBhbiBvdmVyYWxsIHN5c3RlbSByZXN1bHQKCiAgIG8gIFRyaWdnZXJpbmcgcG9zdHVy ZSByZWFzc2Vzc21lbnQgd2hlcmUgc3VwcG9ydGVkCgo2LjIuMy4zLiAgUG9zdHVyZSB2YWxpZGF0 b3IKCiAgIEEgUG9zdHVyZSB2YWxpZGF0b3IgaXMgYSBzZXJ2ZXIgdGhhdCBpcyByZXNwb25zaWJs ZSBmb3IgYXNzZXNzaW5nCiAgIGluZm9ybWF0aW9uIGZyb20gdGhlIGNvcnJlc3BvbmRpbmcgUG9z dHVyZSBjb2xsZWN0b3IgYW5kIGRldGVybWluaW5nCiAgIHRoZSByZXN1bHQgb2YgdGhlIGFzc2Vz c21lbnQuICBUaGVyZSBtYXkgYmUgbXVsdGlwbGUgUG9zdHVyZQogICB2YWxpZGF0b3JzIGVhY2gg dGFyZ2V0ZWQgYXQgYSBwYXJ0aWN1bGFyIHNlY3VyaXR5IGFwcGxpY2F0aW9uIGZyb20gYQogICBw YXJ0aWN1bGFyIHZlbmRvci4gIEluIHNvbWUgYXJjaGl0ZWN0dXJlcywgdGhlIFBvc3R1cmUgdmFs aWRhdG9ycyBhcmUKICAgbm90IGNvLWxvY2F0ZWQgd2l0aCB0aGUgTkVBIHNlcnZlci4KCiAgIEEg UG9zdHVyZSB2YWxpZGF0b3IgaXMgcmVzcG9uc2libGUgZm9yIHRoZSBmb2xsb3dpbmc6CgoKCgpI YW5uYSwgZXQgYWwuICAgICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciA1LCAyMDA2ICAgICAgICAg ICAgICBbUGFnZSAxMl0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgIE5FQSBQcm9ibGVtIFN0 YXRlbWVudCAgICAgICAgICAgICAgIE1hcmNoIDIwMDYKCgogICBvICBSZXF1ZXN0aW5nIGFuZCBy ZWNlaXZpbmcgcG9zdHVyZSBpbmZvcm1hdGlvbiBmcm9tIGEgcGFydGljdWxhcgogICAgICBQb3N0 dXJlIGNvbGxlY3RvcgoKICAgbyAgQXNzZXNzaW5nIHRoZSBlbmRwb2ludCBwb3N0dXJlIGFuZCBw cm92aWRpbmcgYSByZXN1bHQgdG8gdGhlCiAgICAgIFNlcnZlciBicm9rZXIKCiAgIG8gIFNlbmRp bmcgdG8gdGhlIFBvc3R1cmUgY29sbGVjdG9yIGluZm9ybWF0aW9uIG9uIHJlbWVkaWF0aW9uCiAg ICAgIGFjdGlvbnMgdG8gYmUgdGFrZW4KCiAgIG8gIEluZGljYXRpbmcgdG8gdGhlIFNlcnZlciBi cm9rZXIgd2hlbiBwb3N0dXJlIHJlYXNzZXNzbWVudCBtYXkgYmUKICAgICAgbmVlZGVkCgo2LjMu ICBJbnRlcmZhY2VzCgo2LjMuMS4gIFBvc3R1cmUgQXR0cmlidXRlIGludGVyZmFjZSAoSUYtUEEp CgogICBUaGUgSUYtUEEgaXMgYSBwcm90b2NvbCBiZXR3ZWVuIGEgUG9zdHVyZSBjb2xsZWN0b3Ig YW5kIHRoZQogICBhc3NvY2lhdGVkIFBvc3R1cmUgdmFsaWRhdG9yIGZvciB0aGUgcGFydGljdWxh ciB2ZW5kb3IgYW5kCiAgIGFwcGxpY2F0aW9uLiAgVGhlIGludGVyZmFjZSBpcyB1c2VkIHRvIHBh c3MgaW5mb3JtYXRpb24gZ2F0aGVyZWQgYnkgYQogICBQb3N0dXJlIGNvbGxlY3RvciB0byB0aGUg UG9zdHVyZSB2YWxpZGF0b3IsIGFuZCB0byBwYXNzIHRoZSByZXN1bHRzCiAgIG9mIHRoZSBhc3Nl c3NtZW50IGFuZCBpbmZvcm1hdGlvbiBuZWVkZWQgZm9yIHJlbWVkaWF0aW9uIGZyb20gdGhlCiAg IFBvc3R1cmUgdmFsaWRhdG9yIHRvIHRoZSBQb3N0dXJlIGNvbGxlY3Rvci4KCjYuMy4yLiAgUG9z dHVyZSBCcm9rZXIgSW50ZXJmYWNlIChJRi1QQikKCiAgIFRoZSBJRi1QQiBpcyBhIHByb3RvY29s IHRoYXQgY2FycmllcyBhZ2dyZWdhdGVkIHBvc3R1cmUgaW5mb3JtYXRpb24KICAgYmV0d2VlbiBh bGwgcmVxdWVzdGVkIFBvc3R1cmUgY29sbGVjdG9ycyBvbiBhbiBlbmRwb2ludCBhbmQgdGhlCiAg IGNvcnJlc3BvbmRpbmcgUG9zdHVyZSB2YWxpZGF0b3JzLiAgVGhpcyBwcm90b2NvbCBhbHNvIGNh cnJpZXMgdGhlCiAgIG92ZXJhbGwgc3lzdGVtIHBvc3R1cmUgcmVzdWx0IGZyb20gdGhlIFNlcnZl ciBicm9rZXIgdG8gdGhlIENsaWVudAogICBicm9rZXIuCgo2LjMuMy4gIFBvc3R1cmUgVHJhbnNw b3J0IEludGVyZmFjZSAoSUYtUFQpCgogICBUaGUgSUYtUFQgaXMgdGhlIHRyYW5zcG9ydCBwcm90 b2NvbCBiZXR3ZWVuIHRoZSBOZXR3b3JrIGFjY2VzcwogICByZXF1ZXN0b3IgYW5kIHRoZSBOZXR3 b3JrIGFjY2VzcyBhdXRob3JpdHkgdGhhdCBjYXJyaWVzIHRoZSBJRi1QQgogICBwcm90b2NvbC4K CiAgIEluIEVBUCBpbnN0YW50aWF0aW9ucyBvZiB0aGlzIGFyY2hpdGVjdHVyZSwgdGhlIElGLVBU IGludGVyZmFjZXMKICAgY29uc2lzdHMgb2YgdHdvIHByb3RvY29sczogMSkgUG9zdHVyZSBUcmFu c3BvcnQgVHVubmVsIChJRi1QVFQpLAogICB3aGljaCBpcyBhbiBFQVAgdHVubmVsaW5nIG1ldGhv ZCBiZXR3ZWVuIHRoZSBOZXR3b3JrIGFjY2VzcyByZXF1ZXN0b3IKICAgaW4gdGhlIE5FQSBjbGll bnQgYW5kIHRoZSBOZXR3b3JrIGFjY2VzcyBhdXRob3JpdHkgaW4gdGhlIE5FQSBzZXJ2ZXIKICAg dGhhdCBjYW4gY2FycnkgcG9zdHVyZSBpbmZvcm1hdGlvbiBpbiBhZGRpdGlvbiB0byBhdXRoZW50 aWNhdGlvbgogICBpbmZvcm1hdGlvbiwgYW5kIDIpIFBvc3R1cmUgVHJhbnNwb3J0IENhcnJpZXIg KElGLVBUQyksIGEgcHJvdG9jb2wKICAgdGhhdCBjYXJyaWVzIEVBUCwgZS5nLiAgRUFQIG92ZXIg ODAyLjFYLCBFQVAgb3ZlciBSQURJVVMuCgo2LjMuNC4gIE5ldHdvcmsgQWNjZXNzIEVuZm9yY2Vt ZW50IEludGVyZmFjZSAoSUYtTkFFKQoKICAgVGhlIElGLU5BRSBpcyB0aGUgcHJvdG9jb2wgYmV0 d2VlbiB0aGUgTmV0d29yayBlbmZvcmNlciBhbmQgTmV0d29yawoKCgpIYW5uYSwgZXQgYWwuICAg ICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciA1LCAyMDA2ICAgICAgICAgICAgICBbUGFnZSAxM10K DApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgIE5FQSBQcm9ibGVtIFN0YXRlbWVudCAgICAgICAg ICAgICAgIE1hcmNoIDIwMDYKCgogICBhY2Nlc3MgYXV0aG9yaXR5IHVzZWQgdG8gY2FycnkgbmV0 d29yayBhdXRob3JpemF0aW9uIGRlY2lzaW9ucwogICBiZXR3ZWVuIHRoZSBOZXR3b3JrIGVuZm9y Y2VyIGFuZCB0aGUgTmV0d29yayBhY2Nlc3MgYXV0aG9yaXR5LgoKICAgSW4gRUFQIEluc3RhbnRp YXRpb25zIG9mIHRoaXMgYXJjaGl0ZWN0dXJlLCB0aGUgSUYtTkFFIGludGVyZmFjZSBpcwogICBS QURJVVMuCgo2LjMuNS4gIFBvc3R1cmUgVmFsaWRhdGlvbiBJbnRlcmZhY2UgKElGLVBWKQoKICAg SW4gc29tZSBpbnN0YW50aWF0aW9ucyBvZiB0aGUgYXJjaGl0ZWN0dXJlLCB0aGUgU2VydmVyIGJy b2tlciBhbmQgdGhlCiAgIFBvc3R1cmUgdmFsaWRhdG9ycyBhcmUgbm90IGNvLWxvY2F0ZWQuICBU aGUgSUYtUFYgcHJvdG9jb2wgYmV0d2VlbgogICB0aGUgU2VydmVyIGJyb2tlciBhbmQgUG9zdHVy ZSB2YWxpZGF0b3IgZm9yd2FyZHMgcG9zdHVyZSBpbmZvcm1hdGlvbgogICBhbmQgcmV0dXJucyBw b3N0dXJlIHZhbGlkYXRpb24gcmVzdWx0cy4KCgo3LiAgU2NvcGUgb2YgU3RhbmRhcmRpemF0aW9u CgogICBQcm90b2NvbHMgdGhhdCBhcmUgY2FuZGlkYXRlcyBmb3Igc3RhbmRhcmRpemF0aW9uIGlu IHRoZSBJRVRGIGluY2x1ZGUKICAgdGhlIGZvbGxvd2luZyA6CgogICBvICBQb3N0dXJlIGF0dHJp YnV0ZXMgaW50ZXJmYWNlIChJRi1QQSk6IFRoaXMgaW50ZXJmYWNlIGNhbiBiZQogICAgICBkZWZp bmVkIGluZGVwZW5kZW50bHkgb2YgdGhlIHVuZGVybHlpbmcgdHJhbnNwb3J0IGludGVyZmFjZXMs CiAgICAgIHdoaWxlIGtlZXBpbmcgaW4gbWluZCBwZXJmb3JtYW5jZSBhbmQgb3RoZXIgY29uc3Ry YWludHMgaW1wb3NlZCBieQogICAgICB0aGUgdW5kZXJseWluZyBwcm90b2NvbHMuICBNYW55IG9m IHRoZSBwb3N0dXJlIGF0dHJpYnV0ZXMgd2lsbCBiZQogICAgICB2ZW5kb3Itc3BlY2lmaWMgYW5k IG5lZWQgb25seSBiZSB1bmRlcnN0b29kIGJ5IHRoZSBjb3JyZXNwb25kaW5nCiAgICAgIFBvc3R1 cmUgY29sbGVjdG9yIGFuZCBpdHMgYXNzb2NpYXRlZCBQb3N0dXJlIHZhbGlkYXRvci4gIEhvd2V2 ZXIsCiAgICAgIHRoZXJlIG1heSBiZSBjb21tb24gYXR0cmlidXRlcyB0aGF0IHdvdWxkIGJlbmVm aXQgZnJvbQogICAgICBzdGFuZGFyZGl6YXRpb24sIGUuZy4gYW4gYXR0cmlidXRlIHJlcHJlc2Vu dGluZyB0aGUgcmVzdWx0IG9mCiAgICAgIGV2YWx1YXRpbmcgcG9zdHVyZSBpbmZvcm1hdGlvbiBm cm9tIGEgUG9zdHVyZSBjb2xsZWN0b3IuCgogICBvICBQb3N0dXJlIGJyb2tlciBpbnRlcmZhY2Ug KElGLVBCKTogVGhpcyBpbnRlcmZhY2UgaXMgYWxzbyBsYXJnZWx5CiAgICAgIGluZGVwZW5kZW50 IG9mIHRoZSB1bmRlcmx5aW5nIHRyYW5zcG9ydCwgYWx0aG91Z2ggaXQgc2hvdWxkIGJlCiAgICAg IGRlZmluZWQgaW4gc3VjaCBhIHdheSB0aGF0IGl0IGNhbiBiZSB1c2VkIGluIHBvc3R1cmUgdHJh bnNwb3J0CiAgICAgIHByb3RvY29scyB0aGF0IGFyZSBsaWtlbHkgdG8gYmUgdXNlZCwgc3VjaCBh cyBFQVAgdHVubmVsaW5nCiAgICAgIG1ldGhvZHMgYmFzZWQgb24gVExTLgoKICAgbyAgUG9zdHVy ZSB0cmFuc3BvcnQgdHVubmVsIGludGVyZmFjZSAoSUYtUFRUKTogQXMgZGVzY3JpYmVkIGluIHRo ZQogICAgICBzZWN0aW9uIGFib3ZlLCBpbiBhbiBFQVAgaW5zdGFudGlhdGlvbiBvZiBhbiBORUEg YXJjaGl0ZWN0dXJlLCBhbgogICAgICBFQVAgdHVubmVsaW5nIG1ldGhvZCBpcyBuZWVkZWQgdG8g Y2FycnkgcG9zdHVyZSBpbmZvcm1hdGlvbiBpbgogICAgICBhZGRpdGlvbiB0byBhdXRoZW50aWNh dGlvbiBjcmVkZW50aWFscy4gIFN0YW5kYXJkaXphdGlvbiBvZgogICAgICBjZXJ0YWluIEVBUCBt ZXRob2RzIGZvciBhdXRoZW50aWNhdGlvbiBpcyB0aGUgcHJvcG9zZWQgY2hhcnRlciBvZgogICAg ICB0aGUgRU1VIFdHLiAgVGhlIG5lZWQgdG8gc3VwcG9ydCBwb3N0dXJlIGFzc2Vzc21lbnQgaW4g YWRkaXRpb24gdG8KICAgICAgYXV0aGVudGljYXRpb24gbWF5IHBsYWNlIGFkZGl0aW9uYWwgcmVx dWlyZW1lbnRzIG9uIHRoZSBFQVAKICAgICAgbWV0aG9kcyB0aGF0IG5lZWQgdG8gYmUgc3RhbmRh cmRpemVkLiAgSW4gcGFydGljdWxhciwKICAgICAgc3RhbmRhcmRpemF0aW9uIG9mIEVBUCB0dW5u ZWxpbmcgbWV0aG9kcyBpcyBhIGhpZ2ggcHJpb3JpdHkuCgogICBvICBQb3N0dXJlIHRyYW5zcG9y dCBjYXJyaWVyIGludGVyZmFjZSAoSUYtUFRDKTogU29tZSBFQVAgY2FycmllcgogICAgICBtZXRo b2RzIGFyZSBzdGFuZGFyZHMgdG9kYXkgZS5nLiA4MDIuMVguIEhvd2V2ZXIsIHRoZXJlIGlzIG5v CiAgICAgIHN0YW5kYXJkIEVBUCB0cmFuc3BvcnQgdG8gc3VwcG9ydCBnYXRld2F5IGFuZCBvdGhl ciAibXVsdGktaG9wIgoKCgpIYW5uYSwgZXQgYWwuICAgICAgICAgICBFeHBpcmVzIFNlcHRlbWJl ciA1LCAyMDA2ICAgICAgICAgICAgICBbUGFnZSAxNF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAg ICAgIE5FQSBQcm9ibGVtIFN0YXRlbWVudCAgICAgICAgICAgICAgIE1hcmNoIDIwMDYKCgogICAg ICBkZXBsb3ltZW50IHNjZW5hcmlvcyBhcyBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQuICBUaGUg UEFOQSBXRwogICAgICBbUEFOQV0gaGFzIHByb3Bvc2VkIGEgc3BlY2lmaWNhdGlvbiBvZiBFQVAg b3ZlciBhIFVEUCB0cmFuc3BvcnQsCiAgICAgIGFsdGhvdWdoIG5vdCBleHBsaWNpdGx5IGZvciB0 aGlzIHVzZSBjYXNlLiAgT3RoZXIgcHJvdG9jb2xzIGhhdmUKICAgICAgYmVlbiBkZXNpZ25lZCBh bmQgdXNlZCBmb3IgdGhpcyBwdXJwb3NlIGUuZy4gIE5ldHdvcmsgQWNjZXNzCiAgICAgIGNvbnRy b2wgUHJvdG9jb2wgW05BQ1BdLgoKICAgbyAgTmV0d29yayBhY2Nlc3MgZW5mb3JjZW1lbnQgaW50 ZXJmYWNlIChJRi1OQUUpOiBFeGlzdGluZyBzdGFuZGFyZHMKICAgICAgZXhpc3QgaW5jbHVkaW5n IFJBRElVUyBhbmQgRGlhbWV0ZXIuICBUaGUgaW5pdGlhbCBmb2N1cyBvZiB0aGUKICAgICAgcHJv cG9zZWQgTkVBIHN0YW5kYXJkaXphdGlvbiBlZmZvcnQgaXMgb24gUkFESVVTLiAgVGhlIFJhZGV4 dCBXRwogICAgICBoYXMgdGhlIGNoYXJ0ZXIgdG8gc3RhbmRhcmRpemUgUkFESVVTIGV4dGVuc2lv bnMuICBJdCdzIG5vdCBjbGVhcgogICAgICB0aGF0IE5FQSB3b3VsZCByZXF1aXJlIGFueSBleHRl bnNpb25zIHRoYXQgZmFsbCBvdXRzaWRlIG9mIHRoZQogICAgICBzY29wZSBvZiB0aGUgZXhpc3Rp bmcgY2hhcnRlciBvZiB0aGF0IFdHLgoKICAgbyAgUG9zdHVyZSB2YWxpZGF0b3IgaW50ZXJmYWNl IChJRi1QVik6IFRoaXMgcHJvdG9jb2wgYWN0cyBhcyBhCiAgICAgIGNhcnJpZXIgZm9yIHBvc3R1 cmUgYXR0cmlidXRlcyBiZXR3ZWVuIGEgU2VydmVyIGJyb2tlciBhbmQgYQogICAgICBQb3N0dXJl IHZhbGlkYXRvciB0aGF0IGlzIG5vdCBjby1sb2NhdGVkIGluIHRoZSBORUEgc2VydmVyLgogICAg ICBEZXBlbmRpbmcgb24gdGhlIGNob2ljZSBvZiBwcm90b2NvbCBmb3IgdGhpcyBwdXJwb3NlLCB0 aGlzIG1heSBvcgogICAgICBtYXkgbm90IGZhbGwgd2l0aGluIHRoZSBzY29wZSBvZiB0aGUgSUVU Ri4KCiAgIFRoZSBwcm9wb3NlZCBpbml0aWFsIHNjb3BlIG9mIHRoZSBORUEgZWZmb3J0IGlzIHRo ZSBmb2xsb3dpbmc6CgogICBvICBJRi1QVFQKCiAgIG8gIElGLU5BRQoKICAgbyAgSUYtUEIKCiAg IG8gIElGLVBUQwoKICAgVGhlIHJlbWFpbmluZyBpbnRlcmZhY2VzLCBJRi1QQSBhbmQgSUYtUFYs IG1heSBiZSBhZGRyZXNzZWQgYXQgYQogICBsYXRlciBkYXRlLgoKCjguICBJQU5BIENvbnNpZGVy YXRpb25zCgogICBUaGlzIGRvY3VtZW50IG1ha2VzIG5vIHJlcXVlc3Qgb2YgSUFOQS4KCiAgIE5v dGUgdG8gUkZDIEVkaXRvcjogdGhpcyBzZWN0aW9uIG1heSBiZSByZW1vdmVkIG9uIHB1YmxpY2F0 aW9uIGFzIGFuCiAgIFJGQy4KCgo5LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMKCiAgIE5FQSBz eXN0ZW1zIGluY2x1ZGUgYSBudW1iZXIgb2YgZnVuY3Rpb25hbCBjb21wb25lbnRzIGFuZCBpbnRl cmZhY2VzLAogICBhbmQgdGh1cyB0aGVyZSBhcmUgYSBudW1iZXIgb2Ygc2VjdXJpdHkgYXNwZWN0 cyBwZXJ0YWluaW5nIHRvIHRoZQogICBzeXN0ZW0gYXMgYSB3aG9sZSB3aGljaCBuZWVkIHRvIGJl IGhpZ2hsaWdodGVkLiAgU29tZSBvZiB0aGVzZSBhcmUKICAgZGlzY3Vzc2VkIGluIHRoZSBmb2xs b3dpbmcgc2VjdGlvbnMuCgoKCgpIYW5uYSwgZXQgYWwuICAgICAgICAgICBFeHBpcmVzIFNlcHRl bWJlciA1LCAyMDA2ICAgICAgICAgICAgICBbUGFnZSAxNV0KDApJbnRlcm5ldC1EcmFmdCAgICAg ICAgICAgIE5FQSBQcm9ibGVtIFN0YXRlbWVudCAgICAgICAgICAgICAgIE1hcmNoIDIwMDYKCgo5 LjEuICBTZWN1cmUgY2hhbm5lbCBiZXR3ZWVuIHRoZSBDbGllbnQgQnJva2VyIGFuZCBTZXJ2ZXIg QnJva2VyCgogICBUaGUgQ2xpZW50IGJyb2tlciBuZWVkcyB0byBiZSBhYmxlIHRvIGNvbW11bmlj YXRlIHRoZSBwb3N0dXJlCiAgIGluZm9ybWF0aW9uIHJlZ2FyZGluZyB0aGUgZW5kcG9pbnQgdG8g dGhlIFNlcnZlciBicm9rZXIgd2l0aAogICBjb21tdW5pY2F0aW9ucyBpbnRlZ3JpdHkgYW5kIGNv bmZpZGVudGlhbGl0eS4gIE9uZSBwb3NzaWJsZSBhdmVudWUKICAgdG93YXJkcyBlc3RhYmxpc2hp bmcgdGhpcyBzZWN1cmUgY2hhbm5lbCAoYXQgdGhlIHBlZXIgbGF5ZXIgb2YgdGhlCiAgIENsaWVu dCBicm9rZXIgYW5kIFNlcnZlciBicm9rZXIpIGlzIHRvIGVzdGFibGlzaCBpdCBlbmQtdG8tZW5k CiAgIGJldHdlZW4gTmV0d29yayBhY2Nlc3MgcmVxdWVzdG9yIChOQVIpIGFuZCB0aGUgTmV0d29y ayBhY2Nlc3MKICAgYXV0aG9yaXR5IChOQUEpLiAgVGhpcyBlbmQtdG8tZW5kIHNlY3VyZSBjaGFu bmVsIHdvdWxkIHByZXZlbnQgYW55CiAgIGludGVybWVkaWF0ZSBlbnRpdHksIGluY2x1ZGluZyB0 aGUgTmV0d29yayBlbmZvcmNlciBmcm9tIGdhaW5pbmcKICAgYWNjZXNzIHRvIHRoZSBwb3N0dXJl IGluZm9ybWF0aW9uLiAgVGhlIGV4YWN0IGltcGxlbWVudGF0aW9uIG9mIHRoaXMKICAgc2VjdXJl IGNoYW5uZWwgaXMgZGVwZW5kZW50IG9uIHRoZSBkb21haW4gb2YgYXBwbGljYXRpb24gYW5kIG5l dHdvcmsKICAgY29uZmlndXJhdGlvbi4KCjkuMi4gIEF1dGhvcml6YXRpb24gZm9yIFBsdWctaW4v QnJva2VyIGludGVyYWN0aW9uCgogICBUaGVyZSBpcyBhIGZ1bmN0aW9uYWwgc2VwYXJhdGlvbiBi ZXR3ZWVuIHRoZSBQb3N0dXJlIGNvbGxlY3RvciBhbmQKICAgdGhlIENsaWVudCBicm9rZXIgKGF0 IHRoZSBORUEgY2xpZW50IHNpZGUpIGFuZCBhbHNvIGJldHdlZW4gUG9zdHVyZQogICB2YWxpZGF0 b3IgYW5kIHRoZSBTZXJ2ZXIgYnJva2VyIChhdCB0aGUgTkVBIFNlcnZlciBzaWRlKS4gIEl0IGlz CiAgIGltcG9ydGFudCB0aGF0IGEgQ2xpZW50IGJyb2tlciBiZSBhbGxvd2VkIHRvIGNvbW11bmlj YXRlIHdpdGggb25seQogICB0aGUgYXV0aG9yaXplZCBQb3N0dXJlIGNvbGxlY3RvcnMuICBTaW1p bGFybHksIHRoZSBTZXJ2ZXIgYnJva2VyCiAgIHNob3VsZCBvbmx5IGNvbW11bmljYXRlIHdpdGgg YXV0aG9yaXplZCBQb3N0dXJlIHZhbGlkYXRvcnMuICBSZWNhbGwKICAgdGhhdCB0aGUgUG9zdHVy ZSBjb2xsZWN0b3IgaXMgc29mdHdhcmUgdGhhdCBwcm92aWRlcyBwb3N0dXJlCiAgIGluZm9ybWF0 aW9uIGFib3V0IHRoZSBlbmRwb2ludCBkZXZpY2UgdG8gdGhlIENsaWVudCBicm9rZXIuICBOb3Rl CiAgIHRoYXQgdGhlcmUgbWF5IGJlIG1hbnkgUG9zdHVyZSBjb2xsZWN0b3JzIGluIGEgTkVBIGNs aWVudCwgb25lIHBlcgogICB2ZW5kb3IgYW5kIGFwcGxpY2F0aW9uIHR5cGUuICBXaXRob3V0IHBy b3RlY3Rpb24sIGEgYm9ndXMgUG9zdHVyZQogICBjb2xsZWN0b3IgKFBvc3R1cmUgdmFsaWRhdG9y KSBjYW4gb3BlbiBjb21tdW5pY2F0aW9ucyB3aXRoIHRoZSBDbGllbnQKICAgYnJva2VyIChTZXJ2 ZXIgYnJva2VyKSwgdGhlcmVieSBvcGVuaW5nIHRoZSBwb3NzaWJpbGl0eSBvZiBhIERlbmlhbC0K ICAgb2YtU2VydmljZSBhdHRhY2sgKGF0IHRoZSB2ZXJ5IGxlYXN0KSBhZ2FpbnN0IHRoZSBDbGll bnQgYnJva2VyIGFuZAogICBTZXJ2ZXIgYnJva2VyIHJlc3BlY3RpdmVseS4KCjkuMy4gIFNlbGYt SW50ZWdyaXR5IG9mIHRoZSBORUEgQ2xpZW50IGFuZCBORUEgU2VydmVyCgogICBUaGUgdHJ1c3R3 b3J0aGluZXNzIG9mIHRoZSBwb3N0dXJlIGluZm9ybWF0aW9uIGJlaW5nIHJlcG9ydGVkIGJ5IHRo ZQogICBORUEgY2xpZW50IHRvIHRoZSBORUEgU2VydmVyIGlzIGRlcGVuZGVudCBvbiBhbmQgaXMg b25seSBhcyBnb29kIGFzCiAgIHRoZSBzZWxmLWludGVncml0eSBvZiB0aGUgTkVBIGNsaWVudCBh bmQgTkVBIFNlcnZlciByZXNwZWN0aXZlbHkuICBJZgogICBtYWxpY2lvdXMgY29kZSBvciBvdGhl ciBtYWx3YXJlIGFyZSBwcmVzZW50IGluIHRoZSBORUEgY2xpZW50CiAgIGFjdGl2ZWx5IG1vZGlm eWluZyBwb3N0dXJlIGluZm9ybWF0aW9uIGJlaW5nIGNvbW11bmljYXRlZCBieSB0aGUgTkVBCiAg IGNsaWVudCwgdGhlIE5FQSBTZXJ2ZXIgbWF5IGJlIGJhc2luZyBpdHMgZGVjaXNpb24tbWFraW5n IG9uCiAgIGluYWNjdXJhdGUgb3IgYm9ndXMgcG9zdHVyZSBpbmZvcm1hdGlvbi4gIFRodXMsIGl0 IGlzIGltcG9ydGFudCB0aGF0CiAgIGJvdGggdGhlIE5FQSBjbGllbnQgYW5kIHRoZSBORUEgU2Vy dmVyIGFyZSBwcm90ZWN0ZWQgYWdhaW5zdCBhdHRhY2tzCiAgIHRoYXQgaWxsZWdhbGx5IG1vZGlm eSB0aGUgc3lzdGVtIGNvbmZpZ3VyYXRpb25zIGFuZCBzeXN0ZW0gY29tcG9uZW50cwogICBvZiB0 aGVzZSBlbnRpdGllcy4KCjkuNC4gIFByb3RlY3Rpb24gb2YgcGFyYW1ldGVycyBleGNoYW5nZWQg YWNyb3NzIEludGVyZmFjZXMKCiAgIEFuIGltcG9ydGFudCBhc3BlY3Qgb2YgYW4gTkVBIHN5c3Rl bSBpcyB0aGUgcHJvdGVjdGlvbiBvZiBwYXJhbWV0ZXJzCiAgIGJlaW5nIGNvbW11bmljYXRlZCBi ZXR3ZWVuIHRoZSB2YXJpb3VzIGludGVyZmFjZXMgZGVmaW5lZCBpbiB0aGUKCgoKSGFubmEsIGV0 IGFsLiAgICAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgNSwgMjAwNiAgICAgICAgICAgICAgW1Bh Z2UgMTZdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICBORUEgUHJvYmxlbSBTdGF0ZW1lbnQg ICAgICAgICAgICAgICBNYXJjaCAyMDA2CgoKICAgYXJjaGl0ZWN0dXJlLiAgRXhhbXBsZXMgb2Yg dGhlIHBhcmFtZXRlcnMgYmVpbmcgZXhjaGFuZ2VkIGluY2x1ZGUsCiAgIGJ1dCBhcmUgbm90IGxp bWl0ZWQgdG8sIHN0YXRlIGNoYW5nZSBub3RpZmljYXRpb25zIGJldHdlZW4gdGhlIENsaWVudAog ICBicm9rZXIgYW5kIFBvc3R1cmUgY29sbGVjdG9yLCBzdGF0ZSBjaGFuZ2Ugbm90aWZpY2F0aW9u cyBiZXR3ZWVuIHRoZQogICBTZXJ2ZXIgYnJva2VyIGFuZCBQb3N0dXJlIHZhbGlkYXRvciwgdGhl IHBhcmFtZXRlcnMgYW5kIG1lc3NhZ2VzCiAgIGV4Y2hhbmdlZCBiZXR3ZWVuIHR3byBwZWVyIGVu dGl0aWVzIChvbiB0aGUgTkVBIGNsaWVudCBhbmQgTkVBIFNlcnZlcgogICByZXNwZWN0aXZlbHkp IGFjcm9zcyBJRi1QQSBhbmQgSUYtUEIsIGFuZCBpbiBnZW5lcmFsIHBhcmFtZXRlcnMgYW5kCiAg IG1lc3NhZ2VzIGV4Y2hhbmdlZCBhY3Jvc3MgaW50ZXJmYWNlcyBJRi1QVCwgYW5kIElGLU5BRS4K CjkuNS4gIElkZW50aXR5IGF1dGhlbnRpY2F0aW9uIG9mIGNvbW11bmljYXRpbmcgZW5kLXBvaW50 cwoKICAgSW4gb3JkZXIgZm9yIHRoZSBORUEgU2VydmVyIHRvIGFjY2VwdCBhY2Nlc3MgcmVxdWVz dHMgYW5kIHBvc3R1cmUKICAgaW5mb3JtYXRpb24gYmVpbmcgcmVwb3J0ZWQgdG8gYnkgdGhlIE5F QSBjbGllbnQsIHRoZSBORUEgU2VydmVyIG1heQogICBuZWVkIHRvIGF1dGhlbnRpY2F0ZSB0aGUg TkVBIGNsaWVudCBpbiBzb21lIG1hbm5lci4gIFNpbWlsYXJseSwKICAgd2l0aGluIHNvbWUgbmV0 d29yayBlbnZpcm9ubWVudHMgdGhlcmUgbWF5IGJlIHRoZSByZXF1aXJlbWVudCB0aGF0CiAgIHRo ZSBORUEgY2xpZW50IGFsc28gYXV0aGVudGljYXRlIHRoZSBORUEgU2VydmVyIHdpdGggd2hvbSBp dCBpcwogICBjb21tdW5pY2F0aW5nLiAgQWx0aG91Z2ggdGhlIHByb2Nlc3Mgb2YgZXZhbHVhdGlu ZyBhbiBhY2Nlc3MgcmVxdWVzdAogICBtYXkgY29tYmluZSB0b2dldGhlciB0aGUgbm90aW9uIG9m IGF1dGhlbnRpY2F0aW9uIGFuZCBpbnRlZ3JpdHkgc3RhdGUKICAgZXZhbHVhdGlvbiAodGhyb3Vn aCBwb3N0dXJlIGluZm9ybWF0aW9uKSwgaXQgaXMgaW1wb3J0YW50IGZyb20gYQogICBzZWN1cml0 eSBwZXJzcGVjdGl2ZSBhbmQgdXNlZnVsIGZyb20gYSBnb29kIGVuZ2luZWVyaW5nIHByYWN0aWNl cwogICBwZXJzcGVjdGl2ZSB0byBiZSBhYmxlIHRvIHNlcGFyYXRlIGVuZC1wb2ludCBhdXRoZW50 aWNhdGlvbgogICAoaW5jbHVkaW5nIGJvdGggbWFjaGluZSBhbmQgdXNlciBhdXRoZW50aWNhdGlv bikgZnJvbSBlbmQtcG9pbnQKICAgcG9zdHVyZSBhc3Nlc3NtZW50LgoKCjEwLiAgQWNrbm93bGVk Z2VtZW50cwoKICAgV2UgYWNrbm93bGVkZ2UgdGhlIGNvbnRyaWJ1dGlvbnMgZnJvbSBtZW1iZXJz IG9mIHRoZSBORUEgbWFpbGluZwogICBsaXN0LgoKCjExLiAgUmVmZXJlbmNlcwoKMTEuMS4gIE5v cm1hdGl2ZSBSZWZlcmVuY2VzCgogICBbUkZDMjExOV0gIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRz IGZvciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZQogICAgICAgICAgICAgIFJlcXVpcmVtZW50IExl dmVscyIsIEJDUCAxNCwgUkZDIDIxMTksIE1hcmNoIDE5OTcuCgogICBbUkZDMjg2NV0gIFJpZ25l eSwgQy4sIFdpbGxlbnMsIFMuLCBSdWJlbnMsIEEuLCBhbmQgVy4gU2ltcHNvbiwKICAgICAgICAg ICAgICAiUmVtb3RlIEF1dGhlbnRpY2F0aW9uIERpYWwgSW4gVXNlciBTZXJ2aWNlIChSQURJVVMp IiwKICAgICAgICAgICAgICBSRkMgMjg2NSwgSnVuZSAyMDAwLgoKICAgW1JGQzM3NDhdICBBYm9i YSwgQi4sIEJsdW5rLCBMLiwgVm9sbGJyZWNodCwgSi4sIENhcmxzb24sIEouLCBhbmQgSC4KICAg ICAgICAgICAgICBMZXZrb3dldHosICJFeHRlbnNpYmxlIEF1dGhlbnRpY2F0aW9uIFByb3RvY29s IChFQVApIiwKICAgICAgICAgICAgICBSRkMgMzc0OCwgSnVuZSAyMDA0LgoKCgoKCgoKSGFubmEs IGV0IGFsLiAgICAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgNSwgMjAwNiAgICAgICAgICAgICAg W1BhZ2UgMTddCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICBORUEgUHJvYmxlbSBTdGF0ZW1l bnQgICAgICAgICAgICAgICBNYXJjaCAyMDA2CgoKMTEuMi4gIEluZm9ybWF0aXZlIFJlZmVyZW5j ZXMKCiAgIFs4MDIuMVhdICAgSUVFRSwgIkxvY2FsIGFuZCBNZXRyb3BvbGl0YW4gQXJlYSBOZXR3 b3JrczpQb3J0LWJhc2VkCiAgICAgICAgICAgICAgTmV0d29yayBBY2Nlc3MgQ29udHJvbCIsIDIw MDQuCgogICBbSS1ELmlldGYtcGFuYS1wYW5hXQogICAgICAgICAgICAgIEZvcnNiZXJnLCBELiwg IlByb3RvY29sIGZvciBDYXJyeWluZyBBdXRoZW50aWNhdGlvbiBmb3IKICAgICAgICAgICAgICBO ZXR3b3JrIEFjY2VzcyAoUEFOQSkiLCBkcmFmdC1pZXRmLXBhbmEtcGFuYS0xMSAod29yayBpbgog ICAgICAgICAgICAgIHByb2dyZXNzKSwgTWFyY2ggMjAwNi4KCiAgIFtJLUQudGhvbXNvbi1uYWNw XQogICAgICAgICAgICAgIFNhbG93ZXksIEouLCBUaG9tc29uLCBTLiwgV3UsIEYuLCBZYXJsYWdh ZGRhLCBWLiwgYW5kIEguCiAgICAgICAgICAgICAgWmhvdSwgIk5ldHdvcmsgQWNjZXNzIENvbnRy b2wgUHJvdG9jb2wgKE5BQ1ApIiwKICAgICAgICAgICAgICBkcmFmdC10aG9tc29uLW5hY3AtMDIg KHdvcmsgaW4gcHJvZ3Jlc3MpLCBNYXJjaCAyMDA2LgoKICAgW05BQ10gICAgICBDaXNjbyBTeXN0 ZW1zLCAiTmV0d29yayBBZG1pc3Npb24gQ29udHJvbCBUZWNobmljYWwKICAgICAgICAgICAgICBP dmVydmlldyIsIDIwMDUuCgogICBbTkFQXSAgICAgIE1pY3Jvc29mdCBDb3Jwb3JhdGlvbiwgIk5l dHdvcmsgQWNjZXNzIFByb3RlY3Rpb24gUGxhdGZvcm0KICAgICAgICAgICAgICBBcmNoaXRlY3R1 cmUiLCBGZWJydWFyeSAyMDA2LgoKICAgW1ROQ10gICAgICBUQ0csICJUTkMgQXJjaGl0ZWN0dXJl IGZvciBJbnRlcm9wZXJhYmlsaXR5IFNwZWNpZmljYXRpb24KICAgICAgICAgICAgICB2MS4wIiwg TWF5IDIwMDUuCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpIYW5uYSwgZXQgYWwuICAgICAg ICAgICBFeHBpcmVzIFNlcHRlbWJlciA1LCAyMDA2ICAgICAgICAgICAgICBbUGFnZSAxOF0KDApJ bnRlcm5ldC1EcmFmdCAgICAgICAgICAgIE5FQSBQcm9ibGVtIFN0YXRlbWVudCAgICAgICAgICAg ICAgIE1hcmNoIDIwMDYKCgpBdXRob3JzJyBBZGRyZXNzZXMKCiAgIFN0ZXZlIEhhbm5hCiAgIEp1 bmlwZXIgTmV0d29ya3MKICAgMzUgRm9yZXN0IFJpZGdlIFJvYWQKICAgQ29uY29yZCwgTUEgIDAx NzQyCiAgIFUuUy5BLgoKICAgUGhvbmU6IDc4MS03MjktOTU1OQogICBFbWFpbDogc2hhbm5hQGp1 bmlwZXIubmV0CgoKICAgVGhvbWFzIEhhcmRqb25vCiAgIFNpZ25hY2VydCBJbmMKICAgMTE1IFNX IEFzaCBTdHJlZXQKICAgU3VpdGUgNDMwCiAgIFBvcnRsYW5kLCBPUiAgOTcyMDQKICAgVS5TLkEK CiAgIFBob25lOiA3ODEtNzI5LTk1NTkKICAgRW1haWw6IHRoYXJkam9ub0BzaWduYWNlcnQuY29t CgoKICAgU3VzYW4gVGhvbXNvbgogICBDaXNjbyBTeXN0ZW1zCiAgIDQ5OSBUaG9ybmFsbCBTdHJl ZXQsIDh0aCBmbG9vcgogICBFZGlzb24sIE5KICAwODgzNwogICBVLlMuQS4KCiAgIFBob25lOiA3 MzItNjM1LTMwODYKICAgRW1haWw6IHNldGhvbXNvQGNpc2NvLmNvbQoKCgoKCgoKCgoKCgoKCgoK CgoKCkhhbm5hLCBldCBhbC4gICAgICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDUsIDIwMDYgICAg ICAgICAgICAgIFtQYWdlIDE5XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgTkVBIFByb2Js ZW0gU3RhdGVtZW50ICAgICAgICAgICAgICAgTWFyY2ggMjAwNgoKCkludGVsbGVjdHVhbCBQcm9w ZXJ0eSBTdGF0ZW1lbnQKCiAgIFRoZSBJRVRGIHRha2VzIG5vIHBvc2l0aW9uIHJlZ2FyZGluZyB0 aGUgdmFsaWRpdHkgb3Igc2NvcGUgb2YgYW55CiAgIEludGVsbGVjdHVhbCBQcm9wZXJ0eSBSaWdo dHMgb3Igb3RoZXIgcmlnaHRzIHRoYXQgbWlnaHQgYmUgY2xhaW1lZCB0bwogICBwZXJ0YWluIHRv IHRoZSBpbXBsZW1lbnRhdGlvbiBvciB1c2Ugb2YgdGhlIHRlY2hub2xvZ3kgZGVzY3JpYmVkIGlu CiAgIHRoaXMgZG9jdW1lbnQgb3IgdGhlIGV4dGVudCB0byB3aGljaCBhbnkgbGljZW5zZSB1bmRl ciBzdWNoIHJpZ2h0cwogICBtaWdodCBvciBtaWdodCBub3QgYmUgYXZhaWxhYmxlOyBub3IgZG9l cyBpdCByZXByZXNlbnQgdGhhdCBpdCBoYXMKICAgbWFkZSBhbnkgaW5kZXBlbmRlbnQgZWZmb3J0 IHRvIGlkZW50aWZ5IGFueSBzdWNoIHJpZ2h0cy4gIEluZm9ybWF0aW9uCiAgIG9uIHRoZSBwcm9j ZWR1cmVzIHdpdGggcmVzcGVjdCB0byByaWdodHMgaW4gUkZDIGRvY3VtZW50cyBjYW4gYmUKICAg Zm91bmQgaW4gQkNQIDc4IGFuZCBCQ1AgNzkuCgogICBDb3BpZXMgb2YgSVBSIGRpc2Nsb3N1cmVz IG1hZGUgdG8gdGhlIElFVEYgU2VjcmV0YXJpYXQgYW5kIGFueQogICBhc3N1cmFuY2VzIG9mIGxp Y2Vuc2VzIHRvIGJlIG1hZGUgYXZhaWxhYmxlLCBvciB0aGUgcmVzdWx0IG9mIGFuCiAgIGF0dGVt cHQgbWFkZSB0byBvYnRhaW4gYSBnZW5lcmFsIGxpY2Vuc2Ugb3IgcGVybWlzc2lvbiBmb3IgdGhl IHVzZSBvZgogICBzdWNoIHByb3ByaWV0YXJ5IHJpZ2h0cyBieSBpbXBsZW1lbnRlcnMgb3IgdXNl cnMgb2YgdGhpcwogICBzcGVjaWZpY2F0aW9uIGNhbiBiZSBvYnRhaW5lZCBmcm9tIHRoZSBJRVRG IG9uLWxpbmUgSVBSIHJlcG9zaXRvcnkgYXQKICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pcHIuCgog ICBUaGUgSUVURiBpbnZpdGVzIGFueSBpbnRlcmVzdGVkIHBhcnR5IHRvIGJyaW5nIHRvIGl0cyBh dHRlbnRpb24gYW55CiAgIGNvcHlyaWdodHMsIHBhdGVudHMgb3IgcGF0ZW50IGFwcGxpY2F0aW9u cywgb3Igb3RoZXIgcHJvcHJpZXRhcnkKICAgcmlnaHRzIHRoYXQgbWF5IGNvdmVyIHRlY2hub2xv Z3kgdGhhdCBtYXkgYmUgcmVxdWlyZWQgdG8gaW1wbGVtZW50CiAgIHRoaXMgc3RhbmRhcmQuICBQ bGVhc2UgYWRkcmVzcyB0aGUgaW5mb3JtYXRpb24gdG8gdGhlIElFVEYgYXQKICAgaWV0Zi1pcHJA aWV0Zi5vcmcuCgoKRGlzY2xhaW1lciBvZiBWYWxpZGl0eQoKICAgVGhpcyBkb2N1bWVudCBhbmQg dGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gYXJlIHByb3ZpZGVkIG9uIGFuCiAgICJB UyBJUyIgYmFzaXMgYW5kIFRIRSBDT05UUklCVVRPUiwgVEhFIE9SR0FOSVpBVElPTiBIRS9TSEUg UkVQUkVTRU5UUwogICBPUiBJUyBTUE9OU09SRUQgQlkgKElGIEFOWSksIFRIRSBJTlRFUk5FVCBT T0NJRVRZIEFORCBUSEUgSU5URVJORVQKICAgRU5HSU5FRVJJTkcgVEFTSyBGT1JDRSBESVNDTEFJ TSBBTEwgV0FSUkFOVElFUywgRVhQUkVTUyBPUiBJTVBMSUVELAogICBJTkNMVURJTkcgQlVUIE5P VCBMSU1JVEVEIFRPIEFOWSBXQVJSQU5UWSBUSEFUIFRIRSBVU0UgT0YgVEhFCiAgIElORk9STUFU SU9OIEhFUkVJTiBXSUxMIE5PVCBJTkZSSU5HRSBBTlkgUklHSFRTIE9SIEFOWSBJTVBMSUVECiAg IFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZIE9SIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxB UiBQVVJQT1NFLgoKCkNvcHlyaWdodCBTdGF0ZW1lbnQKCiAgIENvcHlyaWdodCAoQykgVGhlIElu dGVybmV0IFNvY2lldHkgKDIwMDYpLiAgVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0CiAgIHRvIHRo ZSByaWdodHMsIGxpY2Vuc2VzIGFuZCByZXN0cmljdGlvbnMgY29udGFpbmVkIGluIEJDUCA3OCwg YW5kCiAgIGV4Y2VwdCBhcyBzZXQgZm9ydGggdGhlcmVpbiwgdGhlIGF1dGhvcnMgcmV0YWluIGFs bCB0aGVpciByaWdodHMuCgoKQWNrbm93bGVkZ21lbnQKCiAgIEZ1bmRpbmcgZm9yIHRoZSBSRkMg RWRpdG9yIGZ1bmN0aW9uIGlzIGN1cnJlbnRseSBwcm92aWRlZCBieSB0aGUKICAgSW50ZXJuZXQg U29jaWV0eS4KCgoKCkhhbm5hLCBldCBhbC4gICAgICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDUs IDIwMDYgICAgICAgICAgICAgIFtQYWdlIDIwXQoMCgo= ------_=_NextPart_001_01C63FCC.C412A1E9 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea ------_=_NextPart_001_01C63FCC.C412A1E9-- From nea-bounces@ietf.org Mon Mar 06 09:41:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGGtX-0005Gk-T3; Mon, 06 Mar 2006 09:41:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGGtW-0005Ge-HR for nea@ietf.org; Mon, 06 Mar 2006 09:41:06 -0500 Received: from fmr21.intel.com ([143.183.121.13] helo=scsfmr001.sc.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGGtT-0004aQ-SV for nea@ietf.org; Mon, 06 Mar 2006 09:41:06 -0500 Received: from scsfmr101.sc.intel.com (scsfmr101.sc.intel.com [10.3.253.10]) by scsfmr001.sc.intel.com (8.12.10/8.12.10/d: major-outer.mc, v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id k26Ef2O1013557 for ; Mon, 6 Mar 2006 14:41:02 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by scsfmr101.sc.intel.com (8.12.10/8.12.10/d: major-inner.mc, v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id k26EZRNg029475 for ; Mon, 6 Mar 2006 14:35:32 GMT Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2006030606410220957 for ; Mon, 06 Mar 2006 06:41:02 -0800 Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 6 Mar 2006 06:41:02 -0800 Received: from hdsmsx401.amr.corp.intel.com ([10.127.2.60]) by fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 6 Mar 2006 06:41:02 -0800 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Nea] Updated problem statement I-D X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Mon, 6 Mar 2006 09:40:43 -0500 Message-ID: <5404AEB459F8354F81995E038F3432000292BD7C@hdsmsx401.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Updated problem statement I-D Thread-Index: AcY/zMO5h4OHW3KdStesitCHo6sDbgBXnoLg From: "Blumenthal, Uri" To: X-OriginalArrivalTime: 06 Mar 2006 14:41:02.0212 (UTC) FILETIME=[FDAEAC40:01C6412B] X-Scanned-By: MIMEDefang 2.52 on 10.3.253.10 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1019857189==" Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============1019857189== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6412B.FBE12960" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6412B.FBE12960 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Susan, =20 Great job! =20 =20 I'm especially happy to see the explicit IF-PV protocol there - as IMHO it is _far_ more likely that the Validator will be separated from the Server broker.=20 =20 Regards, Uri. ________________________________ From: Susan Thomson (sethomso) [mailto:sethomso@cisco.com]=20 Sent: Saturday, March 04, 2006 3:47 PM To: nea@ietf.org Subject: [Nea] Updated problem statement I-D =09 =09 I have sent the updated problem statement I-D to the IETF secretariat for publication. In the meantime, have attached the document for your review. =20 The I-D has been updated to be consistent with the proposed WG charter and to take into account comments received on the mailing list. (The proposed charter will need to be tweaked to reflect new names for some of the interfaces).=20 =20 Main Changes: =09 --- Terminology changed to that suggested by Mauricio Sanchez in his comments to mailing list --- Emphasized throughout that focus not on new architecture, but interoperability=20 --- Put an explicit stake in the ground that the initial focus is on an EAP/Radius instantiation of an NEA architecture --- Identified the 2 EAP protocols at IF-PT layer as IF-PTT (EAP tunneling method) and IF-PTC (EAP carrier protocol).=20 --- For convenience, mapped NEA terminology with that used in 3 existing architectures: TNC, NAP, NAC --- References added=20 =20 Feedback appreciated, especially where there may be lack of clarity or disagreement that may preclude a successful BoF. Better to air these on the mailing list now so that we can attempt to address them prior to the BoF. =20 Thanks Steve & Susan ------_=_NextPart_001_01C6412B.FBE12960 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Susan,

Great=20 job!

I'm=20 especially happy to see the explicit IF-PV protocol there - as IMHO it = is _far_=20 more likely that the Validator will be separated from the = Server=20 broker.

Regards,

Uri.

From: Susan Thomson (sethomso)=20 [mailto:sethomso@cisco.com]
Sent: Saturday, March 04, 2006 = 3:47=20 PM
To: nea@ietf.org
Subject: [Nea] Updated problem = statement I-D

I = have sent the=20 updated problem statement I-D to the IETF secretariat for publication. = In the=20 meantime, have attached the document for your = review.

The = I-D has been=20 updated to be consistent with the proposed WG charter and to = take into=20 account comments received on the mailing list. = (The proposed=20 charter will need to be tweaked to reflect new names for some of the=20 interfaces).

Main = Changes:

---=20 Terminology changed to that suggested by Mauricio Sanchez in his comments to mailing=20 list

--- = Emphasized=20 throughout that focus not on = new=20 architecture, but interoperability

--- = Put an=20 explicit stake in the ground that the initial focus is on an = EAP/Radius=20 instantiation of an NEA architecture

--- = Identified the=20 2 EAP protocols at IF-PT layer as IF-PTT (EAP tunneling method) and = IF-PTC=20 (EAP carrier protocol).

--- For convenience, mapped NEA = terminology with=20 that used in 3 existing architectures: TNC, NAP,=20 NAC

--- = References=20 added

Feedback appreciated, especially where = there may be=20 lack of clarity or disagreement that may preclude a successful BoF. = Better to=20 air these on the mailing list now so that we can attempt to address = them prior=20 to the BoF.

Thanks

Steve &=20 = Susan

<= /HTML> ------_=_NextPart_001_01C6412B.FBE12960-- --===============1019857189== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea --===============1019857189==-- From nea-bounces@ietf.org Mon Mar 06 11:40:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGIkp-0005cF-CF; Mon, 06 Mar 2006 11:40:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGIkn-0005c7-EB for nea@ietf.org; Mon, 06 Mar 2006 11:40:13 -0500 Received: from fmr17.intel.com ([134.134.136.16] helo=orsfmr002.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGIkm-0000eS-Rj for nea@ietf.org; Mon, 06 Mar 2006 11:40:13 -0500 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr002.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc, v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id k26GeCTQ023835 for ; Mon, 6 Mar 2006 16:40:12 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc, v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id k26Ge9Wi028718 for ; Mon, 6 Mar 2006 16:40:11 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2006030608401012206 for ; Mon, 06 Mar 2006 08:40:10 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 6 Mar 2006 08:40:10 -0800 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Nea] Updated problem statement I-D Date: Mon, 6 Mar 2006 08:40:07 -0800 Message-ID: <468F3FDA28AA87429AD807992E22D07E08BB0B41@orsmsx408> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Updated problem statement I-D thread-index: AcY/zMO5h4OHW3KdStesitCHo6sDbgBXnoLgAAQcv4A= From: "Khosravi, Hormuzd M" To: X-OriginalArrivalTime: 06 Mar 2006 16:40:10.0553 (UTC) FILETIME=[A26CF290:01C6413C] X-Scanned-By: MIMEDefang 2.52 on 10.7.209.17 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4166dd0e0c668adc975c3d3e0f1bce3b X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1915705887==" Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============1915705887== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6413C.A1B233FA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6413C.A1B233FA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Susan & team, =20 The draft looks very good, great job! Looks like most all the comments on the list have been addressed. =20 I was glad to see the Posture Validation Interface as well, I think this one is important for end-to-end interoperability. =20 See you guys at the IETF meeting, =20 regards Hormuzd =20 =09 ________________________________ From: Susan Thomson (sethomso) [mailto:sethomso@cisco.com]=20 Sent: Saturday, March 04, 2006 3:47 PM To: nea@ietf.org Subject: [Nea] Updated problem statement I-D I have sent the updated problem statement I-D to the IETF secretariat for publication. In the meantime, have attached the document for your review. =20 The I-D has been updated to be consistent with the proposed WG charter and to take into account comments received on the mailing list. (The proposed charter will need to be tweaked to reflect new names for some of the interfaces).=20 =20 Main Changes: --- Terminology changed to that suggested by Mauricio Sanchez in his comments to mailing list --- Emphasized throughout that focus not on new architecture, but interoperability=20 --- Put an explicit stake in the ground that the initial focus is on an EAP/Radius instantiation of an NEA architecture --- Identified the 2 EAP protocols at IF-PT layer as IF-PTT (EAP tunneling method) and IF-PTC (EAP carrier protocol).=20 --- For convenience, mapped NEA terminology with that used in 3 existing architectures: TNC, NAP, NAC --- References added=20 =20 Feedback appreciated, especially where there may be lack of clarity or disagreement that may preclude a successful BoF. Better to air these on the mailing list now so that we can attempt to address them prior to the BoF. =20 Thanks Steve & Susan ------_=_NextPart_001_01C6413C.A1B233FA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Susan & team,

The draft looks very good, great = job!

Looks like most all the comments on = the list have been addressed.

I was glad to see the Posture = Validation Interface as well, I think this one is important for end-to-end interoperability.

See you guys at the IETF = meeting,

regards

Hormuzd

From: Susan Thomson (sethomso) [mailto:sethomso@cisco.com]
Sent: Saturday, March 04, = 2006 3:47 PM
To: nea@ietf.org
Subject: [Nea] Updated = problem statement I-D

I have sent the updated problem statement I-D to the = IETF secretariat for publication. In the meantime, have attached the document = for your review.

The I-D has been updated to be consistent with = the proposed WG charter and to take into account comments received on = the mailing list. (The proposed charter will need to be tweaked to = reflect new names for some of the interfaces).

Main Changes:

--- Terminology changed to that suggested by Mauricio Sanchez in his comments to mailing list

--- Emphasized throughout that focus not on new architecture, but interoperability

--- Put an explicit stake in the ground that the initial focus is on an EAP/Radius instantiation of an NEA = architecture

--- Identified the 2 EAP protocols at IF-PT layer as = IF-PTT (EAP tunneling method) and IF-PTC (EAP carrier protocol). =

--- For convenience, mapped NEA terminology with that used in 3 existing architectures: TNC, NAP, = NAC

--- References added

Feedback appreciated, especially where there may be = lack of clarity or disagreement that may preclude a successful BoF. Better to = air these on the mailing list now so that we can attempt to address them prior to = the BoF.

Thanks

Steve & Susan

------_=_NextPart_001_01C6413C.A1B233FA-- --===============1915705887== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea --===============1915705887==-- From nea-bounces@ietf.org Tue Mar 07 09:31:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGdE6-0008AU-NH; Tue, 07 Mar 2006 09:31:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGdE5-0008AF-1c for nea@ietf.org; Tue, 07 Mar 2006 09:31:49 -0500 Received: from vulcan.rsasecurity.com ([216.162.240.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGdE3-0004hF-Q9 for nea@ietf.org; Tue, 07 Mar 2006 09:31:49 -0500 Received: from hyperion.na.rsa.net by vulcan.rsasecurity.com via smtpd (for stiedprmail1.ietf.org [156.154.16.150]) with ESMTP; Tue, 7 Mar 2006 09:31:47 -0500 Received: from sdtihq24.securid.com (sdtihq24.na.rsa.net [10.100.8.152]) by hyperion.na.rsa.net (MOS 3.7.4b-GA) with ESMTP id ABN30821; Tue, 7 Mar 2006 09:31:47 -0500 (EST) Received: from rsana-ex-hq1.NA.RSA.NET (rsana-ex-hq1.na.rsa.net [10.100.8.50]) by sdtihq24.securid.com (8.12.10/8.12.9) with ESMTP id k27EVjkI006805 for ; Tue, 7 Mar 2006 09:31:45 -0500 (EST) 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: Tue, 7 Mar 2006 09:30:47 -0500 Message-ID: <017630AA6DF2DF4EBC1DD4454F8EE29707BA34AC@rsana-ex-hq1.NA.RSA.NET> Thread-Topic: Updated problem statement I-D Thread-Index: AcY/1H4cJ7nJc1vGRhico2z8/lZICACHlc3Q From: "Polansky, Robert" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [Nea] RE: Updated problem statement I-D X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org I would echo others' statements that this is a good statement of the problem at hand. I know I haven't contributed in the past, but I do have a request for a minor clarification on section 9.5. It says that "it is important from a security perspective" to be able to separate end-point authentication from end-point posture assessment. I understand why you need to be able to separate the architectures from an engineering perspective, but I think the document should be more specific as to the security concerns around why they need to be separable. Is there is risk in overloading one architecture with the other's functionality? Thanks. -Rob Polansky -----Original Message----- From: nea-request@ietf.org [mailto:nea-request@ietf.org]=20 Sent: Saturday, March 04, 2006 3:42 PM To: nea@ietf.org Subject: Nea Digest, Vol 5, Issue 1 [...] 9.5. Identity authentication of communicating end-points In order for the NEA Server to accept access requests and posture information being reported to by the NEA client, the NEA Server may need to authenticate the NEA client in some manner. Similarly, within some network environments there may be the requirement that the NEA client also authenticate the NEA Server with whom it is communicating. Although the process of evaluating an access request may combine together the notion of authentication and integrity state evaluation (through posture information), it is important from a security perspective and useful from a good engineering practices perspective to be able to separate end-point authentication (including both machine and user authentication) from end-point posture assessment. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Mar 07 13:58:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGhO3-0001Wd-Pt; Tue, 07 Mar 2006 13:58:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGhNm-0001Hl-CJ for nea@ietf.org; Tue, 07 Mar 2006 13:58:06 -0500 Received: from mail.signacert.com ([207.162.214.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGhDp-0006EM-Bs for nea@ietf.org; Tue, 07 Mar 2006 13:47:51 -0500 Received: from SCTPHTP42 (unknown [207.162.210.168]) by mail.signacert.com (Postfix) with ESMTP id EF88518EC459; Tue, 7 Mar 2006 10:47:47 -0800 (PST) From: "Thomas Hardjono" To: "'Polansky, Robert'" , Subject: RE: [Nea] RE: Updated problem statement I-D Date: Tue, 7 Mar 2006 10:47:47 -0800 Organization: SignaCert Message-ID: <006401c64217$a0ea0490$9603a8c0@SCTPHTP42> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <017630AA6DF2DF4EBC1DD4454F8EE29707BA34AC@rsana-ex-hq1.NA.RSA.NET> Thread-Index: AcY/1H4cJ7nJc1vGRhico2z8/lZICACHlc3QAAjAlSA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: thomas@signacert.com X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: THardjono@signacert.com List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Rob, The concept of (i) authentication (user or device) is quite distinct from (ii) measuring/reporting the integrity state ("health") of a device. Each have their respective design and security issues (e.g. when a health report is being sent from the client to the server, what is used to protect it in-transit.). So far the IP networking industry has only seen authentication (i) (eg. in the form of passwords, SecureID tokens, certs/PKI, etc.) We have not really seen an industry-wide adoption of (ii) and hence the NEA BOF. These two distinct concepts are separable, but need not be separated in implementations. (For example, in the context of 802.1X with tunneled EAP methods, some form of authentication mechanism might be used to identify the end-points wishing to open the outer-tunnel, while the client health information is sent inside the inner-tunnel. Only the success of both will lead to a common master-key.) PS. I must confess I don't really understand the last sentence of your question ("risk in overloading one architecture with the other's functionality"). Perhaps you could clarify. cheers, /thomas/ -----Original Message----- From: Polansky, Robert [mailto:rpolansky@rsasecurity.com] Sent: Tuesday, March 07, 2006 6:31 AM To: nea@ietf.org Subject: [Nea] RE: Updated problem statement I-D I would echo others' statements that this is a good statement of the problem at hand. I know I haven't contributed in the past, but I do have a request for a minor clarification on section 9.5. It says that "it is important from a security perspective" to be able to separate end-point authentication from end-point posture assessment. I understand why you need to be able to separate the architectures from an engineering perspective, but I think the document should be more specific as to the security concerns around why they need to be separable. Is there is risk in overloading one architecture with the other's functionality? Thanks. -Rob Polansky -----Original Message----- From: nea-request@ietf.org [mailto:nea-request@ietf.org] Sent: Saturday, March 04, 2006 3:42 PM To: nea@ietf.org Subject: Nea Digest, Vol 5, Issue 1 [...] 9.5. Identity authentication of communicating end-points In order for the NEA Server to accept access requests and posture information being reported to by the NEA client, the NEA Server may need to authenticate the NEA client in some manner. Similarly, within some network environments there may be the requirement that the NEA client also authenticate the NEA Server with whom it is communicating. Although the process of evaluating an access request may combine together the notion of authentication and integrity state evaluation (through posture information), it is important from a security perspective and useful from a good engineering practices perspective to be able to separate end-point authentication (including both machine and user authentication) from end-point posture assessment. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Mar 07 14:43:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGi5m-0000lK-6y; Tue, 07 Mar 2006 14:43:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGi5k-0000k5-Ge for nea@ietf.org; Tue, 07 Mar 2006 14:43:32 -0500 Received: from e34.co.us.ibm.com ([32.97.110.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGi5k-00008J-2t for nea@ietf.org; Tue, 07 Mar 2006 14:43:32 -0500 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e34.co.us.ibm.com (8.12.11/8.12.11) with ESMTP id k27JhVG4004943 for ; Tue, 7 Mar 2006 14:43:31 -0500 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k27JkKLf178896 for ; Tue, 7 Mar 2006 12:46:20 -0700 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id k27JhUQF007287 for ; Tue, 7 Mar 2006 12:43:30 -0700 Received: from d03nm129.boulder.ibm.com (d03nm129.boulder.ibm.com [9.17.195.155]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id k27JhUsm007284 for ; Tue, 7 Mar 2006 12:43:30 -0700 Subject: [NEA] Problem Statement Draft - correction/clarification To: nea@ietf.org X-Mailer: Lotus Notes Release 7.0 HF85 November 04, 2005 Message-ID: From: Frank Yeh Jr Date: Tue, 7 Mar 2006 11:43:22 -0800 X-MIMETrack: Serialize by Router on D03NM129/03/M/IBM(Release 7.0HF124 | January 12, 2006) at 03/07/2006 12:46:09 MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1981192942==" Errors-To: nea-bounces@ietf.org --===============1981192942== Content-type: multipart/alternative; Boundary="0__=07BBFBB9DFF8D2778f9e8a93df938690918c07BBFBB9DFF8D277" Content-Disposition: inline --0__=07BBFBB9DFF8D2778f9e8a93df938690918c07BBFBB9DFF8D277 Content-type: text/plain; charset=US-ASCII I believe that Figure 1 in section 6 has the IF-PV interface arrow pointing the wrong way_ it doesn't connect anything. |-------------| |----------------| | Posture | <-------IF-PA-------> | Posture | | Collectors | | Validators | | (1 ...N) | | (1 ...N) | |-------------| |----------------| | | | <------IF-PV--------> | | |-------------| |----------------| | Client | <-------IF-PB-------> | Server | | Broker | | Broker | |--------- ---| |----------------| | | | | |-------------| <------IF-PT-------> |----------------| | | | | | Network | |--------| | Network | | Access |----|Network |------------| Access | | Requestor | |Enforcer| <-IF-NAE-> | Authority | |-------------| |--------| |----------------| NEA CLIENT NEA SERVER Figure 1: NEA Components and Interfaces Section 7 describes the IF-PV as: Posture validator interface (IF-PV): This protocol acts as a carrier for posture attributes between a Server broker and a Posture validator that is not co-located in the NEA server. Shouldn't the figure look like this? |-------------| |----------------| | Posture | <-------IF-PA-------> | Posture | | Collectors | | Validators | | (1 ...N) | | (1 ...N) | |-------------| |----------------| | | ^ | | | | | IF-PV | | | | | v |-------------| |----------------| | Client | <-------IF-PB-------> | Server | | Broker | | Broker | |--------- ---| |----------------| | | | | |-------------| <------IF-PT-------> |----------------| | | | | | Network | |--------| | Network | | Access |----|Network |------------| Access | | Requestor | |Enforcer| <-IF-NAE-> | Authority | |-------------| |--------| |----------------| NEA CLIENT NEA SERVER Figure 1: NEA Components and Interfaces Thanks, Frank Yeh --0__=07BBFBB9DFF8D2778f9e8a93df938690918c07BBFBB9DFF8D277 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

I believe that Figure 1 in section 6 has the IF-PV interface arrow pointing the wrong way_ it doesn't connect anything.

|-------------| |----------------|
| Posture | <-------IF-PA-------> | Posture |
| Collectors | | Validators |
| (1 ...N) | | (1 ...N) |
|-------------| |----------------|
| |
| <------IF-PV-------->
| |
|-------------| |----------------|
| Client | <-------IF-PB-------> | Server |
| Broker | | Broker |
|--------- ---| |----------------|
| |
| |
|-------------| <------IF-PT-------> |----------------|
| | | |
| Network | |--------| | Network |
| Access |----|Network |------------| Access |
| Requestor | |Enforcer| <-IF-NAE-> | Authority |
|-------------| |--------| |----------------|

NEA CLIENT NEA SERVER
Figure 1: NEA Components and Interfaces

Section 7 describes the IF-PV as:
Posture validator interface (IF-PV): This protocol acts as a
carrier for posture attributes between a Server broker and a
Posture validator that is not co-located in the NEA server.

Shouldn't the figure look like this?

|-------------| |----------------|
| Posture | <-------IF-PA-------> | Posture |
| Collectors | | Validators |
| (1 ...N) | | (1 ...N) |
|-------------| |----------------|
| | ^
| | |
| | IF-PV
| | |
| | v
|-------------| |----------------|
| Client | <-------IF-PB-------> | Server |
| Broker | | Broker |
|--------- ---| |----------------|
| |
| |
|-------------| <------IF-PT-------> |----------------|
| | | |
| Network | |--------| | Network |
| Access |----|Network |------------| Access |
| Requestor | |Enforcer| <-IF-NAE-> | Authority |
|-------------| |--------| |----------------|

NEA CLIENT NEA SERVER
Figure 1: NEA Components and Interfaces

Thanks,
Frank Yeh --0__=07BBFBB9DFF8D2778f9e8a93df938690918c07BBFBB9DFF8D277-- --===============1981192942== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea --===============1981192942==-- From nea-bounces@ietf.org Tue Mar 07 16:06:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGjNd-0002Nl-GK; Tue, 07 Mar 2006 16:06:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGjNb-0002N6-Px for nea@ietf.org; Tue, 07 Mar 2006 16:06:03 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGjNb-0006Of-7t for nea@ietf.org; Tue, 07 Mar 2006 16:06:03 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 07 Mar 2006 13:06:03 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k27L5j85003791; Tue, 7 Mar 2006 13:06:02 -0800 (PST) Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 7 Mar 2006 16:06:00 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [NEA] Problem Statement Draft - correction/clarification Date: Tue, 7 Mar 2006 16:06:00 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NEA] Problem Statement Draft - correction/clarification Thread-Index: AcZCH2+hko+KH8cDQtKxsEJKz5HB2QACw12Q From: "Susan Thomson $sethomso$" To: "Frank Yeh Jr" , X-OriginalArrivalTime: 07 Mar 2006 21:06:00.0669 (UTC) FILETIME=[EFD940D0:01C6422A] X-Spam-Score: 1.9 (+) X-Scan-Signature: b84f8c8fba0e1389e5eb998b64078964 Cc: X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0064143060==" Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============0064143060== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6422A.EF830AE8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6422A.EF830AE8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Frank =20 Yes. Either that, or it should be a straight line with no arrows representing an "interface" of interest (this is what I was originally thinking when I drew it). =20 Thanks for pointing this out, and sorry for the confusion. Will take the action to update. =20 Susan ________________________________ From: Frank Yeh Jr [mailto:fyeh@us.ibm.com]=20 Sent: Tuesday, March 07, 2006 2:43 PM To: nea@ietf.org Subject: [NEA] Problem Statement Draft - correction/clarification =09 =09 I believe that Figure 1 in section 6 has the IF-PV interface arrow pointing the wrong way_ it doesn't connect anything. =09 =09 |-------------| |----------------| | Posture | <-------IF-PA-------> | Posture | | Collectors | | Validators | | (1 ...N) | | (1 ...N) | |-------------| |----------------| | | | <------IF-PV--------> | | |-------------| |----------------| | Client | <-------IF-PB-------> | Server | | Broker | | Broker | |--------- ---| |----------------| | | | | |-------------| <------IF-PT-------> |----------------| | | | | | Network | |--------| | Network | | Access |----|Network |------------| Access | | Requestor | |Enforcer| <-IF-NAE-> | Authority | |-------------| |--------| |----------------| =09 NEA CLIENT NEA SERVER Figure 1: NEA Components and Interfaces =09 Section 7 describes the IF-PV as: Posture validator interface (IF-PV): This protocol acts as a carrier for posture attributes between a Server broker and a Posture validator that is not co-located in the NEA server. =09 Shouldn't the figure look like this? =09 =09 |-------------| |----------------| | Posture | <-------IF-PA-------> | Posture | | Collectors | | Validators | | (1 ...N) | | (1 ...N) | |-------------| |----------------| | | ^ | | | | | IF-PV | | | | | v |-------------| |----------------| | Client | <-------IF-PB-------> | Server | | Broker | | Broker | |--------- ---| |----------------| | | | | |-------------| <------IF-PT-------> |----------------| | | | | | Network | |--------| | Network | | Access |----|Network |------------| Access | | Requestor | |Enforcer| <-IF-NAE-> | Authority | |-------------| |--------| |----------------| =09 NEA CLIENT NEA SERVER Figure 1: NEA Components and Interfaces =09 =09 Thanks, Frank Yeh ------_=_NextPart_001_01C6422A.EF830AE8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Frank

Yes. Either that, or it should be a straight = line with=20 no arrows representing an "interface" of interest (this is what I was = originally=20 thinking when I drew it).

Thanks for pointing this out, and sorry for = the=20 confusion. Will take the action to update.

Susan

From: Frank Yeh Jr = [mailto:fyeh@us.ibm.com]=20
Sent: Tuesday, March 07, 2006 2:43 PM
To:=20 nea@ietf.org
Subject: [NEA] Problem Statement Draft -=20 correction/clarification

I believe that Figure 1 in section 6 has = the IF-PV=20 interface arrow pointing the wrong way_ it doesn't connect=20 anything.

|-------------| = |----------------|
| Posture |=20 <-------IF-PA-------> | Posture |
|=20 Collectors | | Validators |
| (1 = ...N) | |=20 (1 ...N) |
|-------------|=20 |----------------|
| = |
| <------IF-PV-------->
| |
|-------------|=20 |----------------|
| Client |=20 <-------IF-PB-------> | Server |
|=20 Broker | | Broker |
|--------- = ---|=20 |----------------|
| = |
| |
|-------------|=20 <------IF-PT-------> |----------------|
| | | |
| = Network |=20 |--------| | Network |
| Access=20 |----|Network |------------| Access |
|=20 Requestor | |Enforcer| <-IF-NAE-> | Authority |
|-------------| |--------|=20 |----------------|

NEA CLIENT = NEA=20 SERVER
Figure 1: NEA Components = and=20 Interfaces

Section 7 = describes the=20 IF-PV as:
Posture validator = interface=20 (IF-PV): This protocol acts as a
carrier=20 for posture attributes between a Server broker and a
Posture validator that is not co-located in the = NEA=20 server.

Shouldn't the figure = look like=20 this?

|-------------|=20 |----------------|
| Posture |=20 <-------IF-PA-------> | Posture |
|=20 Collectors | | Validators |
| (1 = ...N) | |=20 (1 ...N) |
|-------------|=20 |----------------|
| | = ^
| | |
| |=20 IF-PV
| | |
| | v
|-------------|=20 |----------------|
| Client |=20 <-------IF-PB-------> | Server |
|=20 Broker | | Broker |
|--------- = ---|=20 |----------------|
| = |
| |
|-------------|=20 <------IF-PT-------> |----------------|
| | | |
| = Network |=20 |--------| | Network |
| Access=20 |----|Network |------------| Access |
|=20 Requestor | |Enforcer| <-IF-NAE-> | Authority |
|-------------| |--------|=20 |----------------|

NEA CLIENT = NEA=20 SERVER
Figure 1: NEA Components = and=20 Interfaces

Thanks,
Frank Yeh

------_=_NextPart_001_01C6422A.EF830AE8-- --===============0064143060== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea --===============0064143060==-- From nea-bounces@ietf.org Tue Mar 07 18:56:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGm28-0001Ds-Ok; Tue, 07 Mar 2006 18:56:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGm27-0001Dn-Ey for nea@ietf.org; Tue, 07 Mar 2006 18:56:03 -0500 Received: from vulcan.rsasecurity.com ([216.162.240.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGm27-00039x-48 for nea@ietf.org; Tue, 07 Mar 2006 18:56:03 -0500 Received: from hyperion.na.rsa.net by vulcan.rsasecurity.com via smtpd (for ietf-mx.ietf.org [156.154.16.150]) with ESMTP; Tue, 7 Mar 2006 18:56:03 -0500 Received: from sdtihq24.securid.com (sdtihq24.na.rsa.net [10.100.8.152]) by hyperion.na.rsa.net (MOS 3.7.4b-GA) with ESMTP id ABN59666; Tue, 7 Mar 2006 18:56:04 -0500 (EST) Received: from rsana-ex-hq1.NA.RSA.NET (rsana-ex-hq1.na.rsa.net [10.100.8.50]) by sdtihq24.securid.com (8.12.10/8.12.9) with ESMTP id k27NtvkI002257; Tue, 7 Mar 2006 18:55:57 -0500 (EST) 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 Subject: RE: [Nea] RE: Updated problem statement I-D Date: Tue, 7 Mar 2006 18:55:53 -0500 Message-ID: <017630AA6DF2DF4EBC1DD4454F8EE29707BA3949@rsana-ex-hq1.NA.RSA.NET> Thread-Topic: [Nea] RE: Updated problem statement I-D Thread-Index: AcY/1H4cJ7nJc1vGRhico2z8/lZICACHlc3QAAjAlSAACx788A== From: "Polansky, Robert" To: , X-Spam-Score: 0.1 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: thomas@SignaCert.com X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Thomas, I was really trying to dig more deeply into the "security" reasons for making the two concepts separable. Your comment about protecting the data in transit is one example. I was hoping for one or two specific examples of the security reasons for separability to be in the draft instead of having the reader infer the security issues. Thanks. -Rob -----Original Message----- From: Thomas Hardjono [mailto:THardjono@SignaCert.com]=20 Sent: Tuesday, March 07, 2006 12:48 PM To: Polansky, Robert; nea@ietf.org Cc: thomas@SignaCert.com Subject: RE: [Nea] RE: Updated problem statement I-D Rob, The concept of (i) authentication (user or device) is quite distinct from (ii) measuring/reporting the integrity state ("health") of a device. Each have their respective design and security issues (e.g. when a health report is being sent from the client to the server, what is used to protect it in-transit.). So far the IP networking industry has only seen authentication (i) (eg. in the form of passwords, SecureID tokens, certs/PKI, etc.) We have not really seen an industry-wide adoption of (ii) and hence the NEA BOF. These two distinct concepts are separable, but need not be separated in implementations. (For example, in the context of 802.1X with tunneled EAP methods, some form of authentication mechanism might be used to identify the end-points wishing to open the outer-tunnel, while the client health information is sent inside the inner-tunnel. Only the success of both will lead to a common master-key.) PS. I must confess I don't really understand the last sentence of your question ("risk in overloading one architecture with the other's functionality"). Perhaps you could clarify. cheers, /thomas/ -----Original Message----- From: Polansky, Robert [mailto:rpolansky@rsasecurity.com] Sent: Tuesday, March 07, 2006 6:31 AM To: nea@ietf.org Subject: [Nea] RE: Updated problem statement I-D I would echo others' statements that this is a good statement of the problem at hand. I know I haven't contributed in the past, but I do have a request for a minor clarification on section 9.5. It says that "it is important from a security perspective" to be able to separate end-point authentication from end-point posture assessment. I understand why you need to be able to separate the architectures from an engineering perspective, but I think the document should be more specific as to the security concerns around why they need to be separable. Is there is risk in overloading one architecture with the other's functionality? Thanks. -Rob Polansky -----Original Message----- From: nea-request@ietf.org [mailto:nea-request@ietf.org] Sent: Saturday, March 04, 2006 3:42 PM To: nea@ietf.org Subject: Nea Digest, Vol 5, Issue 1 [...] 9.5. Identity authentication of communicating end-points In order for the NEA Server to accept access requests and posture information being reported to by the NEA client, the NEA Server may need to authenticate the NEA client in some manner. Similarly, within some network environments there may be the requirement that the NEA client also authenticate the NEA Server with whom it is communicating. Although the process of evaluating an access request may combine together the notion of authentication and integrity state evaluation (through posture information), it is important from a security perspective and useful from a good engineering practices perspective to be able to separate end-point authentication (including both machine and user authentication) from end-point posture assessment. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Mar 07 19:16:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGmLl-00039Q-DN; Tue, 07 Mar 2006 19:16:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGmLk-000395-AW for nea@ietf.org; Tue, 07 Mar 2006 19:16:20 -0500 Received: from fmr19.intel.com ([134.134.136.18] helo=orsfmr004.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGmLj-0004Bq-I9 for nea@ietf.org; Tue, 07 Mar 2006 19:16:20 -0500 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr004.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id k28003OL031698; Wed, 8 Mar 2006 00:00:03 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id k27Nxb7a029887; Wed, 8 Mar 2006 00:00:02 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2006030716000213644 ; Tue, 07 Mar 2006 16:00:02 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 7 Mar 2006 16:00:02 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [NEA] Problem Statement Draft - correction/clarification Date: Tue, 7 Mar 2006 16:00:01 -0800 Message-ID: <468F3FDA28AA87429AD807992E22D07E08C355D1@orsmsx408> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NEA] Problem Statement Draft - correction/clarification Thread-Index: AcZCH4KV/M132P1KRqSfjgB9ejGhbgAGLN9Q From: "Khosravi, Hormuzd M" To: "Frank Yeh Jr" , X-OriginalArrivalTime: 08 Mar 2006 00:00:02.0611 (UTC) FILETIME=[3FBB2830:01C64243] X-Scanned-By: MIMEDefang 2.52 on 10.7.209.16 X-Spam-Score: 0.0 (/) X-Scan-Signature: d437399464e10b52abe9a34ed7e712d0 Cc: X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0786626066==" Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============0786626066== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C64243.3F15238F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C64243.3F15238F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, I noticed the same thing but assumed it was intentional. Its difficult to express figures in text format sometimes. =20 I think it would be useful to add some more detailed figures in that section in the future. I'll be happy to help out if needed =20 regards Hormuzd =20 ________________________________ From: Frank Yeh Jr [mailto:fyeh@us.ibm.com]=20 Sent: Tuesday, March 07, 2006 11:43 AM To: nea@ietf.org Subject: [NEA] Problem Statement Draft - correction/clarification =20 I believe that Figure 1 in section 6 has the IF-PV interface arrow pointing the wrong way_ it doesn't connect anything. |-------------| |----------------| | Posture | <-------IF-PA-------> | Posture | | Collectors | | Validators | | (1 ...N) | | (1 ...N) | |-------------| |----------------| | | | <------IF-PV--------> | | |-------------| |----------------| | Client | <-------IF-PB-------> | Server | | Broker | | Broker | |--------- ---| |----------------| | | | | |-------------| <------IF-PT-------> |----------------| | | | | | Network | |--------| | Network | | Access |----|Network |------------| Access | | Requestor | |Enforcer| <-IF-NAE-> | Authority | |-------------| |--------| |----------------| NEA CLIENT NEA SERVER Figure 1: NEA Components and Interfaces Section 7 describes the IF-PV as: Posture validator interface (IF-PV): This protocol acts as a carrier for posture attributes between a Server broker and a Posture validator that is not co-located in the NEA server. Shouldn't the figure look like this? |-------------| |----------------| | Posture | <-------IF-PA-------> | Posture | | Collectors | | Validators | | (1 ...N) | | (1 ...N) | |-------------| |----------------| | | ^ | | | | | IF-PV | | | | | v |-------------| |----------------| | Client | <-------IF-PB-------> | Server | | Broker | | Broker | |--------- ---| |----------------| | | | | |-------------| <------IF-PT-------> |----------------| | | | | | Network | |--------| | Network | | Access |----|Network |------------| Access | | Requestor | |Enforcer| <-IF-NAE-> | Authority | |-------------| |--------| |----------------| NEA CLIENT NEA SERVER Figure 1: NEA Components and Interfaces Thanks, Frank Yeh ------_=_NextPart_001_01C64243.3F15238F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes, I noticed the same thing but = assumed it was intentional.

Its difficult to express figures in = text format sometimes.

I think it would be useful to add = some more detailed figures in that section in the future.

I’ll be happy to help out if = needed

regards

Hormuzd

From: Frank = Yeh Jr [mailto:fyeh@us.ibm.com]
Sent: Tuesday, March 07, = 2006 11:43 AM
To: nea@ietf.org
Subject: [NEA] Problem = Statement Draft - correction/clarification

I believe that Figure 1 in section 6 has the IF-PV = interface arrow pointing the wrong way_ it doesn't connect = anything.

|-------------| |----------------|
| = Posture | <-------IF-PA-------> | Posture |
| = Collectors | | Validators |
| = (1 ...N) | | (1 ...N) |
|-------------| |----------------|
| = |
| <------IF-PV-------->
| = |
|-------------| |----------------|
| = Client | <-------IF-PB-------> | Server |
| = Broker | | Broker |
|--------- ---| |----------------|
| = |
| = |
|-------------| <------IF-PT-------> |----------------|
| | = | |
| = Network | |--------| | Network |
| = Access |----|Network |------------| Access |
| = Requestor | |Enforcer| <-IF-NAE-> | Authority |
|-------------| |--------| |----------------|

NEA = CLIENT NEA SERVER
Figure 1: NEA Components and Interfaces

Section 7 describes the IF-PV as:
Posture validator interface (IF-PV): This protocol acts as a
carrier for posture attributes between a Server broker and a
Posture validator that is not co-located in the NEA server.

Shouldn't the figure look like this?

|-------------| |----------------|
| = Posture | <-------IF-PA-------> | Posture |
| = Collectors | | Validators |
| = (1 ...N) | | (1 ...N) |
|-------------| |----------------|
| | = ^
| | = |
| | = IF-PV
| | = |
| | = v
|-------------| |----------------|
| = Client | <-------IF-PB-------> | Server |
| = Broker | | Broker |
|--------- ---| |----------------|
| = |
| = |
|-------------| <------IF-PT-------> |----------------|
| | = | |
| = Network | |--------| | Network |
| = Access |----|Network |------------| Access |
| = Requestor | |Enforcer| <-IF-NAE-> | Authority |
|-------------| |--------| |----------------|

NEA = CLIENT NEA SERVER
Figure 1: NEA Components and Interfaces

Thanks,
Frank Yeh

------_=_NextPart_001_01C64243.3F15238F-- --===============0786626066== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea --===============0786626066==-- From nea-bounces@ietf.org Tue Mar 07 19:46:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGmoi-0006nN-Au; Tue, 07 Mar 2006 19:46:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGmog-0006n8-MC for nea@ietf.org; Tue, 07 Mar 2006 19:46:14 -0500 Received: from mail.signacert.com ([207.162.214.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGmog-00057b-60 for nea@ietf.org; Tue, 07 Mar 2006 19:46:14 -0500 Received: from SCTPHTP42 (unknown [207.162.210.168]) by mail.signacert.com (Postfix) with ESMTP id CEBA118EC466; Tue, 7 Mar 2006 16:46:12 -0800 (PST) From: "Thomas Hardjono" To: "'Polansky, Robert'" , Subject: RE: [Nea] RE: Updated problem statement I-D Date: Tue, 7 Mar 2006 16:46:11 -0800 Organization: SignaCert Message-ID: <000601c64249$b2b107f0$9603a8c0@SCTPHTP42> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcY/1H4cJ7nJc1vGRhico2z8/lZICACHlc3QAAjAlSAACx788AABQlQg In-Reply-To: <017630AA6DF2DF4EBC1DD4454F8EE29707BA3949@rsana-ex-hq1.NA.RSA.NET> X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: thomas@SignaCert.com X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: THardjono@signacert.com List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Thanks Rob. There really is no "security" reasons for separating the two concepts other than they are distinct building blocks that participate in a broader security architecture. Its always wise from a design perspective to identify building blocks, their functions, limitations and interfaces. Having them separate also allows a mix-and-match in different deployment scenarios. Another security consideration (that I did not place in the draft due to time constraints) is the need for end-point authentication to occur first before posture assessment. This is in order to prevent against DOS attacks that waste cycles of its target (posture collector) in doing repeated checks. /thomas/ -----Original Message----- From: Polansky, Robert [mailto:rpolansky@rsasecurity.com] Sent: Tuesday, March 07, 2006 3:56 PM To: THardjono@SignaCert.com; nea@ietf.org Cc: thomas@SignaCert.com Subject: RE: [Nea] RE: Updated problem statement I-D Thomas, I was really trying to dig more deeply into the "security" reasons for making the two concepts separable. Your comment about protecting the data in transit is one example. I was hoping for one or two specific examples of the security reasons for separability to be in the draft instead of having the reader infer the security issues. Thanks. -Rob -----Original Message----- From: Thomas Hardjono [mailto:THardjono@SignaCert.com] Sent: Tuesday, March 07, 2006 12:48 PM To: Polansky, Robert; nea@ietf.org Cc: thomas@SignaCert.com Subject: RE: [Nea] RE: Updated problem statement I-D Rob, The concept of (i) authentication (user or device) is quite distinct from (ii) measuring/reporting the integrity state ("health") of a device. Each have their respective design and security issues (e.g. when a health report is being sent from the client to the server, what is used to protect it in-transit.). So far the IP networking industry has only seen authentication (i) (eg. in the form of passwords, SecureID tokens, certs/PKI, etc.) We have not really seen an industry-wide adoption of (ii) and hence the NEA BOF. These two distinct concepts are separable, but need not be separated in implementations. (For example, in the context of 802.1X with tunneled EAP methods, some form of authentication mechanism might be used to identify the end-points wishing to open the outer-tunnel, while the client health information is sent inside the inner-tunnel. Only the success of both will lead to a common master-key.) PS. I must confess I don't really understand the last sentence of your question ("risk in overloading one architecture with the other's functionality"). Perhaps you could clarify. cheers, /thomas/ -----Original Message----- From: Polansky, Robert [mailto:rpolansky@rsasecurity.com] Sent: Tuesday, March 07, 2006 6:31 AM To: nea@ietf.org Subject: [Nea] RE: Updated problem statement I-D I would echo others' statements that this is a good statement of the problem at hand. I know I haven't contributed in the past, but I do have a request for a minor clarification on section 9.5. It says that "it is important from a security perspective" to be able to separate end-point authentication from end-point posture assessment. I understand why you need to be able to separate the architectures from an engineering perspective, but I think the document should be more specific as to the security concerns around why they need to be separable. Is there is risk in overloading one architecture with the other's functionality? Thanks. -Rob Polansky -----Original Message----- From: nea-request@ietf.org [mailto:nea-request@ietf.org] Sent: Saturday, March 04, 2006 3:42 PM To: nea@ietf.org Subject: Nea Digest, Vol 5, Issue 1 [...] 9.5. Identity authentication of communicating end-points In order for the NEA Server to accept access requests and posture information being reported to by the NEA client, the NEA Server may need to authenticate the NEA client in some manner. Similarly, within some network environments there may be the requirement that the NEA client also authenticate the NEA Server with whom it is communicating. Although the process of evaluating an access request may combine together the notion of authentication and integrity state evaluation (through posture information), it is important from a security perspective and useful from a good engineering practices perspective to be able to separate end-point authentication (including both machine and user authentication) from end-point posture assessment. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Mar 07 20:38:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGndL-0003EV-Uy; Tue, 07 Mar 2006 20:38:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGndK-0003EQ-A2 for nea@ietf.org; Tue, 07 Mar 2006 20:38:34 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGndJ-0007IZ-RS for nea@ietf.org; Tue, 07 Mar 2006 20:38:34 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 07 Mar 2006 17:38:34 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,173,1139212800"; d="scan'208,217"; a="23179824:sNHT46567664" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k281cXVU009742 for ; Tue, 7 Mar 2006 20:38:33 -0500 (EST) 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.211); Tue, 7 Mar 2006 20:38:33 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 7 Mar 2006 20:38:32 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updated WG charter Thread-Index: AcZCUQINXZqOKJ2XQ6SpOjnA++JnLA== From: "Susan Thomson $sethomso$" To: X-OriginalArrivalTime: 08 Mar 2006 01:38:33.0006 (UTC) FILETIME=[0299DCE0:01C64251] X-Spam-Score: 0.0 (/) X-Scan-Signature: df1883a27a831c1ea5e8cfe5eb3ad38e Subject: [Nea] Updated WG charter X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1721194761==" Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============1721194761== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C64251.025C8628" This is a multi-part message in MIME format. ------_=_NextPart_001_01C64251.025C8628 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Below is the proposed WG charter updated with the new protocol names to be consistent with latest problem statement ID. There are a few editorial changes as well, otherwise it is the same as submitted with the BoF request early in February. =20 If you have further comments on this, please let us know. =20 Thanks Steve & Susan ------------------------------------------------------------------------ ------------------------------------------------ =20 Proposed NEA WG Charter =20 Architectures have been implemented in the industry to assess the software or hardware configuration of endpoint devices for the purposes of monitoring or enforcing compliance of endpoints to an organization's policy for access to the network. These architectures are not fully interoperable since some of the protocols used to implement the architecture are not standards. =20 The first purpose of the proposed working group is to define requirements for the protocols needed to ensure interoperability in an NEA system. The second purpose of the working group is to ensure standardization of protocols that meet these requirements. In some cases, these protocols may best be standardized in another working group. Therefore, the proposed working group will work with the area directors to determine the best way to complete this standardization effort (in the proposed working group or in another one). =20 The initial scope of the WG targets an EAP/RADIUS instantiation of a NEA architecture. Other instantiations of NEA architectures may be standardized in the future, but are not part of the initial charter.=20 =20 The initial charter includes the following protocols (as described in draft-thomson-nea-problem-statement-01.txt): =20 1. Posture Broker protocol (IF-PB) 2. Posture Transport Tunnel protocol (IF-PTT) i.e. EAP tunneling method suitable for carrying posture information as well as supporting authentication 3. Posture Transport Carrier protocol (IF-PTC) i.e. EAP over IP carrier protocol 4. RADIUS attributes for network access enforcement (IF-NAE) =20 Other protocols that may be included in the charter at a later date include: * Posture Attribute protocol (IF-PA) * Posture Validation Protocol (IF-PV) =20 Work will be carried out in two phases. In the first phase, the WG will define requirements for each of the protocols identified in 1) - 4) above. When the requirements have been defined, this WG will work with the responsible Area Directors to identify the appropriate WG for meeting these requirements. =20 Milestones: =20 June 2006: * Submit requirements I-D to IETF including=20 --- requirements for IF-PTT (EAP tunneling method)=20 --- requirements for IF-NAE=20 =20 September 2006: * Submit revised requirements I-D to IETF that includes above plus: --- requirements for IF-PB --- requirements for IF-PTC (EAP over IP carrier protocol e.g. EAP over UDP, EAP over TLS) =20 December 2006:=20 * Review ongoing work in IETF (e.g. EMU WG, Radext WG, PANA WG, NEA WG) and work with ADs to identify the WG responsible for accommodating protocol requirements that are not currently being met. =20 Feb 2007: * Submit requirements I-D to IESG for publication as Info RFC * Revise WG charter to accommodate definition of protocols not covered in other WGs e.g. IF-PB * Submit I-D on protocols to be defined in this WG e.g. IF-PB specification ------_=_NextPart_001_01C64251.025C8628 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Below=20 is the proposed WG charter updated with the new protocol names to be = consistent=20 with latest problem statement ID. There are a few editorial changes as = well,=20 otherwise it is the same as submitted with the BoF request early in=20 February.

If=20 you have further comments on this, please let us know.

Thanks

Steve=20 & Susan

----------------------------------------------= -------------------------------------------------------------------------= -

Proposed NEA WG = Charter

Architectures have been = implemented=20 in the industry to assess the software or hardware = configuration of=20 endpoint devices for the purposes of monitoring or enforcing compliance = of=20 endpoints to an organization's policy for access to the network. = These=20 architectures are not fully interoperable since some of the = protocols used=20 to implement the architecture are not standards.

The first purpose of the = proposed=20 working group is to define requirements for the protocols needed to = ensure=20 interoperability in an NEA system. The second purpose of the working = group is to=20 ensure standardization of protocols that meet these requirements. In = some cases,=20 these protocols may best be standardized in another working group. = Therefore,=20 the proposed working group will work with the area directors to = determine the=20 best way to complete this standardization effort (in the proposed = working group=20 or in another one).

The initial scope of the = WG targets=20 an EAP/RADIUS instantiation of a NEA architecture. Other instantiations = of NEA=20 architectures may be standardized in the future, but are not part of the = initial=20 charter.

The initial charter = includes the=20 following protocols (as described in=20 draft-thomson-nea-problem-statement-01.txt):

1. Posture = Broker protocol=20 (IF-PB)

2. Posture Transport = Tunnel protocol=20 (IF-PTT) i.e. EAP tunneling method suitable for carrying posture = information as=20 well as supporting authentication

3. Posture Transport = Carrier=20 protocol (IF-PTC) i.e. EAP over IP carrier protocol

4. RADIUS attributes for = network=20 access enforcement (IF-NAE)

Other protocols that may = be included=20 in the charter at a later date include:

* = Posture=20 Attribute protocol (IF-PA)

* Posture Validation = Protocol=20 (IF-PV)

Work will be carried out = in two=20 phases. In the first phase, the WG will define = requirements for each=20 of the protocols identified in 1) - 4) above. When the = requirements=20 have been defined, this WG will work with the responsible Area = Directors=20 to identify the appropriate WG for meeting these=20 requirements.

Milestones:

June 2006:

* Submit requirements = I-D to=20 IETF including

--- requirements for = IF-PTT (EAP=20 tunneling method)

--- requirements for = IF-NAE=20

September = 2006:

* Submit revised=20 requirements I-D to IETF that includes above plus:

--- requirements=20 for IF-PB

--- requirements = for IF-PTC=20 (EAP over IP carrier protocol e.g. EAP over UDP, EAP over = TLS)

December 2006: =

* Review ongoing work in = IETF (e.g.=20 EMU WG, Radext WG, PANA WG, NEA WG) and work with ADs to identify the WG = responsible for accommodating protocol requirements that are not = currently being=20 met.

Feb 2007:

* Submit requirements = I-D to=20 IESG for publication as Info RFC

* Revise WG charter to = accommodate=20 definition of protocols not covered in other WGs e.g. = IF-PB

* Submit I-D = on protocols to be=20 defined in this WG e.g. IF-PB specification

------_=_NextPart_001_01C64251.025C8628-- --===============1721194761== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea --===============1721194761==-- From nea-bounces@ietf.org Wed Mar 08 12:37:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH2b2-0006du-MB; Wed, 08 Mar 2006 12:37:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH2b2-0006dp-3A for nea@ietf.org; Wed, 08 Mar 2006 12:37:12 -0500 Received: from palrel13.hp.com ([156.153.255.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH2ay-0001aM-Df for nea@ietf.org; Wed, 08 Mar 2006 12:37:12 -0500 Received: from cacexg11.americas.cpqcorp.net (cacexg11.americas.cpqcorp.net [16.92.1.67]) by palrel13.hp.com (Postfix) with ESMTP id C528836667; Wed, 8 Mar 2006 09:37:07 -0800 (PST) Received: from cacexc08.americas.cpqcorp.net ([16.92.1.35]) by cacexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Mar 2006 09:37:07 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Nea] Updated problem statement I-D - My comments Date: Wed, 8 Mar 2006 09:37:06 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Updated problem statement I-D - My comments Thread-Index: AcY/zMO5h4OHW3KdStesitCHo6sDbgDBue8w From: "Sanchez, Mauricio" To: "Susan Thomson (sethomso)" , X-OriginalArrivalTime: 08 Mar 2006 17:37:07.0191 (UTC) FILETIME=[EBBA0870:01C642D6] X-Spam-Score: 0.0 (/) X-Scan-Signature: b6e18fadcfab41fa5e7faede753de4c2 Cc: X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1506061907==" Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============1506061907== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C642D6.EB9325C3" This is a multi-part message in MIME format. ------_=_NextPart_001_01C642D6.EB9325C3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Nice progress. Here's some comments/questions on this version: =20 Section 1 First paragraph: "These architectures are not fully interoperable..." When I read this sentence it first struck me as meaning that a given architecture (e.g. TNC, NAP, NAC) is not interoperable with itself. Moreover, "fully" signals there may be some existing interoperability, which I doubt there is. May want to consider changing to "Components from these architectures cannot be intermixed..."=20 =20 Section 3 Second paragraph: "Remediation instructions or warnings may be sent to the endpoint." Is "remediation" within scope of NEA? Consider defining remediation in terminology section, since remediation means different things to different people. =20 =20 Fifth paragraph: "...,these architectures are still not fully interoperable because..." Same as first comment. =20 Section 4 How are the third and fourth goals different from one another? =20 Last goal: Is assessment without a client within scope of NEA? It's a good goal, but unsure whether we'd be able to make substantive progress on a "clientless" solution? =20 Section 5.2 Second paragraph: Do you mean 802.11i? =20 =20 Table 1: Nice table. It's going to be my cheat-cheat until I learn all 28 terms. =20 Section 6.2.1.2 May there be more the one client broker? =20 =20 Section 6.2.1.3 For the case there are multiple network access requestors, is there one associated client broker. What is the relationship? May want to consider updating figure 1 to show that there may be multiple NAR's (and perhaps client brokers) as has been done with the posture collectors. =20 Section 6.2.3.3 First paragraph: Which architectures don't have posture validators co-located with the NEA server? Moreover, is the NEA server not but a logical concept? If it is, then this statement is misleading since the posture validator will always be part of the logical NEA server. I think what you mean is that the posture validators are some instances not co-located with the NAA and server broker. =20 Third responsibility: Is the posture collector really responsible for taking "remediation" actions? The description for posture collector in 6.2.1.1 does not mention "remediation" as part of its repertoire. =20 Section 6.3.1 Typo on title: Posture Attribute Interface not Posture Attribute interface =20 Section 6.3.3 May want to consider showing an updated Diagram 1 to visually show the relationship of these two new sub-interfaces to the rest of the NEA architecture. Any reason these are not part of the base NEA description? =20 =20 Section 7 Seventh standardization goal: Can you elaborate in which instances IF-PV may not fall within IETF's domain? How are we going to decide this one? If it's not going to fall into IETF (i.e. NEA) why even bother describing it? =20 Cheers, MS =20 =20 =20 =20 ________________________________ From: Susan Thomson (sethomso) [mailto:sethomso@cisco.com]=20 Sent: Saturday, March 04, 2006 12:47 PM To: nea@ietf.org Subject: [Nea] Updated problem statement I-D =09 =09 I have sent the updated problem statement I-D to the IETF secretariat for publication. In the meantime, have attached the document for your review. =20 The I-D has been updated to be consistent with the proposed WG charter and to take into account comments received on the mailing list. (The proposed charter will need to be tweaked to reflect new names for some of the interfaces).=20 =20 Main Changes: =09 --- Terminology changed to that suggested by Mauricio Sanchez in his comments to mailing list --- Emphasized throughout that focus not on new architecture, but interoperability=20 --- Put an explicit stake in the ground that the initial focus is on an EAP/Radius instantiation of an NEA architecture --- Identified the 2 EAP protocols at IF-PT layer as IF-PTT (EAP tunneling method) and IF-PTC (EAP carrier protocol).=20 --- For convenience, mapped NEA terminology with that used in 3 existing architectures: TNC, NAP, NAC --- References added=20 =20 Feedback appreciated, especially where there may be lack of clarity or disagreement that may preclude a successful BoF. Better to air these on the mailing list now so that we can attempt to address them prior to the BoF. =20 Thanks Steve & Susan ------_=_NextPart_001_01C642D6.EB9325C3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Nice progress. Here's some = comments/questions on=20 this version:

Section 1

First paragraph: "These architectures are not = fully=20 interoperable..." When I read this sentence it first struck me as = meaning=20 that a given architecture (e.g. TNC, NAP, NAC) is not interoperable with = itself. Moreover, "fully" signals there may be some existing=20 interoperability, which I doubt there is. May want to = consider=20 changing to "Components from these architectures cannot be = intermixed..."=20

Section 3

Second paragraph: "Remediation instructions or = warnings may=20 be sent to the endpoint." Is "remediation" within scope of = NEA? =20 Consider defining remediation in terminology section, since remediation = means=20 different things to different people.

Fifth paragraph: "...,these architectures are = still not=20 fully interoperable because..." Same as first = comment.

Section 4

How are the third and fourth goals different = from one=20 another?

Last goal: Is assessment without a client = within=20 scope of NEA? It's a good goal, but unsure whether we'd be able to = make=20 substantive progress on a "clientless" solution?

Section 5.2

Second paragraph: Do you mean 802.11i? =20

Table 1: Nice table. It's going to be my = cheat-cheat=20 until I learn all 28 terms.

Section 6.2.1.2

May there be more the one client = broker? =20

Section 6.2.1.3

For the case there are multiple network access = requestors,=20 is there one associated client broker. What is the = relationship? May=20 want to consider updating figure 1 to show that there may be multiple = NAR's (and=20 perhaps client brokers) as has been done with the posture=20 collectors.

Section 6.2.3.3

First paragraph: Which architectures don't have = posture=20 validators co-located with the NEA server? Moreover, is the NEA = server not=20 but a logical concept? If it is, then this statement is misleading = since=20 the posture validator will always be part of the logical NEA = server. I=20 think what you mean is that the posture validators are some instances = not=20 co-located with the NAA and server broker.

Third responsibility: Is the posture collector = really=20 responsible for taking "remediation" actions? The description for = posture=20 collector in 6.2.1.1 does not mention "remediation" as part of its=20 repertoire.

Section 6.3.1

Typo on title: Posture Attribute Interface not = Posture=20 Attribute interface

Section 6.3.3

May want to consider showing an updated Diagram = 1=20 to visually show the relationship of these two new = sub-interfaces=20 to the rest of the NEA architecture. Any reason these are not part = of the=20 base NEA description?

Section 7

Seventh standardization goal: Can you = elaborate in=20 which instances IF-PV may not fall within IETF's domain? How are = we going=20 to decide this one? If it's not going to fall into IETF (i.e. NEA) = why=20 even bother describing it?

Cheers,

From: Susan Thomson (sethomso)=20 [mailto:sethomso@cisco.com]
Sent: Saturday, March 04, 2006 = 12:47=20 PM
To: nea@ietf.org
Subject: [Nea] Updated problem = statement I-D

I = have sent the=20 updated problem statement I-D to the IETF secretariat for publication. = In the=20 meantime, have attached the document for your = review.

The = I-D has been=20 updated to be consistent with the proposed WG charter and to = take into=20 account comments received on the mailing list. = (The proposed=20 charter will need to be tweaked to reflect new names for some of the=20 interfaces).

Main = Changes:

---=20 Terminology changed to that suggested by Mauricio Sanchez in his comments to mailing=20 list

--- = Emphasized=20 throughout that focus not on = new=20 architecture, but interoperability

--- = Put an=20 explicit stake in the ground that the initial focus is on an = EAP/Radius=20 instantiation of an NEA architecture

--- = Identified the=20 2 EAP protocols at IF-PT layer as IF-PTT (EAP tunneling method) and = IF-PTC=20 (EAP carrier protocol).

--- For convenience, mapped NEA = terminology with=20 that used in 3 existing architectures: TNC, NAP,=20 NAC

--- = References=20 added

Feedback appreciated, especially where = there may be=20 lack of clarity or disagreement that may preclude a successful BoF. = Better to=20 air these on the mailing list now so that we can attempt to address = them prior=20 to the BoF.

Thanks

Steve &=20 = Susan

<= /HTML> ------_=_NextPart_001_01C642D6.EB9325C3-- --===============1506061907== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea --===============1506061907==-- From nea-bounces@ietf.org Fri Mar 10 13:31:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHmOp-0000Et-EQ; Fri, 10 Mar 2006 13:31:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHmOo-0000EO-9o for nea@ietf.org; Fri, 10 Mar 2006 13:31:38 -0500 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHmOn-0007eJ-1y for nea@ietf.org; Fri, 10 Mar 2006 13:31:38 -0500 Received: from unknown (HELO mail2.funk.com) ([172.25.68.102]) by borg.juniper.net with ESMTP; 10 Mar 2006 10:31:37 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,181,1139212800"; d="scan'208"; a="535579309:sNHT19052636" Received: by MAIL2 with Internet Mail Service (5.5.2653.19) id ; Fri, 10 Mar 2006 13:30:28 -0500 Message-ID: From: Steve Hanna To: nea@ietf.org Date: Fri, 10 Mar 2006 13:31:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [Nea] NEA BOF time change X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Note that the time for the IETF NEA BOF has changed. It's still on Tuesday, March 21. But it has moved from 1-3 PM to 3:20 PM - 5:20 PM CST. This still might change but that's unlikely. Thanks, Steve _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Mar 13 22:42:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ0Qa-0004p9-Fm; Mon, 13 Mar 2006 22:42:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ0QZ-0004p1-4A for nea@ietf.org; Mon, 13 Mar 2006 22:42:31 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJ0QY-0001Lw-IZ for nea@ietf.org; Mon, 13 Mar 2006 22:42:31 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 13 Mar 2006 19:42:30 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2E3gTw3001183; Mon, 13 Mar 2006 19:42:29 -0800 (PST) Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 13 Mar 2006 22:42:29 -0500 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 Subject: RE: [Nea] Updated problem statement I-D - My comments Date: Mon, 13 Mar 2006 22:42:27 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Updated problem statement I-D - My comments Thread-Index: AcY/zMO5h4OHW3KdStesitCHo6sDbgDBue8wAQezGyA= From: "Susan Thomson $sethomso$" To: "Sanchez, Mauricio" , X-OriginalArrivalTime: 14 Mar 2006 03:42:29.0403 (UTC) FILETIME=[51847EB0:01C64719] X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org =20 Hi Mauricio Inline ... ________________________________ From: Sanchez, Mauricio [mailto:mauricio.sanchez@hp.com]=20 Sent: Wednesday, March 08, 2006 12:37 PM To: Susan Thomson (sethomso); nea@ietf.org Cc: Steve Hanna Subject: RE: [Nea] Updated problem statement I-D - My comments Nice progress. Here's some comments/questions on this version: =20 Section 1 First paragraph: "These architectures are not fully interoperable..." When I read this sentence it first struck me as meaning that a given architecture (e.g. TNC, NAP, NAC) is not interoperable with itself. Moreover, "fully" signals there may be some existing interoperability, which I doubt there is. May want to consider changing to "Components from these architectures cannot be intermixed..."=20 [Susan] Yes, will change to something like "components from different architectures are not interoperable because not all required protocols are standards" or some such. The reason for the "fully" is because, to the extent that 802.1x and RADIUS are standards, there is some interoperability today. =20 Section 3 Second paragraph: "Remediation instructions or warnings may be sent to the endpoint." Is "remediation" within scope of NEA? Consider defining remediation in terminology section, since remediation means different things to different people. =20 [Susan] Remediation itself is not part of NEA, but information about posture status and remediations steps (e.g. URL of remediation server to contact) can take place at the PA layer and possibly at PB layer. Remediation steps are typically specific to the application being validated and will be part of PA layer. The PA leyer is not part of initial scope of NEA charter as currently proposed, though. User notifications and warnings may be done at the PB layer based on the overall posture result, and since the PB layer is in scope, so is this. =20 Fifth paragraph: "...,these architectures are still not fully interoperable because..." Same as first comment. Section 4 How are the third and fourth goals different from one another? [Susan]The third says NEA can happen at a L2 or L3 hop. The fourth says it could happen at multiple hops on a path. (If one supports L3 hops, one cannot preclude a deployment scenario where NEA is enabled in multiple places on a path.) =20 Last goal: Is assessment without a client within scope of NEA? It's a good goal, but unsure whether we'd be able to make substantive progress on a "clientless" solution? [Susan] When I included this, I had something specific in mind, but don't recall what it is now. Probably was not thinking clearly, so I'll plan to take it out. =20 Section 5.2 Second paragraph: Do you mean 802.11i? =20 [Susan] Yes. =20 Table 1: Nice table. It's going to be my cheat-cheat until I learn all 28 terms. =20 Section 6.2.1.2 May there be more the one client broker? =20 [Susan] Could be, although from NEA point of view, not sure that it matters given the interface between client broker and Network access requestor is not in scope. =20 Section 6.2.1.3 For the case there are multiple network access requestors, is there one associated client broker. What is the relationship? May want to consider updating figure 1 to show that there may be multiple NAR's (and perhaps client brokers) as has been done with the posture collectors. [Susan] The assumption is one client broker per Network access requestor. Likely to be same client broker for multiple Network access requestors. =20 Section 6.2.3.3 First paragraph: Which architectures don't have posture validators co-located with the NEA server? Moreover, is the NEA server not but a logical concept? If it is, then this statement is misleading since the posture validator will always be part of the logical NEA server. I think what you mean is that the posture validators are some instances not co-located with the NAA and server broker. [Susan] NAC is one example of such an architecture. Agree that rewording is required. =20 Third responsibility: Is the posture collector really responsible for taking "remediation" actions? The description for posture collector in 6.2.1.1 does not mention "remediation" as part of its repertoire. [Susan] An example of "information on remediation actions" (this could be better worded) may be to send the URL of the remediation server to the posture collector. Section 6.2.1.1 does have text about receiving such a thing. =20 Section 6.3.1 Typo on title: Posture Attribute Interface not Posture Attribute interface =20 Section 6.3.3 May want to consider showing an updated Diagram 1 to visually show the relationship of these two new sub-interfaces to the rest of the NEA architecture. Any reason these are not part of the base NEA description? =20 [Susan] Agreed that this should be made explicit. Probably another figure is required, the idea being to have the general picture that does not assume an underlying EAP framework to allow for other possible "instantiations" of the architecture in the future, along with a figure that is more specific to the EAP framework. =20 Section 7 Seventh standardization goal: Can you elaborate in which instances IF-PV may not fall within IETF's domain? How are we going to decide this one? If it's not going to fall into IETF (i.e. NEA) why even bother describing it? [Susan] Depending on what technology is used, it could be OASIS, for example. There is no pre-judgement here. Once we have made progress on the other protocols in the initial charter, we can revisit including this interface in NEA as part of revising the charter scope at the end of the year.=20 [Susan] Thanks for the comments. Assuming the BOF is successful, this doc in its current form will likely die, with those sections deemed useful pulled into a requirements I-D and more detail added sufficient for a requirements spec. Susan =20 Cheers, MS =20 =20 =20 =20 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Mar 13 22:54:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ0cM-00026i-2H; Mon, 13 Mar 2006 22:54:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ0cK-00026d-TJ for nea@ietf.org; Mon, 13 Mar 2006 22:54:40 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJ0cK-0001cE-HW for nea@ietf.org; Mon, 13 Mar 2006 22:54:40 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 13 Mar 2006 19:54:40 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,188,1139212800"; d="scan'208"; a="23536700:sNHT25958236" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k2E3sdVU023840; Mon, 13 Mar 2006 22:54:40 -0500 (EST) 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.211); Mon, 13 Mar 2006 22:54:39 -0500 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, 13 Mar 2006 22:54:38 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Revised charter (again) Thread-Index: AcZHGwRQTCWsmV1YT9+qpkebNz2cag== From: "Susan Thomson $sethomso$" To: X-OriginalArrivalTime: 14 Mar 2006 03:54:39.0793 (UTC) FILETIME=[04DD2A10:01C6471B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: jari.arkko@ericsson.com Subject: [Nea] Revised charter (again) X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Below is another version of the charter for your review. Based on a discussion with the Internet ADs last week, we realized that the charter depended too heavily on information in the problem statement I-D. To enable the charter to stand on its own, it has been updated to include more detail on the problem being addressed and provides a 1 or 2-sentence description with each of the protocols. Also, protocol names no longer have the "IF-" prefix. The scope and milestones remain unchanged. Please provide comments before the end of the week, so that it can be updated prior to BoF. Thanks Steve & Susan ----------------------------------------------- Proposed NEA WG Charter Network Endpoint Assessment (NEA) architectures have been implemented in the industry to assess the "posture" of endpoint devices for the purposes of monitoring or enforcing compliance to an organization's policy for access to the network. Posture refers to the hardware or software configuration of an endpoint as it pertains to an organization's security policy. Posture may include knowledge about the types of hardware and software installed and their configurations, e.g. OS name and version, application patch levels, and anti-virus signature file version. On network access, an endpoint with an NEA Client can be queried for posture information which is validated on an NEA Server as part of network access control. While several of these architectures leverage the EAP/RADIUS framework so that both authentication and posture assessment can be part of network access control, components from the different architectures do not interoperate because not all of the required protocols are standards. The first purpose of the proposed working group is to define requirements for those protocols needed to ensure interoperability. The second purpose of the working group is to determine whether existing protocols are sufficient to meet these requirements and, when not, to ensure standardization of protocols or protocol extensions which meet the requirements. In some cases, these protocols or protocol extensions may best be standardized in another working group. Therefore, the proposed working group will work with the area directors to determine the best way to complete this standardization effort (in the proposed working group or in another one). The initial scope of the WG targets an NEA architecture based on the EAP/RADIUS framework. Other instantiations of NEA architectures may be standardized in the future, but are not part of the initial charter.=20 The initial charter includes defining requirements for the following protocols: 1. Posture Broker (PB) protocol: This protocol aggregates posture attributes from one or more Posture Collectors in an NEA client and sends them to the NEA server for assessment by one or more Posture Validators. 2. Posture Transport Tunnel (PTT) protocol: In the EAP framework, this is an EAP tunneling method suitable for tunneling the PB protocol as well as supporting authentication.=20 3. Posture Transport Carrier (PTC) protocol: The EAP framework supports running EAP over multiple carriers. Targeted deployment scenarios for NEA include both L2 and L3 network access scenarios. Existing standards used in NEA include 802.1x for L2 network access. Requirements need to be defined for an EAP over L3 transport for L3 access scenarios. 4. Network access enforcement (NAE) protocol: In an EAP/RADIUS framework, RADIUS is the protocol used between a network enforcement point and an NEA server acting as an authentication and posture validation server. Requirements may identify new attributes needed (if any). Other protocols that may be included in the charter at a later date include: 5. Posture Attribute (PA) protocol: This protocol is used to carry posture attributes between a particular Posture Collector in a NEA client and a particular Posture Validator in a NEA Server. The PA protocol is carried inside the PB protocol. 6. Posture Validation Protocol (PV): The NEA Server may have a distributed implementation such that the Posture Validator is a remote component. The PV protocol forwards posture attributes to a remote Posture Validator and receives the result of the assessment. Work will be carried out in two phases. In the first phase, the WG will define requirements for each of the protocols identified in 1) - 4) above. When the requirements have been defined, this WG will work with the responsible Area Directors to identify the appropriate WG for meeting these requirements. Milestones: June 2006: * Submit requirements I-D to IETF including --- requirements for PTT protocol (EAP tunneling method) --- requirements for NAE protocol (RADIUS extensions) September 2006: * Submit revised requirements I-D to IETF that includes above plus: --- requirements for PB protocol --- requirements for PTC (EAP over IP carrier protocol) December 2006:=20 * Review ongoing work in IETF (e.g. EMU WG, Radext WG, PANA WG, NEA WG) and work with ADs to identify the WG responsible for accommodating protocol requirements that are not currently being met. Feb 2007: * Submit requirements I-D to IESG for publication as Info RFC * Revise WG charter to accommodate definition of protocols not covered in other WGs e.g. PB * Submit I-D on protocols to be defined in this WG e.g. PB specification _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Mar 14 01:38:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ3Ay-0005FF-Al; Tue, 14 Mar 2006 01:38:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ3Ax-0005EW-7W for nea@ietf.org; Tue, 14 Mar 2006 01:38:35 -0500 Received: from fmr17.intel.com ([134.134.136.16] helo=orsfmr002.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJ38T-0006O8-74 for nea@ietf.org; Tue, 14 Mar 2006 01:36:04 -0500 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr002.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id k2E6Zw0v024545; Tue, 14 Mar 2006 06:35:58 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id k2E6ZwOX025322; Tue, 14 Mar 2006 06:35:58 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2006031322355718739 ; Mon, 13 Mar 2006 22:35:57 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 13 Mar 2006 22:35:57 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Nea] Revised charter (again) Date: Mon, 13 Mar 2006 22:35:55 -0800 Message-ID: <468F3FDA28AA87429AD807992E22D07E08D6998D@orsmsx408> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Revised charter (again) Thread-Index: AcZHGwRQTCWsmV1YT9+qpkebNz2cagAFR6YQ From: "Khosravi, Hormuzd M" To: "Susan Thomson $sethomso$" , X-OriginalArrivalTime: 14 Mar 2006 06:35:57.0994 (UTC) FILETIME=[8D8570A0:01C64731] X-Scanned-By: MIMEDefang 2.52 on 10.7.209.16 X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Cc: jari.arkko@ericsson.com X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Hi Susan & Steve, One fundamental question that I have on the charter is whether this WG is striving for end-to-end interoperability for NEA or interoperability between specific devices/products in the market place? I have been assuming it's the former but would like to clarify this. If my assumption is correct then I believe it will be difficult to do a good job without atleast defining requirements, end-to-end, i.e. including PV & PA in the requirements definition stage. It would be fine to postpone the protocol section for these interfaces to the 2nd phase of the WG, but atleast we will have thought through these in our requirements and thus get a good sense of the end-to-end picture. Let me know your thoughts? Other comments welcome. Thanks Hormuzd -----Original Message----- From: Susan Thomson (sethomso) [mailto:sethomso@cisco.com]=20 Sent: Monday, March 13, 2006 7:55 PM To: nea@ietf.org Cc: jari.arkko@ericsson.com Subject: [Nea] Revised charter (again) Below is another version of the charter for your review. Based on a discussion with the Internet ADs last week, we realized that the charter depended too heavily on information in the problem statement I-D. To enable the charter to stand on its own, it has been updated to include more detail on the problem being addressed and provides a 1 or 2-sentence description with each of the protocols. Also, protocol names no longer have the "IF-" prefix. The scope and milestones remain unchanged. Please provide comments before the end of the week, so that it can be updated prior to BoF. Thanks Steve & Susan ----------------------------------------------- Proposed NEA WG Charter Network Endpoint Assessment (NEA) architectures have been implemented in the industry to assess the "posture" of endpoint devices for the purposes of monitoring or enforcing compliance to an organization's policy for access to the network. Posture refers to the hardware or software configuration of an endpoint as it pertains to an organization's security policy. Posture may include knowledge about the types of hardware and software installed and their configurations, e.g. OS name and version, application patch levels, and anti-virus signature file version. On network access, an endpoint with an NEA Client can be queried for posture information which is validated on an NEA Server as part of network access control. While several of these architectures leverage the EAP/RADIUS framework so that both authentication and posture assessment can be part of network access control, components from the different architectures do not interoperate because not all of the required protocols are standards. The first purpose of the proposed working group is to define requirements for those protocols needed to ensure interoperability. The second purpose of the working group is to determine whether existing protocols are sufficient to meet these requirements and, when not, to ensure standardization of protocols or protocol extensions which meet the requirements. In some cases, these protocols or protocol extensions may best be standardized in another working group. Therefore, the proposed working group will work with the area directors to determine the best way to complete this standardization effort (in the proposed working group or in another one). The initial scope of the WG targets an NEA architecture based on the EAP/RADIUS framework. Other instantiations of NEA architectures may be standardized in the future, but are not part of the initial charter.=20 The initial charter includes defining requirements for the following protocols: 1. Posture Broker (PB) protocol: This protocol aggregates posture attributes from one or more Posture Collectors in an NEA client and sends them to the NEA server for assessment by one or more Posture Validators. 2. Posture Transport Tunnel (PTT) protocol: In the EAP framework, this is an EAP tunneling method suitable for tunneling the PB protocol as well as supporting authentication.=20 3. Posture Transport Carrier (PTC) protocol: The EAP framework supports running EAP over multiple carriers. Targeted deployment scenarios for NEA include both L2 and L3 network access scenarios. Existing standards used in NEA include 802.1x for L2 network access. Requirements need to be defined for an EAP over L3 transport for L3 access scenarios. 4. Network access enforcement (NAE) protocol: In an EAP/RADIUS framework, RADIUS is the protocol used between a network enforcement point and an NEA server acting as an authentication and posture validation server. Requirements may identify new attributes needed (if any). Other protocols that may be included in the charter at a later date include: 5. Posture Attribute (PA) protocol: This protocol is used to carry posture attributes between a particular Posture Collector in a NEA client and a particular Posture Validator in a NEA Server. The PA protocol is carried inside the PB protocol. 6. Posture Validation Protocol (PV): The NEA Server may have a distributed implementation such that the Posture Validator is a remote component. The PV protocol forwards posture attributes to a remote Posture Validator and receives the result of the assessment. Work will be carried out in two phases. In the first phase, the WG will define requirements for each of the protocols identified in 1) - 4) above. When the requirements have been defined, this WG will work with the responsible Area Directors to identify the appropriate WG for meeting these requirements. Milestones: June 2006: * Submit requirements I-D to IETF including --- requirements for PTT protocol (EAP tunneling method) --- requirements for NAE protocol (RADIUS extensions) September 2006: * Submit revised requirements I-D to IETF that includes above plus: --- requirements for PB protocol --- requirements for PTC (EAP over IP carrier protocol) December 2006:=20 * Review ongoing work in IETF (e.g. EMU WG, Radext WG, PANA WG, NEA WG) and work with ADs to identify the WG responsible for accommodating protocol requirements that are not currently being met. Feb 2007: * Submit requirements I-D to IESG for publication as Info RFC * Revise WG charter to accommodate definition of protocols not covered in other WGs e.g. PB * Submit I-D on protocols to be defined in this WG e.g. PB specification _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu Mar 16 16:19:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJzsX-0004Yw-IB; Thu, 16 Mar 2006 16:19:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJzsV-0004Ya-J5 for nea@ietf.org; Thu, 16 Mar 2006 16:19:27 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJzsT-0001Hf-Sb for nea@ietf.org; Thu, 16 Mar 2006 16:19:27 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 16 Mar 2006 16:19:26 -0500 X-IronPort-AV: i="4.03,102,1141621200"; d="scan'208"; a="84302545:sNHT57961364" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k2GLJPVU004201; Thu, 16 Mar 2006 16:19:25 -0500 (EST) 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.211); Thu, 16 Mar 2006 16:19:25 -0500 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 Subject: RE: [Nea] Revised charter (again) Date: Thu, 16 Mar 2006 16:19:24 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Revised charter (again) Thread-Index: AcZHGwRQTCWsmV1YT9+qpkebNz2cagAFR6YQAIOVzhA= From: "Susan Thomson $sethomso$" To: "Khosravi, Hormuzd M" , X-OriginalArrivalTime: 16 Mar 2006 21:19:25.0384 (UTC) FILETIME=[4D36C480:01C6493F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Cc: X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Hi Hormuzd Inline ... -----Original Message----- From: Khosravi, Hormuzd M [mailto:hormuzd.m.khosravi@intel.com]=20 Sent: Tuesday, March 14, 2006 1:36 AM To: Susan Thomson (sethomso); nea@ietf.org Cc: jari.arkko@ericsson.com Subject: RE: [Nea] Revised charter (again) Hi Susan & Steve, One fundamental question that I have on the charter is whether this WG is striving for end-to-end interoperability for NEA or interoperability between specific devices/products in the market place? I have been assuming it's the former but would like to clarify this. [Susan] In general, we are striving for interoperability across all interfaces identified. If my assumption is correct then I believe it will be difficult to do a good job without atleast defining requirements, end-to-end, i.e. including PV & PA in the requirements definition stage. It would be fine to postpone the protocol section for these interfaces to the 2nd phase of the WG, but atleast we will have thought through these in our requirements and thus get a good sense of the end-to-end picture. [Susan] At a minimum, we need to have the role of the components and interfaces clearly defined so that we can drill down on each of the interfaces independently. I don't think that means that we have to work on producing the detailed requirements of all interfaces concurrently.=20 Susan Let me know your thoughts? Other comments welcome. Thanks Hormuzd -----Original Message----- From: Susan Thomson (sethomso) [mailto:sethomso@cisco.com] Sent: Monday, March 13, 2006 7:55 PM To: nea@ietf.org Cc: jari.arkko@ericsson.com Subject: [Nea] Revised charter (again) Below is another version of the charter for your review. Based on a discussion with the Internet ADs last week, we realized that the charter depended too heavily on information in the problem statement I-D. To enable the charter to stand on its own, it has been updated to include more detail on the problem being addressed and provides a 1 or 2-sentence description with each of the protocols. Also, protocol names no longer have the "IF-" prefix. The scope and milestones remain unchanged. Please provide comments before the end of the week, so that it can be updated prior to BoF. Thanks Steve & Susan ----------------------------------------------- Proposed NEA WG Charter Network Endpoint Assessment (NEA) architectures have been implemented in the industry to assess the "posture" of endpoint devices for the purposes of monitoring or enforcing compliance to an organization's policy for access to the network. Posture refers to the hardware or software configuration of an endpoint as it pertains to an organization's security policy. Posture may include knowledge about the types of hardware and software installed and their configurations, e.g. OS name and version, application patch levels, and anti-virus signature file version. On network access, an endpoint with an NEA Client can be queried for posture information which is validated on an NEA Server as part of network access control. While several of these architectures leverage the EAP/RADIUS framework so that both authentication and posture assessment can be part of network access control, components from the different architectures do not interoperate because not all of the required protocols are standards. The first purpose of the proposed working group is to define requirements for those protocols needed to ensure interoperability. The second purpose of the working group is to determine whether existing protocols are sufficient to meet these requirements and, when not, to ensure standardization of protocols or protocol extensions which meet the requirements. In some cases, these protocols or protocol extensions may best be standardized in another working group. Therefore, the proposed working group will work with the area directors to determine the best way to complete this standardization effort (in the proposed working group or in another one). The initial scope of the WG targets an NEA architecture based on the EAP/RADIUS framework. Other instantiations of NEA architectures may be standardized in the future, but are not part of the initial charter.=20 The initial charter includes defining requirements for the following protocols: 1. Posture Broker (PB) protocol: This protocol aggregates posture attributes from one or more Posture Collectors in an NEA client and sends them to the NEA server for assessment by one or more Posture Validators. 2. Posture Transport Tunnel (PTT) protocol: In the EAP framework, this is an EAP tunneling method suitable for tunneling the PB protocol as well as supporting authentication.=20 3. Posture Transport Carrier (PTC) protocol: The EAP framework supports running EAP over multiple carriers. Targeted deployment scenarios for NEA include both L2 and L3 network access scenarios. Existing standards used in NEA include 802.1x for L2 network access. Requirements need to be defined for an EAP over L3 transport for L3 access scenarios. 4. Network access enforcement (NAE) protocol: In an EAP/RADIUS framework, RADIUS is the protocol used between a network enforcement point and an NEA server acting as an authentication and posture validation server. Requirements may identify new attributes needed (if any). Other protocols that may be included in the charter at a later date include: 5. Posture Attribute (PA) protocol: This protocol is used to carry posture attributes between a particular Posture Collector in a NEA client and a particular Posture Validator in a NEA Server. The PA protocol is carried inside the PB protocol. 6. Posture Validation Protocol (PV): The NEA Server may have a distributed implementation such that the Posture Validator is a remote component. The PV protocol forwards posture attributes to a remote Posture Validator and receives the result of the assessment. Work will be carried out in two phases. In the first phase, the WG will define requirements for each of the protocols identified in 1) - 4) above. When the requirements have been defined, this WG will work with the responsible Area Directors to identify the appropriate WG for meeting these requirements. Milestones: June 2006: * Submit requirements I-D to IETF including --- requirements for PTT protocol (EAP tunneling method) --- requirements for NAE protocol (RADIUS extensions) September 2006: * Submit revised requirements I-D to IETF that includes above plus: --- requirements for PB protocol --- requirements for PTC (EAP over IP carrier protocol) December 2006:=20 * Review ongoing work in IETF (e.g. EMU WG, Radext WG, PANA WG, NEA WG) and work with ADs to identify the WG responsible for accommodating protocol requirements that are not currently being met. Feb 2007: * Submit requirements I-D to IESG for publication as Info RFC * Revise WG charter to accommodate definition of protocols not covered in other WGs e.g. PB * Submit I-D on protocols to be defined in this WG e.g. PB specification _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Sun Mar 19 09:14:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKyfQ-0001Mm-FB; Sun, 19 Mar 2006 09:14:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKyfP-0001MM-7Q for nea@ietf.org; Sun, 19 Mar 2006 09:13:59 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKyfN-0003oI-QC for nea@ietf.org; Sun, 19 Mar 2006 09:13:59 -0500 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.12.8/8.12.8) with ESMTP id k2JEDtHa026591 for ; Sun, 19 Mar 2006 16:13:55 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.8/8.12.8/Submit) with ESMTP id k2JEDt20026588 for ; Sun, 19 Mar 2006 16:13:55 +0200 Date: Sun, 19 Mar 2006 16:13:55 +0200 (EET) From: Pekka Savola To: nea@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88/1338/Sun Mar 19 02:04:12 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on otso.netcore.fi X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Nea] heads-up on distsec X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Hi, I just read the NEA problem statement and it looked rather sensible. What you didn't explain very extensively is your threat model. You can be sure this will come up in the BoF from someone.. You already raise NEA Client self-integrity as an issue in Section 9.3. But is NEA approach good enough here because the first thing a next-generation worm/virus/malware will do is trick the NEA client using one of various techniques, therefore making the real posture undetectable? You may not be aware of the "distsec" effort (the lastest draft rewrite is draft-kaeo-distsec-framework-00.txt), which describes a superset problem. I'd recommend taking a look for ideas how to refine the problem statement, threat model and assumptions. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Sun Mar 19 11:36:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL0td-0004Sm-Ua; Sun, 19 Mar 2006 11:36:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL0td-0004Sh-1W for nea@ietf.org; Sun, 19 Mar 2006 11:36:49 -0500 Received: from mail.signacert.com ([207.162.214.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FL0tb-000083-HA for nea@ietf.org; Sun, 19 Mar 2006 11:36:48 -0500 Received: from SCTPHTP42 (c-24-20-132-188.hsd1.or.comcast.net [24.20.132.188]) by mail.signacert.com (Postfix) with ESMTP id C95BB18EC3FD; Sun, 19 Mar 2006 08:36:45 -0800 (PST) From: "Thomas Hardjono" To: , Subject: RE: [Nea] heads-up on distsec Date: Sun, 19 Mar 2006 08:36:44 -0800 Organization: SignaCert Message-ID: <000301c64b73$4f6e0390$660110ac@SCTPHTP42> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: Thread-Index: AcZLX2EeQPmbhHSNSwylD3VliR0SKQAEe95A X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: "'Hardjono, Thomas'" X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: THardjono@signacert.com List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Pekka, Yes, Section 9.3 is trying to convey the awareness of the problem for future discussion (and perhaps for the requirements document). My personal opinion on this matter is that something trustworthy needs to attest to the goodness (trustworthiness) the NEA Client code/binary. This in-turn requires something that malicious code cannot modify (namely trusted hardware). /thomas/ -----Original Message----- From: Pekka Savola [mailto:pekkas@netcore.fi] Sent: Sunday, March 19, 2006 6:14 AM To: nea@ietf.org Subject: [Nea] heads-up on distsec Hi, I just read the NEA problem statement and it looked rather sensible. What you didn't explain very extensively is your threat model. You can be sure this will come up in the BoF from someone.. You already raise NEA Client self-integrity as an issue in Section 9.3. But is NEA approach good enough here because the first thing a next-generation worm/virus/malware will do is trick the NEA client using one of various techniques, therefore making the real posture undetectable? You may not be aware of the "distsec" effort (the lastest draft rewrite is draft-kaeo-distsec-framework-00.txt), which describes a superset problem. I'd recommend taking a look for ideas how to refine the problem statement, threat model and assumptions. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Sun Mar 19 11:58:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL1Ek-0002fT-RV; Sun, 19 Mar 2006 11:58:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL1Ek-0002f1-09 for nea@ietf.org; Sun, 19 Mar 2006 11:58:38 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FL1Ei-00015U-H5 for nea@ietf.org; Sun, 19 Mar 2006 11:58:37 -0500 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.12.8/8.12.8) with ESMTP id k2JGwYHa029901; Sun, 19 Mar 2006 18:58:34 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.8/8.12.8/Submit) with ESMTP id k2JGwYb6029898; Sun, 19 Mar 2006 18:58:34 +0200 Date: Sun, 19 Mar 2006 18:58:34 +0200 (EET) From: Pekka Savola To: Thomas Hardjono Subject: RE: [Nea] heads-up on distsec In-Reply-To: <000301c64b73$4f6e0390$660110ac@SCTPHTP42> Message-ID: References: <000301c64b73$4f6e0390$660110ac@SCTPHTP42> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88/1338/Sun Mar 19 02:04:12 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-3.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on otso.netcore.fi X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: "'Hardjono, Thomas'" , nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Hi, On Sun, 19 Mar 2006, Thomas Hardjono wrote: > My personal opinion on this matter is that something trustworthy needs to > attest to the goodness (trustworthiness) the NEA Client code/binary. This > in-turn requires something that malicious code cannot modify (namely trusted > hardware). Is it enough to have trusted NEA client code? The client will collect information from the programs, file systems, and/or the kernel. So, each of those (except maybe the programs themselves) would need to be "trusted". I'm personally a bit skeptical how we could get there, given that kernels will always have bugs, etc. Of course, security mechanisms don't necessarily need to be perfect; getting e.g., 95% assurance might be enough, given that's acceptable for your threat model.. (That was one of the reasons why distsec was refined to also look at minimizing the effect and maximizing the detection of a security breach that's bound to happen sooner or later.) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Sun Mar 19 20:19:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL93p-0000HB-Hn; Sun, 19 Mar 2006 20:19:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL93p-0000H6-1c for nea@ietf.org; Sun, 19 Mar 2006 20:19:53 -0500 Received: from mga03.intel.com ([143.182.124.21] helo=azsmga101-1.ch.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FL93n-0002wd-4f for nea@ietf.org; Sun, 19 Mar 2006 20:19:52 -0500 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101-1.ch.intel.com with ESMTP; 19 Mar 2006 17:19:47 -0800 Received: from fmsmsx331.fm.intel.com (HELO fmsmsx331.amr.corp.intel.com) ([132.233.42.156]) by azsmga001.ch.intel.com with ESMTP; 19 Mar 2006 17:19:46 -0800 X-IronPort-AV: i="4.03,109,1141632000"; d="scan'208"; a="13505740:sNHT128351307" Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 19 Mar 2006 17:19:46 -0800 Received: from hdsmsx401.amr.corp.intel.com ([10.127.2.60]) by fmsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 19 Mar 2006 17:19:45 -0800 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 Subject: RE: [Nea] heads-up on distsec Date: Sun, 19 Mar 2006 20:19:41 -0500 Message-ID: <5404AEB459F8354F81995E038F34320002A6A28F@hdsmsx401.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] heads-up on distsec Thread-Index: AcZLdrnVwXVcVih4Q9uf8i1kU7jvZQARWesg From: "Blumenthal, Uri" To: "Pekka Savola" , "Thomas Hardjono" X-OriginalArrivalTime: 20 Mar 2006 01:19:45.0719 (UTC) FILETIME=[5FA48470:01C64BBC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: "Hardjono, Thomas" , nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org >On Sun, 19 Mar 2006, Thomas Hardjono wrote: >> My personal opinion on this matter is that something trustworthy needs to >> attest to the goodness (trustworthiness) the NEA Client code/binary. This >> in-turn requires something that malicious code cannot modify (namely trusted >> hardware). > >Is it enough to have trusted NEA client code? The client will collect=20 >information from the programs, file systems, and/or the kernel. So,=20 >each of those (except maybe the programs themselves) would need to be=20 >"trusted". Probably not - but NEA client code can have secure "anchors" - and that would be enough by any standard. >I'm personally a bit skeptical how we could get there, given that=20 >kernels will always have bugs, etc. There are other things. E.g. TPM... >Of course, security mechanisms don't necessarily need to be perfect;=20 >getting e.g., 95% assurance might be enough, given that's acceptable=20 >for your threat model.. There's that too. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Sun Mar 19 20:35:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL9It-0000YS-UZ; Sun, 19 Mar 2006 20:35:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL9Is-0000YN-Jt for nea@ietf.org; Sun, 19 Mar 2006 20:35:26 -0500 Received: from ogo.signacert.com ([207.162.214.7] helo=mail.signacert.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FL9Is-0003bx-Ab for nea@ietf.org; Sun, 19 Mar 2006 20:35:26 -0500 Received: from SCTPHTP42 (c-24-20-132-188.hsd1.or.comcast.net [24.20.132.188]) by mail.signacert.com (Postfix) with ESMTP id D21CC18EC445; Sun, 19 Mar 2006 17:35:24 -0800 (PST) From: "Thomas Hardjono" To: "'Pekka Savola'" Subject: RE: [Nea] heads-up on distsec Date: Sun, 19 Mar 2006 17:35:22 -0800 Organization: SignaCert Message-ID: <000301c64bbe$8ed597f0$660110ac@SCTPHTP42> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcZLdl8Tu0BpBASWT5CePvepgjOF7QARw8jg X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: "'Hardjono, Thomas'" , nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: THardjono@signacert.com List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Understood, Pekka. The BOF/WG would have to decide if these issues (such that mentioned in Section 9.3) and their solution would be in-scope for NEA. I think it is useful for NEA to be aware of the spectrum of issues surrounding (a) end-point trust and integrity, and (b) mechanisms to report (a). This was one of the purposes of Section 9. In this way, NEA can focus on a clear subset of issues out of the entire spectrum. Regards. /thomas/ -----Original Message----- From: Pekka Savola [mailto:pekkas@netcore.fi] Sent: Sunday, March 19, 2006 8:59 AM To: Thomas Hardjono Cc: 'Hardjono, Thomas'; nea@ietf.org Subject: RE: [Nea] heads-up on distsec Hi, On Sun, 19 Mar 2006, Thomas Hardjono wrote: > My personal opinion on this matter is that something trustworthy needs > to attest to the goodness (trustworthiness) the NEA Client > code/binary. This in-turn requires something that malicious code > cannot modify (namely trusted hardware). Is it enough to have trusted NEA client code? The client will collect information from the programs, file systems, and/or the kernel. So, each of those (except maybe the programs themselves) would need to be "trusted". I'm personally a bit skeptical how we could get there, given that kernels will always have bugs, etc. Of course, security mechanisms don't necessarily need to be perfect; getting e.g., 95% assurance might be enough, given that's acceptable for your threat model.. (That was one of the reasons why distsec was refined to also look at minimizing the effect and maximizing the detection of a security breach that's bound to happen sooner or later.) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Mar 22 11:02:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM5nK-0004Zk-3E; Wed, 22 Mar 2006 11:02:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM5nI-0004UR-AC for nea@ietf.org; Wed, 22 Mar 2006 11:02:44 -0500 Received: from segue.merit.edu ([198.108.1.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM5nH-00050G-36 for nea@ietf.org; Wed, 22 Mar 2006 11:02:44 -0500 Received: from snicker.merit.edu (snicker.merit.edu [198.108.62.156]) by segue.merit.edu (Postfix) with ESMTP id A03F558282; Wed, 22 Mar 2006 11:02:42 -0500 (EST) Received: from [130.129.131.50] (DHCP-Wireless-131-50.ietf65.org [130.129.131.50]) by snicker.merit.edu (Postfix) with ESMTP id CBFB6171881; Wed, 22 Mar 2006 11:02:41 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <53DC085C-BA67-4E7A-8EBB-AE235C1384FE@mtghouse.com> Content-Transfer-Encoding: 7bit From: John Vollbrecht Date: Wed, 22 Mar 2006 11:02:40 -0500 To: NEA X-Mailer: Apple Mail (2.746.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Subject: [Nea] meet to review BOF at IETF? X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org I am wondering if people would like to get together to review the BOF and any feedback we might have gotten while we are face to face at IETF. I have gotten some comments that I think are interesting and might help moving forward, and I can note them in an email when I have a few minutes, but I am wondering if people will be around - I will be here till Thursday afternoon - and would like to touch base for a few minutes. - John _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Mar 22 11:09:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM5tO-0000j6-Ot; Wed, 22 Mar 2006 11:09:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM5tO-0000j1-4J for nea@ietf.org; Wed, 22 Mar 2006 11:09:02 -0500 Received: from mga03.intel.com ([143.182.124.21] helo=azsmga101-1.ch.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM5tM-0005KM-LW for nea@ietf.org; Wed, 22 Mar 2006 11:09:02 -0500 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101-1.ch.intel.com with ESMTP; 22 Mar 2006 08:08:25 -0800 Received: from fmsmsx331.fm.intel.com (HELO fmsmsx331.amr.corp.intel.com) ([132.233.42.156]) by azsmga001.ch.intel.com with ESMTP; 22 Mar 2006 08:08:24 -0800 X-IronPort-AV: i="4.03,119,1141632000"; d="scan'208"; a="14278972:sNHT21472367" Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Mar 2006 08:08:09 -0800 Received: from hdsmsx401.amr.corp.intel.com ([10.127.2.60]) by fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Mar 2006 08:08:04 -0800 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 Subject: RE: [Nea] meet to review BOF at IETF? Date: Wed, 22 Mar 2006 11:08:02 -0500 Message-ID: <5404AEB459F8354F81995E038F34320002AFEF4B@hdsmsx401.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] meet to review BOF at IETF? Thread-Index: AcZNypAa1H4Gp2G/QWKKvFYlEzkQnQAADRVA From: "Blumenthal, Uri" To: "John Vollbrecht" , "NEA" X-OriginalArrivalTime: 22 Mar 2006 16:08:05.0152 (UTC) FILETIME=[CD681200:01C64DCA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org I'd like to meet and discuss. Tnx!=20 -----Original Message----- From: John Vollbrecht [mailto:jrv@mtghouse.com]=20 Sent: Wednesday, March 22, 2006 11:03 AM To: NEA Subject: [Nea] meet to review BOF at IETF? I am wondering if people would like to get together to review the BOF =20 and any feedback we might have gotten while we are face to face at =20 IETF. I have gotten some comments that I think are interesting and =20 might help moving forward, and I can note them in an email when I =20 have a few minutes, but I am wondering if people will be around - I =20 will be here till Thursday afternoon - and would like to touch base =20 for a few minutes. - John _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Mar 22 11:12:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM5wF-0001ij-Vk; Wed, 22 Mar 2006 11:11:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM5wE-0001ib-Px for nea@ietf.org; Wed, 22 Mar 2006 11:11:58 -0500 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM5wD-0005Re-Hq for nea@ietf.org; Wed, 22 Mar 2006 11:11:58 -0500 Received: from unknown (HELO mail2.funk.com) ([172.25.68.102]) by borg.juniper.net with ESMTP; 22 Mar 2006 08:11:57 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.03,119,1141632000"; d="scan'208"; a="538076618:sNHT21235356" Received: by MAIL2 with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Mar 2006 11:10:34 -0500 Message-ID: From: Steve Hanna To: John Vollbrecht , NEA Subject: RE: [Nea] meet to review BOF at IETF? Date: Wed, 22 Mar 2006 11:11:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Good idea, John. I'm sure we've all been having interesting conversations and thoughts since the BOF. Unfortunately, Susan and I are busy for lunch (WG Chairs Lunch). How about the afternoon break today? I propose we meet at 4:10 PM at the IETF message board. OK? Thanks, Steve > -----Original Message----- > From: John Vollbrecht [mailto:jrv@mtghouse.com] > Sent: Wednesday, March 22, 2006 10:03 AM > To: NEA > Subject: [Nea] meet to review BOF at IETF? > > I am wondering if people would like to get together to review > the BOF > and any feedback we might have gotten while we are face to face at > IETF. I have gotten some comments that I think are interesting and > might help moving forward, and I can note them in an email when I > have a few minutes, but I am wondering if people will be around - I > will be here till Thursday afternoon - and would like to touch base > for a few minutes. > > - John > > > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www1.ietf.org/mailman/listinfo/nea > _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Mar 22 11:12:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM5wb-0001mc-4j; Wed, 22 Mar 2006 11:12:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM5wZ-0001mX-GK for nea@ietf.org; Wed, 22 Mar 2006 11:12:19 -0500 Received: from gold.veritas.com ([143.127.12.110]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM5wY-0005Sj-18 for nea@ietf.org; Wed, 22 Mar 2006 11:12:19 -0500 Received: from sxchcon1-int.veritas.com (HELO SVLXCHCON1.enterprise.veritas.com) ([10.137.18.171]) by gold.veritas.com with ESMTP; 22 Mar 2006 08:12:17 -0800 X-IronPort-AV: i="4.03,119,1141632000"; d="scan'208"; a="57585137:sNHT28942848" Received: from SVL1XCHEVSPIN01.enterprise.veritas.com ([166.98.169.10]) by SVLXCHCON1.enterprise.veritas.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Mar 2006 08:12:16 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Nea] meet to review BOF at IETF? Date: Wed, 22 Mar 2006 08:12:15 -0800 Message-ID: <5A58F967CBEBBB4A82DF126CF8A9596A9B6F5E@SVL1XCHCLUPIN01.enterprise.veritas.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] meet to review BOF at IETF? thread-index: AcZNyhp+bfxUB5WVQbqRSlRR4OsyiwAAToYg From: "Paul Sangster" To: "John Vollbrecht" , "NEA" X-OriginalArrivalTime: 22 Mar 2006 16:12:16.0913 (UTC) FILETIME=[6377C010:01C64DCB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org I fly out this afternoon but could do lunch today.=20 > -----Original Message----- > From: John Vollbrecht [mailto:jrv@mtghouse.com]=20 > Sent: Wednesday, March 22, 2006 8:03 AM > To: NEA > Subject: [Nea] meet to review BOF at IETF? >=20 > I am wondering if people would like to get together to review=20 > the BOF and any feedback we might have gotten while we are=20 > face to face at IETF. I have gotten some comments that I=20 > think are interesting and might help moving forward, and I=20 > can note them in an email when I have a few minutes, but I am=20 > wondering if people will be around - I will be here till=20 > Thursday afternoon - and would like to touch base for a few minutes. >=20 > - John >=20 >=20 > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www1.ietf.org/mailman/listinfo/nea >=20 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Mar 22 11:14:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM5yV-00029c-G4; Wed, 22 Mar 2006 11:14:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM5yU-00029X-0x for nea@ietf.org; Wed, 22 Mar 2006 11:14:18 -0500 Received: from mga02.intel.com ([134.134.136.20] helo=orsmga101-1.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM5yS-0005fI-G2 for nea@ietf.org; Wed, 22 Mar 2006 11:14:18 -0500 Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101-1.jf.intel.com with ESMTP; 22 Mar 2006 08:13:07 -0800 Received: from orsmsx331.jf.intel.com (HELO orsmsx331.amr.corp.intel.com) ([192.168.65.56]) by orsmga001.jf.intel.com with ESMTP; 22 Mar 2006 08:13:06 -0800 X-IronPort-AV: i="4.03,119,1141632000"; d="scan'208"; a="14665959:sNHT489899361" Received: from orsmsx411.amr.corp.intel.com ([10.22.226.47]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Mar 2006 08:13:04 -0800 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 Subject: RE: [Nea] meet to review BOF at IETF? Date: Wed, 22 Mar 2006 08:13:02 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] meet to review BOF at IETF? thread-index: AcZNypAa1H4Gp2G/QWKKvFYlEzkQnQAADRVAAAArPRA= From: "Khosravi, Hormuzd M" To: "John Vollbrecht" , "NEA" X-OriginalArrivalTime: 22 Mar 2006 16:13:04.0231 (UTC) FILETIME=[7FABE770:01C64DCB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Same here. I'll be around on Thursday Hormuzd -----Original Message----- From: Blumenthal, Uri [mailto:uri.blumenthal@intel.com]=20 Sent: Wednesday, March 22, 2006 8:08 AM To: John Vollbrecht; NEA Subject: RE: [Nea] meet to review BOF at IETF? I'd like to meet and discuss. Tnx!=20 -----Original Message----- From: John Vollbrecht [mailto:jrv@mtghouse.com]=20 Sent: Wednesday, March 22, 2006 11:03 AM To: NEA Subject: [Nea] meet to review BOF at IETF? I am wondering if people would like to get together to review the BOF =20 and any feedback we might have gotten while we are face to face at =20 IETF. I have gotten some comments that I think are interesting and =20 might help moving forward, and I can note them in an email when I =20 have a few minutes, but I am wondering if people will be around - I =20 will be here till Thursday afternoon - and would like to touch base =20 for a few minutes. - John _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Mar 22 11:52:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM6Zl-0003lP-LQ; Wed, 22 Mar 2006 11:52:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM6Zj-0003lF-RV for nea@ietf.org; Wed, 22 Mar 2006 11:52:47 -0500 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM6Zi-0007lG-Ir for nea@ietf.org; Wed, 22 Mar 2006 11:52:47 -0500 Received: from unknown (HELO mail2.funk.com) ([172.25.68.102]) by borg.juniper.net with ESMTP; 22 Mar 2006 08:52:46 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.03,119,1141632000"; d="scan'208"; a="538084982:sNHT21495456" Received: by MAIL2 with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Mar 2006 11:51:23 -0500 Message-ID: From: Steve Hanna To: NEA Date: Wed, 22 Mar 2006 11:52:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Subject: [Nea] Definite time and place for chat today X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org I just ran into Mauricio and he asked for a definitive time and place. Unfortunately, it looks like no time will work for everyone. However, I think it's important to have Susan and myself there to report on AD contacts, etc. So we'll go with 4:10 PM today at the IETF message board. Thanks, Steve > -----Original Message----- > From: Steve Hanna > Sent: Wednesday, March 22, 2006 10:12 AM > To: 'John Vollbrecht'; NEA > Subject: RE: [Nea] meet to review BOF at IETF? > > Good idea, John. I'm sure we've all been having > interesting conversations and thoughts since > the BOF. Unfortunately, Susan and I are busy > for lunch (WG Chairs Lunch). How about the > afternoon break today? I propose we meet at > 4:10 PM at the IETF message board. OK? > > Thanks, > > Steve > > > -----Original Message----- > > From: John Vollbrecht [mailto:jrv@mtghouse.com] > > Sent: Wednesday, March 22, 2006 10:03 AM > > To: NEA > > Subject: [Nea] meet to review BOF at IETF? > > > > I am wondering if people would like to get together to review > > the BOF > > and any feedback we might have gotten while we are face to face at > > IETF. I have gotten some comments that I think are > interesting and > > might help moving forward, and I can note them in an email when I > > have a few minutes, but I am wondering if people will be > around - I > > will be here till Thursday afternoon - and would like to > touch base > > for a few minutes. > > > > - John > > > > > > _______________________________________________ > > Nea mailing list > > Nea@ietf.org > > https://www1.ietf.org/mailman/listinfo/nea > > > _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Mar 22 11:53:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM6a7-0003te-93; Wed, 22 Mar 2006 11:53:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM6a5-0003sC-V6 for nea@ietf.org; Wed, 22 Mar 2006 11:53:09 -0500 Received: from segue.merit.edu ([198.108.1.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM6a4-0007nH-Mt for nea@ietf.org; Wed, 22 Mar 2006 11:53:09 -0500 Received: from snicker.merit.edu (snicker.merit.edu [198.108.62.156]) by segue.merit.edu (Postfix) with ESMTP id 64EF958282; Wed, 22 Mar 2006 11:53:08 -0500 (EST) Received: from [130.129.131.50] (DHCP-Wireless-131-50.ietf65.org [130.129.131.50]) by snicker.merit.edu (Postfix) with ESMTP id 05C20171881; Wed, 22 Mar 2006 11:53:07 -0500 (EST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Vollbrecht Subject: Re: [Nea] meet to review BOF at IETF? Date: Wed, 22 Mar 2006 11:53:06 -0500 To: Steve Hanna X-Mailer: Apple Mail (2.746.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: John Vollbrecht , NEA X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org 4:10 at the message board is fine. I am also free for lunch, and would like to meet with anyone that can't meet there at 4:10. can meet at message board at 11:30 if you want to have lunch. -- John On Mar 22, 2006, at 11:11 AM, Steve Hanna wrote: > Good idea, John. I'm sure we've all been having > interesting conversations and thoughts since > the BOF. Unfortunately, Susan and I are busy > for lunch (WG Chairs Lunch). How about the > afternoon break today? I propose we meet at > 4:10 PM at the IETF message board. OK? > > Thanks, > > Steve > >> -----Original Message----- >> From: John Vollbrecht [mailto:jrv@mtghouse.com] >> Sent: Wednesday, March 22, 2006 10:03 AM >> To: NEA >> Subject: [Nea] meet to review BOF at IETF? >> >> I am wondering if people would like to get together to review >> the BOF >> and any feedback we might have gotten while we are face to face at >> IETF. I have gotten some comments that I think are interesting and >> might help moving forward, and I can note them in an email when I >> have a few minutes, but I am wondering if people will be around - I >> will be here till Thursday afternoon - and would like to touch base >> for a few minutes. >> >> - John >> >> >> _______________________________________________ >> Nea mailing list >> Nea@ietf.org >> https://www1.ietf.org/mailman/listinfo/nea >> > > _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Mar 22 12:17:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM6y4-0007G4-Pm; Wed, 22 Mar 2006 12:17:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM6y2-0007Fz-W1 for nea@ietf.org; Wed, 22 Mar 2006 12:17:54 -0500 Received: from silver.veritas.com ([143.127.12.111]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM6y1-0000LA-Lw for nea@ietf.org; Wed, 22 Mar 2006 12:17:54 -0500 Received: from sxchcon2-int.veritas.com (HELO SVLXCHCON2.enterprise.veritas.com) ([10.137.18.172]) by silver.veritas.com with ESMTP; 22 Mar 2006 09:17:51 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.03,119,1141632000"; d="scan'208"; a="36269217:sNHT23778036" Received: from SVL1XCHEVSPIN01.enterprise.veritas.com ([166.98.169.10]) by SVLXCHCON2.enterprise.veritas.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Mar 2006 09:17:52 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Nea] meet to review BOF at IETF? Date: Wed, 22 Mar 2006 09:17:50 -0800 Message-ID: <5A58F967CBEBBB4A82DF126CF8A9596A9B7009@SVL1XCHCLUPIN01.enterprise.veritas.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] meet to review BOF at IETF? thread-index: AcZN0Rwau5iJIR8HRQ+jIl1W+cAi+gAA1Usg From: "Paul Sangster" To: "John Vollbrecht" , "Steve Hanna" X-OriginalArrivalTime: 22 Mar 2006 17:17:52.0699 (UTC) FILETIME=[8D6108B0:01C64DD4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: NEA X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Ok, I'll see (at least) you there at 11:30. If others are free please join us!=20 > -----Original Message----- > From: John Vollbrecht [mailto:jrv@mtghouse.com]=20 > Sent: Wednesday, March 22, 2006 8:53 AM > To: Steve Hanna > Cc: John Vollbrecht; NEA > Subject: Re: [Nea] meet to review BOF at IETF? >=20 > 4:10 at the message board is fine. I am also free for lunch,=20 > and would like to meet with anyone that can't meet there at=20 > 4:10. can meet at message board at 11:30 if you want to have lunch. >=20 > -- John >=20 >=20 > On Mar 22, 2006, at 11:11 AM, Steve Hanna wrote: >=20 > > Good idea, John. I'm sure we've all been having interesting=20 > > conversations and thoughts since the BOF. Unfortunately,=20 > Susan and I=20 > > are busy for lunch (WG Chairs Lunch). How about the afternoon break=20 > > today? I propose we meet at 4:10 PM at the IETF message board. OK? > > > > Thanks, > > > > Steve > > > >> -----Original Message----- > >> From: John Vollbrecht [mailto:jrv@mtghouse.com] > >> Sent: Wednesday, March 22, 2006 10:03 AM > >> To: NEA > >> Subject: [Nea] meet to review BOF at IETF? > >> > >> I am wondering if people would like to get together to=20 > review the BOF=20 > >> and any feedback we might have gotten while we are face to face at=20 > >> IETF. I have gotten some comments that I think are=20 > interesting and=20 > >> might help moving forward, and I can note them in an email when I=20 > >> have a few minutes, but I am wondering if people will be=20 > around - I=20 > >> will be here till Thursday afternoon - and would like to=20 > touch base=20 > >> for a few minutes. > >> > >> - John > >> > >> > >> _______________________________________________ > >> Nea mailing list > >> Nea@ietf.org > >> https://www1.ietf.org/mailman/listinfo/nea > >> > > > > >=20 >=20 > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www1.ietf.org/mailman/listinfo/nea >=20 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Mar 22 12:22:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM72Q-0003Hc-LD; Wed, 22 Mar 2006 12:22:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM72P-0003FN-S1 for nea@ietf.org; Wed, 22 Mar 2006 12:22:25 -0500 Received: from mga02.intel.com ([134.134.136.20] helo=orsmga101-1.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM72O-0000Rd-8D for nea@ietf.org; Wed, 22 Mar 2006 12:22:25 -0500 Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101-1.jf.intel.com with ESMTP; 22 Mar 2006 09:18:26 -0800 Received: from fmsmsx332.fm.intel.com (HELO fmsmsx332.amr.corp.intel.com) ([132.233.42.148]) by orsmga001.jf.intel.com with ESMTP; 22 Mar 2006 09:18:25 -0800 X-IronPort-AV: i="4.03,119,1141632000"; d="scan'208"; a="14686830:sNHT33390049" Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Mar 2006 09:18:08 -0800 Received: from hdsmsx401.amr.corp.intel.com ([10.127.2.60]) by fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Mar 2006 09:18:08 -0800 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 Subject: RE: [Nea] meet to review BOF at IETF? Date: Wed, 22 Mar 2006 12:18:05 -0500 Message-ID: <5404AEB459F8354F81995E038F34320002AFF07C@hdsmsx401.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] meet to review BOF at IETF? Thread-Index: AcZN0cu5i2V3vglySKuqpyREWhkNnAAAr3UA From: "Blumenthal, Uri" To: "NEA" X-OriginalArrivalTime: 22 Mar 2006 17:18:08.0481 (UTC) FILETIME=[96C92D10:01C64DD4] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org ACK on both 11:30 and 4:10 today. -----Original Message----- From: John Vollbrecht [mailto:jrv@mtghouse.com]=20 Sent: Wednesday, March 22, 2006 11:53 AM To: Steve Hanna Cc: John Vollbrecht; NEA Subject: Re: [Nea] meet to review BOF at IETF? 4:10 at the message board is fine. I am also free for lunch, and =20 would like to meet with anyone that can't meet there at 4:10. can =20 meet at message board at 11:30 if you want to have lunch. -- John On Mar 22, 2006, at 11:11 AM, Steve Hanna wrote: > Good idea, John. I'm sure we've all been having > interesting conversations and thoughts since > the BOF. Unfortunately, Susan and I are busy > for lunch (WG Chairs Lunch). How about the > afternoon break today? I propose we meet at > 4:10 PM at the IETF message board. OK? > > Thanks, > > Steve > >> -----Original Message----- >> From: John Vollbrecht [mailto:jrv@mtghouse.com] >> Sent: Wednesday, March 22, 2006 10:03 AM >> To: NEA >> Subject: [Nea] meet to review BOF at IETF? >> >> I am wondering if people would like to get together to review >> the BOF >> and any feedback we might have gotten while we are face to face at >> IETF. I have gotten some comments that I think are interesting and >> might help moving forward, and I can note them in an email when I >> have a few minutes, but I am wondering if people will be around - I >> will be here till Thursday afternoon - and would like to touch base >> for a few minutes. >> >> - John >> >> >> _______________________________________________ >> Nea mailing list >> Nea@ietf.org >> https://www1.ietf.org/mailman/listinfo/nea >> > > _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Mar 22 12:24:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM74F-0004OU-HA; Wed, 22 Mar 2006 12:24:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM74D-0004Gv-Kn for nea@ietf.org; Wed, 22 Mar 2006 12:24:17 -0500 Received: from mail.signacert.org ([207.162.214.7] helo=mail.signacert.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM74B-0000Wg-8w for nea@ietf.org; Wed, 22 Mar 2006 12:24:17 -0500 Received: from [10.194.192.75] (unknown [66.209.15.234]) by mail.signacert.com (Postfix) with ESMTP id 3639B18EC46A; Wed, 22 Mar 2006 09:24:06 -0800 (PST) Mime-Version: 1.0 X-Mailer: SnapperMail 2.3.2.01 by Snapperfish To: John Vollbrecht , Steve Hanna Subject: Re: [Nea] meet to review BOF at IETF? Message-ID: <4318-SnapperMsgF6E419A5C0473863@[10.194.192.75]> In-Reply-To: References:

From: Thomas Hardjono Date: Wed, 22 Mar 2006 9:22:17 -0800 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Spam-Score: 0.3 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: John Vollbrecht , NEA X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: thardjono@signacert.com List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Apologies folks - I'm back on the west coast due to company meetings. /thomas/ ___ ---- Sent from a Treo --- ...... Original Message ....... On Wed, 22 Mar 2006 11:53:06 -0500 John Vollbrecht wrote: >4:10 at the message board is fine. I am also free for lunch, and >would like to meet with anyone that can't meet there at 4:10. can >meet at message board at 11:30 if you want to have lunch. > >-- John > > >On Mar 22, 2006, at 11:11 AM, Steve Hanna wrote: > >> Good idea, John. I'm sure we've all been having >> interesting conversations and thoughts since >> the BOF. Unfortunately, Susan and I are busy >> for lunch (WG Chairs Lunch). How about the >> afternoon break today? I propose we meet at >> 4:10 PM at the IETF message board. OK? >> >> Thanks, >> >> Steve >> >>> -----Original Message----- >>> From: John Vollbrecht [mailto:jrv@mtghouse.com] >>> Sent: Wednesday, March 22, 2006 10:03 AM >>> To: NEA >>> Subject: [Nea] meet to review BOF at IETF? >>> >>> I am wondering if people would like to get together to review >>> the BOF >>> and any feedback we might have gotten while we are face to face at >>> IETF. I have gotten some comments that I think are interesting and >>> might help moving forward, and I can note them in an email when I >>> have a few minutes, but I am wondering if people will be around - I >>> will be here till Thursday afternoon - and would like to touch base >>> for a few minutes. >>> >>> - John >>> >>> >>> _______________________________________________ >>> Nea mailing list >>> Nea@ietf.org >>> https://www1.ietf.org/mailman/listinfo/nea >>> >> >> > > >_______________________________________________ >Nea mailing list >Nea@ietf.org >https://www1.ietf.org/mailman/listinfo/nea > _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Mar 22 12:52:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM7Vt-00063e-0s; Wed, 22 Mar 2006 12:52:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM7Vs-00063Z-CD for nea@ietf.org; Wed, 22 Mar 2006 12:52:52 -0500 Received: from e1.ny.us.ibm.com ([32.97.182.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM7Vs-0001Tm-0B for nea@ietf.org; Wed, 22 Mar 2006 12:52:52 -0500 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e1.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id k2MHqmpu000354 for ; Wed, 22 Mar 2006 12:52:48 -0500 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k2MHqm08203616 for ; Wed, 22 Mar 2006 12:52:48 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.13.3) with ESMTP id k2MHqm5s032450 for ; Wed, 22 Mar 2006 12:52:48 -0500 Received: from d01mlc83.pok.ibm.com (d01mlc83.pok.ibm.com [9.56.228.211]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id k2MHqmhY032447; Wed, 22 Mar 2006 12:52:48 -0500 In-Reply-To: <4318-SnapperMsgF6E419A5C0473863@[10.194.192.75]> To: thardjono@signacert.com MIME-Version: 1.0 Subject: Re: [Nea] meet to review BOF at IETF? X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Diana J Arroyo Date: Wed, 22 Mar 2006 11:52:46 -0600 X-MIMETrack: Serialize by Router on D01MLC83/01/M/IBM(Release 7.0.1 HF1|March 1, 2006) at 03/22/2006 12:52:47, Serialize complete at 03/22/2006 12:52:47 X-Spam-Score: 0.1 (/) X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186 Cc: John Vollbrecht , NEA X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0486104773==" Errors-To: nea-bounces@ietf.org This is a multipart message in MIME format. --===============0486104773== Content-Type: multipart/alternative; boundary="=_alternative 0062369486257139_=" This is a multipart message in MIME format. --=_alternative 0062369486257139_= Content-Type: text/plain; charset="US-ASCII" I'm back in Austin as well. If someone would be willing to post any notes/summaries from the meetings it would be greatly appreciated. Regards, Diana Arroyo Software Engineer, Corporate Security Strategy 512.838.0088 darroyo@us.ibm.com Thomas Hardjono 03/22/2006 11:22 AM Please respond to thardjono To: John Vollbrecht , Steve Hanna cc: John Vollbrecht , NEA Subject: Re: [Nea] meet to review BOF at IETF? Apologies folks - I'm back on the west coast due to company meetings. /thomas/ ___ ---- Sent from a Treo --- ...... Original Message ....... On Wed, 22 Mar 2006 11:53:06 -0500 John Vollbrecht wrote: >4:10 at the message board is fine. I am also free for lunch, and >would like to meet with anyone that can't meet there at 4:10. can >meet at message board at 11:30 if you want to have lunch. > >-- John > > >On Mar 22, 2006, at 11:11 AM, Steve Hanna wrote: > >> Good idea, John. I'm sure we've all been having >> interesting conversations and thoughts since >> the BOF. Unfortunately, Susan and I are busy >> for lunch (WG Chairs Lunch). How about the >> afternoon break today? I propose we meet at >> 4:10 PM at the IETF message board. OK? >> >> Thanks, >> >> Steve >> >>> -----Original Message----- >>> From: John Vollbrecht [mailto:jrv@mtghouse.com] >>> Sent: Wednesday, March 22, 2006 10:03 AM >>> To: NEA >>> Subject: [Nea] meet to review BOF at IETF? >>> >>> I am wondering if people would like to get together to review >>> the BOF >>> and any feedback we might have gotten while we are face to face at >>> IETF. I have gotten some comments that I think are interesting and >>> might help moving forward, and I can note them in an email when I >>> have a few minutes, but I am wondering if people will be around - I >>> will be here till Thursday afternoon - and would like to touch base >>> for a few minutes. >>> >>> - John >>> >>> >>> _______________________________________________ >>> Nea mailing list >>> Nea@ietf.org >>> https://www1.ietf.org/mailman/listinfo/nea >>> >> >> > > >_______________________________________________ >Nea mailing list >Nea@ietf.org >https://www1.ietf.org/mailman/listinfo/nea > _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea --=_alternative 0062369486257139_= Content-Type: text/html; charset="US-ASCII"
I'm back in Austin as well. If someone would be willing to post any notes/summaries from the meetings it would be greatly appreciated.

Regards,
Diana Arroyo
Software Engineer, Corporate Security Strategy
512.838.0088
darroyo@us.ibm.com

Thomas Hardjono <thardjono@signacert.com>

03/22/2006 11:22 AM
Please respond to thardjono

To: John Vollbrecht <jrv@mtghouse.com>, Steve Hanna <shanna@juniper.net>
cc: John Vollbrecht <jrv@mtghouse.com>, NEA <nea@ietf.org>
Subject: Re: [Nea] meet to review BOF at IETF?

Apologies folks - I'm back on the west coast due to company meetings. /thomas/ ___ ---- Sent from a Treo --- ...... Original Message ....... On Wed, 22 Mar 2006 11:53:06 -0500 John Vollbrecht <jrv@mtghouse.com> wrote: >4:10 at the message board is fine. I am also free for lunch, and >would like to meet with anyone that can't meet there at 4:10. can >meet at message board at 11:30 if you want to have lunch. > >-- John > > >On Mar 22, 2006, at 11:11 AM, Steve Hanna wrote: > >> Good idea, John. I'm sure we've all been having >> interesting conversations and thoughts since >> the BOF. Unfortunately, Susan and I are busy >> for lunch (WG Chairs Lunch). How about the >> afternoon break today? I propose we meet at >> 4:10 PM at the IETF message board. OK? >> >> Thanks, >> >> Steve >> >>> -----Original Message----- >>> From: John Vollbrecht [mailto:jrv@mtghouse.com] >>> Sent: Wednesday, March 22, 2006 10:03 AM >>> To: NEA >>> Subject: [Nea] meet to review BOF at IETF? >>> >>> I am wondering if people would like to get together to review >>> the BOF >>> and any feedback we might have gotten while we are face to face at >>> IETF. I have gotten some comments that I think are interesting and >>> might help moving forward, and I can note them in an email when I >>> have a few minutes, but I am wondering if people will be around - I >>> will be here till Thursday afternoon - and would like to touch base >>> for a few minutes. >>> >>> - John >>> >>> >>> _______________________________________________ >>> Nea mailing list >>> Nea@ietf.org >>> https://www1.ietf.org/mailman/listinfo/nea >>> >> >> > > >_______________________________________________ >Nea mailing list >Nea@ietf.org >https://www1.ietf.org/mailman/listinfo/nea > _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea
--=_alternative 0062369486257139_=-- --===============0486104773== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea --===============0486104773==-- From nea-bounces@ietf.org Wed Mar 22 14:19:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM8ra-00066e-Qe; Wed, 22 Mar 2006 14:19:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM8rZ-00066Z-Hs for nea@ietf.org; Wed, 22 Mar 2006 14:19:21 -0500 Received: from mga03.intel.com ([143.182.124.21] helo=azsmga101-1.ch.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM8rY-0006Bg-R9 for nea@ietf.org; Wed, 22 Mar 2006 14:19:21 -0500 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101-1.ch.intel.com with ESMTP; 22 Mar 2006 11:13:20 -0800 Received: from orsmsx331.jf.intel.com (HELO orsmsx331.amr.corp.intel.com) ([192.168.65.56]) by azsmga001.ch.intel.com with ESMTP; 22 Mar 2006 11:13:13 -0800 X-IronPort-AV: i="4.03,119,1141632000"; d="scan'208,217"; a="14337202:sNHT1868844915" Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Mar 2006 11:13:10 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Nea] meet to review BOF at IETF? Date: Wed, 22 Mar 2006 11:13:09 -0800 Message-ID: <96E39AF1B99FDC47A38DDAB22C3E70CA074E61AE@orsmsx408> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] meet to review BOF at IETF? Thread-Index: AcZN2gCehwzmAgzWQPCdUtGOC3cASgACn3GA From: "Sahita, Ravi" To: "Diana J Arroyo" , X-OriginalArrivalTime: 22 Mar 2006 19:13:10.0128 (UTC) FILETIME=[A87CEF00:01C64DE4] X-Spam-Score: 0.3 (/) X-Scan-Signature: 03fb21b15d5177c512a4caa19876f30a Cc: John Vollbrecht , NEA X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: ,