
From shawn.emery@oracle.com  Tue Jun  1 00:43:39 2010
Return-Path: <shawn.emery@oracle.com>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BB783A68BD; Tue,  1 Jun 2010 00:43:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.998
X-Spam-Level: 
X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPsAyOw4SVKR; Tue,  1 Jun 2010 00:43:38 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 10B5A3A6824; Tue,  1 Jun 2010 00:43:38 -0700 (PDT)
Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o517hKZ9017027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 Jun 2010 07:43:22 GMT
Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o517Saon011978; Tue, 1 Jun 2010 07:43:19 GMT
Received: from abhmt019.oracle.com by acsmt354.oracle.com with ESMTP id 312300221275378176; Tue, 01 Jun 2010 00:42:56 -0700
Received: from [129.150.48.63] (/129.150.48.63) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 01 Jun 2010 00:42:55 -0700
Message-ID: <4C04B9FE.2090804@oracle.com>
Date: Tue, 01 Jun 2010 01:42:54 -0600
From: Shawn Emery <shawn.emery@oracle.com>
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1
MIME-Version: 1.0
To: kitten@ietf.org, sasl@ietf.org
Subject: Kitten Recharter
Content-Type: multipart/mixed; boundary="------------060805080206080204000308"
X-Auth-Type: Internal IP
X-Source-IP: rcsinet15.oracle.com [148.87.113.117]
X-CT-RefId: str=0001.0A090201.4C04BA1C.01BA:SCFMA4539811,ss=1,fgs=0
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Jun 2010 07:43:39 -0000

This is a multi-part message in MIME format.
--------------060805080206080204000308
Content-Type: multipart/alternative;
 boundary="------------040107090009090306070208"


--------------040107090009090306070208
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


Per the recent thead on "MOGGIES Proposed Charter"; I have taken 
suggestions by kitten/SASL WG members and created recharter text for 
Kitten (whilst closing SASL).  Please let me know if I missed anything.

Shawn.
Kitten co-chair.
--

--------------040107090009090306070208
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>

<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body text="#000000" bgcolor="#ffffff">
<font size="+1"><tt><br>
Per the recent thead on "MOGGIES Proposed Charter"; I have taken
suggestions by kitten/SASL WG members and created recharter text for
Kitten (whilst closing SASL).&nbsp; Please let me know if I missed anything.<br>
<br>
Shawn.<br>
Kitten co-chair.<br>
--</tt></font><br>
<font size="+1"><tt></tt></font>
</body>
</html>

--------------040107090009090306070208--

--------------060805080206080204000308
Content-Type: text/plain;
 name="kitten-recharter.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="kitten-recharter.txt"

Kitten (Common Authentication Technology Next Generation)


Description of Working Group:

The Generic Security Services (GSS) API and Simple Authentication and Security
Layer (SASL) provide various applications with a security framework for secure
network communication.  The purpose of the Common Authentication Technology
Next Generation (Kitten) working group (WG) is to develop
extensions/improvements to the GSS-API, shepherd specific GSS-API security
mechanisms, and provide guidance for any new SASL-related submissions.
 
This working is chartered to specify the following extensions and improvements
(draft-yu-kitten-api-wishlist-00) to the GSS-API:

* Provide new interfaces for credential management, which include the following:
	initializing credentials
	iterating credentials
	exporting/importing credentials

* Specify interface for asynchronous calls.

* Define interfaces for better error message reporting.

* Provide a more programmer friendly interface for application developers.

This WG is also chartered to transition proposed SASL mechanisms as
GSS-API mechanisms:

* A SASL Mechanism for OpenID
	draft-lear-ietf-sasl-openid-00
* A SASL Mechanism for SAML
	draft-wierenga-ietf-sasl-saml-00

The transition from SASL to GSS-API mechanisms will allow a greater set of
applications to utilize said mechanisms with SASL implementations that support
the use of GSS-API mechanisms in SASL (draft-ietf-sasl-gs2).

* Shepard draft-melnikov-digest-to-historic through standards track.

This WG should review proposals for new SASL and GSS-API mechanisms.  The WG
should also review non-mechanism proposals related to SASL and the GSS-API.


Deliverables:

* GSS-API: initializing credentials
[editor: TBD]

* GSS-API: iterating credentials
[editor: TBD]

* GSS-API: exporting/importing credentials
[editor: TBD]

* GSS-API: specification for asynchronous calls
[editor: TBD]

* GSS-API: interfaces/improvements for better error message reporting
[editor: TBD]

* GSS-API: programmer friendly interfaces
[editor: TBD]

* GSS-API: transition SASL mechanism for OpenID
[editor: TBD]

* GSS-API: transition SASL mechanism for SAML
[editor: TBD]

* GSS-API: publish draft-ietf-kitten-gssapi-extensions-iana
[editor: Nicolas Williams]

* GSS-API: publish draft-ietf-kitten-gssapi-naming-exts
[editor: Leif Johansson]

* SASL: publish draft-melnikov-digest-to-historic
[editor: Alexey Melnikov]

Goals and Milestones:

June 2010	Submit publish draft-ietf-kitten-gssapi-naming-exts to the IESG as Proposed Standard
June 2010	WGLC, again, on draft-ietf-kitten-gssapi-extensions-iana
July 2010	Submit draft-ietf-kitten-gssapi-extensions-iana to the IESG as Proposed Standard
July 2010	First Meeting
TBD		Other Listed Work Items

--------------060805080206080204000308--

From shawn.emery@oracle.com  Tue Jun  8 16:19:52 2010
Return-Path: <shawn.emery@oracle.com>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 059403A6826 for <kitten@core3.amsl.com>; Tue,  8 Jun 2010 16:19:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gtw-WWWfhaqS for <kitten@core3.amsl.com>; Tue,  8 Jun 2010 16:19:50 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id BF36D3A684C for <kitten@ietf.org>; Tue,  8 Jun 2010 16:19:45 -0700 (PDT)
Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o58NJikP004769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <kitten@ietf.org>; Tue, 8 Jun 2010 23:19:46 GMT
Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o58Cdthp027866 for <kitten@ietf.org>; Tue, 8 Jun 2010 23:19:43 GMT
Received: from abhmt021.oracle.com by acsmt355.oracle.com with ESMTP id 331330641276039098; Tue, 08 Jun 2010 16:18:18 -0700
Received: from [129.150.48.15] (/129.150.48.15) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 08 Jun 2010 16:18:18 -0700
Message-ID: <4C0ECFB9.7080900@oracle.com>
Date: Tue, 08 Jun 2010 17:18:17 -0600
From: Shawn Emery <shawn.emery@oracle.com>
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1
MIME-Version: 1.0
To: kitten@ietf.org
Subject: extensions-iana registry
Content-Type: multipart/alternative; boundary="------------000401050709060507080307"
X-Auth-Type: Internal IP
X-Source-IP: rcsinet13.oracle.com [148.87.113.125]
X-CT-RefId: str=0001.0A090202.4C0ED012.0089:SCFMA4539811,ss=1,fgs=0
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Jun 2010 23:19:52 -0000

This is a multi-part message in MIME format.
--------------000401050709060507080307
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


Based on IANA feed-back; the WG needs to reach consensus on how the 
GSS-API extensions are to be registered.  Options proposed:

     1. single GSS-API name-space registry
     2. separate registry - symbolic and constant registries
     3. registry per programming language
     4. multiple registries
     ...

Time-out is in two weeks (ending 6/22/10).

</co-chair> My preference is option 1.

Shawn kitten co-chair.
--

--------------000401050709060507080307
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>

<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body text="#000000" bgcolor="#ffffff">
<font size="+1"><tt><br>
Based on IANA feed-back; the WG needs to reach consensus on how the
GSS-API extensions are to be registered.&nbsp; Options proposed:<br>
<br>
&nbsp;&nbsp;&nbsp; 1. single GSS-API name-space registry<br>
&nbsp;&nbsp;&nbsp; 2. separate registry - symbolic and constant registries<br>
&nbsp;&nbsp;&nbsp; 3. registry per programming language<br>
&nbsp;&nbsp;&nbsp; 4. multiple registries<br>
&nbsp;&nbsp;&nbsp; ...<br>
<br>
Time-out is in two weeks (ending 6/22/10).<br>
<br>
&lt;/co-chair&gt; My preference is option 1.<br>
<br>
Shawn kitten co-chair.<br>
--<br>
</tt></font>
</body>
</html>

--------------000401050709060507080307--

From stpeter@stpeter.im  Tue Jun  8 18:21:01 2010
Return-Path: <stpeter@stpeter.im>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8287F3A682D for <kitten@core3.amsl.com>; Tue,  8 Jun 2010 18:21:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.299
X-Spam-Level: 
X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fj7NK6EBN6IJ for <kitten@core3.amsl.com>; Tue,  8 Jun 2010 18:21:00 -0700 (PDT)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 849B53A67A4 for <kitten@ietf.org>; Tue,  8 Jun 2010 18:21:00 -0700 (PDT)
Received: from squire.local (dsl-240-39.dynamic-dsl.frii.net [216.17.240.39]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8969D40CFD for <kitten@ietf.org>; Tue,  8 Jun 2010 19:21:01 -0600 (MDT)
Message-ID: <4C0EEC7C.9030707@stpeter.im>
Date: Tue, 08 Jun 2010 19:21:00 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: kitten@ietf.org
Subject: Re: extensions-iana registry
References: <4C0ECFB9.7080900@oracle.com>
In-Reply-To: <4C0ECFB9.7080900@oracle.com>
X-Enigmail-Version: 1.0.1
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020409010702000902070606"
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Jun 2010 01:21:01 -0000

This is a cryptographically signed message in MIME format.

--------------ms020409010702000902070606
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 6/8/10 5:18 PM, Shawn Emery wrote:

>     1. single GSS-API name-space registry

That's my vote.

Peter

--=20
Peter Saint-Andre
https://stpeter.im/




--------------ms020409010702000902070606
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC
B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK
Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT
aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl
IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG
EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q
UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0
aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN
AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs
hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP
XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5
wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV//
Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID
hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH
AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA
c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x
CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg
RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp
Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw
ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG
CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8
BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0
eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv
bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz
bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0
cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC
hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j
cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA
A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R
gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA
X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/
kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM
UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g
AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx
ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50
IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw
DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k
YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl
IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0
cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue
HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/
+Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1
siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz
yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9
sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud
EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV
HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy
LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE
BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs
IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g
QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI
KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH
AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF
BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk
IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp
ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy
dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0
c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j
cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz
cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV
HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/
jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh
BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk
/eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw
xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i
bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP
MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu
MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD
EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x
MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr
MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv
U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G
CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO
0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx
c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B
x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ
bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ
6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd
BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX
aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk
LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE
AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr
BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh
LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et
Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD
VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j
ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z
dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg
Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy
ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl
cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu
c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB
DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt
YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT
fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T
lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H
jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h
dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX
luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ
FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC
IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO
3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+
YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20
OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx
ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50
IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI
hvcNAQkFMQ8XDTEwMDYwOTAxMjEwMFowIwYJKoZIhvcNAQkEMRYEFFNGCtQ5Uwnh2V/faqVH
IqjGxChpMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG
SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ
KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk
LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE
AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw
gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4
MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg
Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAjMPsO3ag+kN24kOlEmYB76PEZOeFw32TEU6zzFz/
xrx0cb9XN69cCykG6bxfQiSM0rDZY2o7Wu2owEnxjivlX/XYnEDsyST+Bcnmkax8Ywgj7KK8
iNwu1Oyhax7WWsplev/ZufhTG4JSqRty0Bb6DJEtV2SiQablFciJSYKMIwcZRBvzI4PqC69C
nyAJfSji4EWCCETfKvvPZLfd9Mao0CotAQHbyWrpPPwtx0v22X8YEAYGl3r58JmbnACcIQeA
Wdi/N5bDD3n7qVkAyC9g9Wk7UySY/DTNmF+D+2UxyAobQ66UEFrgPHqoAZN5v4BQFtjLWBGw
o2AAIhZ/pF3LQAAAAAAAAA==
--------------ms020409010702000902070606--

From alexey.melnikov@isode.com  Tue Jun  8 22:25:19 2010
Return-Path: <alexey.melnikov@isode.com>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A47E63A6885 for <kitten@core3.amsl.com>; Tue,  8 Jun 2010 22:25:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.213
X-Spam-Level: 
X-Spam-Status: No, score=-2.213 tagged_above=-999 required=5 tests=[AWL=0.386,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cODeVV8mHxiU for <kitten@core3.amsl.com>; Tue,  8 Jun 2010 22:25:19 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id DCF673A685A for <kitten@ietf.org>; Tue,  8 Jun 2010 22:25:18 -0700 (PDT)
Received: from [172.16.2.133] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <TA8lvwBeGRo5@rufus.isode.com>; Wed, 9 Jun 2010 06:25:19 +0100
Message-ID: <4C0F25B0.9060801@isode.com>
Date: Wed, 09 Jun 2010 06:25:04 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: kitten@ietf.org
Subject: Re: extensions-iana registry
References: <4C0ECFB9.7080900@oracle.com>
In-Reply-To: <4C0ECFB9.7080900@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Jun 2010 05:25:19 -0000

Shawn Emery wrote:

>
> Based on IANA feed-back; the WG needs to reach consensus on how the 
> GSS-API extensions are to be registered.  Options proposed:
>
>     1. single GSS-API name-space registry

I prefer this choice.

>     2. separate registry - symbolic and constant registries
>     3. registry per programming language
>     4. multiple registries
>     ...
>
> Time-out is in two weeks (ending 6/22/10).



From alexey.melnikov@isode.com  Fri Jun 11 10:40:42 2010
Return-Path: <alexey.melnikov@isode.com>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7702B3A67D6; Fri, 11 Jun 2010 10:40:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.748
X-Spam-Level: 
X-Spam-Status: No, score=-0.748 tagged_above=-999 required=5 tests=[AWL=-0.749, BAYES_50=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2xLenSwKlsed; Fri, 11 Jun 2010 10:40:41 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 106F03A6A30; Fri, 11 Jun 2010 10:40:41 -0700 (PDT)
Received: from [172.16.2.142] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <TBJ1GQAJfwh1@rufus.isode.com>; Fri, 11 Jun 2010 18:40:41 +0100
Message-ID: <4C12750D.4030904@isode.com>
Date: Fri, 11 Jun 2010 18:40:29 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Shawn Emery <shawn.emery@oracle.com>
Subject: Re: [sasl] Kitten Recharter
References: <4C04B9FE.2090804@oracle.com>
In-Reply-To: <4C04B9FE.2090804@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: kitten@ietf.org, sasl@ietf.org
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Jun 2010 17:40:42 -0000

Shawn Emery wrote:

> Per the recent thead on "MOGGIES Proposed Charter"; I have taken 
> suggestions by kitten/SASL WG members and created recharter text for 
> Kitten (whilst closing SASL).  Please let me know if I missed anything.
>
> Shawn.
> Kitten co-chair.

Hi Sean,
Thanks for the updated version. This looks much better.
Some additional comments inline.

>Kitten (Common Authentication Technology Next Generation)
>
>
>Description of Working Group:
>
>The Generic Security Services (GSS) API and Simple Authentication and Security
>Layer (SASL) provide various applications with a security framework for secure
>network communication.  The purpose of the Common Authentication Technology
>Next Generation (Kitten) working group (WG) is to develop
>extensions/improvements to the GSS-API, shepherd specific GSS-API security
>mechanisms, and provide guidance for any new SASL-related submissions.
> 
>This working is chartered to specify the following extensions and improvements
>(draft-yu-kitten-api-wishlist-00) to the GSS-API:
>
>* Provide new interfaces for credential management, which include the following:
>	initializing credentials
>	iterating credentials
>	exporting/importing credentials
>
>* Specify interface for asynchronous calls.
>
>* Define interfaces for better error message reporting.
>
>* Provide a more programmer friendly interface for application developers.
>  
>
This point is a bit vague. Do we actually need this as an explicit goal?

>This WG is also chartered to transition proposed SASL mechanisms as
>GSS-API mechanisms:
>
>* A SASL Mechanism for OpenID
>	draft-lear-ietf-sasl-openid-00
>* A SASL Mechanism for SAML
>	draft-wierenga-ietf-sasl-saml-00
>
>The transition from SASL to GSS-API mechanisms will allow a greater set of
>applications to utilize said mechanisms with SASL implementations that support
>the use of GSS-API mechanisms in SASL (draft-ietf-sasl-gs2).
>
>* Shepard draft-melnikov-digest-to-historic through standards track.
>
typo: shephard

>This WG should review proposals for new SASL and GSS-API mechanisms.  The WG
>should also review non-mechanism proposals related to SASL and the GSS-API.
>
I think this is a bit too open-ended for IESG. I would have asked about 
that if I were asked to review such charter ;-).

To be frank, I would delete these 2 sentences, or say the exactly 
opposite: other proposals would require rechartering. However chairs 
always have some flexibility in allowing conversations on related 
topics, as long as this doesn't compromise progress on major deliverables.

>Deliverables:
>
>* GSS-API: initializing credentials
>[editor: TBD]
>
>* GSS-API: iterating credentials
>[editor: TBD]
>
>* GSS-API: exporting/importing credentials
>[editor: TBD]
>
>* GSS-API: specification for asynchronous calls
>[editor: TBD]
>
>* GSS-API: interfaces/improvements for better error message reporting
>[editor: TBD]
>
>* GSS-API: programmer friendly interfaces
>[editor: TBD]
>
>* GSS-API: transition SASL mechanism for OpenID
>[editor: TBD]
>
>* GSS-API: transition SASL mechanism for SAML
>[editor: TBD]
>
>* GSS-API: publish draft-ietf-kitten-gssapi-extensions-iana
>[editor: Nicolas Williams]
>
>* GSS-API: publish draft-ietf-kitten-gssapi-naming-exts
>[editor: Leif Johansson]
>
>* SASL: publish draft-melnikov-digest-to-historic
>[editor: Alexey Melnikov]
>
>Goals and Milestones:
>
>June 2010	Submit publish draft-ietf-kitten-gssapi-naming-exts to the IESG as Proposed Standard
>June 2010	WGLC, again, on draft-ietf-kitten-gssapi-extensions-iana
>July 2010	Submit draft-ietf-kitten-gssapi-extensions-iana to the IESG as Proposed Standard
>July 2010	First Meeting
>TBD		Other Listed Work Items
>  
>


From jhutz@cmu.edu  Fri Jun 11 11:10:45 2010
Return-Path: <jhutz@cmu.edu>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 388813A6A2F; Fri, 11 Jun 2010 11:10:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.299
X-Spam-Level: 
X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.300,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7R0FvvO5q3uM; Fri, 11 Jun 2010 11:10:42 -0700 (PDT)
Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by core3.amsl.com (Postfix) with ESMTP id EA89C3A6A2D; Fri, 11 Jun 2010 11:10:41 -0700 (PDT)
Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o5BIAgGX006123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Jun 2010 14:10:42 -0400 (EDT)
Date: Fri, 11 Jun 2010 14:10:42 -0400
From: Jeffrey Hutzelman <jhutz@cmu.edu>
To: Alexey Melnikov <alexey.melnikov@isode.com>, Shawn Emery <shawn.emery@oracle.com>
Subject: Re: [sasl] Kitten Recharter
Message-ID: <5531409D439CF3B42925B973@minbar.fac.cs.cmu.edu>
In-Reply-To: <1763_1276278048_o5BHelQL016299_4C12750D.4030904@isode.com>
References: <4C04B9FE.2090804@oracle.com> <1763_1276278048_o5BHelQL016299_4C12750D.4030904@isode.com>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.217.197
Cc: kitten@ietf.org, sasl@ietf.org, jhutz@cmu.edu
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Jun 2010 18:10:45 -0000

--On Friday, June 11, 2010 06:40:29 PM +0100 Alexey Melnikov 
<alexey.melnikov@isode.com> wrote:

>> * Shepard draft-melnikov-digest-to-historic through standards track.
>>
> typo: shephard

shepherd, with an 'e', please


>> This WG should review proposals for new SASL and GSS-API mechanisms.
>> The WG should also review non-mechanism proposals related to SASL and
>> the GSS-API.
>>
> I think this is a bit too open-ended for IESG. I would have asked about
> that if I were asked to review such charter ;-).
>
> To be frank, I would delete these 2 sentences, or say the exactly
> opposite: other proposals would require rechartering. However chairs
> always have some flexibility in allowing conversations on related topics,
> as long as this doesn't compromise progress on major deliverables.

Not at all.  The intent here is not that the WG have an open-ended mandate 
to take on any and all mechanism work.  However, we want to be clear that 
this is the place to take any such proposals, and that it is in scope for 
the WG to discuss and review them, and to consider whether it wants to work 
on them (in which case a charter revision would be needed).

-- Jeff

From alexey.melnikov@isode.com  Fri Jun 11 11:13:16 2010
Return-Path: <alexey.melnikov@isode.com>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6CF93A69A0; Fri, 11 Jun 2010 11:13:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.025
X-Spam-Level: 
X-Spam-Status: No, score=-2.025 tagged_above=-999 required=5 tests=[AWL=0.574,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Av62LmpqIsid; Fri, 11 Jun 2010 11:13:14 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 467173A6A15; Fri, 11 Jun 2010 11:13:14 -0700 (PDT)
Received: from [172.16.2.142] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <TBJ8vAAJfwfy@rufus.isode.com>; Fri, 11 Jun 2010 19:13:16 +0100
Message-ID: <4C127CAE.6010203@isode.com>
Date: Fri, 11 Jun 2010 19:13:02 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Jeffrey Hutzelman <jhutz@cmu.edu>
Subject: Re: [sasl] Kitten Recharter
References: <4C04B9FE.2090804@oracle.com> <1763_1276278048_o5BHelQL016299_4C12750D.4030904@isode.com> <5531409D439CF3B42925B973@minbar.fac.cs.cmu.edu>
In-Reply-To: <5531409D439CF3B42925B973@minbar.fac.cs.cmu.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: kitten@ietf.org, sasl@ietf.org
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Jun 2010 18:13:16 -0000

Jeffrey Hutzelman wrote:

> --On Friday, June 11, 2010 06:40:29 PM +0100 Alexey Melnikov 
> <alexey.melnikov@isode.com> wrote:
>
>>> * Shepard draft-melnikov-digest-to-historic through standards track.
>>
>> typo: shephard
>
> shepherd, with an 'e', please.

Thanks :-)

>>> This WG should review proposals for new SASL and GSS-API mechanisms.
>>> The WG should also review non-mechanism proposals related to SASL and
>>> the GSS-API.
>>>
>> I think this is a bit too open-ended for IESG. I would have asked about
>> that if I were asked to review such charter ;-).
>>
>> To be frank, I would delete these 2 sentences, or say the exactly
>> opposite: other proposals would require rechartering. However chairs
>> always have some flexibility in allowing conversations on related 
>> topics,
>> as long as this doesn't compromise progress on major deliverables.
>
> Not at all.  The intent here is not that the WG have an open-ended 
> mandate to take on any and all mechanism work.  However, we want to be 
> clear that this is the place to take any such proposals, and that it 
> is in scope for the WG to discuss and review them, and to consider 
> whether it wants to work on them (in which case a charter revision 
> would be needed).

If that is the intent, then the text is not good enough. It doesn't 
explicitly says that rechartering would be needed, it seems to imply the 
opposite.
It is also not clear to me what can be described as "non-mechanism 
proposals related to SASL and the GSS-API". If we are talking about SASL 
protocol profiles, then we should say that.


From jhutz@cmu.edu  Fri Jun 11 11:49:42 2010
Return-Path: <jhutz@cmu.edu>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5452328C122; Fri, 11 Jun 2010 11:49:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.624
X-Spam-Level: 
X-Spam-Status: No, score=-5.624 tagged_above=-999 required=5 tests=[AWL=0.975,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3It3rkgN4ovJ; Fri, 11 Jun 2010 11:49:41 -0700 (PDT)
Received: from smtp01.srv.cs.cmu.edu (SMTP01.SRV.CS.CMU.EDU [128.2.217.196]) by core3.amsl.com (Postfix) with ESMTP id 4593C28C0F9; Fri, 11 Jun 2010 11:49:41 -0700 (PDT)
Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o5BIngcq005400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Jun 2010 14:49:42 -0400 (EDT)
Date: Fri, 11 Jun 2010 14:49:42 -0400
From: Jeffrey Hutzelman <jhutz@cmu.edu>
To: Alexey Melnikov <alexey.melnikov@isode.com>
Subject: Re: [sasl] Kitten Recharter
Message-ID: <B71621A25E603F701667F193@minbar.fac.cs.cmu.edu>
In-Reply-To: <4C127CAE.6010203@isode.com>
References: <4C04B9FE.2090804@oracle.com>            <1763_1276278048_o5BHelQL016299_4C12750D.4030904@isode.com>  <5531409D439CF3B42925B973@minbar.fac.cs.cmu.edu> <4C127CAE.6010203@isode.com>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.217.196
Cc: kitten@ietf.org, sasl@ietf.org, jhutz@cmu.edu
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Jun 2010 18:49:42 -0000

--On Friday, June 11, 2010 07:13:02 PM +0100 Alexey Melnikov 
<alexey.melnikov@isode.com> wrote:

> Jeffrey Hutzelman wrote:
>
>> --On Friday, June 11, 2010 06:40:29 PM +0100 Alexey Melnikov
>> <alexey.melnikov@isode.com> wrote:
>>
>>>> * Shepard draft-melnikov-digest-to-historic through standards track.
>>>
>>> typo: shephard
>>
>> shepherd, with an 'e', please.
>
> Thanks :-)
>
>>>> This WG should review proposals for new SASL and GSS-API mechanisms.
>>>> The WG should also review non-mechanism proposals related to SASL and
>>>> the GSS-API.
>>>>
>>> I think this is a bit too open-ended for IESG. I would have asked about
>>> that if I were asked to review such charter ;-).
>>>
>>> To be frank, I would delete these 2 sentences, or say the exactly
>>> opposite: other proposals would require rechartering. However chairs
>>> always have some flexibility in allowing conversations on related
>>> topics,
>>> as long as this doesn't compromise progress on major deliverables.
>>
>> Not at all.  The intent here is not that the WG have an open-ended
>> mandate to take on any and all mechanism work.  However, we want to be
>> clear that this is the place to take any such proposals, and that it
>> is in scope for the WG to discuss and review them, and to consider
>> whether it wants to work on them (in which case a charter revision
>> would be needed).
>
> If that is the intent, then the text is not good enough. It doesn't
> explicitly says that rechartering would be needed, it seems to imply the
> opposite.
> It is also not clear to me what can be described as "non-mechanism
> proposals related to SASL and the GSS-API". If we are talking about SASL
> protocol profiles, then we should say that.

I don't think it's talking about SASL protocol profiles.  It's talking 
about proposals related to SASL and GSS-API, other than mechanisms.  In 
other words, we're not restricted to considering proposals for new 
mechanisms; we can also consider proposals to do things like adding 
mechanism attribute query to GSS-API or adding the PRF or channel binding 
abstractions to SASL, or whatever else comes along.

I do think it should be in scope for the WG to review and provide expert 
advice on any work which adds SASL or GSS-API support to a new or existing 
protocol.  However, actually _doing_ such work should be explicitly out of 
scope, as that should happen in the appropriate WG for the application 
protocol in question.

-- Jeff

From hartmans@painless-security.com  Wed Jun 16 13:31:53 2010
Return-Path: <hartmans@painless-security.com>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C50E28C190; Wed, 16 Jun 2010 13:31:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.026
X-Spam-Level: 
X-Spam-Status: No, score=-1.026 tagged_above=-999 required=5 tests=[AWL=-1.361, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eohXenAb6O3H; Wed, 16 Jun 2010 13:31:06 -0700 (PDT)
Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 87EC43A6986; Wed, 16 Jun 2010 13:30:36 -0700 (PDT)
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id DA52E20394; Wed, 16 Jun 2010 16:30:36 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E0EC940D4; Wed, 16 Jun 2010 16:30:25 -0400 (EDT)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: ietf@ietf.org, emu@ietf.org, kitten@ietf.org, moonshot-community@jiscmail.ac.uk, saag@ietf.org
Subject: Federated Authentication BOF at IETF 78
mail-copies-to: never
mail-followups-to: moonshot-community@jiscmail.ac.uk
Date: Wed, 16 Jun 2010 16:30:25 -0400
Message-ID: <tsleig6ra8u.fsf@mit.edu>
User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Jun 2010 20:31:54 -0000

Hi.  I'd like to announce that there will be a BOF on federated
authentication beyond the web at IETF 78.  we'd like to form a working
group to standardize protocols for federated access to applications that
are not browser based.  Targets include think client applications and
some machine-to-machine authentication use cases.  At this point we have
not focused on requirements imposed by RAI applications.

You can see draft specs at
http://www.project-moonshot.org/specifications 
There is a BOF agenda at http://www.project-moonshot.org/bof/agenda 

We encourage you to join our mailing list, see
http://jiscmail.ac.uk/cgi-bin/webadmin?LIST=MOONSHOT-COMMUNITY .  To the
extent we're able we'd love to collect comments or things people will
want to discuss at the BOF now.  Hopefully we can get as much as
possible out of the way on the list and have a very productive session!
We hope to see you there.

From shawn.emery@oracle.com  Thu Jun 17 17:44:42 2010
Return-Path: <shawn.emery@oracle.com>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D1C93A659B; Thu, 17 Jun 2010 17:44:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.299
X-Spam-Level: 
X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bTXJGWYVgiyr; Thu, 17 Jun 2010 17:44:41 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 1E9393A67A2; Thu, 17 Jun 2010 17:44:41 -0700 (PDT)
Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o5I0iij4028219 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 18 Jun 2010 00:44:45 GMT
Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o5HKKKk0014638; Fri, 18 Jun 2010 00:44:43 GMT
Received: from abhmt020.oracle.com by acsmt354.oracle.com with ESMTP id 354165281276821849; Thu, 17 Jun 2010 17:44:09 -0700
Received: from [129.150.48.15] (/129.150.48.15) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 17 Jun 2010 17:44:09 -0700
Message-ID: <4C1AC158.8090009@oracle.com>
Date: Thu, 17 Jun 2010 18:44:08 -0600
From: Shawn Emery <shawn.emery@oracle.com>
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1
MIME-Version: 1.0
To: Alexey Melnikov <alexey.melnikov@isode.com>
Subject: Re: [sasl] Kitten Recharter
References: <4C04B9FE.2090804@oracle.com> <4C12750D.4030904@isode.com>
In-Reply-To: <4C12750D.4030904@isode.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Auth-Type: Internal IP
X-Source-IP: acsinet15.oracle.com [141.146.126.227]
X-CT-RefId: str=0001.0A090204.4C1AC17E.0001:SCFMA922111,ss=1,fgs=0
Cc: kitten@ietf.org, sasl@ietf.org
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Jun 2010 00:44:42 -0000

On 06/11/10 11:40 AM, Alexey Melnikov wrote:
> Shawn Emery wrote:
>
>> Per the recent thead on "MOGGIES Proposed Charter"; I have taken 
>> suggestions by kitten/SASL WG members and created recharter text for 
>> Kitten (whilst closing SASL).  Please let me know if I missed anything.
>>
>> Shawn.
>> Kitten co-chair.
>
> Hi Sean,
> Thanks for the updated version. This looks much better.

Thanks.

> Some additional comments inline.
>
>> Kitten (Common Authentication Technology Next Generation)
>>
>> <snip>
>>
>> * Provide a more programmer friendly interface for application 
>> developers.
>>
>>
> This point is a bit vague. Do we actually need this as an explicit goal?

Do you want more details on how this will be accomplished?  For example:

* Provide a more programmer friendly GSS-API for application 
developers.  This could include reducing the number of interface 
parameters, eliminating those whose values' are commonly used.

<snip>
>> This WG should review proposals for new SASL and GSS-API mechanisms.  
>> The WG
>> should also review non-mechanism proposals related to SASL and the 
>> GSS-API.
>>
> I think this is a bit too open-ended for IESG. I would have asked 
> about that if I were asked to review such charter ;-).
>
> To be frank, I would delete these 2 sentences, or say the exactly 
> opposite: other proposals would require rechartering. However chairs 
> always have some flexibility in allowing conversations on related 
> topics, as long as this doesn't compromise progress on major deliverables.

I've read the follow-up thread between you and Hutzelman, and concluded 
that the following clarification should be made:

This WG should review proposals for new SASL and GSS-API mechanisms.  
The WG should also review non-mechanism proposals related to SASL and 
the GSS-API.  However, work that adds SASL or GSS-API support in 
application protocols should be handled by the application's WG.

Shawn.
--

From jhutz@cmu.edu  Thu Jun 17 18:22:38 2010
Return-Path: <jhutz@cmu.edu>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 993093A6877; Thu, 17 Jun 2010 18:22:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.612
X-Spam-Level: 
X-Spam-Status: No, score=-4.612 tagged_above=-999 required=5 tests=[AWL=-0.427, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0BxxxcmGfYNs; Thu, 17 Jun 2010 18:22:35 -0700 (PDT)
Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by core3.amsl.com (Postfix) with ESMTP id 47CE23A63CB; Thu, 17 Jun 2010 18:22:35 -0700 (PDT)
Received: from LYSITHEA.FAC.CS.CMU.EDU (LYSITHEA.FAC.CS.CMU.EDU [128.2.172.62]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o5I1McV1024508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Jun 2010 21:22:39 -0400 (EDT)
Date: Thu, 17 Jun 2010 21:22:38 -0400
From: Jeffrey Hutzelman <jhutz@cmu.edu>
To: Shawn Emery <shawn.emery@oracle.com>, Alexey Melnikov <alexey.melnikov@isode.com>
Subject: Re: [sasl] Kitten Recharter
Message-ID: <685B4ECEA1A018F865B69F0D@lysithea.fac.cs.cmu.edu>
In-Reply-To: <31094_1276821891_o5I0io9L012053_4C1AC158.8090009@oracle.com>
References: <4C04B9FE.2090804@oracle.com> <4C12750D.4030904@isode.com> <31094_1276821891_o5I0io9L012053_4C1AC158.8090009@oracle.com>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.217.197
Cc: kitten@ietf.org, sasl@ietf.org, jhutz@cmu.edu
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Jun 2010 01:22:39 -0000

--On Thursday, June 17, 2010 06:44:08 PM -0600 Shawn Emery 
<shawn.emery@oracle.com> wrote:

> On 06/11/10 11:40 AM, Alexey Melnikov wrote:
>> Shawn Emery wrote:
>>
>>> Per the recent thead on "MOGGIES Proposed Charter"; I have taken
>>> suggestions by kitten/SASL WG members and created recharter text for
>>> Kitten (whilst closing SASL).  Please let me know if I missed anything.
>>>
>>> Shawn.
>>> Kitten co-chair.
>>
>> Hi Sean,
>> Thanks for the updated version. This looks much better.
>
> Thanks.
>
>> Some additional comments inline.
>>
>>> Kitten (Common Authentication Technology Next Generation)
>>>
>>> <snip>
>>>
>>> * Provide a more programmer friendly interface for application
>>> developers.
>>>
>>>
>> This point is a bit vague. Do we actually need this as an explicit goal?
>
> Do you want more details on how this will be accomplished?  For example:
>
> * Provide a more programmer friendly GSS-API for application developers.
> This could include reducing the number of interface parameters,
> eliminating those whose values' are commonly used.
>
> <snip>
>>> This WG should review proposals for new SASL and GSS-API mechanisms.
>>> The WG
>>> should also review non-mechanism proposals related to SASL and the
>>> GSS-API.
>>>
>> I think this is a bit too open-ended for IESG. I would have asked
>> about that if I were asked to review such charter ;-).
>>
>> To be frank, I would delete these 2 sentences, or say the exactly
>> opposite: other proposals would require rechartering. However chairs
>> always have some flexibility in allowing conversations on related
>> topics, as long as this doesn't compromise progress on major
>> deliverables.
>
> I've read the follow-up thread between you and Hutzelman, and concluded
> that the following clarification should be made:
>
> This WG should review proposals for new SASL and GSS-API mechanisms.  The
> WG should also review non-mechanism proposals related to SASL and the
> GSS-API.  However, work that adds SASL or GSS-API support in application
> protocols should be handled by the application's WG.

To the first sentence, add "but may take on work on such mechanisms only 
through a revision of this charter".  Then I think you'll have captured the 
gist of the discussion.

-- Jeff



From alexey.melnikov@isode.com  Fri Jun 18 01:47:48 2010
Return-Path: <alexey.melnikov@isode.com>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DBAF3A6A11; Fri, 18 Jun 2010 01:47:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.66
X-Spam-Level: 
X-Spam-Status: No, score=-1.66 tagged_above=-999 required=5 tests=[AWL=0.939,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tO6Q3+au9yyj; Fri, 18 Jun 2010 01:47:46 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 4B8D13A6A13; Fri, 18 Jun 2010 01:47:46 -0700 (PDT)
Received: from [188.28.32.193] (188.28.32.193.threembb.co.uk [188.28.32.193])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <TBsypgAJf190@rufus.isode.com>; Fri, 18 Jun 2010 09:47:35 +0100
Message-ID: <4C1B32A2.4090109@isode.com>
Date: Fri, 18 Jun 2010 09:47:30 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Jeffrey Hutzelman <jhutz@cmu.edu>
Subject: Re: [sasl] Kitten Recharter
References: <4C04B9FE.2090804@oracle.com> <4C12750D.4030904@isode.com> <31094_1276821891_o5I0io9L012053_4C1AC158.8090009@oracle.com> <685B4ECEA1A018F865B69F0D@lysithea.fac.cs.cmu.edu>
In-Reply-To: <685B4ECEA1A018F865B69F0D@lysithea.fac.cs.cmu.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: kitten@ietf.org, sasl@ietf.org
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Jun 2010 08:47:48 -0000

Jeffrey Hutzelman wrote:

> --On Thursday, June 17, 2010 06:44:08 PM -0600 Shawn Emery 
> <shawn.emery@oracle.com> wrote:
>
>> On 06/11/10 11:40 AM, Alexey Melnikov wrote:
>>
>>> Shawn Emery wrote:
>>
 [...]

>>>> <snip>
>>>>
>>>> * Provide a more programmer friendly interface for application
>>>> developers.
>>>
>>> This point is a bit vague. Do we actually need this as an explicit 
>>> goal?
>>
>> Do you want more details on how this will be accomplished?  For example:
>>
>> * Provide a more programmer friendly GSS-API for application developers.
>> This could include reducing the number of interface parameters,
>> eliminating those whose values' are commonly used.
>
*not* commonly used?

Yes, something like that.

>> <snip>
>>
>>>> This WG should review proposals for new SASL and GSS-API mechanisms.
>>>> The WG
>>>> should also review non-mechanism proposals related to SASL and the
>>>> GSS-API.
>>>
>>> I think this is a bit too open-ended for IESG. I would have asked
>>> about that if I were asked to review such charter ;-).
>>>
>>> To be frank, I would delete these 2 sentences, or say the exactly
>>> opposite: other proposals would require rechartering. However chairs
>>> always have some flexibility in allowing conversations on related
>>> topics, as long as this doesn't compromise progress on major
>>> deliverables.
>>
>> I've read the follow-up thread between you and Hutzelman, and concluded
>> that the following clarification should be made:
>>
>> This WG should review proposals for new SASL and GSS-API mechanisms.  
>> The
>> WG should also review non-mechanism proposals related to SASL and the
>> GSS-API.  However, work that adds SASL or GSS-API support in application
>> protocols should be handled by the application's WG.
>
> To the first sentence, add "but may take on work on such mechanisms 
> only through a revision of this charter".  Then I think you'll have 
> captured the gist of the discussion.

+1.


From lha@kth.se  Fri Jun 18 12:04:20 2010
Return-Path: <lha@kth.se>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0A003A68A0 for <kitten@core3.amsl.com>; Fri, 18 Jun 2010 12:04:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.459
X-Spam-Level: 
X-Spam-Status: No, score=-4.459 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rmRi3lSzK+Sf for <kitten@core3.amsl.com>; Fri, 18 Jun 2010 12:04:20 -0700 (PDT)
Received: from smtp-2.sys.kth.se (smtp-2.sys.kth.se [130.237.32.160]) by core3.amsl.com (Postfix) with ESMTP id CA92C3A67D4 for <kitten@ietf.org>; Fri, 18 Jun 2010 12:04:19 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 94DAD14C022; Fri, 18 Jun 2010 21:03:54 +0200 (CEST)
X-Virus-Scanned: by amavisd-new at kth.se
Received: from smtp-2.sys.kth.se ([127.0.0.1]) by localhost (smtp-2.sys.kth.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 6YFiAvXEAE1q; Fri, 18 Jun 2010 21:03:50 +0200 (CEST)
X-KTH-Auth: lha [2620:0:1b00:1121:81ec:1fd5:e34c:5dd9]
X-KTH-mail-from: lha@kth.se
Received: from [IPv6:2620::1b00:1121:81ec:1fd5:e34c:5dd9] (unknown [IPv6:2620:0:1b00:1121:81ec:1fd5:e34c:5dd9]) by smtp-2.sys.kth.se (Postfix) with ESMTP id E178614DC41; Fri, 18 Jun 2010 21:03:49 +0200 (CEST)
Subject: Re: extensions-iana registry
Mime-Version: 1.0 (Apple Message framework v1150)
Content-Type: multipart/signed; boundary=Apple-Mail-29-80423516; protocol="application/pkcs7-signature"; micalg=sha1
From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= <lha@kth.se>
In-Reply-To: <4C0ECFB9.7080900@oracle.com>
Date: Fri, 18 Jun 2010 12:04:10 -0700
Message-Id: <C861980A-78B8-4730-91BC-882A93243A05@kth.se>
References: <4C0ECFB9.7080900@oracle.com>
To: Shawn Emery <shawn.emery@oracle.com>
X-Mailer: Apple Mail (2.1150)
Cc: "kitten@ietf.org" <kitten@ietf.org>
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Jun 2010 19:04:21 -0000

--Apple-Mail-29-80423516
Content-Type: multipart/alternative;
	boundary=Apple-Mail-28-80423463


--Apple-Mail-28-80423463
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


8 jun 2010 kl. 16:18 skrev Shawn Emery:

>=20
> Based on IANA feed-back; the WG needs to reach consensus on how the =
GSS-API extensions are to be registered.  Options proposed:
>=20
>     1. single GSS-API name-space registry
>     2. separate registry - symbolic and constant registries
>     3. registry per programming language
>     4. multiple registries


How would each of these look like ? Esp the first one.

Love


--Apple-Mail-28-80423463
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>8 jun 2010 kl. 16:18 skrev Shawn Emery:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<div text="#000000" bgcolor="#ffffff">
<font size="+1"><tt><br>
Based on IANA feed-back; the WG needs to reach consensus on how the
GSS-API extensions are to be registered.&nbsp; Options proposed:<br>
<br>
&nbsp;&nbsp;&nbsp; 1. single GSS-API name-space registry<br></tt></font></div></blockquote><blockquote type="cite"><div text="#000000" bgcolor="#ffffff"><font size="+1"><tt>&nbsp;&nbsp; &nbsp;2. separate registry - symbolic and constant registries<br>
&nbsp;&nbsp;&nbsp; 3. registry per programming language<br>
&nbsp;&nbsp;&nbsp; 4. multiple registries<br></tt></font></div></blockquote><div><br></div><div><br></div><div>How would each of these look like ? Esp the first one.</div><div><br></div><div>Love</div><div><br></div></div></body></html>
--Apple-Mail-28-80423463--

--Apple-Mail-29-80423516
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKHjCCBMww
ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow
gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl
cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG
A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV
zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl
Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB
L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g
J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC
AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX
ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB
BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl
bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk
oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi
bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G
CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y
o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS
KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFSjCCBDKgAwIBAgIQXzoqZKwXOvvxymIt
KZOH2DANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ
bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1
c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u
YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi
c2NyaWJlciBDQSAtIEcyMB4XDTEwMDQwMTAwMDAwMFoXDTExMDQwMTIzNTk1OVowggETMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp
dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxHzAdBgNVBAMUFkxvdmUgSPZy
bnF1aXN0IMVzdHJhbmQxGTAXBgkqhkiG9w0BCQEWCmxoYUBrdGguc2UwggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQDExzsEl8kHec1Flo6WDOR55uZ9e526lJpegh+pnb7kUoiMc3+L+oTM
HbAQs4hOjUV1+kwPsdnBFolLJ6CR5lkwyZBHjzdbHMXnxh2czeIDjaD1lWxnEPTPefGZ0LEUgbix
pThFfdW6wA9z43J/1VsZeQU8ZEY50ZHSkhjM+1PFdgjL5RJv2j7sFgHVr7P2mvEFNTy+PCKW/1Gj
agjSehjXvFCqs8O9Was/dEdQ8pyT216VBPi+S77qcbGYAH6yqQ0XqiF0ogBZE8jKnkUDhFZz60gC
QqlClW6i7iczbalEjnvEx3z+tsUzIK2UGrwqv0BmCg0qz7T1RZgbTowy0D/BAgMBAAGjgcwwgckw
CQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz
Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwME
BggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZl
cmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAF01Bxe7vzqE
/pJ4hZ30dqxJDSjHVOSmKdAkHg/i0uKLbIs7C+RYDlOptqlrmXwE40cTjFk26XVimzYayfHev/mA
lgqxPlQC28zhQTHi1VtwVUXwslphpGRJk/WK8esXu61gGgjEErcGtNB7G4KfymM3yQgIudUM4cZb
Z+5Et5fzLd9WLHIqd5vb2IbC4Q/dg00lmIWmikQtjt9mi1EaUUIAiySzjI5e6Akq8uyeOw+7ccPg
WZOPPfif8D0z0WDXpSwCyTo9SG/f1gvwPkuxfJ4pilIBVBPkS2zAb7a5ZM1xXdLIjbboFCLCzJhk
VsK40ZdKTdMvp9t/M1O1D/b7U+MxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNV
BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD
VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe
MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx
IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBfOipkrBc6+/HKYi0pk4fYMAkGBSsOAwIa
BQCgggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDYxODE5
MDQxMFowIwYJKoZIhvcNAQkEMRYEFAppvkULUUVpZSQejFcXOhURUAF5MIIBAwYJKwYBBAGCNxAE
MYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT
FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov
L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0
ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g
RzICEF86KmSsFzr78cpiLSmTh9gwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMC
VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw
YSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2ln
biBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBfOipkrBc6+/HKYi0pk4fY
MA0GCSqGSIb3DQEBAQUABIIBAKo/4gSeUTWuuyk0AwcuRD3H+iXqjg30RWF8HJYSM6h1NbV0RITQ
kRMre6LpTMEQMH8Vm0RIzN8bJfdhrQ9GrFhlDNHEVgNR7JHIORAp3yfJkkWNhvu3t3o3FUgib21v
IsniOxbngNZzyokynGRecqPi6KVNJVgkszwk9QklPDeRmo6oZSmSCKnt1Einv8S+hgiXuIu/1KIk
vWIF8gK04uNDoFAQd5bOpfW+IT0HF1ptS7Rvu0rzMF+Ql/HASZovto5x6joWQ4xQwEC6kaD/cUFk
RLwhwwPikC61wGZc0DZnVs8HqKMv5XCW1F1BjxVbMxpsb3impGusjVVYLGgqkkAAAAAAAAA=

--Apple-Mail-29-80423516--

From shawn.emery@oracle.com  Tue Jun 22 22:55:52 2010
Return-Path: <shawn.emery@oracle.com>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDA673A6A43 for <kitten@core3.amsl.com>; Tue, 22 Jun 2010 22:55:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.194
X-Spam-Level: 
X-Spam-Status: No, score=-5.194 tagged_above=-999 required=5 tests=[AWL=-0.755, BAYES_20=-0.74, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OHZxsxC4s785 for <kitten@core3.amsl.com>; Tue, 22 Jun 2010 22:55:44 -0700 (PDT)
Received: from rcsinet14.oracle.com (rcsinet14.oracle.com [148.87.113.126]) by core3.amsl.com (Postfix) with ESMTP id 61A453A6A4C for <kitten@ietf.org>; Tue, 22 Jun 2010 22:55:24 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by rcsinet14.oracle.com (Sentrion-MP-4.0.0/Sentrion-MP-4.0.0) with ESMTP id o5N5rNM5022357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <kitten@ietf.org>; Wed, 23 Jun 2010 05:53:23 GMT
Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o5N5qprp002574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 23 Jun 2010 05:52:52 GMT
Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o5MMSxPA014915; Wed, 23 Jun 2010 05:52:50 GMT
Received: from abhmt014.oracle.com by acsmt355.oracle.com with ESMTP id 349125511277272354; Tue, 22 Jun 2010 22:52:34 -0700
Received: from [129.150.48.15] (/129.150.48.15) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 22 Jun 2010 22:52:34 -0700
Message-ID: <4C21A121.30603@oracle.com>
Date: Tue, 22 Jun 2010 23:52:33 -0600
From: Shawn Emery <shawn.emery@oracle.com>
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Love_H=F6rnquist_=C5strand?= <lha@kth.se>
Subject: Re: extensions-iana registry
References: <4C0ECFB9.7080900@oracle.com> <C861980A-78B8-4730-91BC-882A93243A05@kth.se>
In-Reply-To: <C861980A-78B8-4730-91BC-882A93243A05@kth.se>
Content-Type: multipart/alternative; boundary="------------040005070809010907000307"
X-Auth-Type: Internal IP
X-Source-IP: rcsinet15.oracle.com [148.87.113.117]
X-CT-RefId: str=0001.0A090201.4C21A134.01F6:SCFMA4539811,ss=1,fgs=0
Cc: "kitten@ietf.org" <kitten@ietf.org>
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Jun 2010 05:55:53 -0000

This is a multi-part message in MIME format.
--------------040005070809010907000307
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

On 06/18/10 01:04 PM, Love Hörnquist Åstrand wrote:
>
> 8 jun 2010 kl. 16:18 skrev Shawn Emery:
>
>>
>> Based on IANA feed-back; the WG needs to reach consensus on how the 
>> GSS-API extensions are to be registered.  Options proposed:
>>
>>     1. single GSS-API name-space registry
>>     2. separate registry - symbolic and constant registries
>>     3. registry per programming language
>>     4. multiple registries
>
>
> How would each of these look like ? Esp the first one.

1. single GSS-API name-space registry
A type that does not have separate symbolic and constant registries.  In 
other words, not 2 or 3.

2. separate registry - symbolic and constant registries
A constant registry contains entries specific to constant name-values.
A symbolic registry contains entries for non-constants, e.g. function 
names, name types, etc.

3. registry per programming language
Registries partitioned by programming language, for example:
Registry a. contains entries for bindings in C.
Registry b. contains entries for binging in Java.
...
Entries in a. and b. do not have to be unique, but all entries in each 
of the language registries should be specified.

4. multiple registries
Multiple registries is really 2 or 3.

Perhaps we should put an example with different name-space types in the 
appendix for the single name-space registry?  Would this help clarify?

Shawn.
--

--------------040005070809010907000307
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html; charset=ISO-8859-1"
 http-equiv="Content-Type">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
On 06/18/10 01:04 PM, Love H&ouml;rnquist &Aring;strand wrote:
<blockquote cite="mid:C861980A-78B8-4730-91BC-882A93243A05@kth.se"
 type="cite"><br>
  <div>
  <div>8 jun 2010 kl. 16:18 skrev Shawn Emery:</div>
  <br class="Apple-interchange-newline">
  <blockquote type="cite">
    <div text="#000000" bgcolor="#ffffff"><font size="+1"><tt><br>
Based on IANA feed-back; the WG needs to reach consensus on how the
GSS-API extensions are to be registered.&nbsp; Options proposed:<br>
    <br>
&nbsp;&nbsp;&nbsp; 1. single GSS-API name-space registry<br>
    </tt></font></div>
  </blockquote>
  <blockquote type="cite">
    <div text="#000000" bgcolor="#ffffff"><font size="+1"><tt>&nbsp;&nbsp; &nbsp;2.
separate registry - symbolic and constant registries<br>
&nbsp;&nbsp;&nbsp; 3. registry per programming language<br>
&nbsp;&nbsp;&nbsp; 4. multiple registries<br>
    </tt></font></div>
  </blockquote>
  <div><br>
  </div>
  <div><br>
  </div>
  <div>How would each of these look like ? Esp the first one.</div>
  </div>
</blockquote>
<br>
1.<font size="+1"> </font><small><font size="+1"><small>single GSS-API
name-space registry</small></font></small><br>
A type that does not have separate symbolic and constant registries.&nbsp;
In other words, not 2 or 3.<br>
<br>
2. separate registry - symbolic and constant registries<br>
A constant registry contains entries specific to constant name-values.<br>
A symbolic registry contains entries for non-constants, e.g. function
names, name types, etc.<br>
<br>
3<font size="+1">. </font><small><font size="+1"><small>registry per
programming language</small></font></small><br>
Registries partitioned by programming language, for example:<br>
Registry a. contains entries for bindings in C.<br>
Registry b. contains entries for binging in Java.<br>
...<br>
Entries in a. and b. do not have to be unique, but all entries in each
of the language registries should be specified.<br>
<br>
4. multiple registries<br>
Multiple registries is really 2 or 3.<br>
<br>
Perhaps we should put an example with different name-space types in the
appendix for the single name-space registry?&nbsp; Would this help clarify?<br>
<br>
Shawn.<br>
--<br>
</body>
</html>

--------------040005070809010907000307--

From shawn.emery@oracle.com  Tue Jun 22 22:56:00 2010
Return-Path: <shawn.emery@oracle.com>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE6373A6A48 for <kitten@core3.amsl.com>; Tue, 22 Jun 2010 22:56:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.122
X-Spam-Level: 
X-Spam-Status: No, score=-6.122 tagged_above=-999 required=5 tests=[AWL=0.476,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4qzYHzoYSj3F for <kitten@core3.amsl.com>; Tue, 22 Jun 2010 22:55:53 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id F02913A6A41 for <kitten@ietf.org>; Tue, 22 Jun 2010 22:55:46 -0700 (PDT)
Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o5N5tW2q008415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <kitten@ietf.org>; Wed, 23 Jun 2010 05:55:34 GMT
Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o5N24Hkt013936 for <kitten@ietf.org>; Wed, 23 Jun 2010 05:55:31 GMT
Received: from abhmt002.oracle.com by acsmt354.oracle.com with ESMTP id 365903251277272504; Tue, 22 Jun 2010 22:55:04 -0700
Received: from [129.150.48.15] (/129.150.48.15) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 22 Jun 2010 22:55:03 -0700
Message-ID: <4C21A1B7.60703@oracle.com>
Date: Tue, 22 Jun 2010 23:55:03 -0600
From: Shawn Emery <shawn.emery@oracle.com>
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1
MIME-Version: 1.0
To: "kitten@ietf.org" <kitten@ietf.org>
Subject: Fwd: Fwd: Nomcom 2010-2011: Second Call for Volunteers
Content-Type: multipart/alternative; boundary="------------010801070305050907040601"
X-Auth-Type: Internal IP
X-Source-IP: acsinet15.oracle.com [141.146.126.227]
X-CT-RefId: str=0001.0A090202.4C21A1D6.00D5:SCFMA922111,ss=1,fgs=0
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Jun 2010 05:56:01 -0000

This is a multi-part message in MIME format.
--------------010801070305050907040601
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit



-------- Original Message --------
Subject: 	Fwd: Nomcom 2010-2011: Second Call for Volunteers
Date: 	Tue, 22 Jun 2010 18:41:58 -0400
From: 	Russ Housley <housley@vigilsec.com>
To: 	IETF WG Chairs <wgchairs@ietf.org>



Some WG Chairs have helped spread the word by posting this call for
participants to their mail list.  If you have not already done so,
please pass the word.

Russ

>  From: NomCom Chair<nomcom-chair@ietf.org>
>  Date: June 21, 2010 5:49:08 PM EDT
>  To: IETF Announcement list<ietf-announce@ietf.org>
>  Subject: Nomcom 2010-2011: Second Call for Volunteers
>
>  Hi all,
>
>  This is the Second call for Volunteers for the 2010-11 nomcom.  We are
>  just about halfway through the volunteer period so if you are
>  considering
>  volunteering please do so very soon.
>
>  I am pleased to report that we have 29 volunteers thus far whose
>  qualifications have been confirmed by the secretariat. I have notified
>  each of these volunteers by email.
>
>  If you volunteered before 08:00 PDT (15:00 UTC) on June 21 to serve
>  as a
>  voting member and have not received a confirmation email from me,
>  please
>  re-submit and bring to my attention right away!
>
>  However, we need many more volunteers.  You have until 17:00 PDT
>  (24:00
>  UTC) on July 8, 2010 to volunteer for nomcom but it is much better
>  if you
>  volunteer as early as possible.  The more volunteers, the better
>  chance we
>  have of choosing a random yet representative cross section of the IETF
>  pouplation.
>
>  As a reminder, volunteers must have attended 3 of the past 5 IETF
>  meetings - per RFC 3777, which means 3 of the following meetings:
>  IETF-73,
>  IETF-74, IETF-75, IETF-76 and IETF-77.  If you qualify, and are
>  willing to
>  forgo appointment to any of the positions for which the nominating
>  committee is responsible, please volunteer.
>
>  The 10 nominating committee members are selected randomly from a
>  pool of
>  volunteers.  The details of the operation of nomcom may be found in
>  RFC
>  3777.  The process on how to volunteer for nomcom is in the initial
>  announcement:  https://datatracker.ietf.org/ann/nomcom/2330/
>
>  The lists of open positions and people whose terms end in March 2011
>  and
>  thus the positions for which the nominating committee is responsible
>  are
>  summarized in the initial announcement:
>  https://datatracker.ietf.org/ann/nomcom/2330/
>
>  The 29 volunteers who have thus far been qualified by the secretariat
>  are:
>
>  Fred Baker, Cisco Systems
>
>  Stephan Wenger, Vidyo, Inc.
>
>  Marc Blanchet, Viagenie
>
>  Lixia Zhang, UCLA
>
>  John Drake, Juniper Networks
>
>  Ole Troan, Cisco
>
>  Jiankang Yao, CNNIC
>
>  Wassim Haddad, Ericsson
>
>  Yi Zhao, Huawei USA
>
>  Teemu Savolainen, Nokia
>
>  Jouni Korhonen, Nokia Siemens Networks
>
>  Mehmet Ersue, Nokia Siemens Networks
>
>  Christian Schmidt, Nokia Siemens Networks
>
>  Stephen Hanna, Juniper Networks
>
>  Suresh Krishnan, Ericsson
>
>  Eric Gray, Ericsson
>
>  David Sinicrope, Ericsson
>
>  Jan Melen, Ericsson
>
>  Richard Barnes, BBN Technologies
>
>  Hugo Salgado Hernandez, NIC Chile
>
>  Ning Zong, Huawei Technologies
>
>  Qin Wu, Huawei Technologies
>
>  Karen Seo, BBN Technologies
>
>  Haibin Song, Huawei Technologies
>
>  Susan Hares, Huawei Technologies
>
>  Tony Hansen. AT&T Labs
>
>  Fuqing Huang, Huawei Technologies Co., Ltd.
>
>  Huub van Helvoort, Huawei Technologies
>
>  Miya Kohno, Juniper Networks
>
>  The primary activity for this nomcom will begin just prior to
>  IETF-78 in
>  Maastricht and should be completed in early January 2011.  The
>  nomcom will
>  be collecting requirements from the community, as well as talking to
>  candidates and to community members about candidates. There will be
>  weekly
>  conference calls to ensure progress. Thus, being a nomcom member does
>  require some time commitment.
>
>  While, there is no requirement in RFC 3777 that a participant attend
>  IETF
>  meetings while serving on nomcom, please consider that during the IETF
>  meetings, people that do not attend would be expected to remotely
>  participate during the day in the time zones of the meeting
>  locations -
>  Maastricht at the end of July and Beijing in November.
>
>  If you are not yet sure you would like to volunteer, please consider
>  that
>  nomcom members play a very important role in shaping the leadership
>  of the
>  IETF.  Ensuring the leadership of the IETF is fair and balanced and
>  comprised of those who can lead the IETF in the right direction is an
>  important responsibility that rests on the IETF participants at large.
>  Volunteering for the nomcom is a good way of contributing in that
>  direction.
>
>  Please volunteer by sending an email before:
>  17:00 PDT (24:00 UTC) July 8, 2010 as follows:
>
>  To: nomcom-chair@ietf.org
>  Subject: Nomcom 2010-11 Volunteer
>
>  Please include the following information in the body:
>
>  <Your Full Name>   // As you enter in the IETF Registration Form,
>                   // First/Given name followed by Last/Family Name
>
>  <Current Primary Affiliation>
>                   // typically what goes in the Company field
>                   // in the IETF Registration Form
>
>  [<all email addresses used to Register for the past 5 IETF meetings>]
>  <Preferred email address>   //
>
>  <Telephone number>          // For confirmation if selected
>
>  Please expect an email response from me within 3 days stating
>  whether or
>  not you are qualified.  If you don't receive a response, please re-
>  send
>  your email with the tag "Duplicate:" added to the subject line.
>
>  Thank you and I hope to hear from you,
>
>  Thomas Walsh
>  Chair, Nomcom 2010-11
>  Email: nomcom-chair@ietf.org
>
>
>  _______________________________________________
>  IETF-Announce mailing list
>  IETF-Announce@ietf.org
>  https://www.ietf.org/mailman/listinfo/ietf-announce
>




--------------010801070305050907040601
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>

<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body text="#000000" bgcolor="#ffffff">
<br>
<br>
-------- Original Message --------
<table class="moz-email-headers-table" cellpadding="0" cellspacing="0"
 border="0">
  <tbody>
    <tr>
      <th nowrap="nowrap" valign="BASELINE" align="RIGHT">Subject: </th>
      <td>Fwd: Nomcom 2010-2011: Second Call for Volunteers</td>
    </tr>
    <tr>
      <th nowrap="nowrap" valign="BASELINE" align="RIGHT">Date: </th>
      <td>Tue, 22 Jun 2010 18:41:58 -0400</td>
    </tr>
    <tr>
      <th nowrap="nowrap" valign="BASELINE" align="RIGHT">From: </th>
      <td>Russ Housley <a class="moz-txt-link-rfc2396E" href="mailto:housley@vigilsec.com">&lt;housley@vigilsec.com&gt;</a></td>
    </tr>
    <tr>
      <th nowrap="nowrap" valign="BASELINE" align="RIGHT">To: </th>
      <td>IETF WG Chairs <a class="moz-txt-link-rfc2396E" href="mailto:wgchairs@ietf.org">&lt;wgchairs@ietf.org&gt;</a></td>
    </tr>
  </tbody>
</table>
<br>
<br>
<pre>Some WG Chairs have helped spread the word by posting this call for
participants to their mail list.  If you have not already done so,
please pass the word.

Russ

&gt; From: NomCom Chair <a class="moz-txt-link-rfc2396E" href="mailto:nomcom-chair@ietf.org">&lt;nomcom-chair@ietf.org&gt;</a>
&gt; Date: June 21, 2010 5:49:08 PM EDT
&gt; To: IETF Announcement list <a class="moz-txt-link-rfc2396E" href="mailto:ietf-announce@ietf.org">&lt;ietf-announce@ietf.org&gt;</a>
&gt; Subject: Nomcom 2010-2011: Second Call for Volunteers
&gt;
&gt; Hi all,
&gt;
&gt; This is the Second call for Volunteers for the 2010-11 nomcom.  We are
&gt; just about halfway through the volunteer period so if you are  
&gt; considering
&gt; volunteering please do so very soon.
&gt;
&gt; I am pleased to report that we have 29 volunteers thus far whose
&gt; qualifications have been confirmed by the secretariat. I have notified
&gt; each of these volunteers by email.
&gt;
&gt; If you volunteered before 08:00 PDT (15:00 UTC) on June 21 to serve  
&gt; as a
&gt; voting member and have not received a confirmation email from me,  
&gt; please
&gt; re-submit and bring to my attention right away!
&gt;
&gt; However, we need many more volunteers.  You have until 17:00 PDT  
&gt; (24:00
&gt; UTC) on July 8, 2010 to volunteer for nomcom but it is much better  
&gt; if you
&gt; volunteer as early as possible.  The more volunteers, the better  
&gt; chance we
&gt; have of choosing a random yet representative cross section of the IETF
&gt; pouplation.
&gt;
&gt; As a reminder, volunteers must have attended 3 of the past 5 IETF
&gt; meetings - per RFC 3777, which means 3 of the following meetings:  
&gt; IETF-73,
&gt; IETF-74, IETF-75, IETF-76 and IETF-77.  If you qualify, and are  
&gt; willing to
&gt; forgo appointment to any of the positions for which the nominating
&gt; committee is responsible, please volunteer.
&gt;
&gt; The 10 nominating committee members are selected randomly from a  
&gt; pool of
&gt; volunteers.  The details of the operation of nomcom may be found in  
&gt; RFC
&gt; 3777.  The process on how to volunteer for nomcom is in the initial
&gt; announcement:  <a class="moz-txt-link-freetext" href="https://datatracker.ietf.org/ann/nomcom/2330/">https://datatracker.ietf.org/ann/nomcom/2330/</a>
&gt;
&gt; The lists of open positions and people whose terms end in March 2011  
&gt; and
&gt; thus the positions for which the nominating committee is responsible  
&gt; are
&gt; summarized in the initial announcement:
&gt; <a class="moz-txt-link-freetext" href="https://datatracker.ietf.org/ann/nomcom/2330/">https://datatracker.ietf.org/ann/nomcom/2330/</a>
&gt;
&gt; The 29 volunteers who have thus far been qualified by the secretariat
&gt; are:
&gt;
&gt; Fred Baker, Cisco Systems
&gt;
&gt; Stephan Wenger, Vidyo, Inc.
&gt;
&gt; Marc Blanchet, Viagenie
&gt;
&gt; Lixia Zhang, UCLA
&gt;
&gt; John Drake, Juniper Networks
&gt;
&gt; Ole Troan, Cisco
&gt;
&gt; Jiankang Yao, CNNIC
&gt;
&gt; Wassim Haddad, Ericsson
&gt;
&gt; Yi Zhao, Huawei USA
&gt;
&gt; Teemu Savolainen, Nokia
&gt;
&gt; Jouni Korhonen, Nokia Siemens Networks
&gt;
&gt; Mehmet Ersue, Nokia Siemens Networks
&gt;
&gt; Christian Schmidt, Nokia Siemens Networks
&gt;
&gt; Stephen Hanna, Juniper Networks
&gt;
&gt; Suresh Krishnan, Ericsson
&gt;
&gt; Eric Gray, Ericsson
&gt;
&gt; David Sinicrope, Ericsson
&gt;
&gt; Jan Melen, Ericsson
&gt;
&gt; Richard Barnes, BBN Technologies
&gt;
&gt; Hugo Salgado Hernandez, NIC Chile
&gt;
&gt; Ning Zong, Huawei Technologies
&gt;
&gt; Qin Wu, Huawei Technologies
&gt;
&gt; Karen Seo, BBN Technologies
&gt;
&gt; Haibin Song, Huawei Technologies
&gt;
&gt; Susan Hares, Huawei Technologies
&gt;
&gt; Tony Hansen. AT&amp;T Labs
&gt;
&gt; Fuqing Huang, Huawei Technologies Co., Ltd.
&gt;
&gt; Huub van Helvoort, Huawei Technologies
&gt;
&gt; Miya Kohno, Juniper Networks
&gt;
&gt; The primary activity for this nomcom will begin just prior to  
&gt; IETF-78 in
&gt; Maastricht and should be completed in early January 2011.  The  
&gt; nomcom will
&gt; be collecting requirements from the community, as well as talking to
&gt; candidates and to community members about candidates. There will be  
&gt; weekly
&gt; conference calls to ensure progress. Thus, being a nomcom member does
&gt; require some time commitment.
&gt;
&gt; While, there is no requirement in RFC 3777 that a participant attend  
&gt; IETF
&gt; meetings while serving on nomcom, please consider that during the IETF
&gt; meetings, people that do not attend would be expected to remotely
&gt; participate during the day in the time zones of the meeting  
&gt; locations -
&gt; Maastricht at the end of July and Beijing in November.
&gt;
&gt; If you are not yet sure you would like to volunteer, please consider  
&gt; that
&gt; nomcom members play a very important role in shaping the leadership  
&gt; of the
&gt; IETF.  Ensuring the leadership of the IETF is fair and balanced and
&gt; comprised of those who can lead the IETF in the right direction is an
&gt; important responsibility that rests on the IETF participants at large.
&gt; Volunteering for the nomcom is a good way of contributing in that
&gt; direction.
&gt;
&gt; Please volunteer by sending an email before:
&gt; 17:00 PDT (24:00 UTC) July 8, 2010 as follows:
&gt;
&gt; To: <a class="moz-txt-link-abbreviated" href="mailto:nomcom-chair@ietf.org">nomcom-chair@ietf.org</a>
&gt; Subject: Nomcom 2010-11 Volunteer
&gt;
&gt; Please include the following information in the body:
&gt;
&gt; &lt;Your Full Name&gt;  // As you enter in the IETF Registration Form,
&gt;                  // First/Given name followed by Last/Family Name
&gt;
&gt; &lt;Current Primary Affiliation&gt;
&gt;                  // typically what goes in the Company field
&gt;                  // in the IETF Registration Form
&gt;
&gt; [&lt;all email addresses used to Register for the past 5 IETF meetings&gt;]
&gt; &lt;Preferred email address&gt;  //
&gt;
&gt; &lt;Telephone number&gt;         // For confirmation if selected
&gt;
&gt; Please expect an email response from me within 3 days stating  
&gt; whether or
&gt; not you are qualified.  If you don't receive a response, please re- 
&gt; send
&gt; your email with the tag "Duplicate:" added to the subject line.
&gt;
&gt; Thank you and I hope to hear from you,
&gt;
&gt; Thomas Walsh
&gt; Chair, Nomcom 2010-11
&gt; Email: <a class="moz-txt-link-abbreviated" href="mailto:nomcom-chair@ietf.org">nomcom-chair@ietf.org</a>
&gt;
&gt;
&gt; _______________________________________________
&gt; IETF-Announce mailing list
&gt; <a class="moz-txt-link-abbreviated" href="mailto:IETF-Announce@ietf.org">IETF-Announce@ietf.org</a>
&gt; <a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/ietf-announce">https://www.ietf.org/mailman/listinfo/ietf-announce</a>
&gt;



</pre>
</body>
</html>

--------------010801070305050907040601--

From lha@kth.se  Wed Jun 23 10:00:51 2010
Return-Path: <lha@kth.se>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB9BD3A6AB1 for <kitten@core3.amsl.com>; Wed, 23 Jun 2010 10:00:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.274
X-Spam-Level: 
X-Spam-Status: No, score=-4.274 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_20=-0.74, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VQ+sQOuQIbVh for <kitten@core3.amsl.com>; Wed, 23 Jun 2010 10:00:51 -0700 (PDT)
Received: from smtp-1.sys.kth.se (smtp-1.sys.kth.se [130.237.32.175]) by core3.amsl.com (Postfix) with ESMTP id 6820A3A6AB0 for <kitten@ietf.org>; Wed, 23 Jun 2010 10:00:50 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 64BE7155AEA; Wed, 23 Jun 2010 19:00:27 +0200 (CEST)
X-Virus-Scanned: by amavisd-new at kth.se
Received: from smtp-1.sys.kth.se ([127.0.0.1]) by localhost (smtp-1.sys.kth.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id A8SUPfBLx1Mh; Wed, 23 Jun 2010 19:00:26 +0200 (CEST)
X-KTH-Auth: lha [2620:0:1b00:1121:d56d:b16f:2c2a:deee]
X-KTH-mail-from: lha@kth.se
Received: from [IPv6:2620::1b00:1121:d56d:b16f:2c2a:deee] (unknown [IPv6:2620:0:1b00:1121:d56d:b16f:2c2a:deee]) by smtp-1.sys.kth.se (Postfix) with ESMTP id A014515700F; Wed, 23 Jun 2010 19:00:25 +0200 (CEST)
Subject: Re: extensions-iana registry
Mime-Version: 1.0 (Apple Message framework v1153)
Content-Type: multipart/signed; boundary=Apple-Mail-118-505029016; protocol="application/pkcs7-signature"; micalg=sha1
From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= <lha@kth.se>
In-Reply-To: <4C21A121.30603@oracle.com>
Date: Wed, 23 Jun 2010 10:00:55 -0700
Message-Id: <8247527F-431B-46B5-957F-406AFA822149@kth.se>
References: <4C0ECFB9.7080900@oracle.com> <C861980A-78B8-4730-91BC-882A93243A05@kth.se> <4C21A121.30603@oracle.com>
To: Shawn Emery <shawn.emery@oracle.com>
X-Mailer: Apple Mail (2.1153)
Cc: "kitten@ietf.org" <kitten@ietf.org>
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Jun 2010 17:00:51 -0000

--Apple-Mail-118-505029016
Content-Type: multipart/alternative;
	boundary=Apple-Mail-117-505028971


--Apple-Mail-117-505028971
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1


22 jun 2010 kl. 22:52 skrev Shawn Emery:

> On 06/18/10 01:04 PM, Love H=F6rnquist =C5strand wrote:
>>=20
>>=20
>> 8 jun 2010 kl. 16:18 skrev Shawn Emery:
>>=20
>>>=20
>>> Based on IANA feed-back; the WG needs to reach consensus on how the =
GSS-API extensions are to be registered.  Options proposed:
>>>=20
>>>     1. single GSS-API name-space registry
>>>     2. separate registry - symbolic and constant registries
>>>     3. registry per programming language
>>>     4. multiple registries
>>=20
>>=20
>> How would each of these look like ? Esp the first one.

I think I was more looking for examples.

For example, every time a new language is added, yet another row need to =
be added, and I'm concered how easy that is to manged and express to =
IANA what change we want to make.

I think there should be one registry for each language added and how it =
maps to the base specification language.

Love

>=20
> 1. single GSS-API name-space registry
> A type that does not have separate symbolic and constant registries.  =
In other words, not 2 or 3.
>=20
> 2. separate registry - symbolic and constant registries
> A constant registry contains entries specific to constant name-values.
> A symbolic registry contains entries for non-constants, e.g. function =
names, name types, etc.
>=20
> 3. registry per programming language
> Registries partitioned by programming language, for example:
> Registry a. contains entries for bindings in C.
> Registry b. contains entries for binging in Java.
> ...
> Entries in a. and b. do not have to be unique, but all entries in each =
of the language registries should be specified.
>=20
> 4. multiple registries
> Multiple registries is really 2 or 3.
>=20
> Perhaps we should put an example with different name-space types in =
the appendix for the single name-space registry?  Would this help =
clarify?
>=20
> Shawn.
> --


--Apple-Mail-117-505028971
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><br><div><div>22 jun 2010 kl. 22:52 skrev Shawn Emery:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div =
text=3D"#000000" bgcolor=3D"#ffffff">
On 06/18/10 01:04 PM, Love H=F6rnquist =C5strand wrote:
<blockquote cite=3D"mid:C861980A-78B8-4730-91BC-882A93243A05@kth.se" =
type=3D"cite"><br>
  <div>
  <div>8 jun 2010 kl. 16:18 skrev Shawn Emery:</div>
  <br class=3D"Apple-interchange-newline">
  <blockquote type=3D"cite">
    <div text=3D"#000000" bgcolor=3D"#ffffff"><font size=3D"+1"><tt><br>
Based on IANA feed-back; the WG needs to reach consensus on how the
GSS-API extensions are to be registered.&nbsp; Options proposed:<br>
    <br>
&nbsp;&nbsp;&nbsp; 1. single GSS-API name-space registry<br>
    </tt></font></div>
  </blockquote>
  <blockquote type=3D"cite">
    <div text=3D"#000000" bgcolor=3D"#ffffff"><font =
size=3D"+1"><tt>&nbsp;&nbsp; &nbsp;2.
separate registry - symbolic and constant registries<br>
&nbsp;&nbsp;&nbsp; 3. registry per programming language<br>
&nbsp;&nbsp;&nbsp; 4. multiple registries<br>
    </tt></font></div>
  </blockquote>
  <div><br>
  </div>
  <div><br>
  </div>
  <div>How would each of these look like ? Esp the first =
one.</div></div></blockquote></div></blockquote><div><br></div><div>I =
think I was more looking for examples.</div><div><br></div><div>For =
example, every time a new language is added, yet another row need to be =
added, and I'm concered how easy that is to manged and express to IANA =
what change we want to make.</div><div><br></div><div>I think there =
should be one registry for each language added and how it maps to the =
base specification =
language.</div><div><br></div><div>Love</div><br><blockquote =
type=3D"cite"><div text=3D"#000000" bgcolor=3D"#ffffff"><blockquote =
cite=3D"mid:C861980A-78B8-4730-91BC-882A93243A05@kth.se" =
type=3D"cite"><div>
  </div>
</blockquote>
<br>
1.<font size=3D"+1"> </font><small><font size=3D"+1"><small>single =
GSS-API
name-space registry</small></font></small><br>
A type that does not have separate symbolic and constant =
registries.&nbsp;
In other words, not 2 or 3.<br>
<br>
2. separate registry - symbolic and constant registries<br>
A constant registry contains entries specific to constant =
name-values.<br>
A symbolic registry contains entries for non-constants, e.g. function
names, name types, etc.<br>
<br>
3<font size=3D"+1">. </font><small><font size=3D"+1"><small>registry per
programming language</small></font></small><br>
Registries partitioned by programming language, for example:<br>
Registry a. contains entries for bindings in C.<br>
Registry b. contains entries for binging in Java.<br>
...<br>
Entries in a. and b. do not have to be unique, but all entries in each
of the language registries should be specified.<br>
<br>
4. multiple registries<br>
Multiple registries is really 2 or 3.<br>
<br>
Perhaps we should put an example with different name-space types in the
appendix for the single name-space registry?&nbsp; Would this help =
clarify?<br>
<br>
Shawn.<br>
--<br>
</div>

</blockquote></div><br></body></html>=

--Apple-Mail-117-505028971--

--Apple-Mail-118-505029016
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKHjCCBMww
ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow
gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl
cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG
A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV
zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl
Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB
L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g
J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC
AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX
ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB
BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl
bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk
oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi
bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G
CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y
o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS
KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFSjCCBDKgAwIBAgIQXzoqZKwXOvvxymIt
KZOH2DANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ
bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1
c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u
YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi
c2NyaWJlciBDQSAtIEcyMB4XDTEwMDQwMTAwMDAwMFoXDTExMDQwMTIzNTk1OVowggETMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp
dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxHzAdBgNVBAMUFkxvdmUgSPZy
bnF1aXN0IMVzdHJhbmQxGTAXBgkqhkiG9w0BCQEWCmxoYUBrdGguc2UwggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQDExzsEl8kHec1Flo6WDOR55uZ9e526lJpegh+pnb7kUoiMc3+L+oTM
HbAQs4hOjUV1+kwPsdnBFolLJ6CR5lkwyZBHjzdbHMXnxh2czeIDjaD1lWxnEPTPefGZ0LEUgbix
pThFfdW6wA9z43J/1VsZeQU8ZEY50ZHSkhjM+1PFdgjL5RJv2j7sFgHVr7P2mvEFNTy+PCKW/1Gj
agjSehjXvFCqs8O9Was/dEdQ8pyT216VBPi+S77qcbGYAH6yqQ0XqiF0ogBZE8jKnkUDhFZz60gC
QqlClW6i7iczbalEjnvEx3z+tsUzIK2UGrwqv0BmCg0qz7T1RZgbTowy0D/BAgMBAAGjgcwwgckw
CQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz
Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwME
BggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZl
cmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAF01Bxe7vzqE
/pJ4hZ30dqxJDSjHVOSmKdAkHg/i0uKLbIs7C+RYDlOptqlrmXwE40cTjFk26XVimzYayfHev/mA
lgqxPlQC28zhQTHi1VtwVUXwslphpGRJk/WK8esXu61gGgjEErcGtNB7G4KfymM3yQgIudUM4cZb
Z+5Et5fzLd9WLHIqd5vb2IbC4Q/dg00lmIWmikQtjt9mi1EaUUIAiySzjI5e6Akq8uyeOw+7ccPg
WZOPPfif8D0z0WDXpSwCyTo9SG/f1gvwPkuxfJ4pilIBVBPkS2zAb7a5ZM1xXdLIjbboFCLCzJhk
VsK40ZdKTdMvp9t/M1O1D/b7U+MxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNV
BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD
VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe
MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx
IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBfOipkrBc6+/HKYi0pk4fYMAkGBSsOAwIa
BQCgggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDYyMzE3
MDA1NlowIwYJKoZIhvcNAQkEMRYEFMhnHV4/W9lU1f8llW6u8vepf20dMIIBAwYJKwYBBAGCNxAE
MYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT
FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov
L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0
ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g
RzICEF86KmSsFzr78cpiLSmTh9gwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMC
VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw
YSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2ln
biBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBfOipkrBc6+/HKYi0pk4fY
MA0GCSqGSIb3DQEBAQUABIIBAEwKxX5dPe9xNLOGLDjOpvfnYWI77Luu7guvLsKdd8173P5n5joH
MhuSo0Xj1sR4qpbhhZQfG9fh8/Fh5n6ZFOj82e9iuO+ELHV2eFh0R/H3Hv029hagrLyXRiv5w6mT
qeDPnG3mkGQanmjYpu5IpKgT+D6aaIxUcLiEzOdNAL6euAhEq8Q9myDqnhwLtFavUj+MPVDwrnA0
uhMBOF7ufy1bGkjv7fU5/mFUGbOj02iKY9BkF9+q8hpR/v2YW4fzhR1oaoTHtqDA0h55UHgtYKX2
ljlI+DYkcwTQdpB4cWJFaxkJi4I5wQjaTfNQL3bkpSvCTOSW9X1Zkbkb9GZfI9AAAAAAAAA=

--Apple-Mail-118-505029016--

From root@core3.amsl.com  Thu Jun 24 12:45:01 2010
Return-Path: <root@core3.amsl.com>
X-Original-To: kitten@ietf.org
Delivered-To: kitten@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0) id C71703A688C; Thu, 24 Jun 2010 12:45:01 -0700 (PDT)
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Subject: I-D Action:draft-ietf-kitten-gssapi-naming-exts-08.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20100624194501.C71703A688C@core3.amsl.com>
Date: Thu, 24 Jun 2010 12:45:01 -0700 (PDT)
Cc: kitten@ietf.org
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Jun 2010 19:45:01 -0000

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Kitten (GSS-API Next Generation) Working Group of the IETF.


	Title           : GSS-API Naming Extensions
	Author(s)       : N. Williams, L. Johansson
	Filename        : draft-ietf-kitten-gssapi-naming-exts-08.txt
	Pages           : 14
	Date            : 2010-06-24

The Generic Security Services API (GSS-API) provides a simple naming
architecture that supports name-based authorization.  This document
introduces new APIs that extend the GSS-API naming model to support
name attribute transfer between GSS-API peers.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-naming-exts-08.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-kitten-gssapi-naming-exts-08.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2010-06-24124316.I-D@ietf.org>


--NextPart--

From root@core3.amsl.com  Thu Jun 24 20:30:16 2010
Return-Path: <root@core3.amsl.com>
X-Original-To: kitten@ietf.org
Delivered-To: kitten@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0) id D996528C0D7; Thu, 24 Jun 2010 20:30:03 -0700 (PDT)
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Subject: I-D Action:draft-ietf-kitten-digest-to-historic-00.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20100625033010.D996528C0D7@core3.amsl.com>
Date: Thu, 24 Jun 2010 20:30:03 -0700 (PDT)
Cc: kitten@ietf.org
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Jun 2010 03:30:16 -0000

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Kitten (GSS-API Next Generation) Working Group of the IETF.


	Title           : Moving DIGEST-MD5 to Historic
	Author(s)       : A. Melnikov
	Filename        : draft-ietf-kitten-digest-to-historic-00.txt
	Pages           : 7
	Date            : 2010-06-24

This memo describes problems with the DIGEST-MD5 Simple
Authentication and Security Layer (SASL) mechanism as specified in
RFC 2831.  It recommends that DIGEST-MD5 to be marked as OBSOLETE in
the IANA Registry of SASL mechanisms, and that RFC 2831 be moved to
Historic status.

Note

A revised version of this draft document will be submitted to the RFC
editor as a Proposed Standard for the Internet Community.  Discussion
and suggestions for improvement are requested, and should be sent to
ietf-sasl@imc.org.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-kitten-digest-to-historic-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-kitten-digest-to-historic-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2010-06-24202204.I-D@ietf.org>


--NextPart--
