Request to create KITTEN (daughter of CAT) Working Group within the IETF Security Area

This is a cryptographically signed message in MIME format.

--------------ms010303090907050209030406
Content-Type: multipart/alternative;
 boundary="------------070503080106010007000203"

This is a multi-part message in MIME format.
--------------070503080106010007000203
Content-Type: text/plain; charset=windows-1251; format=flowed
Content-Transfer-Encoding: 7bit

Russ and Steve:

During the years since the Security Area's Common Authentication 
Technology working group closed its doors there has been significant new 
experience gained by those designing applications which utilize GSSAPI 
v2 update 1 and the GSSAPI v2 C Language Bindings.  This experience has 
demonstrated several areas within the existing RFCs (2743 and 2744) 
which are less than well-defined and/or lacking in functionality.

Attempts to address these deficiencies have resulted in discussions 
taking place in many inappropriate forums.  Some attempts have occurred 
within existing IETF working groups which have rejected the work as 
being outside the existing charter.  Other attempts have been pursued by 
third party organizations such as Global Grid Forum which have chosen to 
extend IETF standards on their own due to an inability to find a forum 
within IETF to pursue their work.

The discussions on the IETF-CAT mailing list over the last several 
months have been quite contentious not to mention fun to read.  The 
fruits of these discussions are the following:

    * There are a number of interested parties who would like to produce
      an new and improved GSSAPI specification be created to address
      issues related to credentials management; thread safety; channel
      binding usability (as discussed at IETF Minneapolis SAAG); C
      Language usage; ABI stability; mechanism specific extensibility;
      and support for mechanisms which do not provide a single canonical
      name.
    * There is an apparent consensus that the existing GSSAPI v2 RFCs
      should be revised to include improved language to clarify areas
      which have resulted in confusion for GSS mechanism implementors
      and application developers.  There should be new text describing
      the lack of thread safety in GSSAPI v2 as well as descriptions of
      how to support IPv6 in the existing channel bindings.  However,
      these revisions must not change the specification in any way which
      would affect backward interoperability with either existing
      implementations of GSSAPI v2 or even GSSAPI v1.
    * There is an apparent consensus that a new GSSAPI v3 specification
      be created to support the extended functionality that is required.
    * There is rough consensus that work should proceed to develop new
      forms of non-address based channel bindings which may be used to
      bind GSS to TLS, IPSec, SSH, and other cryptographic channels.
    * There are also proposals that a new mechansism for negotiating and
      properly using channel bindings (CCM) should be defined and that
      SPNEGO (RFC 2748) be updated to correct flaws in its design and
      specification.

The current participants of the IETF-CAT mailing list believe the time 
is right to form the Common Authentication Technology Next Generation 
working group (aka Kitten) to address these work areas.  As such we 
would like permission from the IESG to form the working group at San 
Diego or if necessary to hold a BOF to discuss the need for the working 
group and the scope of its charter.  What follows is a proposed charter 
for the Kitten Working Group.

Proposed Charter

The Generic Security Services API [RFC 2743, RFC 2744] provides an API 
for applications to set up security contexts and to use these contexts 
for per-message protection services.  The Common Authentication 
Technology Next Generation Working Group (Kitten) will work on 
standardizing extensions  and improvements to the GSSAPI that the IETF 
believes are necessary based on experience using GSSAPI over the last 10 
years.  Extensions may be published as separate drafts or included in a 
GSSAPI version 3.  While version 2 of the GSSAPI may be clarified, no 
backward incompatible changes will be made to this version of the API.

This working group is chartered to revise the GSSAPI v2 RFCs for the 
purpose of clarifying areas of ambiguity:

    * Use of channel bindings
    * Thread safety restrictions
    * C Language utilization
          o use of const
          o utilization of gss types by the application
          o gss name space
          o improve recommendations for implementation specific types
            (e.g., use pointers to incomplete structs)
    * Guidelines for GSS-API mechanism designers
    * Guidelines for GSS-API application protocol designers

This working group is chartered to specify a non-backward compatible 
GSSAPI v3 to support the following extensions:

    * Clarify the portable use of channel bindings and better specify
      channel bindings in a language-independent manner.
    * Specify thread safety extensions to allow multi-threaded
      applications to use GSSAPI
    * Definitions of channel bindings for TLS, IPSec, SSH and other
      cryptographic  channels based on work started in the NFSV4
      working  group.
    * Defined a GSSAPI extension to allow applications to store
      credentials.  Discussions to be started based upon:
          o draft-williams-gss-store-deleg-creds-xx.txt
    * Extensions to solve problems posed by the Global Grid Forum's
      GSSAPI extensions document.
    * Extensions to deal with mechanism-specific extensibility in a
      multi-mechanism environment.
    * Extend GSSAPI to support mechanisms that do not have a single
      canonical name for each authentication identity.
    * Extensions to support stackable GSSAPI mechanisms.


This working group is chartered to perform the following GSSAPI 
mechanism specification work:

    * Specify a GSSAPI v2/v3 Channel Conjunction Mechanism
    * Revise RFC 2748 (SPNEGO) to correct problems that make the
      specification unimplementable and to document the problems found
      in widely-deployed attempts to implement this spec.

End of Proposed Charter


The participants of the IETF-CAT mailing list realize the quantity of 
work which we desire to undertake is quite ambitious in scope. This is 
simply an indication of how much work has accumulated over the last few 
years since the CAT working group disbanded.  We believe that we can 
accomplish the stated work items in 18 months.

Milestones

    * Clarifications to GSSAPIv2 (six months to IESG)
      Informational
      [editor: Jeffrey Altman]
    * The Channel Conjunction Mechanism (CCM) for the GSSAPI (six months
      to IESG)
      Proposed Standard
      [editors: Nicolas Williams/Mike Eisler]
    * On the Use of Channel Bindings to Secure Channels (six months to
      IESG)
      Proposed Standard
      [editor: Nicolas Williams]
      draft-ietf-nfsv4-channel-bindings-01.txt
    * GSSAPIv3 (18 months to IESG)
      Proposed Standard
      [editor: to be determined]
    * Stackable Generic Security Service Pseudo-mechanisms
      Proposed Standard or to be folded into GSSAPIv3
      [editor: Nicolas Williams]
      draft-williams-gssapi-stackable-pseudo-mechs-00.txt
    * GSS-APIv2 Extension for Storing Delegated Credentials
      Proposed Standard or to be folded into GSSAPIv3
      [editor: Nicolas Williams]
    * draft-williams-gssapi-store-deleg-creds-00.txt SPNEGO (RFC 2478)
      Revisions (18 months to IESG)
      Proposed Standard
      [editor: to be determined]

End of Milestones

Chairperson
The proposed chairperson for the Kitten WG is Jeffrey Altman.

Mailing List
The current mailing list for discussions is [email protected].
Due to the facts that no one at Stanford is actively involved in the
discussions and the mailing list software is quite old, the working group
when formed will switch to a new mailing list.


Sincerely,

Jeffrey Altman (for the participants of the ietf-cat-wg mailing list)


--------------070503080106010007000203
Content-Type: text/html; charset=windows-1251
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=windows-1251"
 http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Russ and Steve:<br>
<br>
During the years since the Security Area's Common Authentication
Technology working group closed its doors there has been significant
new experience gained by those designing applications which utilize
GSSAPI v2 update 1 and the GSSAPI v2 C Language Bindings.  This
experience has demonstrated several areas within the existing RFCs
(2743 and 2744) which are less than well-defined and/or lacking in
functionality.<br>
<br>
Attempts to address these deficiencies have resulted in discussions
taking place in many inappropriate forums.  Some attempts have
occurred within existing IETF working groups which have rejected the
work as being outside the existing charter.  Other attempts have
been pursued by third party organizations such as Global Grid Forum
which have chosen to extend IETF standards on their own due to an
inability to find a forum within IETF to pursue their work.<br>
<br>
The discussions on the IETF-CAT mailing list over the last several
months have been quite contentious not to mention fun to read. 
The fruits of these discussions are the following:<br>
<ul>
  <li>There are a number of interested parties who would like to
produce an new and improved GSSAPI specification be created to address
issues related to credentials management; thread safety; channel
binding usability (as discussed at IETF Minneapolis SAAG); C Language
usage; ABI stability; mechanism specific extensibility; and support for
mechanisms which do not provide a single canonical name.</li>
  <li>There is an apparent consensus that the existing GSSAPI v2 RFCs
should be revised to include improved language to clarify areas which
have resulted in confusion for GSS mechanism implementors and
application developers.  There should be new text describing the
lack of thread safety in GSSAPI v2 as well as descriptions of how to
support IPv6 in the existing channel bindings.  However, these
revisions must not change the specification in any way which would
affect backward interoperability with either existing implementations
of GSSAPI v2 or even GSSAPI v1.</li>
  <li>There is an apparent consensus that a new GSSAPI v3 specification
be created to support the extended functionality that is required.</li>
  <li>There is rough consensus that work should proceed to develop new
forms of non-address based channel bindings which may be used to bind
GSS to TLS, IPSec, SSH, and other cryptographic channels.</li>
  <li>There are also proposals that a new mechansism for negotiating
and properly using channel bindings (CCM) should be
defined and that SPNEGO (RFC 2748) be updated to correct flaws in its
design and specification.</li>
</ul>
The current participants of the IETF-CAT mailing list believe the time
is right to form the Common Authentication Technology Next Generation
working group (aka Kitten) to address these work areas.  As such
we would like permission from the IESG to form the working group
at San Diego or if necessary to hold a BOF to discuss the need for the
working group
and the scope of its charter.  What follows is a proposed charter
for the Kitten Working Group.<br>
<br>
<span style="text-decoration: underline;">Proposed Charter</span><br>
<br>
The Generic Security Services API [RFC 2743, RFC 2744] provides an API
for applications to set up security contexts and to use these contexts
for per-message protection services.  The Common Authentication
Technology Next Generation Working Group (Kitten) will work on
standardizing extensions  and improvements to the GSSAPI that the
IETF believes are necessary based on experience using GSSAPI over the
last 10 years.  Extensions may be published as separate drafts or
included in a GSSAPI version 3.  While version 2 of the GSSAPI
may be clarified, no backward incompatible changes will be made to this
version of the API.<br>
<br>
This working group is chartered to revise the GSSAPI v2 RFCs for the
purpose of clarifying areas of ambiguity:<br>
<ul>
  <li>Use of channel bindings</li>
  <li>Thread safety restrictions</li>
  <li>C Language utilization</li>
  <ul>
    <li>use of const</li>
    <li>utilization of gss types by the application</li>
    <li>gss name space</li>
    <li>improve recommendations for implementation specific types
(e.g., use pointers to incomplete structs)<br>
    </li>
  </ul>
  <li>Guidelines for GSS-API mechanism designers</li>
  <li>Guidelines for GSS-API application protocol designers</li>
</ul>
This working group is chartered to specify a non-backward compatible
GSSAPI v3 to support the following extensions:<br>
<ul>
  <li>Clarify the portable use of channel bindings and better specify
channel bindings in a language-independent manner.</li>
  <li>Specify thread safety extensions to allow multi-threaded
applications to use GSSAPI</li>
  <li>Definitions of channel bindings for TLS, IPSec, SSH and other
cryptographic  channels based on work started in the NFSV4
working  group.</li>
  <li>Defined a GSSAPI extension to allow applications to store
credentials.  Discussions to be started based upon:</li>
  <ul>
    <li>draft-williams-gss-store-deleg-creds-xx.txt</li>
  </ul>
  <li>Extensions to solve problems posed by the Global Grid Forum's
GSSAPI extensions document.</li>
  <li>Extensions to deal with mechanism-specific extensibility in a
multi-mechanism environment.</li>
  <li>Extend GSSAPI to support mechanisms that do not have a single
canonical name for each authentication identity.</li>
  <li>Extensions to support stackable GSSAPI mechanisms.</li>
</ul>
<br>
This working group is chartered to perform the following GSSAPI
mechanism specification work:<br>
<ul>
  <li>Specify a GSSAPI v2/v3 Channel Conjunction Mechanism</li>
  <li>Revise RFC 2748 (SPNEGO) to correct problems that make the
specification unimplementable and to document the problems found in
widely-deployed attempts to implement this spec.</li>
</ul>
<span style="text-decoration: underline;">End of Proposed Charter</span><br>
<br>
<br>
The participants of the IETF-CAT mailing list realize the quantity of
work which we desire to undertake is quite ambitious in scope. This is
simply an indication of how much work has accumulated over the last few
years since the CAT working group disbanded.  We believe that we
can accomplish the stated work items in 18 months.<br>
<br>
<span style="text-decoration: underline;">Milestones</span><br>
<ul>
  <li>Clarifications to GSSAPIv2 (six months to IESG) <br>
Informational<br>
[editor: Jeffrey Altman]</li>
  <li>The Channel Conjunction Mechanism (CCM) for the GSSAPI (six
months to IESG) <br>
Proposed Standard<br>
[editors: Nicolas Williams/Mike Eisler]</li>
  <li>On the Use of Channel Bindings to Secure Channels (six months to
IESG) <br>
Proposed Standard<br>
[editor: Nicolas Williams]<br>
draft-ietf-nfsv4-channel-bindings-01.txt<br>
  </li>
  <li>GSSAPIv3 (18 months to IESG)<br>
Proposed Standard<br>
[editor: to be determined]<br>
  </li>
  <li>Stackable Generic Security Service Pseudo-mechanisms<br>
Proposed Standard or to be folded into GSSAPIv3 <br>
[editor: Nicolas Williams]<br>
draft-williams-gssapi-stackable-pseudo-mechs-00.txt<br>
  </li>
  <li>GSS-APIv2 Extension for Storing Delegated Credentials<br>
  </li>
Proposed Standard or to be folded into GSSAPIv3<br>
[editor: Nicolas Williams]<br>
draft-williams-gssapi-store-deleg-creds-00.txt <li>SPNEGO (RFC
2478) Revisions (18 months to IESG)<br>
Proposed Standard<br>
[editor: to be determined]</li>
  <br>
</ul>
<span style="text-decoration: underline;">End of Milestones</span><br>
<br>
<span style="text-decoration: underline;">Chairperson</span><br>
The proposed chairperson for the Kitten WG is Jeffrey Altman.<br>
<br>
<span style="text-decoration: underline;">Mailing List</span><br>
The current mailing list for discussions is
<a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a>.<br>
Due to the facts that no one at Stanford is actively involved in the <br>
discussions and the mailing list software is quite old, the working
group<br>
when formed will switch to a new mailing list. <br>
<br>
<br>
Sincerely, <br>
<br>
Jeffrey Altman (for the participants of the ietf-cat-wg mailing list)<br>
<br>
</body>
</html>

--------------070503080106010007000203--

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJOzCC
AvgwggJhoAMCAQICAwwjmjANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE
ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv
bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNDE2MDIxODM0WhcNMDUwNDE2MDIxODM0
WjBGMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSMwIQYJKoZIhvcNAQkBFhRq
YWx0bWFuQGNvbHVtYmlhLmVkdTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKyS
7eWrak81hbARkTT+lqX+uujXLK3tDmCn/6IQH9tDKYtf5A8/llZJdPYHUA9p1FH9hwk23iGY
scSkJq84FJenlWKOOqOsT6BlueWsrlKuseJCdMf9uhN28p+UnZvrcVhcLLTYfRvQT9OUw/k3
h4TzNdyAXbBJ3LnL1ySbFRaNVkq7cW/2ircAWpcyqHH4ZKstdSLbo6axsDHWRZL8yHUsI1Gz
esRSYQf2aUeUqvmGbEKEKFwbfqgfLwlBLiv1Lqib/++J3s5g3syhqWe3T8tUffmhdibUdX2W
umT2uiWl/WGEBvc1+o5k0T2JqWMNR9VgzPyk8P+iZRHl76Yb49ECAwEAAaNUMFIwDgYDVR0P
AQH/BAQDAgP4MBEGCWCGSAGG+EIBAQQEAwIFoDAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVt
YmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAGXYUcZvaLEqctXUsgt0
fUMFXukM3E5fpLBkk3+BbcY457WQE38ZM1AOvcYOHqB1xhJCxP1U0pSJu2Xfe9Z1M2mU4C4V
2w4sDcWkZteM9EW7VYbXzSCKCw0TKKp3Wl9TFIWFdiFwPvhOzhXUonGTdYbOvRuAXQuJdNQW
O4v2sQg1MIIC+DCCAmGgAwIBAgIDDCOaMA0GCSqGSIb3DQEBBAUAMGIxCzAJBgNVBAYTAlpB
MSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3
dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wNDA0MTYwMjE4MzRaFw0wNTA0
MTYwMjE4MzRaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxIzAhBgkqhkiG
9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEArJLt5atqTzWFsBGRNP6Wpf666Ncsre0OYKf/ohAf20Mpi1/kDz+WVkl09gdQD2nU
Uf2HCTbeIZixxKQmrzgUl6eVYo46o6xPoGW55ayuUq6x4kJ0x/26E3byn5Sdm+txWFwstNh9
G9BP05TD+TeHhPM13IBdsEncucvXJJsVFo1WSrtxb/aKtwBalzKocfhkqy11ItujprGwMdZF
kvzIdSwjUbN6xFJhB/ZpR5Sq+YZsQoQoXBt+qB8vCUEuK/UuqJv/74nezmDezKGpZ7dPy1R9
+aF2JtR1fZa6ZPa6JaX9YYQG9zX6jmTRPYmpYw1H1WDM/KTw/6JlEeXvphvj0QIDAQABo1Qw
UjAOBgNVHQ8BAf8EBAMCA/gwEQYJYIZIAYb4QgEBBAQDAgWgMB8GA1UdEQQYMBaBFGphbHRt
YW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAZdhRxm9o
sSpy1dSyC3R9QwVe6QzcTl+ksGSTf4FtxjjntZATfxkzUA69xg4eoHXGEkLE/VTSlIm7Zd97
1nUzaZTgLhXbDiwNxaRm14z0RbtVhtfNIIoLDRMoqndaX1MUhYV2IXA++E7OFdSicZN1hs69
G4BdC4l01BY7i/axCDUwggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYD
VQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAY
BgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZp
Y2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzAp
BgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAw
MDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENv
bnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls
IElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5o
wHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuv
PAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAe
ZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0
hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDAL
BgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4
MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6ot
nzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V
2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDOzCCAzcCAQEwaTBi
MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEs
MCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwwjmjAJBgUr
DgMCGgUAoIIBpzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0w
NDA1MjQxODI4MDdaMCMGCSqGSIb3DQEJBDEWBBQhAW90aYaNVOotVEDdhTJE6xaVfjBSBgkq
hkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB
QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDB4BgkrBgEEAYI3EAQxazBpMGIxCzAJBgNVBAYT
AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU
aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDCOaMHoGCyqGSIb3DQEJEAIL
MWugaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg
THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwwj
mjANBgkqhkiG9w0BAQEFAASCAQBL4JSKXbhKHaUFc8xb5eFeRiJT5oTiBCZp4W0RPUcfkhyx
HVCRjrhZn9um9fNXpiuhP+sDbokxXc/PB3w/YDBV3tqJ+ePzBJeTETXK+p52/I2CLhcwogXe
NVKeyTSsjN9ZfjL9HSOAgzfuYbTu/qEmAGdRaog1wGu8VCbSqsZw1bzD/Y3Fy1X/WjXOaX0j
mRRWKXVs6wae3CW/axUl0EWjdFQGd2rzEho2IOtrRDxY8E061ZIQeI+jsgKEYm1a2h7CHxsp
l9OdBWnBdXjee6f7k7rB5dehbVqjD1YYLw2KPYNgoDVc96w/NGaUzRiKEOvC00q+O1xtnwrK
61Df2iIKAAAAAAAA
--------------ms010303090907050209030406--
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email protected]