Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5R1AJsD097870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jun 2007 18:10:19 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5R1AJlo097869; Tue, 26 Jun 2007 18:10:19 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from ns4.neustar.com (ns4.neustar.com [156.154.24.139]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5R1AIrB097863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 26 Jun 2007 18:10:18 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id AE7612AC63; Wed, 27 Jun 2007 01:10:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I3M2k-00060E-FR; Tue, 26 Jun 2007 21:10:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-ltans@imc.org From: Internet-Drafts@ietf.org Subject: I-D Action:draft-ietf-ltans-dssc-00.txt Message-Id: Date: Tue, 26 Jun 2007 21:10:02 -0400 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Long-Term Archive and Notary Services Working Group of the IETF. Title : Data Structure for Security Suitabilities of Cryptographic Algorithms (DSSC) Author(s) : T. Kunz, et al. Filename : draft-ietf-ltans-dssc-00.txt Pages : 27 Date : 2007-06-24 In many application areas it must be possible to prove the existence and integrity of digital signed data. This proof depends on the security suitability of the used cryptographic algorithms. Because algorithms can become weak over the years, it is necessary to periodically evaluate these security suitabilities. When signing or verifying data, these evaluations must be considered. This document specifies a data structure for security suitabilities of cryptographic algorithms which may be automatically interpreted. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltans-dssc-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ltans-dssc-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ltans-dssc-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-06-26210653.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltans-dssc-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltans-dssc-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-06-26210653.I-D\@ietf.org> --OtherAccess-- --NextPart-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LBaGMx015915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jun 2007 04:36:17 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5LBaG95015914; Thu, 21 Jun 2007 04:36:16 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from ganymede.on-x.com (ganymede.on-x.com [194.51.68.3]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LBaFAq015891 for ; Thu, 21 Jun 2007 04:36:15 -0700 (MST) (envelope-from Peter.Sylvester@edelweb.fr) Received: from localhost (ganymede [127.0.0.1]) by ganymede.on-x.com (Postfix) with ESMTP id 45B2335; Thu, 21 Jun 2007 13:36:13 +0200 (CEST) Received: from ganymede.on-x.com ([127.0.0.1]) by localhost (ganymede.on-x.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30800-06; Thu, 21 Jun 2007 13:36:11 +0200 (CEST) Received: from vinea.on-x.com (sedna.puteaux.on-x [192.168.10.9]) by ganymede.on-x.com (Postfix) with ESMTP id E3FD12F; Thu, 21 Jun 2007 13:36:10 +0200 (CEST) Received: from [193.51.14.5] ([212.234.46.65]) by vinea.on-x.com (Lotus Domino Release 5.0.11) with ESMTP id 2007062113360983:307358 ; Thu, 21 Jun 2007 13:36:09 +0200 Message-ID: <467A6212.7050207@edelweb.fr> Date: Thu, 21 Jun 2007 13:33:38 +0200 From: Peter Sylvester User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: Aljosa Jerman Blazic Cc: Istvan Zsolt BERTA , ietf-ltans@imc.org Subject: Re: A new operation for LTAP, please comment References: In-Reply-To: X-MIMETrack: Itemize by SMTP Server on vinea/ON-X(Release 5.0.11 |July 24, 2002) at 06/21/2007 01:36:09 PM, Serialize by Router on vinea/ON-X(Release 5.0.11 |July 24, 2002) at 06/21/2007 01:36:10 PM, Serialize complete at 06/21/2007 01:36:10 PM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020904090500090404040705" X-Virus-Scanned: by amavisd-new at on-x.com Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a cryptographically signed message in MIME format. --------------ms020904090500090404040705 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit Aljosa Jerman Blazic wrote: > The list function we are discussing was orginally implemented thorugh STATUS function, i.e. if everything is lost by a client, a simple (empty) status operation may return available IDs. Furthermore, identification is done through different mchanisms, like internal (LTA) IDs, external (client) IDs or message imprints... Hence I see no particular reason for list operation. For now... > > I seems that I had forgotten this aspect of the status function. The problem that I see here is the size of the response, we must be careful to allow a responder to "stream" the data, e.g. we must not require a DER encoded responses for this case (as well as for returning data). --------------ms020904090500090404040705 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC BHIwggLfoAMCAQICBgqvijKA3jANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNzAzMjYxMDM3MDNaFw0wOTA2MDMxMDM3MDNaMHAx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPB7ZSfmYsUuVIV0W2izxb1Zyvr6ZJ IjPiqRMs77dbEQhQ6FZhhUSuABxxc8NjZvyPMRo0uuT0iVpRDktb0fWPTx3m9qTfdqrhWg2c IOBKNbNQr8NogDJvG1AxRx4q9SXKZCVpZCoHu3fz2Rfji1kL7l597+7qBEsFd9IyvRaexQID AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5 MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSZjq81LuJmsiiu1Yt/ezwCiUQSQTAfBgNV HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA A4IBfAAUq5MJ3gXhdKDpOm0ascDE9e1iMo0RQ24ujkc9IrFXhAJNS+3eNwcJEieU2vgZTsGb zKeBZom1zVOFoh73VIRP6T08j4dDlndpDYZbxD20KzFt9zX6gV8IgR2zkkZXLQRbLyW16kw8 oFe3s//p1csCkCPAlZv1rZQYR5Psm0A1aiOiuSHhWUmgfAJxmIgfbmKtS3WpsUZVBuLQpThN rWjLRAqJKYA++++qqo3ujqAAzJLe+MHrX5dai7+n6WBfV4qo1uDArR7XbmgVpV/EdPA75XRi XEedLgbFDawJ9nAMN6WfL/NG6GZkEa7mZ7sH/gG34y21nq4w4mAAxn9wz7mDKMsEbJMZ5VlJ TOp0g6TdYqGjNoc/rQg7pqjcRChVitwd1Rl8O31+bIdNSpv4UReNMDcffRQrt+pF1FxR4q6q M9YLJU8NThx/89Mf/WF7fzrgVlsNJ78D9nJu0EhKes/9EX2qpIcHUfk/izOj8lCc1ksFgXpd UEchE0DcMIIEcjCCAt+gAwIBAgIGCq+KMoDeMA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA3MDMyNjEwMzcwM1oXDTA5MDYwMzEw MzcwM1owcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM8HtlJ+ZixS5UhXRbaL PFvVnK+vpkkiM+KpEyzvt1sRCFDoVmGFRK4AHHFzw2Nm/I8xGjS65PSJWlEOS1vR9Y9PHeb2 pN92quFaDZwg4Eo1s1Cvw2iAMm8bUDFHHir1JcpkJWlkKge7d/PZF+OLWQvuXn3v7uoESwV3 0jK9Fp7FAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJmOrzUu4mayKK7Vi397PAKJ RBJBMB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI hvcNAQEFBQADggF8ABSrkwneBeF0oOk6bRqxwMT17WIyjRFDbi6ORz0isVeEAk1L7d43BwkS J5Ta+BlOwZvMp4FmibXNU4WiHvdUhE/pPTyPh0OWd2kNhlvEPbQrMW33NfqBXwiBHbOSRlct BFsvJbXqTDygV7ez/+nVywKQI8CVm/WtlBhHk+ybQDVqI6K5IeFZSaB8AnGYiB9uYq1Ldamx RlUG4tClOE2taMtECokpgD7776qqje6OoADMkt74wetfl1qLv6fpYF9XiqjW4MCtHtduaBWl X8R08DvldGJcR50uBsUNrAn2cAw3pZ8v80boZmQRruZnuwf+AbfjLbWerjDiYADGf3DPuYMo ywRskxnlWUlM6nSDpN1ioaM2hz+tCDumqNxEKFWK3B3VGXw7fX5sh01Km/hRF40wNx99FCu3 6kXUXFHirqoz1gslTw1OHH/z0x/9YXt/OuBWWw0nvwP2cm7QSEp6z/0RfaqkhwdR+T+LM6Py UJzWSwWBel1QRyETQNwwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0 MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe 1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0 dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3 UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy 4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6 PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18 k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ S0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwNjIxMTEzMzM4WjAjBgkqhkiG9w0B CQQxFgQUXqYAGjfUCRlPm0FA3IKM/1pgaPIwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy c0dFTgIGCq+KMoDeMHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ IEVkZWxXZWIgUGVyc0dFTgIGCq+KMoDeMA0GCSqGSIb3DQEBAQUABIGAShFe70N3HhXkfSEK 1vRGSkMqfj81yTd3t9QcYEisPX1ALkJBvT9Bx8fO/RHnXC6GfDC4Zx8y1mNLTAFgvix5Wkuq og88Fj5OsNeRkcv6pe38IKelGhEmz+pwubYZ1k6hh+7piq+snr2g7IqjOcUWnNFOYrHOp9l+ k6nWzCnApRMAAAAAAAA= --------------ms020904090500090404040705-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LB0kgh012431 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jun 2007 04:00:46 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5LB0k7K012430; Thu, 21 Jun 2007 04:00:46 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from setcce.si (localpolitix.setcce.org [193.138.1.155]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LB0jNL012424 for ; Thu, 21 Jun 2007 04:00:46 -0700 (MST) (envelope-from aljosa@setcce.si) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: A new operation for LTAP, please comment Date: Thu, 21 Jun 2007 13:00:54 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: A new operation for LTAP, please comment thread-index: Acez7sHJzq7bkXWRR9GO9lERQB7jzwAA/fxA From: "Aljosa Jerman Blazic" To: "Istvan Zsolt BERTA" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l5LB0kNL012425 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The list function we are discussing was orginally implemented thorugh STATUS function, i.e. if everything is lost by a client, a simple (empty) status operation may return available IDs. Furthermore, identification is done through different mchanisms, like internal (LTA) IDs, external (client) IDs or message imprints... Hence I see no particular reason for list operation. For now... BR > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Istvan Zsolt BERTA > Sent: 21. junij 2007 12:16 > To: ietf-ltans@imc.org > Subject: Re: A new operation for LTAP, please comment > > > Hello, > > In our company we operate a long-term archiving service and > we see that our clients send their documents into the > archiving service not only for preserving the long-term > validity of their signatures. What they want is to forget > about all the archiving-related tasks after they send their > documents into the archive. > > Although an archiving system can theoretically function > without such a 'listing' function, we found this function to > be essential in a real, practical system. > > I think an archiving system that loses the client's documents > if the client fails to archive 'something' (e.g. references > to the archived > documents) does not solve the right problem: a client needs > to archive something in order to make use of an archiving service. > > When implementing our service we did not want to create a > document management system either, so we also planned atomic > functions only. > However, we had to add a lot of search and listing related > functionality to make our system useable. > > István > > > -- > Dr. István Zsolt BERTA, PKI expert > MSc in Tech. Informatics, PhD, MBA, CISA > e-mail: istvan.berta@microsec.hu, tel: (+361) 505 4462 > Microsec Ltd., Záhony u. 7, Budapest, Hungary, H-1031 > > > Aljosa Jerman Blazic írta: > >> Hello Peter, > >> > >> I would envision a call to get the list of references more as a > >> document management function (which of course must have > appropriate > >> access control applied to it) and therefore would prefer it to be > >> outside the scope of LTAP. The function definitely makes sense, as > >> well as a query interface to receive certain documents, but this > >> should not be part of LTAP. > > > > I had the same concerns during the discussion with Peter... However > > this may have implication on the protocol usage. The > problem here is > > the role of LTA. As defined up to now, there are only atomic level > > functions, e.g. insert/get/verify/... Extending this > functions somehow > > pushes LTA towards EDMS and then the thing gets complex and > indeed I > > would not like to se it blown out of proportions. However, I would > > definitely look forward for some basic LTA service > characteristics/expectations. > > > >> I have thought a lot about LTAP lately, and would like to > also talk > >> about some thoughts about some kind of restructuring, to > learn what > >> you think: > >> My major goal is that LTAP gets implemented. > >> I get the feeling, that for many vendors it would be most > beneficial > >> for implementation, if there would be an "absolute minimal > subset" of > >> LTAP calls (like "get" and "put") together with the more > >> sophisticated calls - that are definitely very useful - of LTAP. > > > > Well, the current state of LTAP does exactly that. There are fields > > that are mandatory and fields that are open. What we need is only > > careful examination of field types/requirements. > > > >> My concerns is that a one-piece complicated complete > protocol might > >> raise the bar too high and reduce the chance of implementation. To > >> somehow split LTAP (e.g. inside the document or even in two > >> documents) into one "absolute minimal" set and one > "general use" set > >> might help here, to get implementers to at first take the first > >> hurdle quite easily and when they realize this is good and > easy they > >> will probably be more motivated to implement the whole thing. > > > > If the minimal set is defined (i.e. required fields) then > > extensions/upgrades are always optional. Furthermore, we > might follow > > the metainformation approach which has changed through the LTAP > > versions and it is now open to be filled in with arbitrary metadata > > types, even data objects. A very good point are guidelines > for minimal usage set... > > > > BR > > > > A. > > > >> > >>> -----Original Message----- > >>> From: owner-ietf-ltans@mail.imc.org > >>> [mailto:owner-ietf-ltans@mail.imc.org] > >>> On Behalf Of Peter Sylvester > >>> Sent: Tuesday, June 19, 2007 1:28 PM > >>> To: ietf-ltans@imc.org > >>> Subject: A new operation for LTAP, please comment > >>> > >>> Hello, > >>> > >>> I would like to ask the group about comments concerning a new > >>> operation for LTAP before I try to write it down into the draft. > >>> > >>> During a discussion with a company implementing an > >> 'electronic safe', > >>> and to see what functionality a protocol should provide, we > >> stumbled > >>> over the following. > >>> > >>> It happens that a client wants to get all its data back > but has not > >>> kept any knowledge about the references. > >>> > >>> This can occur in at least two scenarios, one is a real end user > >>> asking to a service provider, and it seems reasonable for > a service > >>> provider to offer such a service. > >>> One can argue that the service provider should maintain > somewhere a > >>> registry of all the stored data and provide a particular > operation. > >>> > >>> But then, this registry must be operated in a way which provides > >>> equivalent security as the archive itself. Or, if you loose the > >>> registry/directory there is no way to get data out the > >> archive unless > >>> you have strict sequential naming conventions or a particular > >>> operation. > >>> > >>> What we came up is an operation DIRLIST (name to be > discussed which > >>> allows to ask an archive to return a list of data > >> references that it > >>> possesses. > >>> Assuming that the archive has some internal order, the operation > >>> operates in a 'next' mode, i.e. a parameter indicated that > >> references > >>> 'behind' a particular one should be returned. > >>> > >>> We also think that this operation can have some other filters, at > >>> least a 'after date x' and also one selector of an owner of data. > >>> > >>> A client would then receive all the references and can get > >> them back > >>> individually. > >>> > >>> This operation is also useful when a client sends many > >> requests to the > >>> server in order to determine the final outcome of all of > >> them, instead > >>> of polling and repeating each operation, the client can > >> send a request > >>> to list all finished archive operations, and then ask the > >> final result > >>> only once. > >>> > >>> We are not sure whether such an operation should be part > of LTAP or > >>> definitely be outside. > >>> > >>> Please don't hesitate to make comments. > >>> > >>> Thanks in advance > >>> Peter > >>> > >>> > >>> > >> > > > > > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LAGEOT004609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jun 2007 03:16:14 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5LAGEYg004608; Thu, 21 Jun 2007 03:16:14 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from everest.microsec.hu (everest.microsec.hu [193.226.230.4]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5LAGB7E004584 for ; Thu, 21 Jun 2007 03:16:13 -0700 (MST) (envelope-from istvan.berta@microsec.hu) Received: from [127.0.0.1] ([10.42.223.19]) by everest.microsec.hu (8.12.9 w/patch for CAN-2003-0694/8.10.1) with ESMTP id l5LAG8Ox025262 for ; Thu, 21 Jun 2007 12:16:08 +0200 (MET DST) Message-ID: <467A4FE6.6010803@microsec.hu> Date: Thu, 21 Jun 2007 12:16:06 +0200 From: Istvan Zsolt BERTA User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ietf-ltans@imc.org Subject: Re: A new operation for LTAP, please comment References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000704060208000509040608" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a cryptographically signed message in MIME format. --------------ms000704060208000509040608 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Hello, In our company we operate a long-term archiving service and we see that=20 our clients send their documents into the archiving service not only for = preserving the long-term validity of their signatures. What they want is = to forget about all the archiving-related tasks after they send their=20 documents into the archive. Although an archiving system can theoretically function without such a=20 'listing' function, we found this function to be essential in a real,=20 practical system. I think an archiving system that loses the client's documents if the=20 client fails to archive 'something' (e.g. references to the archived=20 documents) does not solve the right problem: a client needs to archive=20 something in order to make use of an archiving service. When implementing our service we did not want to create a document=20 management system either, so we also planned atomic functions only.=20 However, we had to add a lot of search and listing related functionality = to make our system useable. Istv=C3=A1n -- Dr. Istv=C3=A1n Zsolt BERTA, PKI expert MSc in Tech. Informatics, PhD, MBA, CISA e-mail: istvan.berta@microsec.hu, tel: (+361) 505 4462 Microsec Ltd., Z=C3=A1hony u. 7, Budapest, Hungary, H-1031 Aljosa Jerman Blazic =C3=ADrta: >> Hello Peter, >> >> I would envision a call to get the list of references more as=20 >> a document management function (which of course must have=20 >> appropriate access control applied to it) and therefore would=20 >> prefer it to be outside the scope of LTAP. The function=20 >> definitely makes sense, as well as a query interface to=20 >> receive certain documents, but this should not be part of LTAP.=20 >=20 > I had the same concerns during the discussion with Peter... However thi= s > may have implication on the protocol usage. The problem here is the rol= e > of LTA. As defined up to now, there are only atomic level functions, > e.g. insert/get/verify/... Extending this functions somehow pushes LTA > towards EDMS and then the thing gets complex and indeed I would not lik= e > to se it blown out of proportions. However, I would definitely look > forward for some basic LTA service characteristics/expectations. > =20 >> I have thought a lot about LTAP lately, and would like to=20 >> also talk about some thoughts about some kind of=20 >> restructuring, to learn what you think: >> My major goal is that LTAP gets implemented.=20 >> I get the feeling, that for many vendors it would be most=20 >> beneficial for implementation, if there would be an "absolute=20 >> minimal subset" of LTAP calls (like "get" and "put") together=20 >> with the more sophisticated calls - that are definitely very=20 >> useful - of LTAP. >=20 > Well, the current state of LTAP does exactly that. There are fields tha= t > are mandatory and fields that are open. What we need is only careful > examination of field types/requirements. >=20 >> My concerns is that a one-piece complicated complete protocol=20 >> might raise the bar too high and reduce the chance of=20 >> implementation. To somehow split LTAP (e.g. inside the=20 >> document or even in two documents) into one "absolute=20 >> minimal" set and one "general use" set might help here, to=20 >> get implementers to at first take the first hurdle quite=20 >> easily and when they realize this is good and easy they will=20 >> probably be more motivated to implement the whole thing.=20 >=20 > If the minimal set is defined (i.e. required fields) then > extensions/upgrades are always optional. Furthermore, we might follow > the metainformation approach which has changed through the LTAP version= s > and it is now open to be filled in with arbitrary metadata types, even > data objects. A very good point are guidelines for minimal usage set...= >=20 > BR >=20 > A. >=20 >> >>> -----Original Message----- >>> From: owner-ietf-ltans@mail.imc.org=20 >>> [mailto:owner-ietf-ltans@mail.imc.org] >>> On Behalf Of Peter Sylvester >>> Sent: Tuesday, June 19, 2007 1:28 PM >>> To: ietf-ltans@imc.org >>> Subject: A new operation for LTAP, please comment >>> >>> Hello, >>> >>> I would like to ask the group about comments concerning a new=20 >>> operation for LTAP before I try to write it down into the draft. >>> >>> During a discussion with a company implementing an=20 >> 'electronic safe',=20 >>> and to see what functionality a protocol should provide, we=20 >> stumbled=20 >>> over the following. >>> >>> It happens that a client wants to get all its data back but has not=20 >>> kept any knowledge about the references. >>> >>> This can occur in at least two scenarios, one is a real end user=20 >>> asking to a service provider, and it seems reasonable for a service=20 >>> provider to offer such a service. >>> One can argue that the service provider should maintain somewhere a=20 >>> registry of all the stored data and provide a particular operation. >>> >>> But then, this registry must be operated in a way which provides=20 >>> equivalent security as the archive itself. Or, if you loose the=20 >>> registry/directory there is no way to get data out the=20 >> archive unless=20 >>> you have strict sequential naming conventions or a particular=20 >>> operation. >>> >>> What we came up is an operation DIRLIST (name to be discussed which=20 >>> allows to ask an archive to return a list of data=20 >> references that it=20 >>> possesses. >>> Assuming that the archive has some internal order, the operation=20 >>> operates in a 'next' mode, i.e. a parameter indicated that=20 >> references=20 >>> 'behind' a particular one should be returned. >>> >>> We also think that this operation can have some other filters, at=20 >>> least a 'after date x' and also one selector of an owner of data. >>> >>> A client would then receive all the references and can get=20 >> them back=20 >>> individually. >>> >>> This operation is also useful when a client sends many=20 >> requests to the=20 >>> server in order to determine the final outcome of all of=20 >> them, instead=20 >>> of polling and repeating each operation, the client can=20 >> send a request=20 >>> to list all finished archive operations, and then ask the=20 >> final result=20 >>> only once. >>> >>> We are not sure whether such an operation should be part of LTAP or=20 >>> definitely be outside. >>> >>> Please don't hesitate to make comments. >>> >>> Thanks in advance >>> Peter >>> >>> >>> >> >=20 --------------ms000704060208000509040608 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINsjCC BgYwggTuoAMCAQICAgFwMA0GCSqGSIb3DQEBBQUAMG4xCzAJBgNVBAYTAkhVMREwDwYDVQQH EwhCdWRhcGVzdDEWMBQGA1UEChMNTWljcm9zZWMgTHRkLjEUMBIGA1UECxMLZS1Temlnbm8g Q0ExHjAcBgNVBAMTFUFkdmFuY2VkIGUtU3ppZ25vIENBMzAeFw0wNzA0MTIxMjMyNDFaFw0w OTA0MTIxMjMyNDFaMIG/MQswCQYDVQQGEwJIVTERMA8GA1UEBwwIQnVkYXBlc3QxFjAUBgNV BAoMDU1pY3Jvc2VjIEtmdC4xFjAUBgNVBAsMDWUtU3ppZ27DsyBIU1oxIDAeBgNVBAMMF0Ry LiBCZXJ0YSBJc3R2w6FuIFpzb2x0MScwJQYJKoZIhvcNAQkBFhhpc3R2YW4uYmVydGFAbWlj cm9zZWMuaHUxIjAgBgNVBAUTGTEuMy42LjEuNC4xLjIxNTI4LjIuMi4zLjIwgZ8wDQYJKoZI hvcNAQEBBQADgY0AMIGJAoGBALzCux3ayRJf7nxUlQjelFuQGjz5IfJqjP8bCUrx/U4mjKZi +L6lBT6I+b92Kn/m5JH0aS6WugOjEdytceddeIV/8Ph92J898MlI06xBdRY18uwxvK0c938p aKo3W33DNuoF4uuD/eZczFM9HpMkmniZg78doI2OX7PBijzMAJJ7AgMBAAGjggLeMIIC2jAM BgNVHRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIGwDATBgNVHSUEDDAKBggrBgEFBQcDBDCCAXYG A1UdIASCAW0wggFpMIIBZQYMKwYBBAGBqBgCAQELMIIBUzApBggrBgEFBQcCARYdaHR0cDov L3d3dy5lLXN6aWduby5odS9BU1pTWi8wggEkBggrBgEFBQcCAjCCARYeggESAEYAbwBrAG8A egBvAHQAdAAgAGIAaQB6AHQAbwBuAHMA4QBnAPoAIAB0AGEAbgD6AHMA7QB0AHYA4QBuAHkA LAAgAHIAZQBnAGkAcwB6AHQAcgDhAGMAaQDzAGsAbwByACAAYQAgAHMAegBlAG0A6QBsAHkA ZQBzACAAbQBlAGcAagBlAGwAZQBuAOkAcwAgAGsA9gB0AGUAbABlAHoBUQAsACAAUwB6AG8A bABnAOEAbAB0AGEAdADhAHMAaQAgAFMAegBhAGIA4QBsAHkAegBhAHQAOgAgAGgAdAB0AHAA OgAvAC8AdwB3AHcALgBlAC0AcwB6AGkAZwBuAG8ALgBoAHUALwBBAFMAWgBTAFoALzAdBgNV HQ4EFgQUNrZXxTrLCZSJdQgF56K75MYICW4wHwYDVR0jBBgwFoAUIpSkBqt8FOTMNhaLmYY0 xFjwLnowIwYDVR0RBBwwGoEYaXN0dmFuLmJlcnRhQG1pY3Jvc2VjLmh1MDAGA1UdHwQpMCcw JaAjoCGGH2h0dHA6Ly93d3cuZS1zemlnbm8uaHUvQUNBMy5jcmwwgZMGCCsGAQUFBwEBBIGG MIGDMCkGCCsGAQUFBzABhh1odHRwczovL2JjYS5lLXN6aWduby5odS9hb2NzcDArBggrBgEF BQcwAoYfaHR0cDovL3d3dy5lLXN6aWduby5odS9BQ0EzLmNydDApBggrBgEFBQcwA4YdaHR0 cHM6Ly9idHNhLmUtc3ppZ25vLmh1L2F0c2EwDQYJKoZIhvcNAQEFBQADggEBAMEE7L+15GSx XnC+2Li/pr8TTPPubJ9nnOQVhz92APUUmDMQbx4R//aB0od+m/+xUwb3dQxzWkhE4ulEtFz/ 6icuj2xCHPI1d8y8VtQK8x44xovf3+edmSwTOWEtUcH4W0+CSP44nHyckxQk9DSNdVP+hs+d MZGOcBBlvBh77tqCgvhi86+yZnuzA5T/DM0GAzhWQQmLhodkigdxDOmqFLO7JNCppfJJ6N3a 81h8ZdAkVjR/wVaQcNZOeg5jucQfQMYR64nE3tMfoK0O1620dPVob8YFfyT671QC/DQn1Xd5 BJac/Qq+XfyZjldGs1wd7IxqFZ97az3eXlw+HlUC1V0wggekMIIGjKADAgECAhANFfTNMDy+ liPC7kBmb8PHMA0GCSqGSIb3DQEBBQUAMHIxCzAJBgNVBAYTAkhVMREwDwYDVQQHEwhCdWRh cGVzdDEWMBQGA1UEChMNTWljcm9zZWMgTHRkLjEUMBIGA1UECxMLZS1Temlnbm8gQ0ExIjAg BgNVBAMTGU1pY3Jvc2VjIGUtU3ppZ25vIFJvb3QgQ0EwHhcNMDUwNTI1MDkwNjEzWhcNMTUw NTI1MDkwNjEzWjBuMQswCQYDVQQGEwJIVTERMA8GA1UEBxMIQnVkYXBlc3QxFjAUBgNVBAoT DU1pY3Jvc2VjIEx0ZC4xFDASBgNVBAsTC2UtU3ppZ25vIENBMR4wHAYDVQQDExVBZHZhbmNl ZCBlLVN6aWdubyBDQTMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDLzQxK56Pt G1qOjO5NBLMdGoEXXCfpx6nFT7mTt+pdwNfOlaB/xrxTo0QSbFVMjiTnOuzHh1+m7qxxtRar vcEeli95sdEBmbkvttKcL39Q1vMyqhbkCsE32d6sTk+odjRi3VZRDqTkGhsSk0wlp9hOAb/s NPJqqZ5nN/GQC3Ln00BMtsowfm4U3lCLKF2DuehSS8KPSnHBTZEwdVLUIKTu3a5rWoKBLnzM bFmcb1tmLYj5h9sMUldWdiAA+7K6/E/JMCTmXZ59WH4W0zGqowGnfwxpTM3Qma+/4E67iwJd CEHaE0rgm60hw4XWxrBNAxGVD4mEq/tnzD2aUvZdibl/AgMBAAGjggQ4MIIENDCBkgYDVR0R BIGKMIGHgRBpbmZvQGUtc3ppZ25vLmh1pHMwcTEfMB0GA1UEAwwWRm9rb3pvdHQgZS1Temln bsOzIENBMzEWMBQGA1UECwwNZS1TemlnbsOzIEhTWjEWMBQGA1UEChMNTWljcm9zZWMgS2Z0 LjERMA8GA1UEBxMIQnVkYXBlc3QxCzAJBgNVBAYTAkhVMGkGCCsGAQUFBwEBBF0wWzAqBggr BgEFBQcwAYYeaHR0cHM6Ly9hcmNhLmUtc3ppZ25vLmh1L2FvY3NwMC0GCCsGAQUFBzAChiFo dHRwOi8vd3d3LmUtc3ppZ25vLmh1L1Jvb3RDQS5jcnQwgawGA1UdIwSBpDCBoYAUx6BJdRZh hNsxS4TS8TdAkO9O3PehdqR0MHIxCzAJBgNVBAYTAkhVMREwDwYDVQQHEwhCdWRhcGVzdDEW MBQGA1UEChMNTWljcm9zZWMgTHRkLjEUMBIGA1UECxMLZS1Temlnbm8gQ0ExIjAgBgNVBAMT GU1pY3Jvc2VjIGUtU3ppZ25vIFJvb3QgQ0GCEQDMuOe/Tika/aLcZqUcLA8RMA8GA1UdEwEB /wQFMAMBAf8wggF2BgNVHSAEggFtMIIBaTCCAWUGDCsGAQQBgagYAgEBCDCCAVMwKQYIKwYB BQUHAgEWHWh0dHA6Ly93d3cuZS1zemlnbm8uaHUvRlNaU1ovMIIBJAYIKwYBBQUHAgIwggEW HoIBEgBBACAAdABhAG4A+gBzAO0AdAB2AOEAbgB5ACAA6QByAHQAZQBsAG0AZQB6AOkAcwDp AGgAZQB6ACAA6QBzACAAZQBsAGYAbwBnAGEAZADhAHMA4QBoAG8AegAgAGEAIABTAHoAbwBs AGcA4QBsAHQAYQB0APMAIABTAHoAbwBsAGcA4QBsAHQAYQB0AOEAcwBpACAAUwB6AGEAYgDh AGwAeQB6AGEAdABhACAAcwB6AGUAcgBpAG4AdAAgAGsAZQBsAGwAIABlAGwAagDhAHIAbgBp ADoAIABoAHQAdABwADoALwAvAHcAdwB3AC4AZQAtAHMAegBpAGcAbgBvAC4AaAB1AC8ARgBT AFoAUwBaAC8wgcgGA1UdHwSBwDCBvTCBuqCBt6CBtIYhaHR0cDovL3d3dy5lLXN6aWduby5o dS9Sb290Q0EuY3JshoGObGRhcDovL2xkYXAuZS1zemlnbm8uaHUvQ049TWljcm9zZWMlMjBl LVN6aWdubyUyMFJvb3QlMjBDQSxPVT1lLVN6aWdubyUyMENBLE89TWljcm9zZWMlMjBMdGQu LEw9QnVkYXBlc3QsQz1IVT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0O2JpbmFyeTAOBgNV HQ8BAf8EBAMCAQYwHQYDVR0OBBYEFCKUpAarfBTkzDYWi5mGNMRY8C56MA0GCSqGSIb3DQEB BQUAA4IBAQB3RoqS7NQZHXspzNnH44zhc8tYsMg4To7kfUeSz/8ocSiU2TTij2yP9PZuCYlX BniZl1drADXGZgYw06VY3cjmt+0cRGTbRWHx50Z4NrjWHU6sxvhTYmmD2tGnP2ChprmIDUoe dsdkZXkLDs0p6tQk0foQaPCOTUc/5mHN/2W6vVBcXWhd36QCPGlE9fxQ/PdYlxcqD+rPwAbP hMCvMCFSHMCFljivlXU5YkTNB9+d+gq72qsazEJqjUay4pU7+Pcm2+Qw8GMWHK3DYXFhskxy CeJwvZbNJAq5KQ55ZNF5VrsJK28T7lBYwg6+63HTI2VNJwMeAj8mHoE/JpaaRohlMYIBzjCC AcoCAQEwdDBuMQswCQYDVQQGEwJIVTERMA8GA1UEBxMIQnVkYXBlc3QxFjAUBgNVBAoTDU1p Y3Jvc2VjIEx0ZC4xFDASBgNVBAsTC2UtU3ppZ25vIENBMR4wHAYDVQQDExVBZHZhbmNlZCBl LVN6aWdubyBDQTMCAgFwMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDcwNjIxMTAxNjA2WjAjBgkqhkiG9w0BCQQxFgQUoGgqbUze hlGg+fGVbp/2pShu2cUwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcN AQEBBQAEgYAirsOwQXW9+vv49+9pt8aJa5u/p+hM48G+oHno9zHqMVEiTSIz5qih5osodJ6E skrPPurau5btgK0xSwMaRP4zZbSpKizTXQrYnUrrmFd2NNLcXNKva1x3/sUfGGynlESm+0qA GeRS6HEEgRFsro6GwUHHvjBqdEAA5IEjuMSUbgAAAAAAAA== --------------ms000704060208000509040608-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5KL6pGg070661 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Jun 2007 14:06:51 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5KL6pC9070660; Wed, 20 Jun 2007 14:06:51 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5KL6npU070644 for ; Wed, 20 Jun 2007 14:06:49 -0700 (MST) (envelope-from tglassey@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=UAi+e3Cp284p4tvzyD8kpxSvTShQnIrZWhjnpfXa8ABF1aUchuYRIA43W+xlgONm; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [64.125.79.23] (helo=gw) by elasmtp-junco.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1I17O2-0001cz-1D; Wed, 20 Jun 2007 17:06:46 -0400 Message-ID: <00bc01c7b37e$e8faa4e0$174f7d40@home.glassey.com> From: "todd glassey" To: "Tobias Gondrom" , "Harald Alvestrand" , "Contreras, Jorge" Cc: , References: <2666EB2A846BAC4BB2D7F593301A7868011E4D76@MUCXGC2.opentext.net><013501c7b35e$5c099ca0$174f7d40@home.glassey.com> <46796A6C.6060806@alvestrand.no> <015701c7b366$0e616b10$174f7d40@home.glassey.com> <2666EB2A846BAC4BB2D7F593301A78680C6668@MUCXGC2.opentext.net> Subject: Re: LTANS WG Last Call on draft-ietf-ltans-ers-scvp-03.txt Date: Wed, 20 Jun 2007 14:06:43 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B9_01C7B344.3B59FE10" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79a3c3c35f6e4c692ea2d0d7a68f7579dd350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.125.79.23 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_00B9_01C7B344.3B59FE10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: LTANS WG Last Call on draft-ietf-ltans-ers-scvp-03.txtTobias and = Jorge... ----- Original Message -----=20 From: Tobias Gondrom=20 To: todd glassey ; Harald Alvestrand ; Contreras, Jorge=20 Cc: ietf-ltans@imc.org ; ipr-wg@ietf.org=20 Sent: Wednesday, June 20, 2007 12:42 PM Subject: RE: LTANS WG Last Call on draft-ietf-ltans-ers-scvp-03.txt Hello, *sigh* my company as many others has the policy to include certain = disclaimers in the emails sent out by their employees. As do most SOX impacted companys too... The problem is that they (the = disclaimers) mean what they say and removing them doesnt change the = corporate or entity policy which was what was trying to be disclosed to = the recipient by the Entity. Since you dont own any email that is sent = through the GW per the commentary in the Disclaimer - it doesnt matter = whether you delete the disclaimer or not - you still wont own the IP = therein. Any of it... (note: Technically I can in fact remove or modify this disclaimer if = necessary. Tobias - Again - I too can erase the text the email tool I use puts on = the mailings as a disclaimer, but that doesnt change the corporate = policy... so being able to delete the disclaimer text in the outgoing = email does NOT invalidate the corporate policy from controlling that = email. In fact it may in some jurisdictions it may be a criminal to = remove it since the material then misrepresnts ownership and control of = the IP itself.=20 Remember that (c) does not have to be stated to be in effect. In fact no = copyright message or warning is needed at all anymore to have that media = protected by copyright convention. But as I would have to do this for every single email individually, I = tend to forget to modify my footer for the IETF. Maybe I could use a = private email instead, but this would also not be the most convenient = option...) Although I understand that it might be interesting to make a precedent = case of my email, please note that this email DID obviously NOT CONTAIN = ANY IP content. So maybe not the best example? Actually it contained plenty of IP - and those IP's were documenting the = functioning of the SDO's processes, and as such it is possible to file = for and have granted a utility patent against the IETF's standards = process making anything that documented that process real IP therein. However, as I might make this mistake in the future again - to leave = the footer as it is - any ruling from the IPR group of the IETF would be = pretty welcome. I would like to understand this as described by Harald, = but of course am no lawyer... If this is not the case and my email is in fact an infringement of the = IETF policies, please accept my apologies. (If this would be an = infringement of IETF policies, we(IETF) should definitely also very fast = implement an automatic scanner for disclaimers and bounce back the other = violating emails as well.) I agree. But the real issue is in implementing the proper disclosure = model so that the Hosting Sponsor Entitie's are all regularly informed = of any changes to their sponsoree's positions within the IETF or legal = requirements from the Sponsor's for their sponsoree's participation. = This is a key issue to manage and it means that the Corporate Legal or = HR department's must sign off on their employee/sponsoree's = participation under the IETF's rules. Todd Tobias Ps.: I would propose to lead this discussion on the ipr-wg list and = not on ltans - unless you want to also discuss it on all the other IETF = WG lists as well. -----Original Message----- From: todd glassey [mailto:tglassey@earthlink.net] Sent: Wed 6/20/2007 8:08 PM To: Harald Alvestrand; Tobias Gondrom; Contreras, Jorge Cc: ietf-ltans@imc.org; ipr-wg@ietf.org Subject: Re: LTANS WG Last Call on draft-ietf-ltans-ers-scvp-03.txt No Harald - ITS YOU WHO ARE WRONG... If Tobias doesn't own the mail server and/or doesn't have legal power = of attorney for the mail server, then he cannot assign the ownership of anything to anyone sent through that gateway whether you like it or = not... PERIOD. But hey Harald - since you cannot provide ANY basis in fact for that statement you made, and yet you continue to insist I am wrong... I = suggest that you get the IETF's lawyers to publicly say that "NoteWell = overrides any and all printed disclaimers or IP Ownership Statement's in any = submissions to the IETF"... and since we both know that this will open the IETF to litigation from every SOX impacted company on the face of the planet for attacking the controls they need on their email GW's, I am betting that you refuse to do this too... That said - Harald - either document that there is precedent in US Law = to set aside the disclaimer statement in the Tobias' email or back off = the commentary ... Todd Glassey ----- Original Message ----- From: "Harald Alvestrand" To: "Tobias Gondrom" Cc: ; Sent: Wednesday, June 20, 2007 10:57 AM Subject: Re: LTANS WG Last Call on draft-ietf-ltans-ers-scvp-03.txt todd glassey wrote: > Tobias I want to point out an inconsistency in how the IETF = operates... > We are told that any and all submissions belong to the IETF, but > according to the text disclaimer in your filing, the Open Text = Corporation > claims it holds and retains any and all rights to the text herein. = That > means that the NoteWell processes of the IETF DONT work here, and = cannot > by the very disclaimer you have on the mailings themselves. > This is not my doing - I am just noticing this and asking how = NoteWell > can possibly be called into effect when disclaimers like the one you = have > below are included in the mailing since I see no formal way of = setting > those terms and conditions aside. I dont mean this as a slam on the = LTANS > WG - this is the problem of the management of the IPR WG who is > responsible for this screw-up IMHO. There is precedent for this; the disclaimers on a message that is voluntarily and knowingly posted to a forum where the rules are different cause the disclaimers to be without any legal effect. In particular, by sending the message to the LTANS list, Tobias = Gondrom is bound by the IETF rules on contributions, no matter what his (IMHO silly) disclaimers say. Harald > Todd Glassey > > ----- Original Message ----- > *From:* Tobias Gondrom > *To:* ietf-ltans@imc.org > *Sent:* Wednesday, June 20, 2007 9:33 AM > *Subject:* LTANS WG Last Call on = draft-ietf-ltans-ers-scvp-03.txt > > Hello dear LTANS WG, > > to progress with ers-scvp, I would like to announce WG Last Call > for this document. > > Please make a last careful review of the draft and submit > comments, questions and discuss items for this draft until > July-05, so that we can present a final status on the draft at = the > Chicago meeting and submit it to the IESG soon. > > Thank you, > > Tobias > > Chair of LTANS > > > ***__________________________________________* > *Tobias Gondrom* > Head of Open Text Security Team > Director, Product Security > > *Open Text Corporation* > Technopark 2 > Werner-von-Siemens-Ring 20 > D-85630 Grasbrunn > > Phone: +49 (0) 89 4629-1816 > Mobile: +49 (0) 173 5942987 > Telefax: +49 (0) 89 4629-33-1816 > eMail: mailto:tobias.gondrom@opentext.com > Internet: http://www.opentext.com/ > Place of Incorporation / Sitz der Gesellschaft: Open Text GmbH, = An > der Trift 65, 63303 Dreieich, Germany | Phone: +49 (0) 6103 890 = 40 > | Fax: +49 (0) 6103 89 04 11 | Register Court / Registergericht: > Offenbach, Germany | Trade Register Number / HRB: 33340 | VAT ID > Number /USt-ID: DE 114 169 819 | Managing Director / > Gesch=E4ftsf=FChrer: John Shackleton > > This email is protected by domestic and international copyright > laws and treaties and is the property of Open Text Corporation, = it > may contain confidential and/or trade secret information of the > Open Text Corporation and/or its subsidiaries (OTC), and may be > subject to legal privilege in favor of OTC. This email may only = be > lawfully received, accessed, displayed on a computer screen, > printed, copied, and/or used by the specific addressee(s) named > above ("Authorized Recipient") for the purpose for which it was > sent by OTC. All other rights and licenses to this email are = fully > reserved to OTC. If you are not an Authorized Recipient, you are > required to immediately delete this email in its entirety = without > printing, copying, using, and/or re-transmitting this email, > either in whole or in part. The transmission of this email by = OTC > is not to be construed as a waiver by OTC and/or the individual > sending this email on behalf of OTC of any of their respective > rights or privileges at law or otherwise, howsoever arising. > > = ------------------------------------------------------------------------ > > _______________________________________________ > Ipr-wg mailing list > Ipr-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/ipr-wg > _______________________________________________ Ipr-wg mailing list Ipr-wg@ietf.org https://www1.ietf.org/mailman/listinfo/ipr-wg ------=_NextPart_000_00B9_01C7B344.3B59FE10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: LTANS WG Last Call on = draft-ietf-ltans-ers-scvp-03.txt
Tobias and = Jorge...
----- Original Message -----
From:=20 Tobias=20 Gondrom
To: todd glassey ; Harald=20 Alvestrand ; Contreras, Jorge =
Cc: ietf-ltans@imc.org ; ipr-wg@ietf.org
Sent: Wednesday, June 20, 2007 = 12:42=20 PM
Subject: RE: LTANS WG Last Call = on=20 draft-ietf-ltans-ers-scvp-03.txt

Hello,

*sigh* my company as many others has = the policy=20 to include certain disclaimers in the emails sent out by their=20 employees.

 
As do most = SOX impacted=20 companys too... The problem is that they (the disclaimers) mean = what they=20 say and removing them doesnt change the corporate or entity policy which = was=20 what was trying to be disclosed to the recipient by the Entity. Since = you dont=20 own any email that is sent through the GW per the commentary in the = Disclaimer -=20 it doesnt matter whether you delete the disclaimer or not - you still = wont own=20 the IP therein. Any of it...

(note: Technically I can in fact remove or modify this disclaimer = if=20 necessary.

Tobias - Again - I too can = erase the=20 text the email tool I use puts on the mailings as a disclaimer, but that = doesnt=20 change the corporate policy... so being able to delete the disclaimer = text in=20 the outgoing email does NOT invalidate the corporate policy from=20 controlling that email. In fact it may in some jurisdictions it may be a = criminal to remove it since the material = then misrepresnts=20 ownership and control of the IP itself.

Remember that (c) does not = have to be=20 stated to be in effect. In fact no copyright message or warning is = needed at all=20 anymore to have that media protected by copyright convention.

 But as I would have to do this for every single email = individually, I=20 tend to forget to modify my footer for the IETF. Maybe I could use a = private=20 email instead, but this would also not be the most convenient=20 option...)

Although I understand that it might be interesting = to make a=20 precedent case of my email, please note that this email DID obviously = NOT=20 CONTAIN ANY IP content. So maybe not the best = example?

Actually it contained plenty = of IP - and=20 those IP's were documenting the functioning of the SDO's processes, and = as such=20 it is possible to file for and have granted a utility patent against the = IETF's=20 standards process making anything that documented that process real IP=20 therein.



However, as I might make this mistake in the future again - = to=20 leave the footer as it is - any ruling from the IPR group of the IETF = would be=20 pretty welcome. I would like to understand this as described by = Harald, but of=20 course am no lawyer...

If this is not the case and my email is = in fact=20 an infringement of the IETF policies, please accept my apologies. (If = this=20 would be an infringement of IETF policies, we(IETF) should definitely = also=20 very fast implement an automatic scanner for disclaimers and bounce = back the=20 other violating emails as well.)

 

I agree. But the real issue = is in=20 implementing the proper disclosure model so that the Hosting Sponsor = Entitie's=20 are all regularly informed of any changes to their sponsoree's positions = within=20 the IETF or legal requirements from the Sponsor's for their sponsoree's=20 participation. This is a key issue to manage and it means that the = Corporate=20 Legal or HR department's must sign off on their employee/sponsoree's=20 participation under the IETF's rules.

Todd



Tobias


Ps.: I would propose to lead this = discussion on=20 the ipr-wg list and not on ltans - unless you want to also discuss it = on all=20 the other IETF WG lists as well.




-----Original=20 Message-----
From: todd glassey [mailto:tglassey@earthlink.net]=
Sent:=20 Wed 6/20/2007 8:08 PM
To: Harald Alvestrand; Tobias Gondrom; = Contreras,=20 Jorge
Cc: ietf-ltans@imc.org; ipr-wg@ietf.org
Subject: Re: LTANS = WG Last=20 Call on draft-ietf-ltans-ers-scvp-03.txt

No Harald - ITS YOU = WHO ARE=20 WRONG...

If Tobias doesn't own the mail server and/or doesn't = have=20 legal power of
attorney for the mail server, then he cannot assign = the=20 ownership of
anything to anyone sent through that gateway whether = you like=20 it or not...
PERIOD.

But hey Harald - since you cannot = provide ANY=20 basis in fact for that
statement you made, and yet you continue to = insist I=20 am wrong... I suggest
that you get the IETF's lawyers to publicly = say that=20 "NoteWell overrides any
and all printed disclaimers or IP Ownership = Statement's in any submissions
to the IETF"... and since we both = know that=20 this will open the IETF to
litigation from every SOX impacted = company on=20 the face of the planet
for attacking the controls they need on = their email=20 GW's, I am betting
that you refuse to do this too...

That = said -=20 Harald - either document that there is precedent in US Law to
set = aside the=20 disclaimer statement in the Tobias' email or back off = the
commentary=20 ...

Todd Glassey
----- Original Message -----
From: = "Harald=20 Alvestrand" <harald@alvestrand.no>
To: "Tobias Gondrom"=20 <tgondrom@opentext.com>
Cc: <ietf-ltans@imc.org>;=20 <ipr-wg@ietf.org>
Sent: Wednesday, June 20, 2007 10:57 = AM
Subject:=20 Re: LTANS WG Last Call on = draft-ietf-ltans-ers-scvp-03.txt


todd=20 glassey wrote:
> Tobias I want to point out an inconsistency in = how the=20 IETF operates...
>  We are told that any and all = submissions belong=20 to the IETF, but
> according to the text disclaimer in your = filing, the=20 Open Text Corporation
> claims it holds and retains any and all = rights=20 to the text herein. That
> means that the NoteWell processes of = the IETF=20 DONT work here, and cannot
> by the very disclaimer you have on = the=20 mailings themselves.
>  This is not my doing - I am just = noticing=20 this and asking how NoteWell
> can possibly be called into = effect when=20 disclaimers like the one you have
> below are included in the = mailing=20 since I see no formal way of setting
> those terms and = conditions aside.=20 I dont mean this as a slam on the LTANS
> WG - this is the = problem of=20 the management of the IPR WG who is
> responsible for this = screw-up=20 IMHO.
There is precedent for this; the disclaimers on a message = that=20 is
voluntarily and knowingly posted to a forum where the rules=20 are
different cause the disclaimers to be without any legal=20 effect.

In particular, by sending the message to the LTANS = list, Tobias=20 Gondrom
is bound by the IETF rules on contributions, no matter what = his=20 (IMHO
silly) disclaimers=20 = say.

          &= nbsp;          =20 Harald
>  Todd = Glassey
>
>    =20 ----- Original Message -----
>     *From:* = Tobias=20 Gondrom <mailto:tgondrom@opentext.com>= ;
>    =20 *To:* ietf-ltans@imc.org <mailto:ietf-ltans@imc.org>
&= gt;    =20 *Sent:* Wednesday, June 20, 2007 9:33 = AM
>    =20 *Subject:* LTANS WG Last Call on=20 = draft-ietf-ltans-ers-scvp-03.txt
>
>     = Hello=20 dear LTANS WG,
>
>     to progress = with=20 ers-scvp, I would like to announce WG Last=20 Call
>     for this=20 document.
>
>     Please make a last = careful=20 review of the draft and submit
>     = comments,=20 questions and discuss items for this draft=20 until
>     July-05, so that we can present = a final=20 status on the draft at the
>     Chicago = meeting and=20 submit it to the IESG soon.
>
>     = Thank=20 you,
>
>    =20 Tobias
>
>     Chair of=20 LTANS
>
>
>    =20 = ***__________________________________________*
>   &= nbsp;=20 *Tobias Gondrom*
>     Head of Open Text = Security=20 Team
>     Director, Product=20 Security
>
>     *Open Text=20 Corporation*
>     Technopark=20 2
>     Werner-von-Siemens-Ring=20 20
>     D-85630=20 Grasbrunn
>
>     Phone: +49 (0) 89=20 4629-1816
>     Mobile: +49 (0) 173=20 5942987
>     Telefax: +49 (0) 89=20 4629-33-1816
>     eMail: mailto:tobias.gondrom@opentex= t.com
>    =20 Internet: http://www.opentext.com/
>&nb= sp;   =20 Place of Incorporation / Sitz der Gesellschaft: Open Text GmbH,=20 An
>     der Trift 65, 63303 Dreieich, = Germany |=20 Phone: +49 (0) 6103 890 40
>     | Fax: +49 = (0) 6103=20 89 04 11 | Register Court / = Registergericht:
>    =20 Offenbach, Germany | Trade Register Number / HRB: 33340 | VAT=20 ID
>     Number /USt-ID:  DE 114 169 = 819 |=20 Managing Director /
>     = Gesch=E4ftsf=FChrer: John=20 Shackleton
>
>     This email is = protected by=20 domestic and international copyright
>     = laws and=20 treaties and is the property of Open Text Corporation,=20 it
>     may contain confidential and/or = trade=20 secret information of the
>     Open Text=20 Corporation and/or its subsidiaries (OTC), and may=20 be
>     subject to legal privilege in favor = of OTC.=20 This email may only be
>     lawfully = received,=20 accessed, displayed on a computer = screen,
>    =20 printed, copied, and/or used by the specific addressee(s)=20 named
>     above ("Authorized Recipient") = for the=20 purpose for which it was
>     sent by OTC. = All=20 other rights and licenses to this email are=20 fully
>     reserved to OTC. If you are not = an=20 Authorized Recipient, you are
>     required = to=20 immediately delete this email in its entirety=20 without
>     printing, copying, using, = and/or=20 re-transmitting this email,
>     either in = whole or=20 in part. The transmission of this email by = OTC
>    =20 is not to be construed as a waiver by OTC and/or the=20 individual
>     sending this email on = behalf of OTC=20 of any of their respective
>     rights or=20 privileges at law or otherwise, howsoever arising.
>
>=20 = ------------------------------------------------------------------------<= BR>>
>=20 _______________________________________________
> Ipr-wg mailing = list
> Ipr-wg@ietf.org
> https://www1.ietf.= org/mailman/listinfo/ipr-wg
>


______________________= _________________________
Ipr-wg=20 mailing list
Ipr-wg@ietf.org
https://www1.ietf.= org/mailman/listinfo/ipr-wg


------=_NextPart_000_00B9_01C7B344.3B59FE10-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5KJh7ud050274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Jun 2007 12:43:07 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5KJh7dn050273; Wed, 20 Jun 2007 12:43:07 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx01.ixos.de (mucmx01.ixos.de [149.235.128.48]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5KJh4qJ050252 for ; Wed, 20 Jun 2007 12:43:05 -0700 (MST) (envelope-from tgondrom@opentext.com) Received: from MUCXGC2.opentext.net (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id l5KJgsp9008795; Wed, 20 Jun 2007 21:42:55 +0200 (MEST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: LTANS WG Last Call on draft-ietf-ltans-ers-scvp-03.txt Date: Wed, 20 Jun 2007 21:42:54 +0200 Message-ID: <2666EB2A846BAC4BB2D7F593301A78680C6668@MUCXGC2.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LTANS WG Last Call on draft-ietf-ltans-ers-scvp-03.txt Thread-Index: AcezZhGHdWCq1+7tTN6Y7sFm0/McRAACuVC6 X-Priority: 5 Importance: low References: <2666EB2A846BAC4BB2D7F593301A7868011E4D76@MUCXGC2.opentext.net><013501c7b35e$5c099ca0$174f7d40@home.glassey.com> <46796A6C.6060806@alvestrand.no> <015701c7b366$0e616b10$174f7d40@home.glassey.com> From: "Tobias Gondrom" To: "todd glassey" , "Harald Alvestrand" , "Contreras, Jorge" Cc: , Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: RE: LTANS WG Last Call on = draft-ietf-ltans-ers-scvp-03.txt

Hello,

*sigh* my company as many others has the policy to include certain = disclaimers in the emails sent out by their employees.
(note: Technically I can in fact remove or modify this disclaimer if = necessary. But as I would have to do this for every single email = individually, I tend to forget to modify my footer for the IETF. Maybe I = could use a private email instead, but this would also not be the most = convenient option...)

Although I understand that it might be interesting to make a precedent = case of my email, please note that this email DID obviously NOT CONTAIN = ANY IP content. So maybe not the best example?

However, as I might make this mistake in the future again - to leave the = footer as it is - any ruling from the IPR group of the IETF would be = pretty welcome. I would like to understand this as described by Harald, = but of course am no lawyer...

If this is not the case and my email is in fact an infringement of the = IETF policies, please accept my apologies. (If this would be an = infringement of IETF policies, we(IETF) should definitely also very fast = implement an automatic scanner for disclaimers and bounce back the other = violating emails as well.)

Tobias


Ps.: I would propose to lead this discussion on the ipr-wg list and not = on ltans - unless you want to also discuss it on all the other IETF WG = lists as well.




-----Original Message-----
From: todd glassey [mailto:tglassey@earthlink.net]=
Sent: Wed 6/20/2007 8:08 PM
To: Harald Alvestrand; Tobias Gondrom; Contreras, Jorge
Cc: ietf-ltans@imc.org; ipr-wg@ietf.org
Subject: Re: LTANS WG Last Call on draft-ietf-ltans-ers-scvp-03.txt

No Harald - ITS YOU WHO ARE WRONG...

If Tobias doesn't own the mail server and/or doesn't have legal power = of
attorney for the mail server, then he cannot assign the ownership of
anything to anyone sent through that gateway whether you like it or = not...
PERIOD.

But hey Harald - since you cannot provide ANY basis in fact for that
statement you made, and yet you continue to insist I am wrong... I = suggest
that you get the IETF's lawyers to publicly say that "NoteWell = overrides any
and all printed disclaimers or IP Ownership Statement's in any = submissions
to the IETF"... and since we both know that this will open the IETF = to
litigation from every SOX impacted company on the face of the planet
for attacking the controls they need on their email GW's, I am = betting
that you refuse to do this too...

That said - Harald - either document that there is precedent in US Law = to
set aside the disclaimer statement in the Tobias' email or back off = the
commentary ...

Todd Glassey
----- Original Message -----
From: "Harald Alvestrand" <harald@alvestrand.no>
To: "Tobias Gondrom" <tgondrom@opentext.com>
Cc: <ietf-ltans@imc.org>; <ipr-wg@ietf.org>
Sent: Wednesday, June 20, 2007 10:57 AM
Subject: Re: LTANS WG Last Call on draft-ietf-ltans-ers-scvp-03.txt


todd glassey wrote:
> Tobias I want to point out an inconsistency in how the IETF = operates...
>  We are told that any and all submissions belong to the IETF, = but
> according to the text disclaimer in your filing, the Open Text = Corporation
> claims it holds and retains any and all rights to the text herein. = That
> means that the NoteWell processes of the IETF DONT work here, and = cannot
> by the very disclaimer you have on the mailings themselves.
>  This is not my doing - I am just noticing this and asking how = NoteWell
> can possibly be called into effect when disclaimers like the one = you have
> below are included in the mailing since I see no formal way of = setting
> those terms and conditions aside. I dont mean this as a slam on the = LTANS
> WG - this is the problem of the management of the IPR WG who is
> responsible for this screw-up IMHO.
There is precedent for this; the disclaimers on a message that is
voluntarily and knowingly posted to a forum where the rules are
different cause the disclaimers to be without any legal effect.

In particular, by sending the message to the LTANS list, Tobias = Gondrom
is bound by the IETF rules on contributions, no matter what his = (IMHO
silly) disclaimers say.

            &= nbsp;         Harald
>  Todd Glassey
>
>     ----- Original Message -----
>     *From:* Tobias Gondrom <mailto:tgondrom@opentext.com>= ;
>     *To:* ietf-ltans@imc.org <mailto:ietf-ltans@imc.org>
>     *Sent:* Wednesday, June 20, 2007 9:33 = AM
>     *Subject:* LTANS WG Last Call on = draft-ietf-ltans-ers-scvp-03.txt
>
>     Hello dear LTANS WG,
>
>     to progress with ers-scvp, I would like to = announce WG Last Call
>     for this document.
>
>     Please make a last careful review of the = draft and submit
>     comments, questions and discuss items for = this draft until
>     July-05, so that we can present a final = status on the draft at the
>     Chicago meeting and submit it to the IESG = soon.
>
>     Thank you,
>
>     Tobias
>
>     Chair of LTANS
>
>
>     = ***__________________________________________*
>     *Tobias Gondrom*
>     Head of Open Text Security Team
>     Director, Product Security
>
>     *Open Text Corporation*
>     Technopark 2
>     Werner-von-Siemens-Ring 20
>     D-85630 Grasbrunn
>
>     Phone: +49 (0) 89 4629-1816
>     Mobile: +49 (0) 173 5942987
>     Telefax: +49 (0) 89 4629-33-1816
>     eMail: mailto:tobias.gondrom@opentex= t.com
>     Internet: http://www.opentext.com/
>     Place of Incorporation / Sitz der = Gesellschaft: Open Text GmbH, An
>     der Trift 65, 63303 Dreieich, Germany | = Phone: +49 (0) 6103 890 40
>     | Fax: +49 (0) 6103 89 04 11 | Register = Court / Registergericht:
>     Offenbach, Germany | Trade Register Number = / HRB: 33340 | VAT ID
>     Number /USt-ID:  DE 114 169 819 | = Managing Director /
>     Gesch=E4ftsf=FChrer: John Shackleton
>
>     This email is protected by domestic and = international copyright
>     laws and treaties and is the property of = Open Text Corporation, it
>     may contain confidential and/or trade = secret information of the
>     Open Text Corporation and/or its = subsidiaries (OTC), and may be
>     subject to legal privilege in favor of OTC. = This email may only be
>     lawfully received, accessed, displayed on a = computer screen,
>     printed, copied, and/or used by the = specific addressee(s) named
>     above ("Authorized Recipient") = for the purpose for which it was
>     sent by OTC. All other rights and licenses = to this email are fully
>     reserved to OTC. If you are not an = Authorized Recipient, you are
>     required to immediately delete this email = in its entirety without
>     printing, copying, using, and/or = re-transmitting this email,
>     either in whole or in part. The = transmission of this email by OTC
>     is not to be construed as a waiver by OTC = and/or the individual
>     sending this email on behalf of OTC of any = of their respective
>     rights or privileges at law or otherwise, = howsoever arising.
>
> = ------------------------------------------------------------------------<= BR> >
> _______________________________________________
> Ipr-wg mailing list
> Ipr-wg@ietf.org
> https://www1.ietf.= org/mailman/listinfo/ipr-wg
>


_______________________________________________
Ipr-wg mailing list
Ipr-wg@ietf.org
https://www1.ietf.= org/mailman/listinfo/ipr-wg

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5KI8vAN022020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Jun 2007 11:08:57 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5KI8vtJ022019; Wed, 20 Jun 2007 11:08:57 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5KI8rw6022001 for ; Wed, 20 Jun 2007 11:08:56 -0700 (MST) (envelope-from tglassey@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Ol+R9LmhoDlkZvSd0YDpHonWvvbnZQUJv4ixQhtK6NLeewwYuu2K9acJpWrT7d6U; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [64.125.79.23] (helo=gw) by elasmtp-curtail.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1I14bp-0006n0-32; Wed, 20 Jun 2007 14:08:49 -0400 Message-ID: <015701c7b366$0e616b10$174f7d40@home.glassey.com> From: "todd glassey" To: "Harald Alvestrand" , "Tobias Gondrom" , "Contreras, Jorge" Cc: , References: <2666EB2A846BAC4BB2D7F593301A7868011E4D76@MUCXGC2.opentext.net><013501c7b35e$5c099ca0$174f7d40@home.glassey.com> <46796A6C.6060806@alvestrand.no> Subject: Re: LTANS WG Last Call on draft-ietf-ltans-ers-scvp-03.txt Date: Wed, 20 Jun 2007 11:08:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec794cb1e242a464b2edd369da583e3330ba350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.125.79.23 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: No Harald - ITS YOU WHO ARE WRONG... If Tobias doesn't own the mail server and/or doesn't have legal power of attorney for the mail server, then he cannot assign the ownership of anything to anyone sent through that gateway whether you like it or not... PERIOD. But hey Harald - since you cannot provide ANY basis in fact for that statement you made, and yet you continue to insist I am wrong... I suggest that you get the IETF's lawyers to publicly say that "NoteWell overrides any and all printed disclaimers or IP Ownership Statement's in any submissions to the IETF"... and since we both know that this will open the IETF to litigation from every SOX impacted company on the face of the planet for attacking the controls they need on their email GW's, I am betting that you refuse to do this too... That said - Harald - either document that there is precedent in US Law to set aside the disclaimer statement in the Tobias' email or back off the commentary ... Todd Glassey ----- Original Message ----- From: "Harald Alvestrand" To: "Tobias Gondrom" Cc: ; Sent: Wednesday, June 20, 2007 10:57 AM Subject: Re: LTANS WG Last Call on draft-ietf-ltans-ers-scvp-03.txt todd glassey wrote: > Tobias I want to point out an inconsistency in how the IETF operates... > We are told that any and all submissions belong to the IETF, but > according to the text disclaimer in your filing, the Open Text Corporation > claims it holds and retains any and all rights to the text herein. That > means that the NoteWell processes of the IETF DONT work here, and cannot > by the very disclaimer you have on the mailings themselves. > This is not my doing - I am just noticing this and asking how NoteWell > can possibly be called into effect when disclaimers like the one you have > below are included in the mailing since I see no formal way of setting > those terms and conditions aside. I dont mean this as a slam on the LTANS > WG - this is the problem of the management of the IPR WG who is > responsible for this screw-up IMHO. There is precedent for this; the disclaimers on a message that is voluntarily and knowingly posted to a forum where the rules are different cause the disclaimers to be without any legal effect. In particular, by sending the message to the LTANS list, Tobias Gondrom is bound by the IETF rules on contributions, no matter what his (IMHO silly) disclaimers say. Harald > Todd Glassey > > ----- Original Message ----- > *From:* Tobias Gondrom > *To:* ietf-ltans@imc.org > *Sent:* Wednesday, June 20, 2007 9:33 AM > *Subject:* LTANS WG Last Call on draft-ietf-ltans-ers-scvp-03.txt > > Hello dear LTANS WG, > > to progress with ers-scvp, I would like to announce WG Last Call > for this document. > > Please make a last careful review of the draft and submit > comments, questions and discuss items for this draft until > July-05, so that we can present a final status on the draft at the > Chicago meeting and submit it to the IESG soon. > > Thank you, > > Tobias > > Chair of LTANS > > > ***__________________________________________* > *Tobias Gondrom* > Head of Open Text Security Team > Director, Product Security > > *Open Text Corporation* > Technopark 2 > Werner-von-Siemens-Ring 20 > D-85630 Grasbrunn > > Phone: +49 (0) 89 4629-1816 > Mobile: +49 (0) 173 5942987 > Telefax: +49 (0) 89 4629-33-1816 > eMail: mailto:tobias.gondrom@opentext.com > Internet: http://www.opentext.com/ > Place of Incorporation / Sitz der Gesellschaft: Open Text GmbH, An > der Trift 65, 63303 Dreieich, Germany | Phone: +49 (0) 6103 890 40 > | Fax: +49 (0) 6103 89 04 11 | Register Court / Registergericht: > Offenbach, Germany | Trade Register Number / HRB: 33340 | VAT ID > Number /USt-ID: DE 114 169 819 | Managing Director / > Geschäftsführer: John Shackleton > > This email is protected by domestic and international copyright > laws and treaties and is the property of Open Text Corporation, it > may contain confidential and/or trade secret information of the > Open Text Corporation and/or its subsidiaries (OTC), and may be > subject to legal privilege in favor of OTC. This email may only be > lawfully received, accessed, displayed on a computer screen, > printed, copied, and/or used by the specific addressee(s) named > above ("Authorized Recipient") for the purpose for which it was > sent by OTC. All other rights and licenses to this email are fully > reserved to OTC. If you are not an Authorized Recipient, you are > required to immediately delete this email in its entirety without > printing, copying, using, and/or re-transmitting this email, > either in whole or in part. The transmission of this email by OTC > is not to be construed as a waiver by OTC and/or the individual > sending this email on behalf of OTC of any of their respective > rights or privileges at law or otherwise, howsoever arising. > > ------------------------------------------------------------------------ > > _______________________________________________ > Ipr-wg mailing list > Ipr-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/ipr-wg > _______________________________________________ Ipr-wg mailing list Ipr-wg@ietf.org https://www1.ietf.org/mailman/listinfo/ipr-wg Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5KHvD69019123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Jun 2007 10:57:13 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5KHvDLs019122; Wed, 20 Jun 2007 10:57:13 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5KHvCRc019116 for ; Wed, 20 Jun 2007 10:57:12 -0700 (MST) (envelope-from harald@alvestrand.no) Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D3E132596D8; Wed, 20 Jun 2007 19:57:11 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14285-10; Wed, 20 Jun 2007 19:57:03 +0200 (CEST) Received: from [192.168.1.54] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id 110172596D6; Wed, 20 Jun 2007 19:57:03 +0200 (CEST) Message-ID: <46796A6C.6060806@alvestrand.no> Date: Wed, 20 Jun 2007 19:57:00 +0200 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.7 (X11/20060921) MIME-Version: 1.0 To: Tobias Gondrom Cc: ietf-ltans@imc.org, ipr-wg@ietf.org Subject: Re: LTANS WG Last Call on draft-ietf-ltans-ers-scvp-03.txt References: <2666EB2A846BAC4BB2D7F593301A7868011E4D76@MUCXGC2.opentext.net> <013501c7b35e$5c099ca0$174f7d40@home.glassey.com> In-Reply-To: <013501c7b35e$5c099ca0$174f7d40@home.glassey.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at alvestrand.no Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: todd glassey wrote: > Tobias I want to point out an inconsistency in how the IETF operates... > > We are told that any and all submissions belong to the IETF, but > according to the text disclaimer in your filing, the Open Text > Corporation claims it holds and retains any and all rights to the text > herein. That means that the NoteWell processes of the IETF DONT work > here, and cannot by the very disclaimer you have on the mailings > themselves. > > This is not my doing - I am just noticing this and asking how NoteWell > can possibly be called into effect when disclaimers like the one you > have below are included in the mailing since I see no formal way of > setting those terms and conditions aside. I dont mean this as a slam > on the LTANS WG - this is the problem of the management of the IPR WG > who is responsible for this screw-up IMHO. There is precedent for this; the disclaimers on a message that is voluntarily and knowingly posted to a forum where the rules are different cause the disclaimers to be without any legal effect. In particular, by sending the message to the LTANS list, Tobias Gondrom is bound by the IETF rules on contributions, no matter what his (IMHO silly) disclaimers say. Harald > > Todd Glassey > > ----- Original Message ----- > *From:* Tobias Gondrom > *To:* ietf-ltans@imc.org > *Sent:* Wednesday, June 20, 2007 9:33 AM > *Subject:* LTANS WG Last Call on draft-ietf-ltans-ers-scvp-03.txt > > Hello dear LTANS WG, > > to progress with ers-scvp, I would like to announce WG Last Call > for this document. > > Please make a last careful review of the draft and submit > comments, questions and discuss items for this draft until > July-05, so that we can present a final status on the draft at the > Chicago meeting and submit it to the IESG soon. > > Thank you, > > Tobias > > Chair of LTANS > > > ***__________________________________________* > *Tobias Gondrom* > Head of Open Text Security Team > Director, Product Security > > *Open Text Corporation* > Technopark 2 > Werner-von-Siemens-Ring 20 > D-85630 Grasbrunn > > Phone: +49 (0) 89 4629-1816 > Mobile: +49 (0) 173 5942987 > Telefax: +49 (0) 89 4629-33-1816 > eMail: mailto:tobias.gondrom@opentext.com > Internet: http://www.opentext.com/ > > Place of Incorporation / Sitz der Gesellschaft: Open Text GmbH, An > der Trift 65, 63303 Dreieich, Germany | Phone: +49 (0) 6103 890 40 > | Fax: +49 (0) 6103 89 04 11 | Register Court / Registergericht: > Offenbach, Germany | Trade Register Number / HRB: 33340 | VAT ID > Number /USt-ID: DE 114 169 819 | Managing Director / > Geschäftsführer: John Shackleton > > This email is protected by domestic and international copyright > laws and treaties and is the property of Open Text Corporation, it > may contain confidential and/or trade secret information of the > Open Text Corporation and/or its subsidiaries (OTC), and may be > subject to legal privilege in favor of OTC. This email may only be > lawfully received, accessed, displayed on a computer screen, > printed, copied, and/or used by the specific addressee(s) named > above ("Authorized Recipient") for the purpose for which it was > sent by OTC. All other rights and licenses to this email are fully > reserved to OTC. If you are not an Authorized Recipient, you are > required to immediately delete this email in its entirety without > printing, copying, using, and/or re-transmitting this email, > either in whole or in part. The transmission of this email by OTC > is not to be construed as a waiver by OTC and/or the individual > sending this email on behalf of OTC of any of their respective > rights or privileges at law or otherwise, howsoever arising. > > ------------------------------------------------------------------------ > > _______________________________________________ > Ipr-wg mailing list > Ipr-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/ipr-wg > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5KHDoWe007516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Jun 2007 10:13:51 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5KHDo7K007513; Wed, 20 Jun 2007 10:13:50 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5KHDj3H007448 for ; Wed, 20 Jun 2007 10:13:46 -0700 (MST) (envelope-from tglassey@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=b8UWnF9NaCtEV/pNwRCCXesPuB95asek8JFI9NQVFhCweKq++Vry0vFkgv8sl4Du; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [64.125.79.23] (helo=gw) by elasmtp-galgo.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1I13kV-0003HJ-Iz; Wed, 20 Jun 2007 13:13:43 -0400 Message-ID: <013501c7b35e$5c099ca0$174f7d40@home.glassey.com> From: "todd glassey" To: "Tobias Gondrom" , Cc: References: <2666EB2A846BAC4BB2D7F593301A7868011E4D76@MUCXGC2.opentext.net> Subject: Re: LTANS WG Last Call on draft-ietf-ltans-ers-scvp-03.txt Date: Wed, 20 Jun 2007 10:13:43 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0132_01C7B323.AE451A20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79af63fe9ee7883061fbe9de0fc3e0ee6a350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.125.79.23 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0132_01C7B323.AE451A20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable LTANS WG Last Call on draft-ietf-ltans-ers-scvp-03.txtTobias I want to = point out an inconsistency in how the IETF operates... We are told that any and all submissions belong to the IETF, but = according to the text disclaimer in your filing, the Open Text = Corporation claims it holds and retains any and all rights to the text = herein. That means that the NoteWell processes of the IETF DONT work = here, and cannot by the very disclaimer you have on the mailings = themselves. This is not my doing - I am just noticing this and asking how NoteWell = can possibly be called into effect when disclaimers like the one you = have below are included in the mailing since I see no formal way of = setting those terms and conditions aside. I dont mean this as a slam on = the LTANS WG - this is the problem of the management of the IPR WG who = is responsible for this screw-up IMHO. Todd Glassey ----- Original Message -----=20 From: Tobias Gondrom=20 To: ietf-ltans@imc.org=20 Sent: Wednesday, June 20, 2007 9:33 AM Subject: LTANS WG Last Call on draft-ietf-ltans-ers-scvp-03.txt Hello dear LTANS WG, to progress with ers-scvp, I would like to announce WG Last Call for = this document.=20 Please make a last careful review of the draft and submit comments, = questions and discuss items for this draft until July-05, so that we can = present a final status on the draft at the Chicago meeting and submit it = to the IESG soon.=20 Thank you,=20 Tobias Chair of LTANS __________________________________________ Tobias Gondrom Head of Open Text Security Team Director, Product Security Open Text Corporation Technopark 2 Werner-von-Siemens-Ring 20 D-85630 Grasbrunn Phone: +49 (0) 89 4629-1816 Mobile: +49 (0) 173 5942987 Telefax: +49 (0) 89 4629-33-1816 eMail: mailto:tobias.gondrom@opentext.com Internet: http://www.opentext.com/ =20 Place of Incorporation / Sitz der Gesellschaft: Open Text GmbH, An der = Trift 65, 63303 Dreieich, Germany | Phone: +49 (0) 6103 890 40 | Fax: = +49 (0) 6103 89 04 11 | Register Court / Registergericht: Offenbach, = Germany | Trade Register Number / HRB: 33340 | VAT ID Number /USt-ID: = DE 114 169 819 | Managing Director / Gesch=E4ftsf=FChrer: John = Shackleton This email is protected by domestic and international copyright laws = and treaties and is the property of Open Text Corporation, it may = contain confidential and/or trade secret information of the Open Text = Corporation and/or its subsidiaries (OTC), and may be subject to legal = privilege in favor of OTC. This email may only be lawfully received, = accessed, displayed on a computer screen, printed, copied, and/or used = by the specific addressee(s) named above ("Authorized Recipient") for = the purpose for which it was sent by OTC. All other rights and licenses = to this email are fully reserved to OTC. If you are not an Authorized = Recipient, you are required to immediately delete this email in its = entirety without printing, copying, using, and/or re-transmitting this = email, either in whole or in part. The transmission of this email by OTC = is not to be construed as a waiver by OTC and/or the individual sending = this email on behalf of OTC of any of their respective rights or = privileges at law or otherwise, howsoever arising. ------=_NextPart_000_0132_01C7B323.AE451A20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable LTANS WG Last Call on = draft-ietf-ltans-ers-scvp-03.txt
Tobias I want to point out = an=20 inconsistency in how the IETF operates...
 
We are told that any and = all=20 submissions belong to the IETF, but according to the text disclaimer in = your=20 filing, the Open Text Corporation claims it holds and retains any and = all rights=20 to the text herein. That means that the NoteWell processes of the IETF = DONT work=20 here, and cannot by the very disclaimer you have on the mailings=20 themselves.
 
This is not my doing - I am = just=20 noticing this and asking how NoteWell can possibly be called into effect = when=20 disclaimers like the one you have below are included in the mailing = since I see=20 no formal way of setting those terms and conditions aside. I dont mean = this as a=20 slam on the LTANS WG - this is the problem of the management of the IPR = WG who=20 is responsible for this screw-up IMHO.
 
Todd Glassey
----- Original Message -----
From:=20 Tobias=20 Gondrom
Sent: Wednesday, June 20, 2007 = 9:33=20 AM
Subject: LTANS WG Last Call on=20 draft-ietf-ltans-ers-scvp-03.txt

Hello = dear LTANS=20 WG,

to=20 progress with ers-scvp, I would like to announce WG Last Call for this = document.

Please make a last careful review = of the draft=20 and=20 submit comments, questions and discuss items for this = draft=20 until=20 July-05,=20 so that we can present a final status on the draft at the Chicago meeting = and submit it=20 to the IESG soon.

Thank=20 you,=20

Tobias

Chair = of=20 LTANS


__________________________________________=
Tobias Gondrom
Head of Open = Text Security=20 Team
Director, Product Security

Open Text Corporation
Technopark 2
Werner-von-Siemens-Ring 20
D-85630=20 Grasbrunn

Phone:=20 +49 (0) 89 4629-1816
Mobile: +49 (0) 173 5942987
Telefax: +49 = (0) 89=20 4629-33-1816
eMail: mailto:tobias.gondrom@opentex= t.com
Internet: http://www.opentext.com/ =20

Place = of Incorporation=20 / Sitz der Gesellschaft: Open Text GmbH, An der Trift 65, 63303 = Dreieich,=20 Germany | Phone: +49 (0) 6103 890 40 | Fax: +49 (0) 6103 89 04 11 | = Register=20 Court / Registergericht: Offenbach, Germany | Trade Register Number / = HRB:=20 33340 | VAT ID Number /USt-ID:  DE 114 169 819 | Managing = Director /=20 Gesch=E4ftsf=FChrer: John Shackleton

This = email is protected=20 by domestic and international copyright laws and treaties and is the = property=20 of Open Text Corporation, it may contain confidential and/or trade = secret=20 information of the Open Text Corporation and/or its subsidiaries = (OTC), and=20 may be subject to legal privilege in favor of OTC. This email may only = be=20 lawfully received, accessed, displayed on a computer screen, printed, = copied,=20 and/or used by the specific addressee(s) named above ("Authorized = Recipient")=20 for the purpose for which it was sent by OTC. All other rights and = licenses to=20 this email are fully reserved to OTC. If you are not an Authorized = Recipient,=20 you are required to immediately delete this email in its entirety = without=20 printing, copying, using, and/or re-transmitting this email, either in = whole=20 or in part. The transmission of this email by OTC is not to be = construed as a=20 waiver by OTC and/or the individual sending this email on behalf of = OTC of any=20 of their respective rights or privileges at law or otherwise, = howsoever=20 arising.

------=_NextPart_000_0132_01C7B323.AE451A20-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5KH0afv004141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Jun 2007 10:00:36 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5KH0aVL004140; Wed, 20 Jun 2007 10:00:36 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5KH0ZvM004126 for ; Wed, 20 Jun 2007 10:00:35 -0700 (MST) (envelope-from tglassey@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=V5kyIKqSXa7EtqsvwJaBsVViTLiuogH5aEwLReiaNo58jhzXjPHLpvuxE06SSTSb; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [64.125.79.23] (helo=gw) by elasmtp-curtail.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1I13Xm-0007fk-CS; Wed, 20 Jun 2007 13:00:34 -0400 Message-ID: <010901c7b35c$85ac4050$174f7d40@home.glassey.com> From: "todd glassey" To: "Tobias Gondrom" , References: <2666EB2A846BAC4BB2D7F593301A7868011E4D76@MUCXGC2.opentext.net> Subject: Re: LTANS WG Last Call on draft-ietf-ltans-ers-scvp-03.txt Date: Wed, 20 Jun 2007 10:00:29 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0106_01C7B321.D5070C10" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79b44d211b5a0b0a21d4f2639120223d2d350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.125.79.23 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0106_01C7B321.D5070C10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable LTANS WG Last Call on draft-ietf-ltans-ers-scvp-03.txtTobias - In the US = there is a VERY VERY important Court Case which will effect any and all = long-term document storage and it needs to be reviewed herein. The case = is Lorraine v Markel and the key ruling in it came from US District = Court Judge, Chief Magistrate Paul W. Grimm on the 4th of May, 2007. The ruling set a five point test for the admissibility of ESI = (Electronic Stored Information) before the US Federal Courts and while = technologically speaking, only three of the five key tests are = technology related, they need to be included here as well.=20 And to quote his honor: "In this case the failure of counsel collectively to establish the = authenticity of their exhibits, resolve potential hearsay issues, comply = with the original writing rule, and demonstrate the absence of unfair = prejudice rendered their exhibits inadmissible, resulting in the = dismissal, without prejudice, of their cross motions for summary = judgment. The discussion above highlights the fact that there are five = distinct but interrelated evidentiary issues that govern whether = electronic evidence will be admitted into evidence at trial or accepted = as an exhibit in summary judgment practice. Although each of these rules = may not apply to every exhibit offered, as was the case here, each still = must be considered in evaluating how to secure the admissibility of = electronic evidence to support claims and defenses. Because it can be = expected that electronic evidence will constitute much, if not most, of = the evidence used in future motions practice or at trial, counsel should = know how to get it right on the first try."=20 The three key issues for LTANs to address are : 1) Authentication of the Stored Media - is there a ongoing = Authentication Model and is it necessary??? 2) Resolution of 'digital hear-say' issues - how is the integrity = of the system proven and its 'objectivity' documented??? 3) Proof under the Original Writing's rule. - which based on = policy will control who may proffer ESI and who cannot before a court??? These three key tests need to be built into any LTANS properties IMHO. Todd Glassey ----- Original Message -----=20 From: Tobias Gondrom=20 To: ietf-ltans@imc.org=20 Sent: Wednesday, June 20, 2007 9:33 AM Subject: LTANS WG Last Call on draft-ietf-ltans-ers-scvp-03.txt Hello dear LTANS WG, to progress with ers-scvp, I would like to announce WG Last Call for = this document.=20 Please make a last careful review of the draft and submit comments, = questions and discuss items for this draft until July-05, so that we can = present a final status on the draft at the Chicago meeting and submit it = to the IESG soon.=20 Thank you,=20 Tobias Chair of LTANS __________________________________________ Tobias Gondrom Head of Open Text Security Team Director, Product Security Open Text Corporation Technopark 2 Werner-von-Siemens-Ring 20 D-85630 Grasbrunn Phone: +49 (0) 89 4629-1816 Mobile: +49 (0) 173 5942987 Telefax: +49 (0) 89 4629-33-1816 eMail: mailto:tobias.gondrom@opentext.com Internet: http://www.opentext.com/ =20 Place of Incorporation / Sitz der Gesellschaft: Open Text GmbH, An der = Trift 65, 63303 Dreieich, Germany | Phone: +49 (0) 6103 890 40 | Fax: = +49 (0) 6103 89 04 11 | Register Court / Registergericht: Offenbach, = Germany | Trade Register Number / HRB: 33340 | VAT ID Number /USt-ID: = DE 114 169 819 | Managing Director / Gesch=E4ftsf=FChrer: John = Shackleton This email is protected by domestic and international copyright laws = and treaties and is the property of Open Text Corporation, it may = contain confidential and/or trade secret information of the Open Text = Corporation and/or its subsidiaries (OTC), and may be subject to legal = privilege in favor of OTC. This email may only be lawfully received, = accessed, displayed on a computer screen, printed, copied, and/or used = by the specific addressee(s) named above ("Authorized Recipient") for = the purpose for which it was sent by OTC. All other rights and licenses = to this email are fully reserved to OTC. If you are not an Authorized = Recipient, you are required to immediately delete this email in its = entirety without printing, copying, using, and/or re-transmitting this = email, either in whole or in part. The transmission of this email by OTC = is not to be construed as a waiver by OTC and/or the individual sending = this email on behalf of OTC of any of their respective rights or = privileges at law or otherwise, howsoever arising. ------=_NextPart_000_0106_01C7B321.D5070C10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable LTANS WG Last Call on = draft-ietf-ltans-ers-scvp-03.txt
Tobias - In the US there is = a VERY VERY=20 important Court Case which will effect any and all long-term document = storage=20 and it needs to be reviewed herein.  The case is Lorraine v Markel = and the=20 key ruling in it came from US District Court Judge, Chief Magistrate = Paul W.=20 Grimm on the 4th of May, 2007.
 
The ruling set a five point = test for=20 the admissibility of ESI (Electronic Stored Information) before the US = Federal=20 Courts and while technologically speaking, only three of the five key = tests are=20 technology related, they need to be included here as well.
 
And to quote his = honor:
 
"In this case the failure of counsel collectively to establish the=20 authenticity of their exhibits, resolve potential hearsay issues, comply = with=20 the original writing rule, and demonstrate the absence of unfair = prejudice=20 rendered their exhibits inadmissible, resulting in the dismissal, = without=20 prejudice, of their cross motions for summary judgment. The discussion = above=20 highlights the fact that there are five distinct but interrelated = evidentiary=20 issues that govern whether electronic evidence will be admitted into = evidence at=20 trial or accepted as an exhibit in summary judgment practice. Although = each of=20 these rules may not apply to every exhibit offered, as was the case = here, each=20 still must be considered in evaluating how to secure the admissibility = of=20 electronic evidence to support claims and defenses. Because it can be = expected=20 that electronic evidence will constitute much, if not most, of the = evidence used=20 in future motions practice or at trial, counsel should know how to get = it right=20 on the first try."
 
The three key issues for = LTANs to=20 address are :
 
    = 1)   =20 Authentication of the Stored Media - is there a ongoing Authentication = Model and=20 is it necessary???
 
    = 2)   =20 Resolution of 'digital hear-say' issues - how is the integrity of the = system=20 proven and its 'objectivity' documented???
 
    = 3)   =20 Proof under the Original Writing's rule. - which based on policy will = control=20 who may proffer ESI and who cannot before a court???
 
These three key tests need = to be built=20 into any LTANS properties IMHO.
 
Todd Glassey
 
----- Original Message -----
From:=20 Tobias=20 Gondrom
Sent: Wednesday, June 20, 2007 = 9:33=20 AM
Subject: LTANS WG Last Call on=20 draft-ietf-ltans-ers-scvp-03.txt

Hello = dear LTANS=20 WG,

to=20 progress with ers-scvp, I would like to announce WG Last Call for this = document.

Please make a last careful review = of the draft=20 and=20 submit comments, questions and discuss items for this = draft=20 until=20 July-05,=20 so that we can present a final status on the draft at the Chicago meeting = and submit it=20 to the IESG soon.

Thank=20 you,=20

Tobias

Chair = of=20 LTANS


__________________________________________=
Tobias Gondrom
Head of Open = Text Security=20 Team
Director, Product Security

Open Text Corporation
Technopark 2
Werner-von-Siemens-Ring 20
D-85630=20 Grasbrunn

Phone:=20 +49 (0) 89 4629-1816
Mobile: +49 (0) 173 5942987
Telefax: +49 = (0) 89=20 4629-33-1816
eMail: mailto:tobias.gondrom@opentex= t.com
Internet: http://www.opentext.com/ =20

Place = of Incorporation=20 / Sitz der Gesellschaft: Open Text GmbH, An der Trift 65, 63303 = Dreieich,=20 Germany | Phone: +49 (0) 6103 890 40 | Fax: +49 (0) 6103 89 04 11 | = Register=20 Court / Registergericht: Offenbach, Germany | Trade Register Number / = HRB:=20 33340 | VAT ID Number /USt-ID:  DE 114 169 819 | Managing = Director /=20 Gesch=E4ftsf=FChrer: John Shackleton

This = email is protected=20 by domestic and international copyright laws and treaties and is the = property=20 of Open Text Corporation, it may contain confidential and/or trade = secret=20 information of the Open Text Corporation and/or its subsidiaries = (OTC), and=20 may be subject to legal privilege in favor of OTC. This email may only = be=20 lawfully received, accessed, displayed on a computer screen, printed, = copied,=20 and/or used by the specific addressee(s) named above ("Authorized = Recipient")=20 for the purpose for which it was sent by OTC. All other rights and = licenses to=20 this email are fully reserved to OTC. If you are not an Authorized = Recipient,=20 you are required to immediately delete this email in its entirety = without=20 printing, copying, using, and/or re-transmitting this email, either in = whole=20 or in part. The transmission of this email by OTC is not to be = construed as a=20 waiver by OTC and/or the individual sending this email on behalf of = OTC of any=20 of their respective rights or privileges at law or otherwise, = howsoever=20 arising.

------=_NextPart_000_0106_01C7B321.D5070C10-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5KGY3Q4098412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Jun 2007 09:34:03 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5KGY3PH098411; Wed, 20 Jun 2007 09:34:03 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx02.ixos.de (mucmx02.ixos.de [149.235.128.47]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5KGY1NC098394 for ; Wed, 20 Jun 2007 09:34:02 -0700 (MST) (envelope-from tgondrom@opentext.com) Received: from MUCXGC2.opentext.net (localhost [127.0.0.1]) by mucmx02.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id l5KGXflm026587 for ; Wed, 20 Jun 2007 18:34:00 +0200 (MEST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7B358.C33EB887" Subject: LTANS WG Last Call on draft-ietf-ltans-ers-scvp-03.txt Date: Wed, 20 Jun 2007 18:33:42 +0200 Message-ID: <2666EB2A846BAC4BB2D7F593301A7868011E4D76@MUCXGC2.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LTANS WG Last Call on draft-ietf-ltans-ers-scvp-03.txt Thread-Index: AcezWMPHK0AkFbVYSMagUU7+nGcVIw== X-Priority: 1 Importance: high From: "Tobias Gondrom" To: Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C7B358.C33EB887 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello dear LTANS WG, to progress with ers-scvp, I would like to announce WG Last Call for = this document.=20 Please make a last careful review of the draft and submit comments, = questions and discuss items for this draft until July-05, so that we can = present a final status on the draft at the Chicago meeting and submit it = to the IESG soon.=20 Thank you,=20 Tobias Chair of LTANS __________________________________________ Tobias Gondrom Head of Open Text Security Team Director, Product Security Open Text Corporation Technopark 2 Werner-von-Siemens-Ring 20 D-85630 Grasbrunn Phone: +49 (0) 89 4629-1816 Mobile: +49 (0) 173 5942987 Telefax: +49 (0) 89 4629-33-1816 eMail: mailto:tobias.gondrom@opentext.com=20 Internet: http://www.opentext.com/ =20 Place of Incorporation / Sitz der Gesellschaft: Open Text GmbH, An der = Trift 65, 63303 Dreieich, Germany | Phone: +49 (0) 6103 890 40 | Fax: = +49 (0) 6103 89 04 11 | Register Court / Registergericht: Offenbach, = Germany | Trade Register Number / HRB: 33340 | VAT ID Number /USt-ID: = DE 114 169 819 | Managing Director / Gesch=E4ftsf=FChrer: John = Shackleton This email is protected by domestic and international copyright laws and = treaties and is the property of Open Text Corporation, it may contain = confidential and/or trade secret information of the Open Text = Corporation and/or its subsidiaries (OTC), and may be subject to legal = privilege in favor of OTC. This email may only be lawfully received, = accessed, displayed on a computer screen, printed, copied, and/or used = by the specific addressee(s) named above ("Authorized Recipient") for = the purpose for which it was sent by OTC. All other rights and licenses = to this email are fully reserved to OTC. If you are not an Authorized = Recipient, you are required to immediately delete this email in its = entirety without printing, copying, using, and/or re-transmitting this = email, either in whole or in part. The transmission of this email by OTC = is not to be construed as a waiver by OTC and/or the individual sending = this email on behalf of OTC of any of their respective rights or = privileges at law or otherwise, howsoever arising. ------_=_NextPart_001_01C7B358.C33EB887 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable LTANS WG Last Call on draft-ietf-ltans-ers-scvp-03.txt

Hello = dear LTANS WG,

to = progress with ers-scvp, I would like to announce WG Last Call for this = document.

Please make a last careful review of the draft = and submit = comments, = questions and discuss items for this draft until July-05, = so that we can present a final status on the = draft at the Chicago meeting and submit it to the IESG soon. =

Thank = you,

Tobias

Chair = of LTANS


__________________________________________
Tobias = Gondrom
Head of = Open Text Security Team
Director, Product Security

Open Text = Corporation
Technopark 2
Werner-von-Siemens-Ring 20
D-85630 Grasbrunn

Phone: +49 (0) 89 4629-1816
Mobile: +49 (0) 173 5942987
Telefax: +49 (0) 89 4629-33-1816
eMail: mailto:tobias.gondrom@opentex= t.com
Internet: http://www.opentext.com/  =

Place = of Incorporation / Sitz der Gesellschaft: Open Text GmbH, An der Trift = 65, 63303 Dreieich, Germany | Phone: +49 (0) 6103 890 40 | Fax: +49 (0) = 6103 89 04 11 | Register Court / Registergericht: Offenbach, Germany | = Trade Register Number / HRB: 33340 | VAT ID Number /USt-ID:  DE 114 = 169 819 | Managing Director / Gesch=E4ftsf=FChrer: John = Shackleton

This = email is protected by domestic and international copyright laws and = treaties and is the property of Open Text Corporation, it may contain = confidential and/or trade secret information of the Open Text = Corporation and/or its subsidiaries (OTC), and may be subject to legal = privilege in favor of OTC. This email may only be lawfully received, = accessed, displayed on a computer screen, printed, copied, and/or used = by the specific addressee(s) named above ("Authorized = Recipient") for the purpose for which it was sent by OTC. All other = rights and licenses to this email are fully reserved to OTC. If you are = not an Authorized Recipient, you are required to immediately delete this = email in its entirety without printing, copying, using, and/or = re-transmitting this email, either in whole or in part. The transmission = of this email by OTC is not to be construed as a waiver by OTC and/or = the individual sending this email on behalf of OTC of any of their = respective rights or privileges at law or otherwise, howsoever = arising.

------_=_NextPart_001_01C7B358.C33EB887-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5KG58E5093191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Jun 2007 09:05:08 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5KG58MG093190; Wed, 20 Jun 2007 09:05:08 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from ganymede.on-x.com (ganymede.on-x.com [194.51.68.3]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5KG54ND093163 for ; Wed, 20 Jun 2007 09:05:06 -0700 (MST) (envelope-from Peter.Sylvester@edelweb.fr) Received: from localhost (ganymede [127.0.0.1]) by ganymede.on-x.com (Postfix) with ESMTP id D52072F for ; Wed, 20 Jun 2007 18:04:52 +0200 (CEST) Received: from ganymede.on-x.com ([127.0.0.1]) by localhost (ganymede.on-x.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05500-08 for ; Wed, 20 Jun 2007 18:04:50 +0200 (CEST) Received: from vinea.on-x.com (sedna.puteaux.on-x [192.168.10.9]) by ganymede.on-x.com (Postfix) with ESMTP id 14A6D2A for ; Wed, 20 Jun 2007 18:04:50 +0200 (CEST) Received: from [193.51.14.5] ([212.234.46.65]) by vinea.on-x.com (Lotus Domino Release 5.0.11) with ESMTP id 2007062018044910:305949 ; Wed, 20 Jun 2007 18:04:49 +0200 Message-ID: <46794F89.30200@edelweb.fr> Date: Wed, 20 Jun 2007 18:02:17 +0200 From: Peter Sylvester User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: ietf-ltans@imc.org Subject: Re: A new operation for LTAP, please comment References: <2666EB2A846BAC4BB2D7F593301A7868011E4CBD@MUCXGC2.opentext.net> In-Reply-To: <2666EB2A846BAC4BB2D7F593301A7868011E4CBD@MUCXGC2.opentext.net> X-MIMETrack: Itemize by SMTP Server on vinea/ON-X(Release 5.0.11 |July 24, 2002) at 06/20/2007 06:04:49 PM, Serialize by Router on vinea/ON-X(Release 5.0.11 |July 24, 2002) at 06/20/2007 06:04:49 PM, Serialize complete at 06/20/2007 06:04:49 PM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060902090602010609040103" X-Virus-Scanned: by amavisd-new at on-x.com Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a cryptographically signed message in MIME format. --------------ms060902090602010609040103 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit As mentioned already, all functions of the actual LTAP are independant, some clients may for example only implement the archive functions, and also service providers may only provide this and do all the rest internally. The other functions already allow two different sets of functions on the data, RETRIEVE and DELETE is one of the branches and STATUS and VERIFY another. I think this can be made a little bit more clear. The proposed function to obtain a list of references is another type of function in the same way, but it can be added at any time to the framework in whatever document. Having said that and not claiming that this is urgently needed in this text etc, I can now freely discuss the idea, I do not see the proposed function not as a part of the data management layer. Any LTA server has to allocate a storage structure to each object and its metadata, manage how to distribute it on disks, in directories, databases or so. This is a totally internal action and outside the scope of LTAP. LTAP also to access to the managed abstract objects at least individually as a "secure single object layer" above. In fact there are two management layers, one above and one below ltap, they are different. They are different but they are related. Each client also has to manage some knowledge of what has been stored. For example, an internal front end that initiated the verify operations, it operates with the LTA backend on the LTAP level or above. It has to keep at some information about all objects, to which they belong and what service has to be applied. This information is nothing else than some of the metadata associated to the object and they are stored safely in the LTA backend, the front can obtain them via LTAP from the backend via a STATUS function. The exception is the list of objects itself. Any OAIS front end needs to manage these information, my approach is that this front end can loose the persitance of all these information, even its parameters, since all relevant information can even be safely archived (which would be needed for proof anyway). One could try to have a fake object that contains the list, so you can GET it, but this is a very ugly thing because we had decided to split into functions whenever there is a important difference for access control, and also one big list is ugly. My previous description was maybe a bit misleading. The minimal functionality for parameters would be - an interval of dates - an optional starting identifier - optionally the service identifier - optionally the owner identifier The function returns a server defined number of identifiers within the interal and after the starting identifier that match the service and owner. regards Peter --------------ms060902090602010609040103 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC BHIwggLfoAMCAQICBgqvijKA3jANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNzAzMjYxMDM3MDNaFw0wOTA2MDMxMDM3MDNaMHAx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPB7ZSfmYsUuVIV0W2izxb1Zyvr6ZJ IjPiqRMs77dbEQhQ6FZhhUSuABxxc8NjZvyPMRo0uuT0iVpRDktb0fWPTx3m9qTfdqrhWg2c IOBKNbNQr8NogDJvG1AxRx4q9SXKZCVpZCoHu3fz2Rfji1kL7l597+7qBEsFd9IyvRaexQID AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5 MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSZjq81LuJmsiiu1Yt/ezwCiUQSQTAfBgNV HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA A4IBfAAUq5MJ3gXhdKDpOm0ascDE9e1iMo0RQ24ujkc9IrFXhAJNS+3eNwcJEieU2vgZTsGb zKeBZom1zVOFoh73VIRP6T08j4dDlndpDYZbxD20KzFt9zX6gV8IgR2zkkZXLQRbLyW16kw8 oFe3s//p1csCkCPAlZv1rZQYR5Psm0A1aiOiuSHhWUmgfAJxmIgfbmKtS3WpsUZVBuLQpThN rWjLRAqJKYA++++qqo3ujqAAzJLe+MHrX5dai7+n6WBfV4qo1uDArR7XbmgVpV/EdPA75XRi XEedLgbFDawJ9nAMN6WfL/NG6GZkEa7mZ7sH/gG34y21nq4w4mAAxn9wz7mDKMsEbJMZ5VlJ TOp0g6TdYqGjNoc/rQg7pqjcRChVitwd1Rl8O31+bIdNSpv4UReNMDcffRQrt+pF1FxR4q6q M9YLJU8NThx/89Mf/WF7fzrgVlsNJ78D9nJu0EhKes/9EX2qpIcHUfk/izOj8lCc1ksFgXpd UEchE0DcMIIEcjCCAt+gAwIBAgIGCq+KMoDeMA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA3MDMyNjEwMzcwM1oXDTA5MDYwMzEw MzcwM1owcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM8HtlJ+ZixS5UhXRbaL PFvVnK+vpkkiM+KpEyzvt1sRCFDoVmGFRK4AHHFzw2Nm/I8xGjS65PSJWlEOS1vR9Y9PHeb2 pN92quFaDZwg4Eo1s1Cvw2iAMm8bUDFHHir1JcpkJWlkKge7d/PZF+OLWQvuXn3v7uoESwV3 0jK9Fp7FAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJmOrzUu4mayKK7Vi397PAKJ RBJBMB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI hvcNAQEFBQADggF8ABSrkwneBeF0oOk6bRqxwMT17WIyjRFDbi6ORz0isVeEAk1L7d43BwkS J5Ta+BlOwZvMp4FmibXNU4WiHvdUhE/pPTyPh0OWd2kNhlvEPbQrMW33NfqBXwiBHbOSRlct BFsvJbXqTDygV7ez/+nVywKQI8CVm/WtlBhHk+ybQDVqI6K5IeFZSaB8AnGYiB9uYq1Ldamx RlUG4tClOE2taMtECokpgD7776qqje6OoADMkt74wetfl1qLv6fpYF9XiqjW4MCtHtduaBWl X8R08DvldGJcR50uBsUNrAn2cAw3pZ8v80boZmQRruZnuwf+AbfjLbWerjDiYADGf3DPuYMo ywRskxnlWUlM6nSDpN1ioaM2hz+tCDumqNxEKFWK3B3VGXw7fX5sh01Km/hRF40wNx99FCu3 6kXUXFHirqoz1gslTw1OHH/z0x/9YXt/OuBWWw0nvwP2cm7QSEp6z/0RfaqkhwdR+T+LM6Py UJzWSwWBel1QRyETQNwwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0 MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe 1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0 dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3 UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy 4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6 PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18 k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ S0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwNjIwMTYwMjE3WjAjBgkqhkiG9w0B CQQxFgQUndnG7CjXNRlHLDQDQZTvkwlM568wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy c0dFTgIGCq+KMoDeMHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ IEVkZWxXZWIgUGVyc0dFTgIGCq+KMoDeMA0GCSqGSIb3DQEBAQUABIGAVSc2zCKCmbN3cgyT dg5QZSHJiZY+/9PoOOl/VCNXU7zgn16au31wNRYkGxuu8IuerKMl02QXNaIZmR238vP9qRYc 7HZAGx1ckPcGq/uex8Ivu6h9XtSCPpJ/9k6JFG/xhkm1gz3VpN/h/UKhTFGoCLFzAQE6a6Jg 2sNB0T580soAAAAAAAA= --------------ms060902090602010609040103-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5KFHHWk087922 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Jun 2007 08:17:17 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5KFHHTB087920; Wed, 20 Jun 2007 08:17:17 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from setcce.si (localpolitix.setcce.org [193.138.1.155]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5KFHFIe087905 for ; Wed, 20 Jun 2007 08:17:16 -0700 (MST) (envelope-from aljosa@setcce.si) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: A new operation for LTAP, please comment Date: Wed, 20 Jun 2007 17:17:24 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: A new operation for LTAP, please comment thread-index: AceyZwG+As34DfbvR+2KcPg/EsrTvQA0IXuwAATCKrA= From: "Aljosa Jerman Blazic" To: "Tobias Gondrom" , "Peter Sylvester" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l5KFHHIe087915 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Hello Peter, > > I would envision a call to get the list of references more as > a document management function (which of course must have > appropriate access control applied to it) and therefore would > prefer it to be outside the scope of LTAP. The function > definitely makes sense, as well as a query interface to > receive certain documents, but this should not be part of LTAP. I had the same concerns during the discussion with Peter... However this may have implication on the protocol usage. The problem here is the role of LTA. As defined up to now, there are only atomic level functions, e.g. insert/get/verify/... Extending this functions somehow pushes LTA towards EDMS and then the thing gets complex and indeed I would not like to se it blown out of proportions. However, I would definitely look forward for some basic LTA service characteristics/expectations. > I have thought a lot about LTAP lately, and would like to > also talk about some thoughts about some kind of > restructuring, to learn what you think: > My major goal is that LTAP gets implemented. > I get the feeling, that for many vendors it would be most > beneficial for implementation, if there would be an "absolute > minimal subset" of LTAP calls (like "get" and "put") together > with the more sophisticated calls - that are definitely very > useful - of LTAP. Well, the current state of LTAP does exactly that. There are fields that are mandatory and fields that are open. What we need is only careful examination of field types/requirements. > My concerns is that a one-piece complicated complete protocol > might raise the bar too high and reduce the chance of > implementation. To somehow split LTAP (e.g. inside the > document or even in two documents) into one "absolute > minimal" set and one "general use" set might help here, to > get implementers to at first take the first hurdle quite > easily and when they realize this is good and easy they will > probably be more motivated to implement the whole thing. If the minimal set is defined (i.e. required fields) then extensions/upgrades are always optional. Furthermore, we might follow the metainformation approach which has changed through the LTAP versions and it is now open to be filled in with arbitrary metadata types, even data objects. A very good point are guidelines for minimal usage set... BR A. > > > > -----Original Message----- > > From: owner-ietf-ltans@mail.imc.org > > [mailto:owner-ietf-ltans@mail.imc.org] > > On Behalf Of Peter Sylvester > > Sent: Tuesday, June 19, 2007 1:28 PM > > To: ietf-ltans@imc.org > > Subject: A new operation for LTAP, please comment > > > > Hello, > > > > I would like to ask the group about comments concerning a new > > operation for LTAP before I try to write it down into the draft. > > > > During a discussion with a company implementing an > 'electronic safe', > > and to see what functionality a protocol should provide, we > stumbled > > over the following. > > > > It happens that a client wants to get all its data back but has not > > kept any knowledge about the references. > > > > This can occur in at least two scenarios, one is a real end user > > asking to a service provider, and it seems reasonable for a service > > provider to offer such a service. > > One can argue that the service provider should maintain somewhere a > > registry of all the stored data and provide a particular operation. > > > > But then, this registry must be operated in a way which provides > > equivalent security as the archive itself. Or, if you loose the > > registry/directory there is no way to get data out the > archive unless > > you have strict sequential naming conventions or a particular > > operation. > > > > What we came up is an operation DIRLIST (name to be discussed which > > allows to ask an archive to return a list of data > references that it > > possesses. > > Assuming that the archive has some internal order, the operation > > operates in a 'next' mode, i.e. a parameter indicated that > references > > 'behind' a particular one should be returned. > > > > We also think that this operation can have some other filters, at > > least a 'after date x' and also one selector of an owner of data. > > > > A client would then receive all the references and can get > them back > > individually. > > > > This operation is also useful when a client sends many > requests to the > > server in order to determine the final outcome of all of > them, instead > > of polling and repeating each operation, the client can > send a request > > to list all finished archive operations, and then ask the > final result > > only once. > > > > We are not sure whether such an operation should be part of LTAP or > > definitely be outside. > > > > Please don't hesitate to make comments. > > > > Thanks in advance > > Peter > > > > > > > > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5KFA3Ya086698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Jun 2007 08:10:03 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5KFA39o086697; Wed, 20 Jun 2007 08:10:03 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from ns3.neustar.com (ns3.neustar.com [156.154.24.138]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5KFA288086689 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 20 Jun 2007 08:10:03 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 48E12175AB; Wed, 20 Jun 2007 15:10:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I11oo-0001pF-1q; Wed, 20 Jun 2007 11:10:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-ltans@imc.org From: Internet-Drafts@ietf.org Subject: I-D Action:draft-ietf-ltans-ers-scvp-03.txt Message-Id: Date: Wed, 20 Jun 2007 11:10:02 -0400 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Long-Term Archive and Notary Services Working Group of the IETF. Title : Using SCVP to Convey Long-term Evidence Records Author(s) : C. Wallace Filename : draft-ietf-ltans-ers-scvp-03.txt Pages : 18 Date : 2007-06-20 The Simple Certificate Validation Protocol (SCVP) defines an extensible means of delegating the development and validation of certification paths to a server. It can be used to support the development and validation of certification paths well after the expiration of the certificates in the path by specifying a time of interest in the past. The Evidence Record Syntax (ERS) defines structures, called evidence records, to support non-repudiation of existence of data. Evidence records can be used to preserve materials that comprise a certification path such that trust can be established in the certificates after the expiration of the certificates in the path and after the cryptographic algorithms used to sign the certificates in the path are no longer secure. This document describes an application of SCVP to serve this purpose using the WantBack feature of SCVP to convey evidence records. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltans-ers-scvp-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ltans-ers-scvp-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ltans-ers-scvp-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-06-20110447.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltans-ers-scvp-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltans-ers-scvp-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-06-20110447.I-D\@ietf.org> --OtherAccess-- --NextPart-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5KCnXev069184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Jun 2007 05:49:33 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5KCnXMw069183; Wed, 20 Jun 2007 05:49:33 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx02.ixos.de (mucmx02.ixos.de [149.235.128.47]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5KCnTn4069164 for ; Wed, 20 Jun 2007 05:49:31 -0700 (MST) (envelope-from tgondrom@opentext.com) Received: from MUCXGC2.opentext.net (localhost [127.0.0.1]) by mucmx02.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id l5KCmtlm022308; Wed, 20 Jun 2007 14:48:57 +0200 (MEST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: A new operation for LTAP, please comment Date: Wed, 20 Jun 2007 14:48:55 +0200 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_000A_01C7B34A.1F18A890" Message-ID: <2666EB2A846BAC4BB2D7F593301A7868011E4CBD@MUCXGC2.opentext.net> In-Reply-To: <4677BDD4.6010407@edelweb.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: A new operation for LTAP, please comment Thread-Index: AceyZwG+As34DfbvR+2KcPg/EsrTvQA0IXuw From: "Tobias Gondrom" To: "Peter Sylvester" , Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_000A_01C7B34A.1F18A890 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello Peter, I would envision a call to get the list of references more as a document management function (which of course must have appropriate access control applied to it) and therefore would prefer it to be outside the scope of LTAP. The function definitely makes sense, as well as a query interface to receive certain documents, but this should not be part of LTAP. I have thought a lot about LTAP lately, and would like to also talk about some thoughts about some kind of restructuring, to learn what you think: My major goal is that LTAP gets implemented. I get the feeling, that for many vendors it would be most beneficial for implementation, if there would be an "absolute minimal subset" of LTAP calls (like "get" and "put") together with the more sophisticated calls - that are definitely very useful - of LTAP. My concerns is that a one-piece complicated complete protocol might raise the bar too high and reduce the chance of implementation. To somehow split LTAP (e.g. inside the document or even in two documents) into one "absolute minimal" set and one "general use" set might help here, to get implementers to at first take the first hurdle quite easily and when they realize this is good and easy they will probably be more motivated to implement the whole thing. What do you think? Tobias > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] > On Behalf Of Peter Sylvester > Sent: Tuesday, June 19, 2007 1:28 PM > To: ietf-ltans@imc.org > Subject: A new operation for LTAP, please comment > > Hello, > > I would like to ask the group about comments concerning > a new operation for LTAP before I try to write it down > into the draft. > > During a discussion with a company implementing an > 'electronic safe', and to see what functionality a protocol > should provide, we stumbled over the following. > > It happens that a client wants to get all its data back but > has not kept any knowledge about the references. > > This can occur in at least two scenarios, one is a real > end user asking to a service provider, and it seems > reasonable for a service provider to offer such a service. > One can argue that the service provider should maintain > somewhere a registry of all the stored data and provide > a particular operation. > > But then, this registry must be operated in a way which > provides equivalent security as the archive itself. Or, > if you loose the registry/directory there is no way to > get data out the archive unless you have strict sequential > naming conventions or a particular operation. > > What we came up is an operation DIRLIST (name to > be discussed which allows to ask an archive to > return a list of data references that it possesses. > Assuming that the archive has some internal order, > the operation operates in a 'next' mode, i.e. a parameter > indicated that references 'behind' a particular one > should be returned. > > We also think that this operation can have some other > filters, at least a 'after date x' and also one selector > of an owner of data. > > A client would then receive all the references and > can get them back individually. > > This operation is also useful when a client sends > many requests to the server in order to determine > the final outcome of all of them, instead of > polling and repeating each operation, the > client can send a request to list all finished > archive operations, and then ask the > final result only once. > > We are not sure whether such an operation > should be part of LTAP or definitely be outside. > > Please don't hesitate to make comments. > > Thanks in advance > Peter > > > ------=_NextPart_000_000A_01C7B34A.1F18A890 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMwzCCBhow ggQCoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwgZExCzAJBgNVBAYTAkRFMRAwDgYDVQQIEwdCYXZh cmlhMQ8wDQYDVQQHEwZNdW5pY2gxEDAOBgNVBAoTB0dvbmRyb20xETAPBgNVBAsTCFNlY3VyaXR5 MRcwFQYDVQQDEw5Ub2JpYXMgR29uZHJvbTEhMB8GCSqGSIb3DQEJARYSdG9iaWFzQGdvbmRyb20u b3JnMB4XDTA2MTEwMzAwMjA0OFoXDTA5MDczMDAwMjA0OFowgZExCzAJBgNVBAYTAkRFMRAwDgYD VQQIEwdCYXZhcmlhMR4wHAYDVQQKExVPcGVuIFRleHQgQ29ycG9yYXRpb24xETAPBgNVBAsTCFNl Y3VyaXR5MRcwFQYDVQQDEw5Ub2JpYXMgR29uZHJvbTEkMCIGCSqGSIb3DQEJARYVdGdvbmRyb21A b3BlbnRleHQuY29tMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA4dYGy7tHBES4+h3Z NS3dQi4TFm0TE84vyqzWPIwPZHpP927sRb3jh5PD7WChVPcb4KG8P4q2c+bJ+EVdaRv1Uvw57n3n uhAbXtb7kcnFPIMfYn92GOBZpHoDCgT8DRYuQHvScH8l4W9WDtc2NHLkIldIBybxHLVdXX3QJsk3 /OFmJ9shKangwS+AT25cgGj5Ltu9iB2CFCrIKn5CCWDvObwoxEsYPj84Z3ygKUEOijNfkISuKiby /xLIfjDPozpWdb2rb0Oi9pYJkjuzmzF5qwHZDFySeJoVKMIHi4n956m7Etahow+7hQk57+XwQyIL l+s62FlMzsyMCZZ6MlpTs+OrymeobB44ttUn6F370N9GNXg/eV388IYA8e9Mui5F459mrM/9ub9T fQmqoW+SdF4AvBi7BOWTHRJ/DrAWeBcw+9UeX3bWgX6cLNNv+SlNSKSiGV+syf5tqD4APvgfIY0a PPmRLsbUy1Urwfe+BjqOLXZe6w+4WFbbKbAdltpUQCK04eA+g5tIT1ZT8zOxH+EvlJFSoV+i4btp Y7Ni2AfJLvf9OdgwoOJBp3gXQL4o5VWzd362GHYjj94X0sqlJf8Ggcdxz4BR4/EsFRt6MQPXrfoi wPBku/q08YwXPe1hvaW4k8MVosddaka88UY8LJrtXkZWXRERyPMH+cIJNw0CAwEAAaN7MHkwCQYD VR0TBAIwADAsBglghkgBhvhCAQ0EHxYdT3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYD VR0OBBYEFDwj2KwaDOuWxUz/MiFFnt7sOYVoMB8GA1UdIwQYMBaAFH1WtHxZxnLGHnuMc6Pu+Gv9 BD5CMA0GCSqGSIb3DQEBBQUAA4ICAQCne6u3Ko8FefZSDqOq8pKEYAKbuV5NoGZqImoamelDm1Yd 6GQzacZF1aJyfHEytazk2GqmcGGB/yrqaFeQopiSTqGGnB7/8fgYMAUlv+S4NHJoohAVZC/onG0W PDtWKnOyARntV2UxWIikKZZaYKlinvAwaBnmguqboWgbKBpYiV1+U7TgHlYdd9W25k1D+0n+E1mN GvqEfPFxRHEiFdLxWuTtSZnvLDAihAEcTlcKOKGz5RIMHPxG4OcVz+acGKEi8WBHQRVx7KKUkLOy SprjUpxSnEi1AbOEK2y0T/Bao3UkkxQiqKC67OUK0GPbvwat18GLmvesHArtTI8SVty63qdEmxnB CKYLuSOJbXBe5SFPrcruMvumiA4QPdcGMyTiLqDtn97QcN+F5HfB93mKFZfqZwOqi86R6jgzFd3J HsujJXDpZ0tIFRcDespNBcUIV+A38JxHsxF7xHw5wVQMEEsMceMjqEB3X58yAssNnXKD0E7WjIoO SxlnODM++6xTBOIFB3N34ENNuj2Ck8196DUOei/YBEmI5oLIlXEKU/lHiDrq1D9TsjO7vhYoG+wC vAFpGAicl25AGhaOTVeXKh+pTvHHlYva62Stww8eB/fHOW6VASWiUddE4OoxZfQiRkpn91K0rJc4 WHsP9HsBVEdA8xrfN36UXb3SXURnRzCCBqEwggSJoAMCAQICCQCamHOHv2sJlzANBgkqhkiG9w0B AQUFADCBkTELMAkGA1UEBhMCREUxEDAOBgNVBAgTB0JhdmFyaWExDzANBgNVBAcTBk11bmljaDEQ MA4GA1UEChMHR29uZHJvbTERMA8GA1UECxMIU2VjdXJpdHkxFzAVBgNVBAMTDlRvYmlhcyBHb25k cm9tMSEwHwYJKoZIhvcNAQkBFhJ0b2JpYXNAZ29uZHJvbS5vcmcwHhcNMDYxMTAzMDAxMzMxWhcN MDkwNzMwMDAxMzMxWjCBkTELMAkGA1UEBhMCREUxEDAOBgNVBAgTB0JhdmFyaWExDzANBgNVBAcT Bk11bmljaDEQMA4GA1UEChMHR29uZHJvbTERMA8GA1UECxMIU2VjdXJpdHkxFzAVBgNVBAMTDlRv YmlhcyBHb25kcm9tMSEwHwYJKoZIhvcNAQkBFhJ0b2JpYXNAZ29uZHJvbS5vcmcwggIiMA0GCSqG SIb3DQEBAQUAA4ICDwAwggIKAoICAQDRNLo77UVeV/wQ+ml3Nb5XWzkYT4Q8zo7Sl7CkuCT7UE9g v8oFNJbzedTDn//SHkUKQJ3RpZf5VP/8gHvcFUVoiZjCMXYCsjlSJppouau3F0ED2wOle+nE9suX lOuZVSsyuFSF89Yff8oD+wzHWi/9naeHrgKMVeqKa0Pcu1+tJ/zAoeeZHXlxHAuLQbF8XY2RGG0l qSYXBwPuGqSVS9OKUP5kxLm+1Cd928h7PhwKJv9JP34YOWaQmxGL6KjkVnTacKpXPbhtqgtNsHC2 QWkmyyBAS8so5qAfIdOnlRi+U0hgwAKBiAF9OQh9g+xPoqLRmb81+Q18zjPDiIQ+KhwXfJeftUZp fRy8k3thtOnkTqfKHTTaM+KaWR1bRY9DKR5u+zd/6qZ3/snVqBCNAKM0hktcSt7zQUcDo+1RsdW7 H8uJp/avtmYrmt21+Fy5+sN23sGWKNI/E3agPlTr0/jALm17ZomMP7/J4FUHsrxt5Sh6d1bWlxcR xRIhU/8JU0BqbRSW1EKeBpzGnUJ3O65wHfyMrXi5aHG2gGXXoo2AiVTEUZylMsYxTCotEeZijfQN zDH6oCvzePh4LF/Qo9u7T16Ovu3tRhOPQGfWltwC9gs+eJn4j7T2HJSEzVNZ3XTStzu8i/yKCcQZ xWYy0j7ZXKZBSUmPyzuviSOvaU/K+QIDAQABo4H5MIH2MB0GA1UdDgQWBBR9VrR8WcZyxh57jHOj 7vhr/QQ+QjCBxgYDVR0jBIG+MIG7gBR9VrR8WcZyxh57jHOj7vhr/QQ+QqGBl6SBlDCBkTELMAkG A1UEBhMCREUxEDAOBgNVBAgTB0JhdmFyaWExDzANBgNVBAcTBk11bmljaDEQMA4GA1UEChMHR29u ZHJvbTERMA8GA1UECxMIU2VjdXJpdHkxFzAVBgNVBAMTDlRvYmlhcyBHb25kcm9tMSEwHwYJKoZI hvcNAQkBFhJ0b2JpYXNAZ29uZHJvbS5vcmeCCQCamHOHv2sJlzAMBgNVHRMEBTADAQH/MA0GCSqG SIb3DQEBBQUAA4ICAQAmu3wb0JFEPQLfb9PLVEfSldtE9sLdEM4dpiJe1XqvgiI3pQI/lBzKbqcR vg4fdP7muS3tcsqrI31L14+YzphrTLTWev86JdR23ir2oJCqrsHupuqYHI0egTRshejcTjnlBlmk OSfxidjl+7RYjFAquFQEqHPEBb4Tcf6jXFbKzSLp/TcVG9a9x05C8wEJjDbINWxxb4EwjanKcMbh ZNS8Vm0x4IwJhOYwkhx980WXruCoMKec9LwrPkAO/H/ZcpW2gR174oayrNXDYZIZ4nVU248jB52R rrZxCt6/TbC8ftMzcafOLxP933RWtnf79qJbZLV9YspUEzQbuPbrb4nNuK/ZdOgJ9rNtLgZKqoa2 l5j9pNW4+yAh10s2+ZAUOlPv5wICK5gIGJo1Lj1P6cNOp3Yh03mudwM4XhQYyRCg2GbUIj0xXv/e NkYfMGA5ljKmt9qnJ3qZKwgiFwMs2+nMfLDh6GuheAaCaWewHFMcgSoMYHNc43osufcygnKno3Eq Fn8sn9YWM7X5vCuFK7+TGoJRVzVuwmzDqSG3l908auEKLetv03frw5v9cCB0ttExvsITo60lkuK3 Vy4CBDvE2U6BvuEr682hIUirV/X6oVORu3h44fTm1t5aibqwdWI3EpENwg9956Qpbo7uATZtQeWp J6lsIPBAfc6YE6crOTGCBOEwggTdAgEBMIGXMIGRMQswCQYDVQQGEwJERTEQMA4GA1UECBMHQmF2 YXJpYTEPMA0GA1UEBxMGTXVuaWNoMRAwDgYDVQQKEwdHb25kcm9tMREwDwYDVQQLEwhTZWN1cml0 eTEXMBUGA1UEAxMOVG9iaWFzIEdvbmRyb20xITAfBgkqhkiG9w0BCQEWEnRvYmlhc0Bnb25kcm9t Lm9yZwIBATAJBgUrDgMCGgUAoIICHjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0wNzA2MjAxMjQ4NTNaMCMGCSqGSIb3DQEJBDEWBBSskeUtatCoT1Y1VaumSz4jEPAN ozBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCBqAYJKwYB BAGCNxAEMYGaMIGXMIGRMQswCQYDVQQGEwJERTEQMA4GA1UECBMHQmF2YXJpYTEPMA0GA1UEBxMG TXVuaWNoMRAwDgYDVQQKEwdHb25kcm9tMREwDwYDVQQLEwhTZWN1cml0eTEXMBUGA1UEAxMOVG9i aWFzIEdvbmRyb20xITAfBgkqhkiG9w0BCQEWEnRvYmlhc0Bnb25kcm9tLm9yZwIBATCBqgYLKoZI hvcNAQkQAgsxgZqggZcwgZExCzAJBgNVBAYTAkRFMRAwDgYDVQQIEwdCYXZhcmlhMQ8wDQYDVQQH EwZNdW5pY2gxEDAOBgNVBAoTB0dvbmRyb20xETAPBgNVBAsTCFNlY3VyaXR5MRcwFQYDVQQDEw5U b2JpYXMgR29uZHJvbTEhMB8GCSqGSIb3DQEJARYSdG9iaWFzQGdvbmRyb20ub3JnAgEBMA0GCSqG SIb3DQEBAQUABIICAKg30IpW3H1tHVBMPp5eGFU2nxHyFtpiIfyQ7/pJ8ItqIQjRaddcdSuryuXO iwvcTJvE8agr+EICmdy9Gk+TNnUre8kdq/82jd4/QrKJZ4Wlnv2LhWvtgvbRz9/3Fd0SUEHXnn4X jt1ePS33JBdKh4hSJU7CXeY42JtrhJk6QJs3PKMqGVsl2ljRqU4c0460P6UACM8VGL0FSznJtNjJ /8J3EqzJHIenPnq5knhA/0R97a7p/6j/LG7cb/5IlhxGS2OX6eF7m5y9MlR4lwtFMzNXl2PIknV5 vDordQqNztsAlRO4BJ9Q2Y8xdr2u1SBZl0vJnD68pI2EKuedZVA59MoBQuukcFofFJvKBIVEE+Tg JZAIRG8Vb6dnMCrVfov6Fky23RlsgYtRk9NRBvgWybmc+ErnxPMprpOvhyCtbRdrCgsE2M9y8dcG oRD1PE8M2J1/gQLoFEGLC4T4fROhTivG/lDUhI5L9fRqElNIxCAXpSNym2zPPeEruhC81jIdyscN k9AQQ85y4yPL+D89CJJjQ+lgsDcPBHUPotNh9DUh4QXnQ8NYbfcozcLLA+ROBfE3utYQAk9VaIpY 4aieuAAUt9LeQoFLJRPyNjcOebvoW6qY0V8OEswYkSnCsvxgUylt3JGvdU3uDV3yYEGZAUTLc1W9 5ijEf5LvPnQfL3A/AAAAAAAA ------=_NextPart_000_000A_01C7B34A.1F18A890-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5JBUvjf023274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jun 2007 04:30:57 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5JBUvhe023272; Tue, 19 Jun 2007 04:30:57 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from ganymede.on-x.com (ganymede.on-x.com [194.51.68.3]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5JBUu13023265 for ; Tue, 19 Jun 2007 04:30:57 -0700 (MST) (envelope-from Peter.Sylvester@edelweb.fr) Received: from localhost (ganymede [127.0.0.1]) by ganymede.on-x.com (Postfix) with ESMTP id B21A12B for ; Tue, 19 Jun 2007 13:30:55 +0200 (CEST) Received: from ganymede.on-x.com ([127.0.0.1]) by localhost (ganymede.on-x.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15346-03 for ; Tue, 19 Jun 2007 13:30:53 +0200 (CEST) Received: from vinea.on-x.com (sedna.puteaux.on-x [192.168.10.9]) by ganymede.on-x.com (Postfix) with ESMTP id F16BA1F for ; Tue, 19 Jun 2007 13:30:52 +0200 (CEST) Received: from [193.51.14.5] ([212.234.46.65]) by vinea.on-x.com (Lotus Domino Release 5.0.11) with ESMTP id 2007061913305190:303781 ; Tue, 19 Jun 2007 13:30:51 +0200 Message-ID: <4677BDD4.6010407@edelweb.fr> Date: Tue, 19 Jun 2007 13:28:20 +0200 From: Peter Sylvester User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: ietf-ltans@imc.org Subject: A new operation for LTAP, please comment X-MIMETrack: Itemize by SMTP Server on vinea/ON-X(Release 5.0.11 |July 24, 2002) at 06/19/2007 01:30:52 PM, Serialize by Router on vinea/ON-X(Release 5.0.11 |July 24, 2002) at 06/19/2007 01:30:52 PM, Serialize complete at 06/19/2007 01:30:52 PM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020108000509040508030508" X-Virus-Scanned: by amavisd-new at on-x.com Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a cryptographically signed message in MIME format. --------------ms020108000509040508030508 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello, I would like to ask the group about comments concerning a new operation for LTAP before I try to write it down into the draft. During a discussion with a company implementing an 'electronic safe', and to see what functionality a protocol should provide, we stumbled over the following. It happens that a client wants to get all its data back but has not kept any knowledge about the references. This can occur in at least two scenarios, one is a real end user asking to a service provider, and it seems reasonable for a service provider to offer such a service. One can argue that the service provider should maintain somewhere a registry of all the stored data and provide a particular operation. But then, this registry must be operated in a way which provides equivalent security as the archive itself. Or, if you loose the registry/directory there is no way to get data out the archive unless you have strict sequential naming conventions or a particular operation. What we came up is an operation DIRLIST (name to be discussed which allows to ask an archive to return a list of data references that it possesses. Assuming that the archive has some internal order, the operation operates in a 'next' mode, i.e. a parameter indicated that references 'behind' a particular one should be returned. We also think that this operation can have some other filters, at least a 'after date x' and also one selector of an owner of data. A client would then receive all the references and can get them back individually. This operation is also useful when a client sends many requests to the server in order to determine the final outcome of all of them, instead of polling and repeating each operation, the client can send a request to list all finished archive operations, and then ask the final result only once. We are not sure whether such an operation should be part of LTAP or definitely be outside. Please don't hesitate to make comments. Thanks in advance Peter --------------ms020108000509040508030508 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC BHIwggLfoAMCAQICBgqvijKA3jANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNzAzMjYxMDM3MDNaFw0wOTA2MDMxMDM3MDNaMHAx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPB7ZSfmYsUuVIV0W2izxb1Zyvr6ZJ IjPiqRMs77dbEQhQ6FZhhUSuABxxc8NjZvyPMRo0uuT0iVpRDktb0fWPTx3m9qTfdqrhWg2c IOBKNbNQr8NogDJvG1AxRx4q9SXKZCVpZCoHu3fz2Rfji1kL7l597+7qBEsFd9IyvRaexQID AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5 MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSZjq81LuJmsiiu1Yt/ezwCiUQSQTAfBgNV HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA A4IBfAAUq5MJ3gXhdKDpOm0ascDE9e1iMo0RQ24ujkc9IrFXhAJNS+3eNwcJEieU2vgZTsGb zKeBZom1zVOFoh73VIRP6T08j4dDlndpDYZbxD20KzFt9zX6gV8IgR2zkkZXLQRbLyW16kw8 oFe3s//p1csCkCPAlZv1rZQYR5Psm0A1aiOiuSHhWUmgfAJxmIgfbmKtS3WpsUZVBuLQpThN rWjLRAqJKYA++++qqo3ujqAAzJLe+MHrX5dai7+n6WBfV4qo1uDArR7XbmgVpV/EdPA75XRi XEedLgbFDawJ9nAMN6WfL/NG6GZkEa7mZ7sH/gG34y21nq4w4mAAxn9wz7mDKMsEbJMZ5VlJ TOp0g6TdYqGjNoc/rQg7pqjcRChVitwd1Rl8O31+bIdNSpv4UReNMDcffRQrt+pF1FxR4q6q M9YLJU8NThx/89Mf/WF7fzrgVlsNJ78D9nJu0EhKes/9EX2qpIcHUfk/izOj8lCc1ksFgXpd UEchE0DcMIIEcjCCAt+gAwIBAgIGCq+KMoDeMA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA3MDMyNjEwMzcwM1oXDTA5MDYwMzEw MzcwM1owcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM8HtlJ+ZixS5UhXRbaL PFvVnK+vpkkiM+KpEyzvt1sRCFDoVmGFRK4AHHFzw2Nm/I8xGjS65PSJWlEOS1vR9Y9PHeb2 pN92quFaDZwg4Eo1s1Cvw2iAMm8bUDFHHir1JcpkJWlkKge7d/PZF+OLWQvuXn3v7uoESwV3 0jK9Fp7FAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJmOrzUu4mayKK7Vi397PAKJ RBJBMB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI hvcNAQEFBQADggF8ABSrkwneBeF0oOk6bRqxwMT17WIyjRFDbi6ORz0isVeEAk1L7d43BwkS J5Ta+BlOwZvMp4FmibXNU4WiHvdUhE/pPTyPh0OWd2kNhlvEPbQrMW33NfqBXwiBHbOSRlct BFsvJbXqTDygV7ez/+nVywKQI8CVm/WtlBhHk+ybQDVqI6K5IeFZSaB8AnGYiB9uYq1Ldamx RlUG4tClOE2taMtECokpgD7776qqje6OoADMkt74wetfl1qLv6fpYF9XiqjW4MCtHtduaBWl X8R08DvldGJcR50uBsUNrAn2cAw3pZ8v80boZmQRruZnuwf+AbfjLbWerjDiYADGf3DPuYMo ywRskxnlWUlM6nSDpN1ioaM2hz+tCDumqNxEKFWK3B3VGXw7fX5sh01Km/hRF40wNx99FCu3 6kXUXFHirqoz1gslTw1OHH/z0x/9YXt/OuBWWw0nvwP2cm7QSEp6z/0RfaqkhwdR+T+LM6Py UJzWSwWBel1QRyETQNwwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0 MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe 1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0 dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3 UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy 4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6 PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18 k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ S0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwNjE5MTEyODIwWjAjBgkqhkiG9w0B CQQxFgQUnqjCOtHmQQbP1JHiE2g6leMq8tIwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy c0dFTgIGCq+KMoDeMHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ IEVkZWxXZWIgUGVyc0dFTgIGCq+KMoDeMA0GCSqGSIb3DQEBAQUABIGAHgIq0JG8BN/8nm6X 6JqpZ4qYkdjIB7BSIADCrlSU4Ls0GPUPPRWwUzOXQnwHFu35TQroxwQWNI4D45DrrgKI0m4K 3bNpRiuImrCC/gm1KfdwrGwt/d141npuxA5yBNUYdWfqwzKBfHswuEMmCgP48FgVHLWNbZC6 PfDKJvVBHlwAAAAAAAA= --------------ms020108000509040508030508-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5IHKslJ017061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Jun 2007 10:20:54 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5IHKrZW017060; Mon, 18 Jun 2007 10:20:53 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx01.ixos.de (mucmx01.ixos.de [149.235.128.48]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5IHKpC2017051 for ; Mon, 18 Jun 2007 10:20:52 -0700 (MST) (envelope-from tgondrom@opentext.com) Received: from MUCXGC2.opentext.net (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id l5IHKjDI000270 for ; Mon, 18 Jun 2007 19:20:50 +0200 (MEST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: FW: Request to forward the Nomcom 2007-8 Announcement to lists youmanage Date: Mon, 18 Jun 2007 19:20:44 +0200 Message-ID: <2666EB2A846BAC4BB2D7F593301A7868011E499D@MUCXGC2.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Request to forward the Nomcom 2007-8 Announcement to lists youmanage Thread-Index: AcewNyAFBRm30M0OT6mdUk8o/kLduwBlMYkA X-Priority: 5 Importance: low From: "Tobias Gondrom" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l5IHKrC2017055 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello, Nomcom asked to forward this announcement to all WGs. Best regards, Tobias Source: https://datatracker.ietf.org/public/show_nomcom_message.cgi?id=1234 From: Lakshminath Dondeti To: IETF Announcement Date: June 4, 2007 Subject: Nomcom 2007-8: First Call for Volunteers Folks, If you have attended 3 out of the past 5 IETF meetings, you are eligible to serve on Nomcom 2007-2008. Please volunteer and you may become one of the voting members of the committee that selects about half of the members to the IESG and IAB and one IAOC member. RFC 3777 describes the process and the responsibilities in detail. Below is the list of people from the IESG, IAB and IAOC whose terms end during the March 2008 IETF meeting. IAOC: Ed Juskevicius IAB: Leslie Daigle Elwyn Davies Kevin Fall Olaf Kolkman David Oran Eric Rescorla IESG: Lisa Dusseault -- Applications Area Director Jari Arkko -- Internet Area Director Dan Romascanu -- Operations and Management Area Director Cullen Jennings -- Real-time Applications and Infrastructure Area Director Ross Callon --- Routing Area Director Sam Hartman -- Security Area Director Magnus Westerlund -- Transport Area Director Before volunteering, please think about whether you want to be considered for one of those positions instead. If you are already convinced, please send an email before 12:00 noon ET (16:00 UTC/GMT) on July 5, 2007 (otherwise, please read on) To: ldondeti@qualcomm.com Subject: Nomcom 2007-8 Volunteer Body: // As you enter in the IETF Registration Form, // First/Given name followed by Last/Family Name // typically what goes in the Company field // in the IETF Registration Form [] // // For confirmation if selected Please expect an email response from me within 1-2 days stating whether you are qualified or not. If you don't receive anything, please re-send your email with the tag (duplicate) in the subject line. Not convinced yet? Please consider that nomcom members play an important role in shaping the leadership of the IETF. If you are a people person, you will enjoy meeting many of the active contributors to the IETF. If you prefer instead to read a lot of email, well, we have that too. Being a nomcom member is also an important responsibility: it requires adherence to confidentiality rules and some time commitment from the members. The term begins just prior to the Chicago meeting and we expect most of the work to be completed by January 2008. During this period, the nomcom members -- collect requirements from the community and interviews candidates during the Chicago and Vancouver IETF meetings -- review candidates' statements and weighs community feedback -- participate in candidate selection deliberations (weekly conferences calls) Nomcom members are selected following a publicly verifiable random selection method specified in RFC 3797. For the nomcom to work as it should, the pool from which the volunteers are chosen should be as large as possible. The more people who volunteer, the better chance we have of choosing a random yet representative cross section of the IETF population. Ensuring the leadership of the IETF is fair and balanced and comprised of those who can lead the IETF in the right direction is an important responsibility that rests on the IETF participants at large. Volunteering for the nomcom is a good way of contributing in that direction. So please volunteer! thanks, Lakshminath Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l58CImSL081668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Jun 2007 05:18:48 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l58CImuC081667; Fri, 8 Jun 2007 05:18:48 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx02.ixos.de (mucmx02.ixos.de [149.235.128.47]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l58CIkKc081659 for ; Fri, 8 Jun 2007 05:18:47 -0700 (MST) (envelope-from tgondrom@opentext.com) Received: from MUCXGC2.opentext.net (localhost [127.0.0.1]) by mucmx02.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id l58CIglk010164; Fri, 8 Jun 2007 14:18:43 +0200 (MEST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7A9C7.26E0DAA8" Subject: LTANS: cut-off dates for version-00 IDs for the 69th IETF Meeting in Chicago, IL, USA Date: Fri, 8 Jun 2007 14:18:41 +0200 Message-ID: <2666EB2A846BAC4BB2D7F593301A7868011E4019@MUCXGC2.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LTANS: cut-off dates for version-00 IDs for the 69th IETF Meeting in Chicago, IL, USA Thread-Index: AcepxybH/R7sqxxzQn2di5eWxbjSUw== X-Priority: 5 Importance: low From: "Tobias Gondrom" To: Cc: "Carl Wallace" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C7A9C7.26E0DAA8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello LTANS colleagues, if you are planning on new drafts for our WG for Chicago, please note = that we have (as always) some cut-off dates to consider: http://www.ietf.org/meetings/69-cutoff_dates.html=20 If you want to propose a new draft, please inform Carl and me until = June-22 about its name and intention as we MUST formally pre-approve = them until June-25 9:00ET or they will not get published after this = date. And please submit the draft then until June-29th.=20 New versions of already existing drafts (versions-01+) have a bit more = time until July-6th. Thanks, Tobias __________________________________________ Tobias Gondrom Head of Open Text Security Team Director, Product Security Open Text Corporation Technopark 2 Werner-von-Siemens-Ring 20 D-85630 Grasbrunn Phone: +49 (0) 89 4629-1816 Mobile: +49 (0) 173 5942987 Telefax: +49 (0) 89 4629-33-1816 eMail: mailto:tobias.gondrom@opentext.com=20 Internet: http://www.opentext.com/ =20 Place of Incorporation / Sitz der Gesellschaft: Open Text GmbH, An der = Trift 65, 63303 Dreieich, Germany | Phone: +49 (0) 6103 890 40 | Fax: = +49 (0) 6103 89 04 11 | Register Court / Registergericht: Offenbach, = Germany | Trade Register Number / HRB: 33340 | VAT ID Number /USt-ID: = DE 114 169 819 | Managing Director / Gesch=E4ftsf=FChrer: John = Shackleton This email is protected by domestic and international copyright laws and = treaties and is the property of Open Text Corporation, it may contain = confidential and/or trade secret information of the Open Text = Corporation and/or its subsidiaries (OTC), and may be subject to legal = privilege in favor of OTC. This email may only be lawfully received, = accessed, displayed on a computer screen, printed, copied, and/or used = by the specific addressee(s) named above ("Authorized Recipient") for = the purpose for which it was sent by OTC. All other rights and licenses = to this email are fully reserved to OTC. If you are not an Authorized = Recipient, you are required to immediately delete this email in its = entirety without printing, copying, using, and/or re-transmitting this = email, either in whole or in part. The transmission of this email by OTC = is not to be construed as a waiver by OTC and/or the individual sending = this email on behalf of OTC of any of their respective rights or = privileges at law or otherwise, howsoever arising. ------_=_NextPart_001_01C7A9C7.26E0DAA8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable LTANS: cut-off dates for version-00 IDs for the 69th IETF Meeting = in Chicago, IL, USA

Hello = LTANS colleagues,

if = you are planning on new drafts for our WG for Chicago, please note that we = have (as always) some cut-off dates to consider:

http://www.ietf.org/meetings/69-cutoff_dates.html

If = you want to propose a new draft, please inform Carl and me until June-22 = about its name and intention = as we MUST formally pre-approve them until June-25 9:00ET or they will not get = published after this date. And please submit the draft then = until June-29th. =

New = versions of already existing drafts (versions-01+) have a bit more = time = until July-6th.

Thanks, Tobias


__________________________________________
Tobias = Gondrom
Head of = Open Text Security Team
Director, Product Security

Open Text = Corporation
Technopark 2
Werner-von-Siemens-Ring 20
D-85630 Grasbrunn

Phone: +49 (0) 89 4629-1816
Mobile: +49 (0) 173 5942987
Telefax: +49 (0) 89 4629-33-1816
eMail: mailto:tobias.gondrom@opentex= t.com
Internet: http://www.opentext.com/  =

Place = of Incorporation / Sitz der Gesellschaft: Open Text GmbH, An der Trift = 65, 63303 Dreieich, Germany | Phone: +49 (0) 6103 890 40 | Fax: +49 (0) = 6103 89 04 11 | Register Court / Registergericht: Offenbach, Germany | = Trade Register Number / HRB: 33340 | VAT ID Number /USt-ID:  DE 114 = 169 819 | Managing Director / Gesch=E4ftsf=FChrer: John = Shackleton

This = email is protected by domestic and international copyright laws and = treaties and is the property of Open Text Corporation, it may contain = confidential and/or trade secret information of the Open Text = Corporation and/or its subsidiaries (OTC), and may be subject to legal = privilege in favor of OTC. This email may only be lawfully received, = accessed, displayed on a computer screen, printed, copied, and/or used = by the specific addressee(s) named above ("Authorized = Recipient") for the purpose for which it was sent by OTC. All other = rights and licenses to this email are fully reserved to OTC. If you are = not an Authorized Recipient, you are required to immediately delete this = email in its entirety without printing, copying, using, and/or = re-transmitting this email, either in whole or in part. The transmission = of this email by OTC is not to be construed as a waiver by OTC and/or = the individual sending this email on behalf of OTC of any of their = respective rights or privileges at law or otherwise, howsoever = arising.

------_=_NextPart_001_01C7A9C7.26E0DAA8-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l55HZk31031956 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Jun 2007 10:35:46 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l55HZkqZ031955; Tue, 5 Jun 2007 10:35:46 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from ganymede.on-x.com (ganymede.on-x.com [194.51.68.3]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l55HZhox031947 for ; Tue, 5 Jun 2007 10:35:45 -0700 (MST) (envelope-from Peter.Sylvester@edelweb.fr) Received: from localhost (ganymede [127.0.0.1]) by ganymede.on-x.com (Postfix) with ESMTP id 8052F22; Tue, 5 Jun 2007 19:35:41 +0200 (CEST) Received: from ganymede.on-x.com ([127.0.0.1]) by localhost (ganymede.on-x.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19566-06; Tue, 5 Jun 2007 19:35:38 +0200 (CEST) Received: from vinea.on-x.com (sedna.puteaux.on-x [192.168.10.9]) by ganymede.on-x.com (Postfix) with ESMTP id 228411E; Tue, 5 Jun 2007 19:35:38 +0200 (CEST) Received: from [193.51.14.5] ([212.234.46.65]) by vinea.on-x.com (Lotus Domino Release 5.0.11) with ESMTP id 2007060519353680:283997 ; Tue, 5 Jun 2007 19:35:36 +0200 Message-ID: <46659E52.2070007@edelweb.fr> Date: Tue, 05 Jun 2007 19:33:06 +0200 From: Peter Sylvester User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: Jesus Maria Mendez Perez Cc: ietf-ltans@imc.org Subject: Re: question about LTANS implementation, help References: In-Reply-To: X-MIMETrack: Itemize by SMTP Server on vinea/ON-X(Release 5.0.11 |July 24, 2002) at 06/05/2007 07:35:36 PM, Serialize by Router on vinea/ON-X(Release 5.0.11 |July 24, 2002) at 06/05/2007 07:35:37 PM, Serialize complete at 06/05/2007 07:35:37 PM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030205050708030007030904" X-Virus-Scanned: by amavisd-new at on-x.com Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a cryptographically signed message in MIME format. --------------ms030205050708030007030904 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Thanks for your question. I'll try to answer. maybe Aljosa adds something. It seems that some of the remarks can be added to the text for clarification, at least I promise to try so because when the text becomes an RFC, it must have its own standard and not depend on discussions on the list. :-) Jesus Maria Mendez Perez wrote: > hello, > im new on this and ive got some questions about LTANS implementation > that i havent understood well. > > ---first about the LTAP protocol - asynchronous implementation. > *A client that send a STATUS or a EXPORT operation, after a time they > receive the first response ACK, but > Have they wait for the second response (status of data or data > respectively)? or the client have to send another message to recover > the status or > the data? This depends on how the lower layer binding of the operation is done. There is still something missing in the current text to talk about binding to http or mail. For an environment like with HTTP, a client has to redo the operation until it receives the final answer. > > *In the EXPORT operation, does the LTA server verify some information > before recover the data o simply recover it? I don't understand what you mean by 'some information'? The server makes all kinds of access control. I think a server must return whatever data it has whether it considers them as valid or not. A missing part in the text is the definition of some metadata where the server indicates what it believes about the quality of the data, when they were verifies last time, and whether the verification failed. > > *In the VERIFY operation, does the client attach another information > (e.g SCVP response) or simply include the reference to the data? and > what does really verifying the LTA server: evidence, signature > validity, both or depending on LTA server implementation? > can you explain in few words the process of verifying step by step? Verifying is a totally open operation. It is up to the server to implement things like read all backup data, calculate hashes, compare k out n copies etc. The verify operation exists in order to allow a client to start such an operation explicitely. The operation is noramally not performed by an external client but rather by some broker that is aassociated either with a client or with the server, or by some independant auditor > > > ---archive object > An archive object is composed by: > 1.Document > 2.Document meta-data (category, size, key-words, ...) > Are these information generate and send by the client or > generate by the LTA sever? > If a client wants to send a signed document, what will happen > with this document meta-data..? One should not confuse the metadata and the signed document. The LTAP does not know whether metadata correspond to whatever inside a signed document. The LTAP takes metadata for whatever purpose like indexing etc. It believes that they are good. Of course, some document content module may add restrictions and formating/type rules > Have the client to sign them too and send together, or are > they send without sign (suppose the client send it). There are two signatures: The one on a document itself, and maybe some to protect the ltap request. The document signature is basically unseen to an simple LTAP server, it stores just a binary blob together with at least one metadata indicating what type they are (mimetype) > 3.Complementary data (digital certificate, crl, ...) > 4.Archive meta-data (document owner, more information about owner, > origin of document, ...) > Are these information generate and send by the client or > generate by the LTA sever? depends on the profile of the server. We can currently only provide a placeholder where a client can put whatever is necessary. > If a client wants to send a signed document, what will happen > with this archive meta-data..? > Have the client to sign them too and send together, or are > they send without sign (suppose the client send it) ?. The client and server use whatever is appropriate to protect requests. There is still text missing to indicate the possible ways, e.g. encapsulate the request inside signedData or just sign it with XML-DSIG or XADES-BES. The structure of the data itself, i.e. whether it is a signed document, may be totally unvisible to the last back en LTAP server. > 5.Evidence record > > > ---encryption data > If a client send encryption data, what will happen if the algorithm > become weak?. Do you mean ENCRYPTED data? This a client problem. There may be specialized proxy brokers to sell a long term confidentiality service. Such a service may use for example encryption but may also used k out of n splitting of data. > Have the LTA server to re-encrypt data..? Not a basic LTA server IMO. > Does the client to recover the data, re-encrypt it with an a secure > algorithm and send it again? That is a possible solution: But if you don't trust the server, how do you know whether it really had deleted the previously stored data? using cryptography for long term storage seems to me simlpy impossible. > > > ---add or remove a document > Suppose i archived some documents together, but now i want to remove > or add one. Currently you cannot archive structured documents and later work on pieces. > What does it affect to the archive-timestamp and hash-tree...? Have > the LTA server to build a new hash-tree? It is not even said that the LTA server builds a hash tree? it uses whatever it wants to do to be able to detect failures or to prove something. Depending on policy, a removal may result in completely removal of the data and all traces, metadata etc. Or the server may maintain some metadata. > Have the client to recover the data and ARCHIVE the new data (bad idea)? It depends: The current protocol only provide the five basic operations. We have so far evacuated extended operations for some broker/proxy like 'transfer some data from one provider to another'. Service providers could provide front end specialized services that can operate on pieces of data, which knows how a 'structured document' would be decomposed into pieces. > > Thanks. You are welcome feel free to continue. --------------ms030205050708030007030904 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC BHIwggLfoAMCAQICBgqvijKA3jANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNzAzMjYxMDM3MDNaFw0wOTA2MDMxMDM3MDNaMHAx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPB7ZSfmYsUuVIV0W2izxb1Zyvr6ZJ IjPiqRMs77dbEQhQ6FZhhUSuABxxc8NjZvyPMRo0uuT0iVpRDktb0fWPTx3m9qTfdqrhWg2c IOBKNbNQr8NogDJvG1AxRx4q9SXKZCVpZCoHu3fz2Rfji1kL7l597+7qBEsFd9IyvRaexQID AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5 MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSZjq81LuJmsiiu1Yt/ezwCiUQSQTAfBgNV HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA A4IBfAAUq5MJ3gXhdKDpOm0ascDE9e1iMo0RQ24ujkc9IrFXhAJNS+3eNwcJEieU2vgZTsGb zKeBZom1zVOFoh73VIRP6T08j4dDlndpDYZbxD20KzFt9zX6gV8IgR2zkkZXLQRbLyW16kw8 oFe3s//p1csCkCPAlZv1rZQYR5Psm0A1aiOiuSHhWUmgfAJxmIgfbmKtS3WpsUZVBuLQpThN rWjLRAqJKYA++++qqo3ujqAAzJLe+MHrX5dai7+n6WBfV4qo1uDArR7XbmgVpV/EdPA75XRi XEedLgbFDawJ9nAMN6WfL/NG6GZkEa7mZ7sH/gG34y21nq4w4mAAxn9wz7mDKMsEbJMZ5VlJ TOp0g6TdYqGjNoc/rQg7pqjcRChVitwd1Rl8O31+bIdNSpv4UReNMDcffRQrt+pF1FxR4q6q M9YLJU8NThx/89Mf/WF7fzrgVlsNJ78D9nJu0EhKes/9EX2qpIcHUfk/izOj8lCc1ksFgXpd UEchE0DcMIIEcjCCAt+gAwIBAgIGCq+KMoDeMA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA3MDMyNjEwMzcwM1oXDTA5MDYwMzEw MzcwM1owcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM8HtlJ+ZixS5UhXRbaL PFvVnK+vpkkiM+KpEyzvt1sRCFDoVmGFRK4AHHFzw2Nm/I8xGjS65PSJWlEOS1vR9Y9PHeb2 pN92quFaDZwg4Eo1s1Cvw2iAMm8bUDFHHir1JcpkJWlkKge7d/PZF+OLWQvuXn3v7uoESwV3 0jK9Fp7FAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJmOrzUu4mayKK7Vi397PAKJ RBJBMB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI hvcNAQEFBQADggF8ABSrkwneBeF0oOk6bRqxwMT17WIyjRFDbi6ORz0isVeEAk1L7d43BwkS J5Ta+BlOwZvMp4FmibXNU4WiHvdUhE/pPTyPh0OWd2kNhlvEPbQrMW33NfqBXwiBHbOSRlct BFsvJbXqTDygV7ez/+nVywKQI8CVm/WtlBhHk+ybQDVqI6K5IeFZSaB8AnGYiB9uYq1Ldamx RlUG4tClOE2taMtECokpgD7776qqje6OoADMkt74wetfl1qLv6fpYF9XiqjW4MCtHtduaBWl X8R08DvldGJcR50uBsUNrAn2cAw3pZ8v80boZmQRruZnuwf+AbfjLbWerjDiYADGf3DPuYMo ywRskxnlWUlM6nSDpN1ioaM2hz+tCDumqNxEKFWK3B3VGXw7fX5sh01Km/hRF40wNx99FCu3 6kXUXFHirqoz1gslTw1OHH/z0x/9YXt/OuBWWw0nvwP2cm7QSEp6z/0RfaqkhwdR+T+LM6Py UJzWSwWBel1QRyETQNwwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0 MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe 1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0 dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3 UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy 4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6 PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18 k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ S0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwNjA1MTczMzA2WjAjBgkqhkiG9w0B CQQxFgQUsCw6yUiN88p8b9wgkEJQRmyLXcUwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy c0dFTgIGCq+KMoDeMHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ IEVkZWxXZWIgUGVyc0dFTgIGCq+KMoDeMA0GCSqGSIb3DQEBAQUABIGAkKOEVzQ1xThXK8yt 5EkxcIUt9jDSkVuxC7qOnzEeLZwS212UOe1PCL3BSKBjFCygC7AQX2yjRxpr1tFgKJK2iNW2 kBvnwHaP2dn/MV4iqi7DgdezQmhOiVgtwSA0LeFpguz7msBdcj4SlF1+shaHR7W3Mbux9W0P ZIn0OyY63bYAAAAAAAA= --------------ms030205050708030007030904-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l557Xis0024797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Jun 2007 00:33:44 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l557XiJB024796; Tue, 5 Jun 2007 00:33:44 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.239]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l557XgcC024789 for ; Tue, 5 Jun 2007 00:33:43 -0700 (MST) (envelope-from jesusmmp@gmail.com) Received: by wx-out-0506.google.com with SMTP id s16so1336693wxc for ; Tue, 05 Jun 2007 00:33:42 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=kytzeaUwnm/HixqzjcRl3IzOM7dAPUjHWjJmKXStq/8Jj6fPekn7Lzy1SBxhX163wwKfNlylJIxExdN4lP18AGG+C7m+Rb5lwbuvi3KV6zkITIZ/8nkGOx2I8tP8GS77YK1B4luVEPQnwaJWZdKtVdwqZKNrHfZ1mzPRBFBaKXI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=VdzlU11yU1kXENwvU/0Q6SXBsV4TPrtAAFGpjEXd3Var3Bz4nKepDDyJhby6pQ5Mju0lnlqYiXU7xmWJE0iiUtZ1fl2rEzqKw3/3UW4AAuWUFhZ6EviLLvDcBRjM0KpouX49nxYUlEet1lgpHaKsTUGE2Y9NXTOlz9xtufsJwiE= Received: by 10.90.87.5 with SMTP id k5mr4517128agb.1181028821966; Tue, 05 Jun 2007 00:33:41 -0700 (PDT) Received: by 10.90.55.13 with HTTP; Tue, 5 Jun 2007 00:33:41 -0700 (PDT) Message-ID: Date: Tue, 5 Jun 2007 09:33:41 +0200 From: "Jesus Maria Mendez Perez" To: ietf-ltans@imc.org Subject: question about LTANS implementation, help MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_11688_15753467.1181028821941" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ------=_Part_11688_15753467.1181028821941 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline hello, im new on this and ive got some questions about LTANS implementation that i havent understood well. ---first about the LTAP protocol - asynchronous implementation. *A client that send a STATUS or a EXPORT operation, after a time they receive the first response ACK, but Have they wait for the second response (status of data or data respectively)? or the client have to send another message to recover the status or the data? *In the EXPORT operation, does the LTA server verify some information before recover the data o simply recover it? *In the VERIFY operation, does the client attach another information (e.gSCVP response) or simply include the reference to the data? and what does really verifying the LTA server: evidence, signature validity, both or depending on LTA server implementation? can you explain in few words the process of verifying step by step? ---archive object An archive object is composed by: 1.Document 2.Document meta-data (category, size, key-words, ...) Are these information generate and send by the client or generate by the LTA sever? If a client wants to send a signed document, what will happen with this document meta-data..? Have the client to sign them too and send together, or are they send without sign (suppose the client send it). 3.Complementary data (digital certificate, crl, ...) 4.Archive meta-data (document owner, more information about owner, origin of document, ...) Are these information generate and send by the client or generate by the LTA sever? If a client wants to send a signed document, what will happen with this archive meta-data..? Have the client to sign them too and send together, or are they send without sign (suppose the client send it) ?. 5.Evidence record ---encryption data If a client send encryption data, what will happen if the algorithm become weak?. Have the LTA server to re-encrypt data..? Does the client to recover the data, re-encrypt it with an a secure algorithm and send it again? ---add or remove a document Suppose i archived some documents together, but now i want to remove or add one. What does it affect to the archive-timestamp and hash-tree...? Have the LTA server to build a new hash-tree? Have the client to recover the data and ARCHIVE the new data (bad idea)? Thanks. ------=_Part_11688_15753467.1181028821941 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline hello,
im new on this and ive got some questions about LTANS implementation that i havent understood well.

---first about the LTAP protocol - asynchronous implementation.
*A client that send a STATUS or a EXPORT operation, after a time they receive the first response ACK, but  
Have they wait for the second response (status of data or data respectively)? or the client have to send another message to recover the status or
the data?

*In the EXPORT operation, does the LTA server verify some information before recover the data o simply recover it?

*In the VERIFY operation, does the client attach another information (e.g SCVP response) or simply include the reference to the data? and
what does really verifying the LTA server: evidence, signature validity, both or depending on LTA server implementation?
can you explain in few words the process of verifying step by step?


---archive object
An archive object is composed by:
    1.Document
    2.Document meta-data (category, size, key-words, ...)
         Are these information generate and send by the client or generate by the LTA sever?
         If a client wants to send a signed document, what will happen with this document meta-data..?
         Have the client to sign them too and send together, or are they send without sign (suppose the client send it).
    3.Complementary data (digital certificate, crl, ...)
    4.Archive meta-data (document owner, more information about owner, origin of document, ...)
         Are these information generate and send by the client or generate by the LTA sever?
         If a client wants to send a signed document, what will happen with this archive meta-data..?
         Have the client to sign them too and send together, or are they send without sign (suppose the client send it) ?.
    5.Evidence record
    
    
---encryption data
If a client send encryption data, what will happen if the algorithm become weak?.
Have the LTA server to re-encrypt data..?
Does the client to recover the data, re-encrypt it with an a secure algorithm and send it again?


---add or remove a document
Suppose i archived some documents together, but now i want to remove or add one.
What does it affect to the archive-timestamp and hash-tree...? Have the LTA server to build a new hash-tree?
Have the client to recover the data and ARCHIVE the new data (bad idea)?

Thanks. ------=_Part_11688_15753467.1181028821941-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l54Jo4IG076262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Jun 2007 12:50:04 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l54Jo4i1076260; Mon, 4 Jun 2007 12:50:04 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from ns0.neustar.com (ns0.neustar.com [156.154.16.158]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l54Jo2Bu076237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 4 Jun 2007 12:50:03 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 31FAD328DC; Mon, 4 Jun 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HvIZ0-0002hH-3X; Mon, 04 Jun 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-ltans@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ltans-ers-15.txt Message-Id: Date: Mon, 04 Jun 2007 15:50:02 -0400 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Long-Term Archive and Notary Services Working Group of the IETF. Title : Evidence Record Syntax (ERS) Author(s) : R. Brandner, et al. Filename : draft-ietf-ltans-ers-15.txt Pages : 33 Date : 2007-6-4 In many scenarios, users must be able prove the existence and integrity of data, including digitally signed data, in a common and reproducible way over a long and possibly undetermined period of time. This document specifies the syntax and processing of an Evidence Record, a structure designed to support long-term non- repudiation of existence of data. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltans-ers-15.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ltans-ers-15.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ltans-ers-15.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-6-4123055.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltans-ers-15.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltans-ers-15.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-4123055.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l54EUTL0019030 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Jun 2007 07:30:29 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l54EUT5a019029; Mon, 4 Jun 2007 07:30:29 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from ns4.neustar.com (ns4.neustar.com [156.154.24.139]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l54EUQ8Q019019 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 4 Jun 2007 07:30:27 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 227D32AD05; Mon, 4 Jun 2007 14:30:26 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HvDZh-0002JZ-Rc; Mon, 04 Jun 2007 10:30:25 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , ltans mailing list , ltans chair Subject: Protocol Action: 'Evidence Record Syntax (ERS)' to Proposed Standard Message-Id: Date: Mon, 04 Jun 2007 10:30:25 -0400 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The IESG has approved the following document: - 'Evidence Record Syntax (ERS) ' as a Proposed Standard This document is the product of the Long-Term Archive and Notary Services Working Group. The IESG contact persons are Tim Polk and Sam Hartman. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltans-ers-14.txt Technical Summary In many scenarios, users must be able prove the existence and integrity of data, including digitally signed data, in a common and reproducible way over a long and possibly undetermined period of time. This document specifies the syntax and processing of an Evidence Record, a structure designed to support long-term non-repudiation of existence of data. Working Group Summary The LTANS WG reached consensus on this document. Protocol Quality There exist several implementations of the specification. At least two vendors have already run compatibility tests based on draft version 08, and they will run final tests after the publication of ERS. This document was reviewed by Tim Polk for the IESG.