From jhutz@cmu.edu Tue Jan 24 15:13:33 2006 Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by michigan.central.org with smtp (Exim 4.50) id 1F1UXl-0005nB-Br for afs3-standardization@openafs.org; Tue, 24 Jan 2006 15:13:33 -0500 Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170]) by minbar.fac.cs.cmu.edu id aa17359; 24 Jan 2006 15:12 EST Date: Tue, 24 Jan 2006 15:12:58 -0500 From: Jeffrey Hutzelman To: afs3-standardization@openafs.org Message-ID: Originator-Info: login-token=Mulberry:01jZeCqPf/9xzZ4vopwBWyFyQJudMUy/v6DLANwxc=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 128.2.185.161 X-SA-Exim-Rcpt-To: afs3-standardization@openafs.org X-SA-Exim-Mail-From: jhutz@cmu.edu X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on michigan.central.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on michigan.central.org) Subject: [AFS3-std] Testing X-BeenThere: afs3-standardization@openafs.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standardizing the AFS 3 Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2006 20:13:33 -0000 Hm. The name of this list is too hard to type. Maybe we should rename to afs3-stds or something... From jaltman@secure-endpoints.com Wed Feb 22 09:59:39 2006 Received: from brinza.cc.columbia.edu ([128.59.29.8] ident=cu41754) by michigan.central.org with esmtp (Exim 4.50) id 1FBvSs-0001S1-8l for afs3-standardization@openafs.org; Wed, 22 Feb 2006 09:59:39 -0500 Received: from [192.168.1.11] (cpe-68-175-91-105.nyc.res.rr.com [68.175.91.105]) (user=jaltman mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id k1MEtbZP015916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Feb 2006 09:55:37 -0500 (EST) Message-ID: <43FC7BB6.9040604@secure-endpoints.com> Date: Wed, 22 Feb 2006 09:56:54 -0500 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: afs3-standardization@openafs.org, afs3-protocol@stacken.kth.se X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080400040601050007070303" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-SA-Exim-Connect-IP: 128.59.29.8 X-SA-Exim-Rcpt-To: afs3-standardization@openafs.org X-SA-Exim-Mail-From: jaltman@secure-endpoints.com X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on michigan.central.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on michigan.central.org) Cc: Ken Hornstein , Harald Barth , Love Subject: [AFS3-std] Standardization of the AFS3 protocol X-BeenThere: afs3-standardization@openafs.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standardizing the AFS 3 Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2006 14:59:39 -0000 This is a cryptographically signed message in MIME format. --------------ms080400040601050007070303 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit AFS3 is not a standardized protocol in the sense of those which follow the IETF processes. There are many reasons for this which at the current time are primarily historical. If we wanted to standardize AFS3 within IETF today we would have to document RX and all of the existing RPCs used by the various servers. Regardless of standardization, documenting the existing protocols would be a huge quantity of work and we simply do not have the human resources to accomplish it. However, this does not mean that developers can go off willy nilly making changes to RX, adding new service RPCs or altering the behavior of existing service RPCs. There needs to be a process setup by which a rough consensus can be achieved on proposed changes in a forum that will be archived so that crucial knowledge will not be lost. Preferably we will also be able to start a documentation process that will include the new work that is agreed to. As OpenAFS maintains both a server and multiple client implementations and the OpenAFS Elders include technical representation from IBM Pittsburgh Labs it has been concluded by the Elders that OpenAFS would be the best place for such standardization work to be done. The afs3-standardization@openafs.org mailing list has been created to be the discussion forum. At the present time a web interface for subscribing can be found at http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization There are several outstanding work efforts that should be discussed on this new list: * RXGK * RX/TCP * Addition of GetCapabilities RPCs to all services, the assignment of bit flag values on a per-service basis, interaction of GetCapabilities with Delayed Callback Breaks, and whether "capabilities" can also include policy hints for clients. * Extensions to the file server SetLock RPC to support LockUpgrade and LockDowngrade. * Extensions to the Protection Server RPCs to support multiple user names per AFS ID. and these are just the ones that I believe are pressing issues. If you are not currently a member of afs3-standardization, please join. Tomorrow I will start postings on each item listed above in order to begin the process of obtaining rough consensus on the last three items in the list. Jeffrey Altman The following discussion took place on afs3-protocol@stacken.kth.se. --------------ms080400040601050007070303 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJXzCC AwowggJzoAMCAQICAw7NrTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwNTI3MTc0NzU3WhcNMDYwNTI3MTc0NzU3 WjBzMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjErMCkGCSqGSIb3DQEJARYcamFsdG1hbkBzZWN1cmUtZW5k cG9pbnRzLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKjPyrF+rdjOUSK/ bWwZHdx5p1+y6iiCd4vvYEVDxouYFp5C/fZEWm5n45ubBUbMSUI1MAZN6ooEoH09UTj6BXhM S8B987ls81dKOIUphTF2jOzq8gsFmeA15yHMRAD20LqUWeLyvYk8FCNQw+dsKMMhX+WdsxOm RY/1jPkJL6oN8kEwoUFkOX9/OfWWh6oFnV6faiEHUKDMFubsb9X0KVD8iIeR7Cxz7i4kXqRX wMlp2fyoxcDIJrBaTY8nA++g3p34IkWt1a5po6g683nIgSnGpwYIwuJheBqSEZfLYWa+1KdD 6Sn27Ud94GqUvPVG5jC6zVC5EJ2aWuoAu+nNuV8CAwEAAaM5MDcwJwYDVR0RBCAwHoEcamFs dG1hbkBzZWN1cmUtZW5kcG9pbnRzLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUA A4GBADtvO//tjiAV6VJGtoNtrl34mB5jGyGTiotzw8riB6zz0GvY11bcWDmp6JKif+pVG+8L IySDosbuva13qu2HwYUxBmWc7CoNd2k9kRlcrfbDUTTrGOZK8qyqNqT3gQZTAa9ZnUI0su9G y/n2o5bQcaYdqR3htNrpvdLSPOWhILOXMIIDCjCCAnOgAwIBAgIDDs2tMA0GCSqGSIb3DQEB BAUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0w NTA1MjcxNzQ3NTdaFw0wNjA1MjcxNzQ3NTdaMHMxDzANBgNVBAQTBkFsdG1hbjEVMBMGA1UE KhMMSmVmZnJleSBFcmljMRwwGgYDVQQDExNKZWZmcmV5IEVyaWMgQWx0bWFuMSswKQYJKoZI hvcNAQkBFhxqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAqM/KsX6t2M5RIr9tbBkd3HmnX7LqKIJ3i+9gRUPGi5gWnkL99kRa bmfjm5sFRsxJQjUwBk3qigSgfT1ROPoFeExLwH3zuWzzV0o4hSmFMXaM7OryCwWZ4DXnIcxE APbQupRZ4vK9iTwUI1DD52wowyFf5Z2zE6ZFj/WM+Qkvqg3yQTChQWQ5f3859ZaHqgWdXp9q IQdQoMwW5uxv1fQpUPyIh5HsLHPuLiRepFfAyWnZ/KjFwMgmsFpNjycD76DenfgiRa3Vrmmj qDrzeciBKcanBgjC4mF4GpIRl8thZr7Up0PpKfbtR33gapS89UbmMLrNULkQnZpa6gC76c25 XwIDAQABozkwNzAnBgNVHREEIDAegRxqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMuY29tMAwG A1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAO287/+2OIBXpUka2g22uXfiYHmMbIZOK i3PDyuIHrPPQa9jXVtxYOanokqJ/6lUb7wsjJIOixu69rXeq7YfBhTEGZZzsKg13aT2RGVyt 9sNRNOsY5kryrKo2pPeBBlMBr1mdQjSy70bL+fajltBxph2pHeG02um90tI85aEgs5cwggM/ MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMM V2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25z dWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYD VQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNv bmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5 WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRk LjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2 vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9 A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEw EgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0 ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYDVR0R BCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GB AEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZ Ohl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVN d+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDOzCCAzcCAQEwaTBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrTAJBgUrDgMCGgUAoIIBpzAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjAyMjIxNDU2NTRaMCMGCSqG SIb3DQEJBDEWBBQD4MIEaoNWKEQg/gknT9yrP+ZWUDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDB4BgkrBgEEAYI3EAQxazBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQQIDDs2tMHoGCyqGSIb3DQEJEAILMWugaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrTANBgkqhkiG9w0BAQEFAASC AQBIcaYQIq4H1piz4/mqjcM/0h7MQzvVDf1aZGT108iFQVqwFvPm0/ZWGjUcn1MAYmHiQcRP VXXU1JxRG2zrn3PYgbfSEBCJg5B3Y8Sdjx6Y24lJkO/l3nGKwCuSM6zQ0YOfOvfPDMCxhDko utePeuD/l9nWsSV49dW97xUK3nmvry1gr0mgdOzytIMjj0tGTW8sJGSGbZ3SD6P7R36LkuYt 6xvMsiSKMauuV25k3gBgVfuU2SGE9KI8x7YQY4S7yOQC3gdoYVJRsW0K2b0k7E57NwCQlCfn 0UPK/WDxGfim7z5j6kJWgBZMVv0qVxHWWo6WZtAduBRJ3SNq5IWKqeV+AAAAAAAA --------------ms080400040601050007070303-- From jaltman@secure-endpoints.com Wed Feb 22 10:33:48 2006 Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754) by michigan.central.org with esmtp (Exim 4.50) id 1FBvzv-0001WV-Kk for afs3-standardization@openafs.org; Wed, 22 Feb 2006 10:33:47 -0500 Received: from [192.168.1.11] (cpe-68-175-91-105.nyc.res.rr.com [68.175.91.105]) (user=jaltman mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id k1MFTfuQ004343 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Feb 2006 10:29:43 -0500 (EST) Message-ID: <43FC83AE.3070907@secure-endpoints.com> Date: Wed, 22 Feb 2006 10:30:54 -0500 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: David Howells References: <43FC7BB6.9040604@secure-endpoints.com> <16659.1140621852@warthog.cambridge.redhat.com> In-Reply-To: <16659.1140621852@warthog.cambridge.redhat.com> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020302000607070105030001" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-SA-Exim-Connect-IP: 128.59.29.6 X-SA-Exim-Rcpt-To: afs3-standardization@openafs.org X-SA-Exim-Mail-From: jaltman@secure-endpoints.com X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on michigan.central.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on michigan.central.org) Cc: Love , Ken Hornstein , afs3-standardization@openafs.org, afs3-protocol@stacken.kth.se, Harald Barth Subject: [AFS3-std] Re: Standardization of the AFS3 protocol X-BeenThere: afs3-standardization@openafs.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standardizing the AFS 3 Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2006 15:33:48 -0000 This is a cryptographically signed message in MIME format. --------------ms020302000607070105030001 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit David Howells wrote: > Jeffrey Altman wrote: > >> If we wanted to standardize AFS3 within IETF today we would have to document >> RX and all of the existing RPCs used by the various servers. > > Can Rx at least be fully documented? The documentation that's out there does > not appear to be complete. > > David David: There is no objections to documenting or even standardizing RX. The question is simply who would have the time and experience to do so. Does Red Hat have the resources to do so? Either by providing staff to do the work or by providing funding so that someone can be hired to do the work? Jeffrey Altman --------------ms020302000607070105030001 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJXzCC AwowggJzoAMCAQICAw7NrTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwNTI3MTc0NzU3WhcNMDYwNTI3MTc0NzU3 WjBzMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjErMCkGCSqGSIb3DQEJARYcamFsdG1hbkBzZWN1cmUtZW5k cG9pbnRzLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKjPyrF+rdjOUSK/ bWwZHdx5p1+y6iiCd4vvYEVDxouYFp5C/fZEWm5n45ubBUbMSUI1MAZN6ooEoH09UTj6BXhM S8B987ls81dKOIUphTF2jOzq8gsFmeA15yHMRAD20LqUWeLyvYk8FCNQw+dsKMMhX+WdsxOm RY/1jPkJL6oN8kEwoUFkOX9/OfWWh6oFnV6faiEHUKDMFubsb9X0KVD8iIeR7Cxz7i4kXqRX wMlp2fyoxcDIJrBaTY8nA++g3p34IkWt1a5po6g683nIgSnGpwYIwuJheBqSEZfLYWa+1KdD 6Sn27Ud94GqUvPVG5jC6zVC5EJ2aWuoAu+nNuV8CAwEAAaM5MDcwJwYDVR0RBCAwHoEcamFs dG1hbkBzZWN1cmUtZW5kcG9pbnRzLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUA A4GBADtvO//tjiAV6VJGtoNtrl34mB5jGyGTiotzw8riB6zz0GvY11bcWDmp6JKif+pVG+8L IySDosbuva13qu2HwYUxBmWc7CoNd2k9kRlcrfbDUTTrGOZK8qyqNqT3gQZTAa9ZnUI0su9G y/n2o5bQcaYdqR3htNrpvdLSPOWhILOXMIIDCjCCAnOgAwIBAgIDDs2tMA0GCSqGSIb3DQEB BAUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0w NTA1MjcxNzQ3NTdaFw0wNjA1MjcxNzQ3NTdaMHMxDzANBgNVBAQTBkFsdG1hbjEVMBMGA1UE KhMMSmVmZnJleSBFcmljMRwwGgYDVQQDExNKZWZmcmV5IEVyaWMgQWx0bWFuMSswKQYJKoZI hvcNAQkBFhxqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAqM/KsX6t2M5RIr9tbBkd3HmnX7LqKIJ3i+9gRUPGi5gWnkL99kRa bmfjm5sFRsxJQjUwBk3qigSgfT1ROPoFeExLwH3zuWzzV0o4hSmFMXaM7OryCwWZ4DXnIcxE APbQupRZ4vK9iTwUI1DD52wowyFf5Z2zE6ZFj/WM+Qkvqg3yQTChQWQ5f3859ZaHqgWdXp9q IQdQoMwW5uxv1fQpUPyIh5HsLHPuLiRepFfAyWnZ/KjFwMgmsFpNjycD76DenfgiRa3Vrmmj qDrzeciBKcanBgjC4mF4GpIRl8thZr7Up0PpKfbtR33gapS89UbmMLrNULkQnZpa6gC76c25 XwIDAQABozkwNzAnBgNVHREEIDAegRxqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMuY29tMAwG A1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAO287/+2OIBXpUka2g22uXfiYHmMbIZOK i3PDyuIHrPPQa9jXVtxYOanokqJ/6lUb7wsjJIOixu69rXeq7YfBhTEGZZzsKg13aT2RGVyt 9sNRNOsY5kryrKo2pPeBBlMBr1mdQjSy70bL+fajltBxph2pHeG02um90tI85aEgs5cwggM/ MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMM V2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25z dWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYD VQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNv bmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5 WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRk LjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2 vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9 A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEw EgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0 ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYDVR0R BCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GB AEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZ Ohl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVN d+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDOzCCAzcCAQEwaTBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrTAJBgUrDgMCGgUAoIIBpzAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjAyMjIxNTMwNTRaMCMGCSqG SIb3DQEJBDEWBBQ51oJVGPhyEj4wzSVjZDkZEOiX2TBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDB4BgkrBgEEAYI3EAQxazBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQQIDDs2tMHoGCyqGSIb3DQEJEAILMWugaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrTANBgkqhkiG9w0BAQEFAASC AQAtFWwZm04rQ/c87Kre7hiRvWFLjkasdig2eU0VT0iOAUgm89Eml5e58qshfr+Dc0jZyBFs KNRVnMEwnbjBS4fqGTwSd5ntXp73a8iO/k4OztRnPb9XXJnxAab0tlRX36Y/ckeM4UqZESpc aFuZgzNJBBNOtipqU1NKdO2rMuZTpiXMg7N6OXjywrPmQr/QldWDF8sAGBaTrXnmPSwWXjKN oVR/gM5iS/6t1iTAGZ6k8pfG2A+rmlc+f9eCzoN09+Cyy5M9iZivQwWF6GT/R9To6mkd1VvC TgkSGJ3YwmXfc0sUA8q+WyCPlUliYwFS7jk8s692dT6K9TXg5kntp9SZAAAAAAAA --------------ms020302000607070105030001-- From tcreedon@easystreet.com Wed Feb 22 11:04:56 2006 Received: from smtpauth.newman.easystreet.com ([206.102.12.11] helo=smtpauth.easystreet.com) by michigan.central.org with esmtp (Exim 4.50) id 1FBwU3-0001Ym-KS for afs3-standardization@openafs.org; Wed, 22 Feb 2006 11:04:56 -0500 Received: from attu1 (c-24-20-41-88.hsd1.or.comcast.net [24.20.41.88]) by smtpauth.easystreet.com (Postfix) with ESMTP id 1A0E729533; Wed, 22 Feb 2006 08:04:44 -0800 (PST) From: "ted creedon" Date: Wed, 22 Feb 2006 08:04:35 -0800 Organization: creedon engineering Message-ID: <005e01c637c9$ad5d60d0$c901010a@home.teddoris.fam> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <43FC83AE.3070907@secure-endpoints.com> Thread-Index: AcY3xWY9GMjTljbcRUSWnDybn6awwwAA8ooQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-SA-Exim-Connect-IP: 206.102.12.11 X-SA-Exim-Rcpt-To: afs3-standardization@openafs.org X-SA-Exim-Mail-From: tcreedon@easystreet.com Subject: RE: [AFS3-std] Re: Standardization of the AFS3 protocol X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on michigan.central.org X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL, BAYES_00, MISSING_HEADERS autolearn=ham version=3.0.3 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on michigan.central.org) Cc: afs3-standardization@openafs.org, afs3-protocol@stacken.kth.se X-BeenThere: afs3-standardization@openafs.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tcreedon@easystreet.com List-Id: Standardizing the AFS 3 Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2006 16:04:56 -0000 The documentation could be done here, but it would be in LaTex. There will be a new LaTex based release of the OpenAFS docs as soon as some changes are created. Tedc -----Original Message----- From: afs3-standardization-bounces@openafs.org [mailto:afs3-standardization-bounces@openafs.org] On Behalf Of Jeffrey Altman Sent: Wednesday, February 22, 2006 7:31 AM To: David Howells Cc: Love; Ken Hornstein; afs3-standardization@openafs.org; afs3-protocol@stacken.kth.se; Harald Barth Subject: [AFS3-std] Re: Standardization of the AFS3 protocol David Howells wrote: > Jeffrey Altman wrote: > >> If we wanted to standardize AFS3 within IETF today we would have to document >> RX and all of the existing RPCs used by the various servers. > > Can Rx at least be fully documented? The documentation that's out there does > not appear to be complete. > > David David: There is no objections to documenting or even standardizing RX. The question is simply who would have the time and experience to do so. Does Red Hat have the resources to do so? Either by providing staff to do the work or by providing funding so that someone can be hired to do the work? Jeffrey Altman From jaltman@secure-endpoints.com Wed Feb 22 11:22:56 2006 Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754) by michigan.central.org with esmtp (Exim 4.50) id 1FBwlU-0001aS-FI for afs3-standardization@openafs.org; Wed, 22 Feb 2006 11:22:56 -0500 Received: from [192.168.1.11] (cpe-68-175-91-105.nyc.res.rr.com [68.175.91.105]) (user=jaltman mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id k1MGMcxe011723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Feb 2006 11:22:43 -0500 (EST) Message-ID: <43FC901C.9010801@secure-endpoints.com> Date: Wed, 22 Feb 2006 11:23:56 -0500 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: tcreedon@easystreet.com References: <005e01c637c9$ad5d60d0$c901010a@home.teddoris.fam> In-Reply-To: <005e01c637c9$ad5d60d0$c901010a@home.teddoris.fam> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040707010903060107020200" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-SA-Exim-Connect-IP: 128.59.29.5 X-SA-Exim-Rcpt-To: afs3-standardization@openafs.org X-SA-Exim-Mail-From: jaltman@secure-endpoints.com Subject: Re: [AFS3-std] Re: Standardization of the AFS3 protocol X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on michigan.central.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on michigan.central.org) Cc: afs3-standardization@openafs.org, afs3-protocol@stacken.kth.se X-BeenThere: afs3-standardization@openafs.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standardizing the AFS 3 Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2006 16:22:56 -0000 This is a cryptographically signed message in MIME format. --------------ms040707010903060107020200 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit ted creedon wrote: > The documentation could be done here, but it would be in LaTex. > > There will be a new LaTex based release of the OpenAFS docs as soon as some > changes are created. > > Tedc Ted: Protocol documentation and OpenAFS End User and Administrator documentation are two completely different things. Protocol documentation is traditionally published in plain text. Jeffrey Altman --------------ms040707010903060107020200 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJXzCC AwowggJzoAMCAQICAw7NrTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwNTI3MTc0NzU3WhcNMDYwNTI3MTc0NzU3 WjBzMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjErMCkGCSqGSIb3DQEJARYcamFsdG1hbkBzZWN1cmUtZW5k cG9pbnRzLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKjPyrF+rdjOUSK/ bWwZHdx5p1+y6iiCd4vvYEVDxouYFp5C/fZEWm5n45ubBUbMSUI1MAZN6ooEoH09UTj6BXhM S8B987ls81dKOIUphTF2jOzq8gsFmeA15yHMRAD20LqUWeLyvYk8FCNQw+dsKMMhX+WdsxOm RY/1jPkJL6oN8kEwoUFkOX9/OfWWh6oFnV6faiEHUKDMFubsb9X0KVD8iIeR7Cxz7i4kXqRX wMlp2fyoxcDIJrBaTY8nA++g3p34IkWt1a5po6g683nIgSnGpwYIwuJheBqSEZfLYWa+1KdD 6Sn27Ud94GqUvPVG5jC6zVC5EJ2aWuoAu+nNuV8CAwEAAaM5MDcwJwYDVR0RBCAwHoEcamFs dG1hbkBzZWN1cmUtZW5kcG9pbnRzLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUA A4GBADtvO//tjiAV6VJGtoNtrl34mB5jGyGTiotzw8riB6zz0GvY11bcWDmp6JKif+pVG+8L IySDosbuva13qu2HwYUxBmWc7CoNd2k9kRlcrfbDUTTrGOZK8qyqNqT3gQZTAa9ZnUI0su9G y/n2o5bQcaYdqR3htNrpvdLSPOWhILOXMIIDCjCCAnOgAwIBAgIDDs2tMA0GCSqGSIb3DQEB BAUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0w NTA1MjcxNzQ3NTdaFw0wNjA1MjcxNzQ3NTdaMHMxDzANBgNVBAQTBkFsdG1hbjEVMBMGA1UE KhMMSmVmZnJleSBFcmljMRwwGgYDVQQDExNKZWZmcmV5IEVyaWMgQWx0bWFuMSswKQYJKoZI hvcNAQkBFhxqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAqM/KsX6t2M5RIr9tbBkd3HmnX7LqKIJ3i+9gRUPGi5gWnkL99kRa bmfjm5sFRsxJQjUwBk3qigSgfT1ROPoFeExLwH3zuWzzV0o4hSmFMXaM7OryCwWZ4DXnIcxE APbQupRZ4vK9iTwUI1DD52wowyFf5Z2zE6ZFj/WM+Qkvqg3yQTChQWQ5f3859ZaHqgWdXp9q IQdQoMwW5uxv1fQpUPyIh5HsLHPuLiRepFfAyWnZ/KjFwMgmsFpNjycD76DenfgiRa3Vrmmj qDrzeciBKcanBgjC4mF4GpIRl8thZr7Up0PpKfbtR33gapS89UbmMLrNULkQnZpa6gC76c25 XwIDAQABozkwNzAnBgNVHREEIDAegRxqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMuY29tMAwG A1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAO287/+2OIBXpUka2g22uXfiYHmMbIZOK i3PDyuIHrPPQa9jXVtxYOanokqJ/6lUb7wsjJIOixu69rXeq7YfBhTEGZZzsKg13aT2RGVyt 9sNRNOsY5kryrKo2pPeBBlMBr1mdQjSy70bL+fajltBxph2pHeG02um90tI85aEgs5cwggM/ MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMM V2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25z dWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYD VQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNv bmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5 WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRk LjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2 vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9 A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEw EgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0 ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYDVR0R BCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GB AEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZ Ohl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVN d+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDOzCCAzcCAQEwaTBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrTAJBgUrDgMCGgUAoIIBpzAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjAyMjIxNjIzNTZaMCMGCSqG SIb3DQEJBDEWBBQh5CoCVXykHaCQOsqYERtDhITDVDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDB4BgkrBgEEAYI3EAQxazBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQQIDDs2tMHoGCyqGSIb3DQEJEAILMWugaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrTANBgkqhkiG9w0BAQEFAASC AQCGRvy83o5qu0eFtw2hVbFwIEELS55eFs91EAG6N6SqvQ/RhdjjwExgaPBY8uZB/gtcNbMZ 5onhSsrXvU1asbvA/Bi0/sxewL4OaB2PSOHRkxItqIVJ+Yl3quH3IuaEdURigH1NrFr6UFgF kzi6ENV5/V986PZUkD/SFb2QOa7xyUx2sItH+kB9I0Kov81PXmdFNEJTJv/xG0TblvOu08UX dl+UeqZvEwEXhQF4D1ImO39jThKn19i8daUbstSu1rE06B7bowcXOUXYcJ+KWMX9Db6r5Jh8 HuOOLn+GTA4aApYrpCYRV5KnBwHGW1bRvrNKZcEQtMhZcmem+uY9E21TAAAAAAAA --------------ms040707010903060107020200-- From tcreedon@easystreet.com Wed Feb 22 11:29:00 2006 Received: from smtpauth.newman.easystreet.com ([206.102.12.11] helo=smtpauth.easystreet.com) by michigan.central.org with esmtp (Exim 4.50) id 1FBwrM-0001bz-C1 for afs3-standardization@openafs.org; Wed, 22 Feb 2006 11:29:00 -0500 Received: from attu1 (c-24-20-41-88.hsd1.or.comcast.net [24.20.41.88]) by smtpauth.easystreet.com (Postfix) with ESMTP id 77741B0AF; Wed, 22 Feb 2006 08:28:56 -0800 (PST) From: "ted creedon" Date: Wed, 22 Feb 2006 08:28:49 -0800 Organization: creedon engineering Message-ID: <007f01c637cd$0f8dea60$c901010a@home.teddoris.fam> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <43FC901C.9010801@secure-endpoints.com> Thread-Index: AcY3zELJLR1iakJBRpq3dDOU/P6XdwAAJ1HA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-SA-Exim-Connect-IP: 206.102.12.11 X-SA-Exim-Rcpt-To: afs3-standardization@openafs.org X-SA-Exim-Mail-From: tcreedon@easystreet.com Subject: RE: [AFS3-std] Re: Standardization of the AFS3 protocol X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on michigan.central.org X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL, BAYES_00, MISSING_HEADERS autolearn=ham version=3.0.3 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on michigan.central.org) Cc: afs3-standardization@openafs.org, afs3-protocol@stacken.kth.se X-BeenThere: afs3-standardization@openafs.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tcreedon@easystreet.com List-Id: Standardizing the AFS 3 Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2006 16:29:00 -0000 Yes but revisions should be indicated with margin stripes and code snippets in verbatim. tedc -----Original Message----- From: afs3-standardization-bounces@openafs.org [mailto:afs3-standardization-bounces@openafs.org] On Behalf Of Jeffrey Altman Sent: Wednesday, February 22, 2006 8:24 AM To: tcreedon@easystreet.com Cc: afs3-standardization@openafs.org; afs3-protocol@stacken.kth.se Subject: Re: [AFS3-std] Re: Standardization of the AFS3 protocol ted creedon wrote: > The documentation could be done here, but it would be in LaTex. > > There will be a new LaTex based release of the OpenAFS docs as soon as some > changes are created. > > Tedc Ted: Protocol documentation and OpenAFS End User and Administrator documentation are two completely different things. Protocol documentation is traditionally published in plain text. Jeffrey Altman From jaltman@secure-endpoints.com Wed Feb 22 11:37:52 2006 Received: from brinza.cc.columbia.edu ([128.59.29.8] ident=cu41754) by michigan.central.org with esmtp (Exim 4.50) id 1FBwzu-0001cw-QX for afs3-standardization@openafs.org; Wed, 22 Feb 2006 11:37:52 -0500 Received: from [192.168.1.11] (cpe-68-175-91-105.nyc.res.rr.com [68.175.91.105]) (user=jaltman mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id k1MGbcK0014209 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Feb 2006 11:37:42 -0500 (EST) Message-ID: <43FC9393.8080801@secure-endpoints.com> Date: Wed, 22 Feb 2006 11:38:43 -0500 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: tcreedon@easystreet.com References: <007f01c637cd$0f8dea60$c901010a@home.teddoris.fam> In-Reply-To: <007f01c637cd$0f8dea60$c901010a@home.teddoris.fam> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030309060907070909010805" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-SA-Exim-Connect-IP: 128.59.29.8 X-SA-Exim-Rcpt-To: afs3-standardization@openafs.org X-SA-Exim-Mail-From: jaltman@secure-endpoints.com Subject: Re: [AFS3-std] Re: Standardization of the AFS3 protocol X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on michigan.central.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on michigan.central.org) Cc: afs3-standardization@openafs.org, afs3-protocol@stacken.kth.se X-BeenThere: afs3-standardization@openafs.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standardizing the AFS 3 Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2006 16:37:52 -0000 This is a cryptographically signed message in MIME format. --------------ms030309060907070909010805 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit ted creedon wrote: > Yes but revisions should be indicated with margin stripes and code snippets > in verbatim. > > tedc Revisions are indicated by publications of new versions. If you are interested in seeing how protocol standards are formatted, please review the archive of IETF RFCs at http://www.rfc-editor.org and the guidelines to authors of Internet Drafts at http://www.ietf.org/ietf/1id-guidelines.html If RX was to be documented, the intention would be to publish the specification as an IETF Informational RFC. As such the documents would have to follow the required guidelines. Jeffrey Altman --------------ms030309060907070909010805 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJXzCC AwowggJzoAMCAQICAw7NrTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwNTI3MTc0NzU3WhcNMDYwNTI3MTc0NzU3 WjBzMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjErMCkGCSqGSIb3DQEJARYcamFsdG1hbkBzZWN1cmUtZW5k cG9pbnRzLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKjPyrF+rdjOUSK/ bWwZHdx5p1+y6iiCd4vvYEVDxouYFp5C/fZEWm5n45ubBUbMSUI1MAZN6ooEoH09UTj6BXhM S8B987ls81dKOIUphTF2jOzq8gsFmeA15yHMRAD20LqUWeLyvYk8FCNQw+dsKMMhX+WdsxOm RY/1jPkJL6oN8kEwoUFkOX9/OfWWh6oFnV6faiEHUKDMFubsb9X0KVD8iIeR7Cxz7i4kXqRX wMlp2fyoxcDIJrBaTY8nA++g3p34IkWt1a5po6g683nIgSnGpwYIwuJheBqSEZfLYWa+1KdD 6Sn27Ud94GqUvPVG5jC6zVC5EJ2aWuoAu+nNuV8CAwEAAaM5MDcwJwYDVR0RBCAwHoEcamFs dG1hbkBzZWN1cmUtZW5kcG9pbnRzLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUA A4GBADtvO//tjiAV6VJGtoNtrl34mB5jGyGTiotzw8riB6zz0GvY11bcWDmp6JKif+pVG+8L IySDosbuva13qu2HwYUxBmWc7CoNd2k9kRlcrfbDUTTrGOZK8qyqNqT3gQZTAa9ZnUI0su9G y/n2o5bQcaYdqR3htNrpvdLSPOWhILOXMIIDCjCCAnOgAwIBAgIDDs2tMA0GCSqGSIb3DQEB BAUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0w NTA1MjcxNzQ3NTdaFw0wNjA1MjcxNzQ3NTdaMHMxDzANBgNVBAQTBkFsdG1hbjEVMBMGA1UE KhMMSmVmZnJleSBFcmljMRwwGgYDVQQDExNKZWZmcmV5IEVyaWMgQWx0bWFuMSswKQYJKoZI hvcNAQkBFhxqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAqM/KsX6t2M5RIr9tbBkd3HmnX7LqKIJ3i+9gRUPGi5gWnkL99kRa bmfjm5sFRsxJQjUwBk3qigSgfT1ROPoFeExLwH3zuWzzV0o4hSmFMXaM7OryCwWZ4DXnIcxE APbQupRZ4vK9iTwUI1DD52wowyFf5Z2zE6ZFj/WM+Qkvqg3yQTChQWQ5f3859ZaHqgWdXp9q IQdQoMwW5uxv1fQpUPyIh5HsLHPuLiRepFfAyWnZ/KjFwMgmsFpNjycD76DenfgiRa3Vrmmj qDrzeciBKcanBgjC4mF4GpIRl8thZr7Up0PpKfbtR33gapS89UbmMLrNULkQnZpa6gC76c25 XwIDAQABozkwNzAnBgNVHREEIDAegRxqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMuY29tMAwG A1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAO287/+2OIBXpUka2g22uXfiYHmMbIZOK i3PDyuIHrPPQa9jXVtxYOanokqJ/6lUb7wsjJIOixu69rXeq7YfBhTEGZZzsKg13aT2RGVyt 9sNRNOsY5kryrKo2pPeBBlMBr1mdQjSy70bL+fajltBxph2pHeG02um90tI85aEgs5cwggM/ MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMM V2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25z dWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYD VQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNv bmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5 WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRk LjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2 vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9 A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEw EgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0 ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYDVR0R BCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GB AEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZ Ohl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVN d+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDOzCCAzcCAQEwaTBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrTAJBgUrDgMCGgUAoIIBpzAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjAyMjIxNjM4NDNaMCMGCSqG SIb3DQEJBDEWBBQH3+yc9NEAgLPQmSTk5kq5MFs6bTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDB4BgkrBgEEAYI3EAQxazBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQQIDDs2tMHoGCyqGSIb3DQEJEAILMWugaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrTANBgkqhkiG9w0BAQEFAASC AQBIH89w8KiVoYqXgRe6tEBPCgYU9LO9qiv78CHVpF2oN8ivc5+wQEyVy6kap1VV0TCAfzOV 1kdKkDo68CgkqmfWeHW1sz3d6q/gHGel6QnMibw1xnXdzv8MJgDi8UJ9a2+n7jwT/EpwN25v A8WePMWmHFU2iVsDaKzoZVfLgIMrh2pMPN5IXKCDypMdnh4vH5TpBK6uCKfyHaIRUns7rAHk jAAOGGckRqgtJRLD3/cgz0HuJbuSyOYUtWZuZP0LOD9ZTOjMyVMhy7u0i9AkFuh8iHuDYHQl kUT4qp84j8x00sAr0rZrFWrXksbBpT7E3Wd/+6W/1haNSogDMPY5J2ddAAAAAAAA --------------ms030309060907070909010805-- From jhutz@cmu.edu Wed Feb 22 11:58:45 2006 Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by michigan.central.org with smtp (Exim 4.50) id 1FBxK8-0001eY-Mz for afs3-standardization@openafs.org; Wed, 22 Feb 2006 11:58:45 -0500 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa09976; 22 Feb 2006 11:58 EST Date: Wed, 22 Feb 2006 11:58:37 -0500 (EST) From: Jeffrey Hutzelman X-X-Sender: To: ted creedon In-Reply-To: <007f01c637cd$0f8dea60$c901010a@home.teddoris.fam> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SA-Exim-Connect-IP: 128.2.185.161 X-SA-Exim-Rcpt-To: afs3-standardization@openafs.org X-SA-Exim-Mail-From: jhutz@cmu.edu Subject: RE: [AFS3-std] Re: Standardization of the AFS3 protocol X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on michigan.central.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on michigan.central.org) Cc: afs3-standardization@openafs.org, afs3-protocol@stacken.kth.se X-BeenThere: afs3-standardization@openafs.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standardizing the AFS 3 Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2006 16:58:45 -0000 On Wed, 22 Feb 2006, ted creedon wrote: > Yes but revisions should be indicated with margin stripes and code snippets > in verbatim. Ted, do you have any experience at all with defining and standardizing network protocols? Perhaps more importantly, do you have any understanding of the inner workings of the rx protocol? These are serious questions. The documentation David is looking for is not "to do X, type command Y" or even "I made these changes to the code today in the hopes of achieving goal foo". What he is looking for is complete details of the exact bits that appear on the wire and their semantics, including which combinations are required, recommended, or prohibited, how all the edge cases work, and a description of the abstract state machine required to implement the protocol correctly. In other words, he wants all the documentation he would need to write a correct, interoperable implementation from scratch. That is, a protocol specification. Unfortunately, no such specification exists today. All we do have is a reference implementation, which itself is quite hairy and difficult to understand, especially if one is not already familiar with the protocol and its history. There are many warts related to backward-compatibility with earlier versions of the code. There is also quite a lot of code related to features that seemed like a good idea at the time, but actually were not, and should never be enabled. A good protocol specification would describe these, but would recommend against doing them, if not outright prohibit doing so (for example, deliberately sending IP datagrams several times the MTU size) Writing down a protocol specification for Rx will require sifting through the code, including all three current branches (IBM AFS, OpenAFS, and Arla all use diverging versions of Rx deriving from the same original codebase) as well as historical versions, figuring out what's there because it's needed for the protocl to work, what are/should be optional vs required features, and what are simply artifacts of the implementation. Rx is a complex, multi-layered protocol, and it is likely that documenting it correctly will require more effort than all of the AFS RPC protocols put together. Still, I think the effort is worthwhile, and I'm willing to spend some of my own time on it, if others are as well. I would very much like to see a truly independent complete, interoperable implementation of Rx, which is something that we do not have today. -- Jeff From jhutz@cmu.edu Wed Feb 22 12:09:29 2006 Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by michigan.central.org with smtp (Exim 4.50) id 1FBxUW-0001gE-CA for afs3-standardization@openafs.org; Wed, 22 Feb 2006 12:09:29 -0500 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa10131; 22 Feb 2006 12:08 EST Date: Wed, 22 Feb 2006 12:08:46 -0500 (EST) From: Jeffrey Hutzelman X-X-Sender: To: Jeffrey Altman In-Reply-To: <43FC9393.8080801@secure-endpoints.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SA-Exim-Connect-IP: 128.2.185.161 X-SA-Exim-Rcpt-To: afs3-standardization@openafs.org X-SA-Exim-Mail-From: jhutz@cmu.edu Subject: Re: [AFS3-std] Re: Standardization of the AFS3 protocol X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on michigan.central.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on michigan.central.org) Cc: tcreedon@easystreet.com, afs3-protocol@stacken.kth.se, afs3-standardization@openafs.org X-BeenThere: afs3-standardization@openafs.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standardizing the AFS 3 Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2006 17:09:29 -0000 On Wed, 22 Feb 2006, Jeffrey Altman wrote: > If RX was to be documented, the intention would be to publish the > specification as an IETF Informational RFC. As multiple documents, I think. One describing the UDP-based transport later, another the session layer, and a third for the RPC layer (the last in terms of XDR, which is already an IETF protocol). Plus one for each security class, and one for RXTCP, when that is mature enough. Jeff, it is worth noting that the IETF's way of publishing protocol specifications is not the only way. There is nothing that says we can't write all of our protocol specs in, say, MacWrite and put those documents up on grand.central.org (one of whose purposes has always been to publish AFS protocol documentation, if anyone ever wrote any). However, given the people who are and have been actively involved in AFS protocol work, it is much more likely that we'll want to do something sane, like develop documents in the form of I-D's and then publish them either as RFC's or independently. It is probably also worth documenting the .xg language, so that RPC-layer protocols can be documented partially in the form of definitions written in that language. From jaltman@secure-endpoints.com Wed Feb 22 12:14:33 2006 Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754) by michigan.central.org with esmtp (Exim 4.50) id 1FBxZR-0001hB-6d for afs3-standardization@openafs.org; Wed, 22 Feb 2006 12:14:33 -0500 Received: from [192.168.1.11] (cpe-68-175-91-105.nyc.res.rr.com [68.175.91.105]) (user=jaltman mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id k1MHETid025837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Feb 2006 12:14:29 -0500 (EST) Message-ID: <43FC9C43.70008@secure-endpoints.com> Date: Wed, 22 Feb 2006 12:15:47 -0500 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Jeffrey Hutzelman References: In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070705030307060302060108" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-SA-Exim-Connect-IP: 128.59.29.5 X-SA-Exim-Rcpt-To: afs3-standardization@openafs.org X-SA-Exim-Mail-From: jaltman@secure-endpoints.com Subject: Re: [AFS3-std] Re: Standardization of the AFS3 protocol X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on michigan.central.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on michigan.central.org) Cc: afs3-standardization@openafs.org, afs3-protocol@stacken.kth.se X-BeenThere: afs3-standardization@openafs.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standardizing the AFS 3 Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2006 17:14:33 -0000 This is a cryptographically signed message in MIME format. --------------ms070705030307060302060108 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Jeffrey Hutzelman wrote: > On Wed, 22 Feb 2006, Jeffrey Altman wrote: > >> If RX was to be documented, the intention would be to publish the >> specification as an IETF Informational RFC. > > As multiple documents, I think. One describing the UDP-based transport > later, another the session layer, and a third for the RPC layer (the last > in terms of XDR, which is already an IETF protocol). Plus one for each > security class, and one for RXTCP, when that is mature enough. I completely agree. This is how we have published all of the Kerberos and GSS-API protocols over the years. It makes it much easier to understand protocol and allow for updates to be published. Not to mention it makes it easier to get started since we can document the new work as we develop it. > Jeff, it is worth noting that the IETF's way of publishing protocol > specifications is not the only way. There is nothing that says we can't > write all of our protocol specs in, say, MacWrite and put those documents > up on grand.central.org (one of whose purposes has always been to publish > AFS protocol documentation, if anyone ever wrote any). of course not but ... > However, given the > people who are and have been actively involved in AFS protocol work, it is > much more likely that we'll want to do something sane, like develop > documents in the form of I-D's and then publish them either as RFC's or > independently. this was the important point > It is probably also worth documenting the .xg language, so that RPC-layer > protocols can be documented partially in the form of definitions written > in that language. Absolutely. Jeffrey Altman --------------ms070705030307060302060108 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJXzCC AwowggJzoAMCAQICAw7NrTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwNTI3MTc0NzU3WhcNMDYwNTI3MTc0NzU3 WjBzMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjErMCkGCSqGSIb3DQEJARYcamFsdG1hbkBzZWN1cmUtZW5k cG9pbnRzLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKjPyrF+rdjOUSK/ bWwZHdx5p1+y6iiCd4vvYEVDxouYFp5C/fZEWm5n45ubBUbMSUI1MAZN6ooEoH09UTj6BXhM S8B987ls81dKOIUphTF2jOzq8gsFmeA15yHMRAD20LqUWeLyvYk8FCNQw+dsKMMhX+WdsxOm RY/1jPkJL6oN8kEwoUFkOX9/OfWWh6oFnV6faiEHUKDMFubsb9X0KVD8iIeR7Cxz7i4kXqRX wMlp2fyoxcDIJrBaTY8nA++g3p34IkWt1a5po6g683nIgSnGpwYIwuJheBqSEZfLYWa+1KdD 6Sn27Ud94GqUvPVG5jC6zVC5EJ2aWuoAu+nNuV8CAwEAAaM5MDcwJwYDVR0RBCAwHoEcamFs dG1hbkBzZWN1cmUtZW5kcG9pbnRzLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUA A4GBADtvO//tjiAV6VJGtoNtrl34mB5jGyGTiotzw8riB6zz0GvY11bcWDmp6JKif+pVG+8L IySDosbuva13qu2HwYUxBmWc7CoNd2k9kRlcrfbDUTTrGOZK8qyqNqT3gQZTAa9ZnUI0su9G y/n2o5bQcaYdqR3htNrpvdLSPOWhILOXMIIDCjCCAnOgAwIBAgIDDs2tMA0GCSqGSIb3DQEB BAUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0w NTA1MjcxNzQ3NTdaFw0wNjA1MjcxNzQ3NTdaMHMxDzANBgNVBAQTBkFsdG1hbjEVMBMGA1UE KhMMSmVmZnJleSBFcmljMRwwGgYDVQQDExNKZWZmcmV5IEVyaWMgQWx0bWFuMSswKQYJKoZI hvcNAQkBFhxqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAqM/KsX6t2M5RIr9tbBkd3HmnX7LqKIJ3i+9gRUPGi5gWnkL99kRa bmfjm5sFRsxJQjUwBk3qigSgfT1ROPoFeExLwH3zuWzzV0o4hSmFMXaM7OryCwWZ4DXnIcxE APbQupRZ4vK9iTwUI1DD52wowyFf5Z2zE6ZFj/WM+Qkvqg3yQTChQWQ5f3859ZaHqgWdXp9q IQdQoMwW5uxv1fQpUPyIh5HsLHPuLiRepFfAyWnZ/KjFwMgmsFpNjycD76DenfgiRa3Vrmmj qDrzeciBKcanBgjC4mF4GpIRl8thZr7Up0PpKfbtR33gapS89UbmMLrNULkQnZpa6gC76c25 XwIDAQABozkwNzAnBgNVHREEIDAegRxqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMuY29tMAwG A1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAO287/+2OIBXpUka2g22uXfiYHmMbIZOK i3PDyuIHrPPQa9jXVtxYOanokqJ/6lUb7wsjJIOixu69rXeq7YfBhTEGZZzsKg13aT2RGVyt 9sNRNOsY5kryrKo2pPeBBlMBr1mdQjSy70bL+fajltBxph2pHeG02um90tI85aEgs5cwggM/ MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMM V2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25z dWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYD VQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNv bmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5 WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRk LjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2 vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9 A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEw EgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0 ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYDVR0R BCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GB AEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZ Ohl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVN d+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDOzCCAzcCAQEwaTBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrTAJBgUrDgMCGgUAoIIBpzAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjAyMjIxNzE1NDdaMCMGCSqG SIb3DQEJBDEWBBTvLHftS3w4vcUbaF98bJoAcCtkCDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDB4BgkrBgEEAYI3EAQxazBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQQIDDs2tMHoGCyqGSIb3DQEJEAILMWugaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrTANBgkqhkiG9w0BAQEFAASC AQCM3n9ShT+YIKS09hO3QDyGfhPyiZs3Kw1b9eoJwZQT3Tli6yqWVjFe84W253z6e79BDiqq ywbr6dmMjRxk0GXZYwb6mo5B42YeNuQ7q1x/JJi7KNhOukWm9//t84EGasyL8INzHD+o9VID diI5wP4129aIVE/8ewk32Ak1THseXEVhPCo1Coeq/ou/76QVV8xAjVg/1pSxks0tHjA5cCNG zPAUQ4DDOntQvyluRHhbY3cFyM7++XNzOxJ9yEs8LPZ6kTPg6Vzxr9/Mu2/c5WKcGVhYNtfQ v1SzwnaZiuJFnbV6GfLE71tyRC6halWanvDTJXtllD5+0/SlgL8d8NN9AAAAAAAA --------------ms070705030307060302060108-- From tcreedon@easystreet.com Wed Feb 22 12:25:17 2006 Received: from smtpauth.newman.easystreet.com ([206.102.12.11] helo=smtpauth.easystreet.com) by michigan.central.org with esmtp (Exim 4.50) id 1FBxjp-0001ig-4A for afs3-standardization@openafs.org; Wed, 22 Feb 2006 12:25:17 -0500 Received: from attu1 (c-24-20-41-88.hsd1.or.comcast.net [24.20.41.88]) by smtpauth.easystreet.com (Postfix) with ESMTP id C7C5AB0D0; Wed, 22 Feb 2006 09:25:15 -0800 (PST) From: "ted creedon" Date: Wed, 22 Feb 2006 09:25:15 -0800 Organization: creedon engineering Message-ID: <009c01c637d4$f2574d80$c901010a@home.teddoris.fam> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcY30UJ/aSp3ZeGdSZiv0rIRzq6A0wAAnR7Q X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-SA-Exim-Connect-IP: 206.102.12.11 X-SA-Exim-Rcpt-To: afs3-standardization@openafs.org X-SA-Exim-Mail-From: tcreedon@easystreet.com Subject: RE: [AFS3-std] Re: Standardization of the AFS3 protocol X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on michigan.central.org X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL, BAYES_00, MISSING_HEADERS autolearn=ham version=3.0.3 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on michigan.central.org) Cc: afs3-standardization@openafs.org, afs3-protocol@stacken.kth.se X-BeenThere: afs3-standardization@openafs.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tcreedon@easystreet.com List-Id: Standardizing the AFS 3 Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2006 17:25:18 -0000 There are 2 sets of skills required: 1. Computer science - understanding the protocol - that's for others 2. Written - making publication quality English of the above End of thread. tedc -----Original Message----- From: afs3-standardization-bounces@openafs.org [mailto:afs3-standardization-bounces@openafs.org] On Behalf Of Jeffrey Hutzelman Sent: Wednesday, February 22, 2006 8:59 AM To: ted creedon Cc: afs3-standardization@openafs.org; afs3-protocol@stacken.kth.se Subject: RE: [AFS3-std] Re: Standardization of the AFS3 protocol On Wed, 22 Feb 2006, ted creedon wrote: > Yes but revisions should be indicated with margin stripes and code snippets > in verbatim. Ted, do you have any experience at all with defining and standardizing network protocols? Perhaps more importantly, do you have any understanding of the inner workings of the rx protocol? These are serious questions. The documentation David is looking for is not "to do X, type command Y" or even "I made these changes to the code today in the hopes of achieving goal foo". What he is looking for is complete details of the exact bits that appear on the wire and their semantics, including which combinations are required, recommended, or prohibited, how all the edge cases work, and a description of the abstract state machine required to implement the protocol correctly. In other words, he wants all the documentation he would need to write a correct, interoperable implementation from scratch. That is, a protocol specification. Unfortunately, no such specification exists today. All we do have is a reference implementation, which itself is quite hairy and difficult to understand, especially if one is not already familiar with the protocol and its history. There are many warts related to backward-compatibility with earlier versions of the code. There is also quite a lot of code related to features that seemed like a good idea at the time, but actually were not, and should never be enabled. A good protocol specification would describe these, but would recommend against doing them, if not outright prohibit doing so (for example, deliberately sending IP datagrams several times the MTU size) Writing down a protocol specification for Rx will require sifting through the code, including all three current branches (IBM AFS, OpenAFS, and Arla all use diverging versions of Rx deriving from the same original codebase) as well as historical versions, figuring out what's there because it's needed for the protocl to work, what are/should be optional vs required features, and what are simply artifacts of the implementation. Rx is a complex, multi-layered protocol, and it is likely that documenting it correctly will require more effort than all of the AFS RPC protocols put together. Still, I think the effort is worthwhile, and I'm willing to spend some of my own time on it, if others are as well. I would very much like to see a truly independent complete, interoperable implementation of Rx, which is something that we do not have today. -- Jeff _______________________________________________ AFS3-standardization mailing list AFS3-standardization@openafs.org //michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization From jhutz@cmu.edu Wed Feb 22 12:27:40 2006 Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by michigan.central.org with smtp (Exim 4.50) id 1FBxm7-0001kM-Bn for afs3-standardization@openafs.org; Wed, 22 Feb 2006 12:27:40 -0500 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa10402; 22 Feb 2006 12:26 EST Date: Wed, 22 Feb 2006 12:26:54 -0500 (EST) From: Jeffrey Hutzelman X-X-Sender: To: Jeffrey Altman In-Reply-To: <43FC7BB6.9040604@secure-endpoints.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SA-Exim-Connect-IP: 128.2.185.161 X-SA-Exim-Rcpt-To: afs3-standardization@openafs.org X-SA-Exim-Mail-From: jhutz@cmu.edu Subject: Re: [AFS3-std] Standardization of the AFS3 protocol X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on michigan.central.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on michigan.central.org) Cc: Harald Barth , Love , afs3-standardization@openafs.org, afs3-protocol@stacken.kth.se, Ken Hornstein X-BeenThere: afs3-standardization@openafs.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standardizing the AFS 3 Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2006 17:27:41 -0000 On Wed, 22 Feb 2006, Jeffrey Altman wrote: > However, this does not mean that developers can go off willy nilly > making changes to RX, adding new service RPCs or altering the behavior > of existing service RPCs. There needs to be a process setup by which > a rough consensus can be achieved on proposed changes in a forum that > will be archived so that crucial knowledge will not be lost. Traditionally, discussion of these sorts of changes has happened via email and/or zephyr, with occasional face-to-face meetings in the form of hackathons which have been held periodically since 2001. For example, the current mechanism for coordinating RPC and pioctl numbers exists because of a need recognized at the first hackathon, and the ways in which those numbers are chosen (assigning new RPC numbers starting at 0x10000, having separate pioctl namespaces for each implementation) are the result of discussions at the same meeting. A large part of what we're trying to accomplish now is a process for designing and specifying protocol changes which is more open, both to observers and would-be participants, and which ultimately results in any protocol changes being well-defined, so that we all know how things are expected to behave. This is critical in orde to know when we make a change in the future that it will not have bad effects. For example, the behavior of the VolSetInfo RPC has now changed more than once in ways that are not backward-compatible, such that older clients may change fields they did not intend to change. Part of the goal is to avoid this sort of lossage in the future. > The afs3-standardization@openafs.org mailing list has been created to > be the discussion forum. At the present time a web interface for > subscribing can be found at > > http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization Once the mailing list transition is complete, michigan-openafs-lists will become lists.openafs.org, and this list will appear alongside all the others. In the meantime, please bear with us. -- Jeff From ota@us.ibm.com Thu Feb 23 06:17:38 2006 Received: from e4.ny.us.ibm.com ([32.97.182.144]) by michigan.central.org with esmtp (Exim 4.50) id 1FCETZ-0003wS-Ah for afs3-standardization@openafs.org; Thu, 23 Feb 2006 06:17:38 -0500 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e4.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id k1NBH6Aj015437 for ; Thu, 23 Feb 2006 06:17:06 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id k1NBH6Z0227018 for ; Thu, 23 Feb 2006 06:17:06 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.13.3) with ESMTP id k1NBH6Se006971 for ; Thu, 23 Feb 2006 06:17:06 -0500 Received: from d01ml604.pok.ibm.com (d01ml604.pok.ibm.com [9.56.227.90]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id k1NBH6uU006968; Thu, 23 Feb 2006 06:17:06 -0500 In-Reply-To: To: Jeffrey Altman MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF2 July 23, 2003 From: Ted Anderson Message-ID: Date: Thu, 23 Feb 2006 07:17:03 -0400 X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Release 7.0HF124 | January 12, 2006) at 02/23/2006 06:17:05, Serialize complete at 02/23/2006 06:17:05 Content-Type: text/plain; charset="US-ASCII" X-SA-Exim-Connect-IP: 32.97.182.144 X-SA-Exim-Rcpt-To: afs3-standardization@openafs.org X-SA-Exim-Mail-From: ota@us.ibm.com X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on michigan.central.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.3 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on michigan.central.org) Cc: afs3-standardization@openafs.org, afs3-protocol@stacken.kth.se Subject: [AFS3-std] Re: Welcome to the "AFS3-standardization" mailing list X-BeenThere: afs3-standardization@openafs.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standardizing the AFS 3 Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2006 11:17:38 -0000 afs3-standardization-bounces+ota=us.ibm.com@openafs.org wrote on 02/22/2006 20:34:23: > Welcome to the AFS3-standardization@openafs.org mailing list! > > To post to this list, send your email to: > > afs3-standardization@openafs.org > > General information about the mailing list is at: > > http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization Why is the mailing lists hosted at this new host and not with the other OpenAFS mailing lists? Likewise, there is no mention of the list on www.openafs.org. Also, it seems that the archives for this new list don't exist yet. Server problems in Pittsburgh? I haven't been able to follow the development mailing list lately, but I didn't see an announcement of this new mailing list in the archives of OpenAFS-devel or received any thing on OpenAFS-announce. Maybe it would be good to spread the news more widely to encourage wider participation. Ted From jaltman@secure-endpoints.com Thu Feb 23 09:17:11 2006 Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754) by michigan.central.org with esmtp (Exim 4.50) id 1FCHHK-0004E5-31 for afs3-standardization@openafs.org; Thu, 23 Feb 2006 09:17:11 -0500 Received: from [192.168.1.11] (cpe-68-175-91-105.nyc.res.rr.com [68.175.91.105]) (user=jaltman mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id k1NEGq9Y024674 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 23 Feb 2006 09:16:57 -0500 (EST) Message-ID: <43FDC3FF.60909@secure-endpoints.com> Date: Thu, 23 Feb 2006 09:17:35 -0500 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Ted Anderson References: In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060301000700010807040102" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-SA-Exim-Connect-IP: 128.59.29.6 X-SA-Exim-Rcpt-To: afs3-standardization@openafs.org X-SA-Exim-Mail-From: jaltman@secure-endpoints.com Subject: Re: [AFS3-std] Re: Welcome to the "AFS3-standardization" mailing list X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on michigan.central.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on michigan.central.org) Cc: afs3-standardization@openafs.org, afs3-protocol@stacken.kth.se X-BeenThere: afs3-standardization@openafs.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standardizing the AFS 3 Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2006 14:17:11 -0000 This is a cryptographically signed message in MIME format. --------------ms060301000700010807040102 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Ted Anderson wrote: > afs3-standardization-bounces+ota=us.ibm.com@openafs.org wrote on > 02/22/2006 20:34:23: >> Welcome to the AFS3-standardization@openafs.org mailing list! >> >> To post to this list, send your email to: >> >> afs3-standardization@openafs.org >> >> General information about the mailing list is at: >> >> > http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization > > Why is the mailing lists hosted at this new host and not with the other > OpenAFS mailing lists? Likewise, there is no mention of the list on > www.openafs.org. Also, it seems that the archives for this new list don't > exist yet. Server problems in Pittsburgh? The openafs.org services are in the process of being upgraded as part of a migration to a new server. Quoting Jeffrey Hutzelman on this list yesterday: "Once the mailing list transition is complete, michigan-openafs-lists will become lists.openafs.org, and this list will appear alongside all the others. In the meantime, please bear with us." > I haven't been able to follow the development mailing list lately, but I > didn't see an announcement of this new mailing list in the archives of > OpenAFS-devel or received any thing on OpenAFS-announce. Maybe it would > be good to spread the news more widely to encourage wider participation. This mailing list info was posted to openafs-devel last week as part of the continuing discussion on development schedules and byte range locking. Several months earlier there was an effort to conduct these discussions on afs3-protocol@stacken.kth.se but the only response to my postings there were from Jeffrey Hutzelman who I specifically asked to join. Wider participation is great but at the moment the primary concern is to provide a forum for those who have been actively attending the hackathons and contributing to the protocol extensions currently under development. This list is for the discussion of the wire protocols not implementations. The OpenAFS implementations are discussed on openafs-devel@openafs.org and the Arla implementations are discussed on arla-drinkers@stacken.kth.se. --------------ms060301000700010807040102 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJXzCC AwowggJzoAMCAQICAw7NrTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwNTI3MTc0NzU3WhcNMDYwNTI3MTc0NzU3 WjBzMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjErMCkGCSqGSIb3DQEJARYcamFsdG1hbkBzZWN1cmUtZW5k cG9pbnRzLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKjPyrF+rdjOUSK/ bWwZHdx5p1+y6iiCd4vvYEVDxouYFp5C/fZEWm5n45ubBUbMSUI1MAZN6ooEoH09UTj6BXhM S8B987ls81dKOIUphTF2jOzq8gsFmeA15yHMRAD20LqUWeLyvYk8FCNQw+dsKMMhX+WdsxOm RY/1jPkJL6oN8kEwoUFkOX9/OfWWh6oFnV6faiEHUKDMFubsb9X0KVD8iIeR7Cxz7i4kXqRX wMlp2fyoxcDIJrBaTY8nA++g3p34IkWt1a5po6g683nIgSnGpwYIwuJheBqSEZfLYWa+1KdD 6Sn27Ud94GqUvPVG5jC6zVC5EJ2aWuoAu+nNuV8CAwEAAaM5MDcwJwYDVR0RBCAwHoEcamFs dG1hbkBzZWN1cmUtZW5kcG9pbnRzLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUA A4GBADtvO//tjiAV6VJGtoNtrl34mB5jGyGTiotzw8riB6zz0GvY11bcWDmp6JKif+pVG+8L IySDosbuva13qu2HwYUxBmWc7CoNd2k9kRlcrfbDUTTrGOZK8qyqNqT3gQZTAa9ZnUI0su9G y/n2o5bQcaYdqR3htNrpvdLSPOWhILOXMIIDCjCCAnOgAwIBAgIDDs2tMA0GCSqGSIb3DQEB BAUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0w NTA1MjcxNzQ3NTdaFw0wNjA1MjcxNzQ3NTdaMHMxDzANBgNVBAQTBkFsdG1hbjEVMBMGA1UE KhMMSmVmZnJleSBFcmljMRwwGgYDVQQDExNKZWZmcmV5IEVyaWMgQWx0bWFuMSswKQYJKoZI hvcNAQkBFhxqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAqM/KsX6t2M5RIr9tbBkd3HmnX7LqKIJ3i+9gRUPGi5gWnkL99kRa bmfjm5sFRsxJQjUwBk3qigSgfT1ROPoFeExLwH3zuWzzV0o4hSmFMXaM7OryCwWZ4DXnIcxE APbQupRZ4vK9iTwUI1DD52wowyFf5Z2zE6ZFj/WM+Qkvqg3yQTChQWQ5f3859ZaHqgWdXp9q IQdQoMwW5uxv1fQpUPyIh5HsLHPuLiRepFfAyWnZ/KjFwMgmsFpNjycD76DenfgiRa3Vrmmj qDrzeciBKcanBgjC4mF4GpIRl8thZr7Up0PpKfbtR33gapS89UbmMLrNULkQnZpa6gC76c25 XwIDAQABozkwNzAnBgNVHREEIDAegRxqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMuY29tMAwG A1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAO287/+2OIBXpUka2g22uXfiYHmMbIZOK i3PDyuIHrPPQa9jXVtxYOanokqJ/6lUb7wsjJIOixu69rXeq7YfBhTEGZZzsKg13aT2RGVyt 9sNRNOsY5kryrKo2pPeBBlMBr1mdQjSy70bL+fajltBxph2pHeG02um90tI85aEgs5cwggM/ MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMM V2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25z dWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYD VQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNv bmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5 WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRk LjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2 vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9 A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEw EgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0 ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYDVR0R BCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GB AEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZ Ohl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVN d+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDOzCCAzcCAQEwaTBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrTAJBgUrDgMCGgUAoIIBpzAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjAyMjMxNDE3MzVaMCMGCSqG SIb3DQEJBDEWBBSM9ZqHbMXURlESDotyhXJdHIVXMDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDB4BgkrBgEEAYI3EAQxazBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQQIDDs2tMHoGCyqGSIb3DQEJEAILMWugaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrTANBgkqhkiG9w0BAQEFAASC AQAr/Fx72G/YWaVr2SBesdglbH94Kk9pLo+iMU5R4Xi+Fk4Gjyqu68J91evx4SqDkCA2zMiC Fa6jM94bkIur86gljxB9o0OoJx0S+cAfRw4Qqocpc+yP0B6aYBr3XckH83aAPkuGzwhlkiQC t5BETdFFcYka9PUgP+UVzQBc9Z4S0STKEAZpYz/vQkOm5CjorGrxZ0eciU53YyMIohbnANd2 Y53tv6vcoDwJz0OIAm+d7Zv22Ynzwt9KB8rM0f7qRCLx2XMaKFeUi9JwQisZFacnZwJFE+dm MGpKN3thrZOewsr3TIrfoqd46bvjKQL10y27JQdG2gPYIOs57yLNvLRRAAAAAAAA --------------ms060301000700010807040102-- From horst@birthelmer.de Thu Feb 23 10:01:15 2006 Received: from www.unx-software.de ([62.75.245.108] helo=vs245108.vserver.de) by michigan.central.org with esmtp (Exim 4.50) id 1FCHxy-0004HX-OM for afs3-standardization@openafs.org; Thu, 23 Feb 2006 10:01:15 -0500 Received: from p54a9e321.dip.t-dialin.net ([84.169.227.33] helo=[192.168.0.101]) by vs245108.vserver.de with esmtpsa (TLS-1.0:RSA_ARCFOUR_SHA:16) (Exim 4.50) id 1FCHxP-000121-43; Thu, 23 Feb 2006 16:00:39 +0100 In-Reply-To: <43FDC3FF.60909@secure-endpoints.com> References: <43FDC3FF.60909@secure-endpoints.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6BA7EC8D-ED31-4F36-B88E-5600F2666A0F@birthelmer.de> Content-Transfer-Encoding: 7bit From: Horst Birthelmer Date: Thu, 23 Feb 2006 16:00:38 +0100 To: Jeffrey Altman X-Mailer: Apple Mail (2.746.2) X-SA-Exim-Connect-IP: 62.75.245.108 X-SA-Exim-Rcpt-To: afs3-standardization@openafs.org X-SA-Exim-Mail-From: horst@birthelmer.de Subject: Re: [AFS3-std] Re: Welcome to the "AFS3-standardization" mailing list X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on michigan.central.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.3 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on michigan.central.org) Cc: Ted Anderson , afs3-standardization@openafs.org, afs3-protocol@stacken.kth.se X-BeenThere: afs3-standardization@openafs.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standardizing the AFS 3 Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2006 15:01:15 -0000 On Feb 23, 2006, at 3:17 PM, Jeffrey Altman wrote: ... > This mailing list info was posted to openafs-devel last week as > part of > the continuing discussion on development schedules and byte range > locking. > > Several months earlier there was an effort to conduct these > discussions > on afs3-protocol@stacken.kth.se but the only response to my postings > there were from Jeffrey Hutzelman who I specifically asked to join. The existance of the afs3-protocol mailing list was kind of a secret. I don't remember anybody talking about that one. Or maybe I missed something ;-) > Wider participation is great but at the moment the primary concern > is to > provide a forum for those who have been actively attending the > hackathons and contributing to the protocol extensions currently under > development. This list is for the discussion of the wire protocols > not implementations. The OpenAFS implementations are discussed on > openafs-devel@openafs.org and the Arla implementations are > discussed on > arla-drinkers@stacken.kth.se. Horst From jaltman@secure-endpoints.com Thu Feb 23 10:09:49 2006 Received: from brinza.cc.columbia.edu ([128.59.29.8] ident=cu41754) by michigan.central.org with esmtp (Exim 4.50) id 1FCI6G-0004IO-T5 for afs3-standardization@openafs.org; Thu, 23 Feb 2006 10:09:49 -0500 Received: from [192.168.1.11] (cpe-68-175-91-105.nyc.res.rr.com [68.175.91.105]) (user=jaltman mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id k1NF9gGt026939 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 23 Feb 2006 10:09:43 -0500 (EST) Message-ID: <43FDD089.4030204@secure-endpoints.com> Date: Thu, 23 Feb 2006 10:11:05 -0500 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Horst Birthelmer References: <43FDC3FF.60909@secure-endpoints.com> <6BA7EC8D-ED31-4F36-B88E-5600F2666A0F@birthelmer.de> In-Reply-To: <6BA7EC8D-ED31-4F36-B88E-5600F2666A0F@birthelmer.de> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030401030600000008080706" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-SA-Exim-Connect-IP: 128.59.29.8 X-SA-Exim-Rcpt-To: afs3-standardization@openafs.org X-SA-Exim-Mail-From: jaltman@secure-endpoints.com Subject: Re: [AFS3-std] Re: Welcome to the "AFS3-standardization" mailing list X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on michigan.central.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on michigan.central.org) Cc: Ted Anderson , afs3-standardization@openafs.org, afs3-protocol@stacken.kth.se X-BeenThere: afs3-standardization@openafs.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standardizing the AFS 3 Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2006 15:09:49 -0000 This is a cryptographically signed message in MIME format. --------------ms030401030600000008080706 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Horst Birthelmer wrote: > On Feb 23, 2006, at 3:17 PM, Jeffrey Altman wrote: >> Several months earlier there was an effort to conduct these discussions >> on afs3-protocol@stacken.kth.se but the only response to my postings >> there were from Jeffrey Hutzelman who I specifically asked to join. > > The existance of the afs3-protocol mailing list was kind of a secret. > I don't remember anybody talking about that one. > Or maybe I missed something ;-) I needed a forum that was appropriate for discussions of the afs3 protocol. afs3-protocol@stacken.kth.se is a mailing list that was created years ago for this purpose. I believe it may even predate the existence of openafs. Its not that the list was secret but that it had gone unused for many many years. When postings there went unanswered, it became clear that a new forum needed to be created. Hence, this mailing list. Jeffrey Altman --------------ms030401030600000008080706 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJXzCC AwowggJzoAMCAQICAw7NrTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwNTI3MTc0NzU3WhcNMDYwNTI3MTc0NzU3 WjBzMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjErMCkGCSqGSIb3DQEJARYcamFsdG1hbkBzZWN1cmUtZW5k cG9pbnRzLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKjPyrF+rdjOUSK/ bWwZHdx5p1+y6iiCd4vvYEVDxouYFp5C/fZEWm5n45ubBUbMSUI1MAZN6ooEoH09UTj6BXhM S8B987ls81dKOIUphTF2jOzq8gsFmeA15yHMRAD20LqUWeLyvYk8FCNQw+dsKMMhX+WdsxOm RY/1jPkJL6oN8kEwoUFkOX9/OfWWh6oFnV6faiEHUKDMFubsb9X0KVD8iIeR7Cxz7i4kXqRX wMlp2fyoxcDIJrBaTY8nA++g3p34IkWt1a5po6g683nIgSnGpwYIwuJheBqSEZfLYWa+1KdD 6Sn27Ud94GqUvPVG5jC6zVC5EJ2aWuoAu+nNuV8CAwEAAaM5MDcwJwYDVR0RBCAwHoEcamFs dG1hbkBzZWN1cmUtZW5kcG9pbnRzLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUA A4GBADtvO//tjiAV6VJGtoNtrl34mB5jGyGTiotzw8riB6zz0GvY11bcWDmp6JKif+pVG+8L IySDosbuva13qu2HwYUxBmWc7CoNd2k9kRlcrfbDUTTrGOZK8qyqNqT3gQZTAa9ZnUI0su9G y/n2o5bQcaYdqR3htNrpvdLSPOWhILOXMIIDCjCCAnOgAwIBAgIDDs2tMA0GCSqGSIb3DQEB BAUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0w NTA1MjcxNzQ3NTdaFw0wNjA1MjcxNzQ3NTdaMHMxDzANBgNVBAQTBkFsdG1hbjEVMBMGA1UE KhMMSmVmZnJleSBFcmljMRwwGgYDVQQDExNKZWZmcmV5IEVyaWMgQWx0bWFuMSswKQYJKoZI hvcNAQkBFhxqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAqM/KsX6t2M5RIr9tbBkd3HmnX7LqKIJ3i+9gRUPGi5gWnkL99kRa bmfjm5sFRsxJQjUwBk3qigSgfT1ROPoFeExLwH3zuWzzV0o4hSmFMXaM7OryCwWZ4DXnIcxE APbQupRZ4vK9iTwUI1DD52wowyFf5Z2zE6ZFj/WM+Qkvqg3yQTChQWQ5f3859ZaHqgWdXp9q IQdQoMwW5uxv1fQpUPyIh5HsLHPuLiRepFfAyWnZ/KjFwMgmsFpNjycD76DenfgiRa3Vrmmj qDrzeciBKcanBgjC4mF4GpIRl8thZr7Up0PpKfbtR33gapS89UbmMLrNULkQnZpa6gC76c25 XwIDAQABozkwNzAnBgNVHREEIDAegRxqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMuY29tMAwG A1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAO287/+2OIBXpUka2g22uXfiYHmMbIZOK i3PDyuIHrPPQa9jXVtxYOanokqJ/6lUb7wsjJIOixu69rXeq7YfBhTEGZZzsKg13aT2RGVyt 9sNRNOsY5kryrKo2pPeBBlMBr1mdQjSy70bL+fajltBxph2pHeG02um90tI85aEgs5cwggM/ MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMM V2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25z dWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYD VQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNv bmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5 WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRk LjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2 vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9 A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEw EgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0 ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYDVR0R BCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GB AEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZ Ohl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVN d+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDOzCCAzcCAQEwaTBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrTAJBgUrDgMCGgUAoIIBpzAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjAyMjMxNTExMDVaMCMGCSqG SIb3DQEJBDEWBBTiyQOL19ewm0o3rsIo9ZVClyEJpjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDB4BgkrBgEEAYI3EAQxazBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQQIDDs2tMHoGCyqGSIb3DQEJEAILMWugaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrTANBgkqhkiG9w0BAQEFAASC AQAiKVEQNL1gXfcnEAswztIrJ/xu0Au14uQtRewKSlQRmG9gfxlPq1ei5Qtb42wbjYBpplqh s09QVB/dR5NTspR6FHc8afpSOeDYZ/l++tRFhj6WGZYdE6UG3rHkXfB8/N2/cQ8DDfYdq9GS qp15VglMZ/eO6LDZdYCbymFO4z1Q6M+6G/PbFTJxQbYemG6QkvLKYFunndtdidPrsZ9Oq1oY /d5ABW107DqWFem3MKPwhWHSvfIm+/UyGS2ncae7E4rDhlwOwHvSc7Vs/G6Aw2GDUcO6aEQb 77WrSa/47v9df0QwBC1V5GrKlmSVzQ7FegEIv9j/AXhNM+DPNG053HnxAAAAAAAA --------------ms030401030600000008080706-- From jaltman@secure-endpoints.com Fri Feb 24 18:15:16 2006 Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754) by michigan.central.org with esmtp (Exim 4.50) id 1FCm9b-0002lT-77 for afs3-standardization@openafs.org; Fri, 24 Feb 2006 18:15:16 -0500 Received: from [192.168.1.11] (cpe-68-175-91-105.nyc.res.rr.com [68.175.91.105]) (user=jaltman mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id k1ONFDPI006916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 24 Feb 2006 18:15:14 -0500 (EST) Message-ID: <43FF93D7.8030502@secure-endpoints.com> Date: Fri, 24 Feb 2006 18:16:39 -0500 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: afs3-standardization@openafs.org X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080403080000090106070401" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-SA-Exim-Connect-IP: 128.59.29.5 X-SA-Exim-Rcpt-To: afs3-standardization@openafs.org X-SA-Exim-Mail-From: jaltman@secure-endpoints.com X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on michigan.central.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on michigan.central.org) Cc: afs3-protocol@stacken.kth.se Subject: [AFS3-std] Standardization of GetCapabilties RPCs for AFS3 client and services X-BeenThere: afs3-standardization@openafs.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standardizing the AFS 3 Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2006 23:15:16 -0000 This is a cryptographically signed message in MIME format. --------------ms080403080000090106070401 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit OpenAFS as part of http://www.openafs.org/cgi-bin/wdelta/capabilities-20030304 added two new RPCs. The first was AFSCB_TellMeAboutYourself that is served by the client and and the second is AFS_GetCapabilities that is served by Viced. At the time these interfaces were poorly defined. The following is a proposal that is compatible with the existing implementations. DATA TYPES: The following types are already in use by existing implementations. They are listed here for reference. const AFS_MAX_INTERFACE_ADDR = 32; struct interfaceAddr { /* for multihomed clients */ int numberOfInterfaces; afsUUID uuid; afs_int32 addr_in[AFS_MAX_INTERFACE_ADDR]; /* net order */ afs_int32 subnetmask[AFS_MAX_INTERFACE_ADDR]; /* net order */ afs_int32 mtu[AFS_MAX_INTERFACE_ADDR]; /* MTU */ }; const AFSCAPABILITIESMAX = 196; typedef afs_uint32 Capabilities; Capabilities are communicated as an array of bit flags providing 6272 distinct capabilities per client or service. RPC Names: RXAFSCB_TellMeAboutYourself (client) RXAFS_GetCapabilities (file server) AFSVol_GetCapabilities (vol server) VL_GetCapabilities (vldb server) PR_GetCapabilities (protection server) RPC Descriptions (using rxgen format) RXAFSCB_TellMeAboutYourself( OUT struct interfaceAddr *addr, OUT Capabilities *capabilities ) = 65538; RXAFS_GetCapabilities( Capabilities *capabilities ) = 65540; AFSVol_GetCapabilities( Capabilities *capabilities ) = to be assigned by registrar@grand.central.org; VL_GetCapabilities( Capabilities *capabilities ) = to be assigned by registrar@grand.central.org; PR_GetCapabilities( Capabilities *capabilities ) = to be assigned by registrar@grand.central.org; CAPABILITY FLAGS: Capability Flags will be registered with registrar@grand.central.org on a per-RPC basis. The following capabilities are already in use: /* Viced Capability Flags */ const VICED_CAPABILITY_ERRORTRANS = 0x0001; const VICED_CAPABILITY_64BITFILES = 0x0002; /* Cache Manager Capability Flags */ const CLIENT_CAPABILITY_ERRORTRANS = 0x0001; IMPLEMENTATION NOTES: Services that implement a xxxx_GetCapabilities RPC should process them with the same semantics that are used for the xxxx_GetTime RPC. This will allow xxxx_GetCapabilities to be used as a replacement for xxxx_GetTime as a ping RPC. A ping RPC must not only return a response for the purpose of maintaining a network route through a NAT but must also re-establish the binding between the calling host and any internal state maintained by the called host about the calling host. If this requirement is ignored in the file server, for example, callbacks with delayed breaks will not be broken in response to a xxxx_GetCapabilities RPC. >From the perspective of the caller, xxxx_GetCapabilities returning RXGEN_OPCODE is an indication that the RPC is not supported and the service is running. However, it does not result in a binding between the rx connection and the internally maintained host data in the OpenAFS file server. Therefore, an AFS Cache Manager client should fallback to calling the xxxx_GetTime RPC if RXGEN_OPCODE is received when attempting to ping the service. PROPOSED USAGE OF CAPABILITY FLAGS: Historically callers of RPCs have probed services for new or extended functionality by calling an RPC and then falling back to an alternate behavior if the RPC is not supported. This has resulted in RPCs such as xxxx_FooBar, xxxx_OldFooBar, xxxx_OldOldFooBar. This method of extending the functionality of AFS has a several drawbacks: (1) there is a performance hit associated with each request when the desired RPC is unsupported by the service. (2) some operations may not be safe to start unless it is known that the necessary RPCs are available to carry out the operations. (3) It is not safe to cache the knowledge that the RPC is not supported because the client may not notice when the service is upgraded to a version that does support it. It is recommended that the Capabilities be used to address these issues as follows: (1) xxxx_GetCapabilities should be used instead of xxxx_GetTime as the mechanism to ping the server to obtain its state. As a side effect of the ping, the caller will refresh the known Capabilities of the server. The caller will therefore always have a fresh knowledge of the supported functionality of the server. (2) When knowledge of a new service is obtained, the service should be pinged to obtain its capabilities. (3) The Capabilities flags when available should be used to determine the supported RPCs instead of probing the RPC support by issuing a call and checking for RXGEN_OPCODE. (4) Instead of extending functionality by issuing a new RPC and then supporting both the old and new forms, RPCs should be extended by adding the new functions to the existing RPC and specifying a Capability flag. For example, adding Lock Upgrade and Lock Downgrade functionality can be performed by a combination of a extending the SetLock RPC and providing a Capability flag. This will prevent new clients that attempt to use the functions from attempting an extra RPC call for each Lock Upgrade and Lock Downgrade request. (5) In addition to advertising new functionality, the Capabilities flags can be used to provide hints to the caller of behavior the server may desire. For example, a file server may prefer that client not request make SetLock requests even though the functionality is supported. These hints would not be mandatory and would simply be a method by which desired policy can be distributed from server to client. Jeffrey Altman --------------ms080403080000090106070401 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJXzCC AwowggJzoAMCAQICAw7NrTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwNTI3MTc0NzU3WhcNMDYwNTI3MTc0NzU3 WjBzMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjErMCkGCSqGSIb3DQEJARYcamFsdG1hbkBzZWN1cmUtZW5k cG9pbnRzLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKjPyrF+rdjOUSK/ bWwZHdx5p1+y6iiCd4vvYEVDxouYFp5C/fZEWm5n45ubBUbMSUI1MAZN6ooEoH09UTj6BXhM S8B987ls81dKOIUphTF2jOzq8gsFmeA15yHMRAD20LqUWeLyvYk8FCNQw+dsKMMhX+WdsxOm RY/1jPkJL6oN8kEwoUFkOX9/OfWWh6oFnV6faiEHUKDMFubsb9X0KVD8iIeR7Cxz7i4kXqRX wMlp2fyoxcDIJrBaTY8nA++g3p34IkWt1a5po6g683nIgSnGpwYIwuJheBqSEZfLYWa+1KdD 6Sn27Ud94GqUvPVG5jC6zVC5EJ2aWuoAu+nNuV8CAwEAAaM5MDcwJwYDVR0RBCAwHoEcamFs dG1hbkBzZWN1cmUtZW5kcG9pbnRzLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUA A4GBADtvO//tjiAV6VJGtoNtrl34mB5jGyGTiotzw8riB6zz0GvY11bcWDmp6JKif+pVG+8L IySDosbuva13qu2HwYUxBmWc7CoNd2k9kRlcrfbDUTTrGOZK8qyqNqT3gQZTAa9ZnUI0su9G y/n2o5bQcaYdqR3htNrpvdLSPOWhILOXMIIDCjCCAnOgAwIBAgIDDs2tMA0GCSqGSIb3DQEB BAUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0w NTA1MjcxNzQ3NTdaFw0wNjA1MjcxNzQ3NTdaMHMxDzANBgNVBAQTBkFsdG1hbjEVMBMGA1UE KhMMSmVmZnJleSBFcmljMRwwGgYDVQQDExNKZWZmcmV5IEVyaWMgQWx0bWFuMSswKQYJKoZI hvcNAQkBFhxqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAqM/KsX6t2M5RIr9tbBkd3HmnX7LqKIJ3i+9gRUPGi5gWnkL99kRa bmfjm5sFRsxJQjUwBk3qigSgfT1ROPoFeExLwH3zuWzzV0o4hSmFMXaM7OryCwWZ4DXnIcxE APbQupRZ4vK9iTwUI1DD52wowyFf5Z2zE6ZFj/WM+Qkvqg3yQTChQWQ5f3859ZaHqgWdXp9q IQdQoMwW5uxv1fQpUPyIh5HsLHPuLiRepFfAyWnZ/KjFwMgmsFpNjycD76DenfgiRa3Vrmmj qDrzeciBKcanBgjC4mF4GpIRl8thZr7Up0PpKfbtR33gapS89UbmMLrNULkQnZpa6gC76c25 XwIDAQABozkwNzAnBgNVHREEIDAegRxqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMuY29tMAwG A1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAO287/+2OIBXpUka2g22uXfiYHmMbIZOK i3PDyuIHrPPQa9jXVtxYOanokqJ/6lUb7wsjJIOixu69rXeq7YfBhTEGZZzsKg13aT2RGVyt 9sNRNOsY5kryrKo2pPeBBlMBr1mdQjSy70bL+fajltBxph2pHeG02um90tI85aEgs5cwggM/ MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMM V2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25z dWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYD VQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNv bmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5 WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRk LjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2 vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9 A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEw EgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0 ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYDVR0R BCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GB AEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZ Ohl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVN d+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDOzCCAzcCAQEwaTBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrTAJBgUrDgMCGgUAoIIBpzAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjAyMjQyMzE2MzlaMCMGCSqG SIb3DQEJBDEWBBRocPmBlGBLpWsTgyFCyxi1qocFQjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDB4BgkrBgEEAYI3EAQxazBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQQIDDs2tMHoGCyqGSIb3DQEJEAILMWugaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrTANBgkqhkiG9w0BAQEFAASC AQBGulZbvHVlBuAonc6jowXWIj8WgBVP0avSvo/ZSFuNVjeNUJc4U3wXZe70/fVEaovHYVt5 9bVU3B4YwD39Jxrb79Nqy0lADILq3xFElZVKfgwt1apXTFROztfsPgyOJxvKFV/d9kX3oz8/ OFLaidwGmOxmR6Ls61cAssINo5V3oXipIA3O6EXl60D6fC3iCvb7uwazkneuAKf/TGqs3eQ4 65rmLfvV4NBk5/1SYmMixcuVwEA3RKXWj6/C8LggvzEfch9kVhVLKvOrneEAMsaGgu6t/VPR WRwb3aOFb00HYVLZhz6R2NBIej7drtoROO9Hs3E1yOn0oNBwTfo1HXsiAAAAAAAA --------------ms080403080000090106070401-- From cg2v@andrew.cmu.edu Fri Feb 24 18:28:32 2006 Received: from smtp.andrew.cmu.edu ([128.2.10.81]) by michigan.central.org with esmtp (Exim 4.50) id 1FCmMR-0002mv-Rc for afs3-standardization@openafs.org; Fri, 24 Feb 2006 18:28:32 -0500 Received: from SPHINX.andrew.cmu.edu (SPHINX.andrew.cmu.edu [128.2.121.9]) (user=cg2v mech=GSSAPI (0 bits)) by smtp.andrew.cmu.edu (8.13.4/8.13.4) with ESMTP id k1ONSVU0001299 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Fri, 24 Feb 2006 18:28:31 -0500 Date: Fri, 24 Feb 2006 18:28:28 -0500 From: Chaskiel M Grundman To: afs3-standardization@openafs.org Message-ID: <8FB75056FF87998F43160AEB@sphinx.andrew.cmu.edu> In-Reply-To: <43FF93D7.8030502@secure-endpoints.com> References: <43FF93D7.8030502@secure-endpoints.com> Originator-Info: login-token=Mulberry:01GEFk+3uolnEqr+yBX8KUWKuh3yijdd2FtpJgTsE=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=sha1; protocol="application/pkcs7-signature"; boundary="==========31FDD9E867EB520E4E13==========" X-SA-Exim-Connect-IP: 128.2.10.81 X-SA-Exim-Rcpt-To: afs3-standardization@openafs.org X-SA-Exim-Mail-From: cg2v@andrew.cmu.edu Subject: Re: [AFS3-std] Standardization of GetCapabilties RPCs for AFS3 client and services X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on michigan.central.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on michigan.central.org) Cc: afs3-protocol@stacken.kth.se X-BeenThere: afs3-standardization@openafs.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standardizing the AFS 3 Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2006 23:28:32 -0000 --==========31FDD9E867EB520E4E13========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline --On Friday, February 24, 2006 18:16:39 -0500 Jeffrey Altman=20 wrote: > > (4) Instead of extending functionality by issuing a new RPC and then > supporting both the old and new forms, RPCs should be extended by > adding the new functions to the existing RPC and specifying a > Capability flag. The usual reason to add a new RPC is because the arguments or argument=20 types differ, not just the semantics. given the current rxgen-generated=20 stubs, an rx client or server cannot provide different wire encodings to=20 different peers based on capabilities. FetchStatus has not had to evolve=20 (yet) as the changes made to it have not resulted in an on-wire change,=20 only a change in semantics of previously reserved fields. > (5) In addition to advertising new functionality, the Capabilities flags > can be used to provide hints to the caller of behavior the server > may desire. For example, a file server may prefer that client not > request make SetLock requests even though the functionality is > supported. These hints would not be mandatory and would simply be > a method by which desired policy can be distributed from server to > client. Why is it a good idea to put client policy configuration in the server? --==========31FDD9E867EB520E4E13========== Content-Type: application/pkcs7-signature Content-Transfer-Encoding: base64 MIIL1wYJKoZIhvcNAQcCoIILyDCCC8QCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3 DQEHAaCCCVswggLjMIICTKADAgECAgMO/8kwDQYJKoZIhvcNAQEEBQAwYjELMAkG A1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4X DTA1MDYyMzE3MzEzMFoXDTA2MDYyMzE3MzEzMFowRTEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjEiMCAGCSqGSIb3DQEJARYTY2cydkBhbmRyZXcuY211 LmVkdTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALujtch96NHbplBs 5DnSTn03EsnbYsLng/wM+wbfyS6ml6CCGYl7HY+sIBm4DNygpyQz0mvtvy9kKz7V M2GTYdH5QLOgxxPxzV3fItv4jF9LKr9tIiT+v9K7XQ2Xl4kDyJi1g19UsKU4wf+s uFdennXZ0pkWTpUld9JRZiLSYQDs/Hi62OekBfIX+H96AskyMBhZj5OVA+CYtnCj fzVYO4a/RoAmemQhlv+whF0Qa3QFrLZtrDXKeYX95KU78q6+cJqtiAri4H3k8NpD SeWavUxFyH/PFhCYPVdfVDiwaTwfEI5lBF0vTTTL8kSnJSmRBRWw9RkYHNZ8hxBC Oo9m1oMCAwEAAaNAMD4wDgYDVR0PAQH/BAQDAgXgMB4GA1UdEQQXMBWBE2NnMnZA YW5kcmV3LmNtdS5lZHUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQCR W9k/ckGNAJQ+DeUey0Hed2nlQb4goaakkHviC70vAVt0N34yrk3uxBf5Kch2olqM SMCR+9+b1iXn0NU9n7QppayQ7SsYci3m8eMlaBk1pK91LrHGQL+ZEqOPqwhRmb0a lQFAAoJpJdotCBzy0X1GP83i+2DUdT6ydPlmtsm8djCCAz8wggKooAMCAQICAQ0w DQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1 bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24x JDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAw MDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29u YWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQ CjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+ B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTAS BgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwu dGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQE AwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgw DQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4 +DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN 3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11f ZU8wggMtMIIClqADAgECAgEAMA0GCSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJa QTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAY BgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9u IFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0 ZS5jb20wHhcNOTYwMTAxMDAwMDAwWhcNMjAxMjMxMjM1OTU5WjCB0TELMAkGA1UE BhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNh dGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0 aGF3dGUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDUadfUsJRkW3Hp R9gMUbbqcpGwhF59LQ2PexLfhSV1KHQ6QixjJ5+Ve0vvfhmHHYbqo925zpZkGsIU bkSsfOaP6E0PcR9AOKYAo4d49vmUhl6t6sBeduvZFKNdbnp8DKVLVX8GGSl/npom 1Wq7OCQIapjHsdqjmJH9edvlWsQcuQIDAQABoxMwETAPBgNVHRMBAf8EBTADAQH/ MA0GCSqGSIb3DQEBBAUAA4GBAMfskn5O+PWWpWdiKqTwTRFg0G+NYFhhrCa7UjVc CM8w+6hKloofYkIjjBcP9LpknBesRynfnZhe0mxgcVyirNx54+duAEcftQ0o6AKd 5Jr9E/Sm2Xyx+NxfIyYJkYBz0BQb3kOpgyXy5pwvFcr+pquKB3WLDN1RhGvk+NHO d6KBMYICRDCCAkACAQEwaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7/yTAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA2MDIyNDIzMjgzMlow IwYJKoZIhvcNAQkEMRYEFJHRwOfdS8lhfze7cjG8F+efv7x8MFIGCSqGSIb3DQEJ DzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIIBABRNSh4s U5EZ14xBTiW4LWm5FzCaU3iC5m/IqQTez7zEu1OwRYCwkW4pJ721RW4yDJSH9Csu A0xWQGl/57rRMOBuylnQYGEEKEMuUdccIQ/LsjHc+omLXVrWOHmVq+72ZTM5l331 +V0Vu2SYvdlwiVBDZWkEKy7tTRcpHP2sS5cxkUMc6Yl3wzJrq/rLJAfXxTSS6tar YWbJpCy8LI8Eq/aD97QoDY/fnX1+qbhs0EssKcVRje9oOUv0cDdjB1ofK9CPEsB9 yYRvrZNbAK8DC/ZotRb0aVcnaTPuT8QWqgBh3PygBlccqFNV11oV4izR5B94vwV2 4P6y+fnsg/LmnE0= --==========31FDD9E867EB520E4E13==========-- From jhutz@cmu.edu Fri Feb 24 18:51:06 2006 Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by michigan.central.org with smtp (Exim 4.50) id 1FCmiI-0002oj-56 for afs3-standardization@openafs.org; Fri, 24 Feb 2006 18:51:06 -0500 Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170]) by minbar.fac.cs.cmu.edu id aa18255; 24 Feb 2006 18:50 EST Date: Fri, 24 Feb 2006 18:50:36 -0500 From: Jeffrey Hutzelman To: Chaskiel M Grundman , afs3-standardization@openafs.org Message-ID: <252A3EB5F6F2185D7134516D@sirius.fac.cs.cmu.edu> In-Reply-To: <8FB75056FF87998F43160AEB@sphinx.andrew.cmu.edu> References: <43FF93D7.8030502@secure-endpoints.com> <8FB75056FF87998F43160AEB@sphinx.andrew.cmu.edu> Originator-Info: login-token=Mulberry:01e+MG0OVLe0THLn5RrmE2PxJVPfsCF3/oWDQ1sWM=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 128.2.185.161 X-SA-Exim-Rcpt-To: afs3-standardization@openafs.org X-SA-Exim-Mail-From: jhutz@cmu.edu Subject: Re: [AFS3-std] Standardization of GetCapabilties RPCs for AFS3 client and services X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on michigan.central.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on michigan.central.org) Cc: afs3-protocol@stacken.kth.se X-BeenThere: afs3-standardization@openafs.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standardizing the AFS 3 Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2006 23:51:06 -0000 On Friday, February 24, 2006 06:28:28 PM -0500 Chaskiel M Grundman wrote: >> (5) In addition to advertising new functionality, the Capabilities flags >> can be used to provide hints to the caller of behavior the server >> may desire. For example, a file server may prefer that client not >> request make SetLock requests even though the functionality is >> supported. These hints would not be mandatory and would simply be >> a method by which desired policy can be distributed from server to >> client. > > Why is it a good idea to put client policy configuration in the server? In general, it's not. However, it is appropriate for a fileserver to provide hints about what functionality it will support, or what access control policies it will apply, particularly in cases where that helps the client to provide a better user experience. For example, it may be helpful to a client to know whether the fileserver supports mandatory locking, and under what circumstances it will grant such locks, in advance of actually trying one. In general, capability bits should be used to describe how the entity advertising the capability will behave; they should not be used to tell the querying entity how to behave. If you want all the clients you manage to have a particular policy, then distribute policy configuration to them via a suitable mechanism, not by overloading server capapbility negotiation. Incidentally, while it is desirable to extend existing RPC's in backward-compatible ways, and appropriate to use capability bits to advertise support for such an extension, we must be careful not to use capabilities as an excuse to make backward-incompatible changes to existing RPC's. The procedure number space is quite large; we can afford to burn a few numbers. I'm not sure I like the implication that every new RPC should have an associated capability bit, either. I see a potential here for a lot of bloat with relatively little benefit. If it costs a client an extra round trip to discover that a server doesn't support the new way of doing things, sometimes that's OK -- especially if the client can cache that information. On the other hand, there certainly are cases where it makes sense to do this, particularly if it is advantageous to the client to know whether an operation is supported well before it tries it, or if the burden of the extra round trip is particularly heavy. Finally, I think we should be clear that even when a capability bit indicates support for a particular feature, clients should be prepared to deal with servers which return errors (particularly, RXGEN_OPCODE or access control errors) when the feature is used. This is especially important with respect to cache manager capabilities, since the transport address used by one cache manager may somewhat unexpectedly be reassigned to another. More on this thread later, probably; for now I should go to dinner. -- Jeff From jaltman@secure-endpoints.com Fri Feb 24 18:51:13 2006 Received: from brinza.cc.columbia.edu ([128.59.29.8] ident=cu41754) by michigan.central.org with esmtp (Exim 4.50) id 1FCmiP-0002pA-6I for afs3-standardization@openafs.org; Fri, 24 Feb 2006 18:51:13 -0500 Received: from [192.168.1.11] (cpe-68-175-91-105.nyc.res.rr.com [68.175.91.105]) (user=jaltman mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id k1ONowjS008588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 24 Feb 2006 18:51:03 -0500 (EST) Message-ID: <43FF9C38.6080502@secure-endpoints.com> Date: Fri, 24 Feb 2006 18:52:24 -0500 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Chaskiel M Grundman References: <43FF93D7.8030502@secure-endpoints.com> <8FB75056FF87998F43160AEB@sphinx.andrew.cmu.edu> In-Reply-To: <8FB75056FF87998F43160AEB@sphinx.andrew.cmu.edu> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080807040102000408060104" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-SA-Exim-Connect-IP: 128.59.29.8 X-SA-Exim-Rcpt-To: afs3-standardization@openafs.org X-SA-Exim-Mail-From: jaltman@secure-endpoints.com Subject: Re: [AFS3-std] Standardization of GetCapabilties RPCs for AFS3 client and services X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on michigan.central.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on michigan.central.org) Cc: afs3-standardization@openafs.org, afs3-protocol@stacken.kth.se X-BeenThere: afs3-standardization@openafs.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standardizing the AFS 3 Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2006 23:51:13 -0000 This is a cryptographically signed message in MIME format. --------------ms080807040102000408060104 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Chaskiel M Grundman wrote: > > > --On Friday, February 24, 2006 18:16:39 -0500 Jeffrey Altman > wrote: > >> >> (4) Instead of extending functionality by issuing a new RPC and then >> supporting both the old and new forms, RPCs should be extended by >> adding the new functions to the existing RPC and specifying a >> Capability flag. > The usual reason to add a new RPC is because the arguments or argument > types differ, not just the semantics. given the current rxgen-generated > stubs, an rx client or server cannot provide different wire encodings to > different peers based on capabilities. FetchStatus has not had to evolve > (yet) as the changes made to it have not resulted in an on-wire change, > only a change in semantics of previously reserved fields. Certainly when the number of arguments or types of arguments change, there is a need for a new RPC. No argument there. >> (5) In addition to advertising new functionality, the Capabilities flags >> can be used to provide hints to the caller of behavior the server >> may desire. For example, a file server may prefer that client not >> request make SetLock requests even though the functionality is >> supported. These hints would not be mandatory and would simply be >> a method by which desired policy can be distributed from server to >> client. > > Why is it a good idea to put client policy configuration in the server? The byte range locks discussions have brought to the surface an interesting problem. Some new functionality may result in changes in behavior that will alter the end user experience or the load that is placed on the servers. Cell administrators do not have control over what clients installed by their users or how their users configure those clients. In addition, afs clients are used to access multiple cells. Administrators may want to support the new functionality but would prefer that it not be used until their help desk staff is trained and appropriate web documentation is updated. The only way that I can think of that would allow an administrator to upgrade their servers and affect the behavior of the clients is by allowing the server to distribute policy flags. These flags would not be mandatory and clients could be configured to ignore them. Jeffrey Altman --------------ms080807040102000408060104 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJXzCC AwowggJzoAMCAQICAw7NrTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwNTI3MTc0NzU3WhcNMDYwNTI3MTc0NzU3 WjBzMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjErMCkGCSqGSIb3DQEJARYcamFsdG1hbkBzZWN1cmUtZW5k cG9pbnRzLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKjPyrF+rdjOUSK/ bWwZHdx5p1+y6iiCd4vvYEVDxouYFp5C/fZEWm5n45ubBUbMSUI1MAZN6ooEoH09UTj6BXhM S8B987ls81dKOIUphTF2jOzq8gsFmeA15yHMRAD20LqUWeLyvYk8FCNQw+dsKMMhX+WdsxOm RY/1jPkJL6oN8kEwoUFkOX9/OfWWh6oFnV6faiEHUKDMFubsb9X0KVD8iIeR7Cxz7i4kXqRX wMlp2fyoxcDIJrBaTY8nA++g3p34IkWt1a5po6g683nIgSnGpwYIwuJheBqSEZfLYWa+1KdD 6Sn27Ud94GqUvPVG5jC6zVC5EJ2aWuoAu+nNuV8CAwEAAaM5MDcwJwYDVR0RBCAwHoEcamFs dG1hbkBzZWN1cmUtZW5kcG9pbnRzLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUA A4GBADtvO//tjiAV6VJGtoNtrl34mB5jGyGTiotzw8riB6zz0GvY11bcWDmp6JKif+pVG+8L IySDosbuva13qu2HwYUxBmWc7CoNd2k9kRlcrfbDUTTrGOZK8qyqNqT3gQZTAa9ZnUI0su9G y/n2o5bQcaYdqR3htNrpvdLSPOWhILOXMIIDCjCCAnOgAwIBAgIDDs2tMA0GCSqGSIb3DQEB BAUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0w NTA1MjcxNzQ3NTdaFw0wNjA1MjcxNzQ3NTdaMHMxDzANBgNVBAQTBkFsdG1hbjEVMBMGA1UE KhMMSmVmZnJleSBFcmljMRwwGgYDVQQDExNKZWZmcmV5IEVyaWMgQWx0bWFuMSswKQYJKoZI hvcNAQkBFhxqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAqM/KsX6t2M5RIr9tbBkd3HmnX7LqKIJ3i+9gRUPGi5gWnkL99kRa bmfjm5sFRsxJQjUwBk3qigSgfT1ROPoFeExLwH3zuWzzV0o4hSmFMXaM7OryCwWZ4DXnIcxE APbQupRZ4vK9iTwUI1DD52wowyFf5Z2zE6ZFj/WM+Qkvqg3yQTChQWQ5f3859ZaHqgWdXp9q IQdQoMwW5uxv1fQpUPyIh5HsLHPuLiRepFfAyWnZ/KjFwMgmsFpNjycD76DenfgiRa3Vrmmj qDrzeciBKcanBgjC4mF4GpIRl8thZr7Up0PpKfbtR33gapS89UbmMLrNULkQnZpa6gC76c25 XwIDAQABozkwNzAnBgNVHREEIDAegRxqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMuY29tMAwG A1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAO287/+2OIBXpUka2g22uXfiYHmMbIZOK i3PDyuIHrPPQa9jXVtxYOanokqJ/6lUb7wsjJIOixu69rXeq7YfBhTEGZZzsKg13aT2RGVyt 9sNRNOsY5kryrKo2pPeBBlMBr1mdQjSy70bL+fajltBxph2pHeG02um90tI85aEgs5cwggM/ MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMM V2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25z dWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYD VQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNv bmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5 WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRk LjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2 vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9 A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEw EgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0 ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYDVR0R BCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GB AEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZ Ohl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVN d+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDOzCCAzcCAQEwaTBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrTAJBgUrDgMCGgUAoIIBpzAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjAyMjQyMzUyMjRaMCMGCSqG SIb3DQEJBDEWBBQhOntp4+316ogJjqVY9SAPsCbexDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhki