Re: Use of "TAA" acronym (was Comments on LTANS documents)
Jeff Williams <jwkckid1@ix.netcom.com> Sun, 01 August 2004 00:22 UTC
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i710MkRB004184; Sat, 31 Jul 2004 17:22:46 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i710Mkl5004183; Sat, 31 Jul 2004 17:22:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from hall.mail.mindspring.net (hall.mail.mindspring.net [207.69.200.60]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i710Mjs1004177 for <ietf-ltans@imc.org>; Sat, 31 Jul 2004 17:22:46 -0700 (PDT) (envelope-from jwkckid1@ix.netcom.com)
Received: from 1cust120.tnt36.dfw9.da.uu.net ([67.234.81.120] helo=ix.netcom.com) by hall.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1Br47l-0005qI-00; Sat, 31 Jul 2004 20:22:49 -0400
Message-ID: <410C510B.6210F172@ix.netcom.com>
Date: Sat, 31 Jul 2004 19:10:20 -0700
From: Jeff Williams <jwkckid1@ix.netcom.com>
Organization: INEGroup Spokesman
X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit)
MIME-Version: 1.0
To: Larry Masinter <LMM@acm.org>
CC: ietf-ltans@imc.org
Subject: Re: Use of "TAA" acronym (was Comments on LTANS documents)
References: <0I1Q00437B2RAR@mailsj-v1.corp.adobe.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>
Larry and all, I like acronyms for good purposes as long as there is a dictionary for describing them as they apply to the IETF or whom/whatever entity uses them. It may be time for the IETF to seriously building such a dictionary for IETF acronyms or acronyms use by the IETF? Larry Masinter wrote: > I think I wasn't clear about my opinion on this subject, > so, for what it is worth: > > (a) I think choices of wording in a document should be > left up to the editor; the working group can make suggestions > and complain when the meaning is unclear or misleading, but > in the end, it is an editorial function. Usually, word choices > can't be made alone, there are many different terms in > the document, we shouldn't spend a lot of working group > time making suggestions about what they should be. > > (b) THAT SAID, personally, I prefer to avoid acronyms unless > they're really necessary. I haven't seen the necessity of > having a TAA or an SAS or a TS or whatever, when we can > write it out, > > "Archive Service" and "Notary Service" > > For that matter, I prefer to try to use neutral terms > "Archive Service", and then note that it would be good > if the Archive Service were trusted, than to add the description > to the label and then later on try to provide procedures > for deciding whether the Archive Service we're talking to > can be (or can't be) trusted. > > Larry > -- > http://larry.masinter.net Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1@ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i710MkRB004184; Sat, 31 Jul 2004 17:22:46 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i710Mkl5004183; Sat, 31 Jul 2004 17:22:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from hall.mail.mindspring.net (hall.mail.mindspring.net [207.69.200.60]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i710Mjs1004177 for <ietf-ltans@imc.org>; Sat, 31 Jul 2004 17:22:46 -0700 (PDT) (envelope-from jwkckid1@ix.netcom.com) Received: from 1cust120.tnt36.dfw9.da.uu.net ([67.234.81.120] helo=ix.netcom.com) by hall.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1Br47l-0005qI-00; Sat, 31 Jul 2004 20:22:49 -0400 Message-ID: <410C510B.6210F172@ix.netcom.com> Date: Sat, 31 Jul 2004 19:10:20 -0700 From: Jeff Williams <jwkckid1@ix.netcom.com> Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Larry Masinter <LMM@acm.org> CC: ietf-ltans@imc.org Subject: Re: Use of "TAA" acronym (was Comments on LTANS documents) References: <0I1Q00437B2RAR@mailsj-v1.corp.adobe.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/> List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe> List-ID: <ietf-ltans.imc.org> Larry and all, I like acronyms for good purposes as long as there is a dictionary for describing them as they apply to the IETF or whom/whatever entity uses them. It may be time for the IETF to seriously building such a dictionary for IETF acronyms or acronyms use by the IETF? Larry Masinter wrote: > I think I wasn't clear about my opinion on this subject, > so, for what it is worth: > > (a) I think choices of wording in a document should be > left up to the editor; the working group can make suggestions > and complain when the meaning is unclear or misleading, but > in the end, it is an editorial function. Usually, word choices > can't be made alone, there are many different terms in > the document, we shouldn't spend a lot of working group > time making suggestions about what they should be. > > (b) THAT SAID, personally, I prefer to avoid acronyms unless > they're really necessary. I haven't seen the necessity of > having a TAA or an SAS or a TS or whatever, when we can > write it out, > > "Archive Service" and "Notary Service" > > For that matter, I prefer to try to use neutral terms > "Archive Service", and then note that it would be good > if the Archive Service were trusted, than to add the description > to the label and then later on try to provide procedures > for deciding whether the Archive Service we're talking to > can be (or can't be) trusted. > > Larry > -- > http://larry.masinter.net Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1@ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i710Hc7H003758; Sat, 31 Jul 2004 17:17:38 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i710Hcod003757; Sat, 31 Jul 2004 17:17:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from hall.mail.mindspring.net (hall.mail.mindspring.net [207.69.200.60]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i710HbnD003739 for <ietf-ltans@imc.org>; Sat, 31 Jul 2004 17:17:38 -0700 (PDT) (envelope-from jwkckid1@ix.netcom.com) Received: from 1cust120.tnt36.dfw9.da.uu.net ([67.234.81.120] helo=ix.netcom.com) by hall.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1Br42g-0002oL-00; Sat, 31 Jul 2004 20:17:34 -0400 Message-ID: <410C4FCF.A4188ABF@ix.netcom.com> Date: Sat, 31 Jul 2004 19:05:05 -0700 From: Jeff Williams <jwkckid1@ix.netcom.com> Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Larry Masinter <LMM@acm.org> CC: "'IETF LTANS'" <ietf-ltans@imc.org> Subject: Re: Use of RFC 2119 terms in requirements docs (was RE: Comments on LTANS documents) References: <0I1Q004NDAPAAR@mailsj-v1.corp.adobe.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/> List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe> List-ID: <ietf-ltans.imc.org> Larry and all, Larry Masinter wrote: > (assuming everyone is on the ltans mailing list and doesn't > want to get two copies) > > Jeff, > > I can't tell, from your message, whether you are in favor or opposed > to the use of RFC 2119 keywords in our document. I am FOR them if, and only if, the meanings of them are understood and defined clearly, which in RFC 2119 they are not from my past experiences, which I outlined in my previous post on this thread... > > > In the case of these particular documents, I wonder a little > about their positioning. Agreed. > It would seem that the business of > the IETF isn't so much to define the functional characteristics > of a long-term archive or a notary service 'must be', but rather > to define an Internet protocol for accessing such service Also agreed here but I think we all must understand and be cognizant of the fact that how notary service is accessed via any protocol is directly linked to the service operation itself... Note: I hope I am not being so brief here as to be misunderstood or misconstrued? > > > >From that point of view, it's important to define what a > long-term archive service does, what it's important characteristics > are, and to define what a notary service might do, so that > we can then define a standard protocol for accessing those > services. > > But there's no point in defining what an archive service MUST > do, except where it comes to its network interface. We can hardly > mandate, oh, putting the service in a physically secure location, > at least in the IETF. Perhaps if you're intending to purchase > an archive service and writing an RFP, you'd want to use these > kinds of terms, because you'll be judging compliance of your > purchase against this. Yes understood. > > > The charter says: > > # The objective of the LTANS working group is to define requirements, data > # structures and protocols for the secure usage of the necessary archive > # and notary services. Right. > > > and let me emphasize "THE SECURE USAGE OF". Some of the 'requirements' > in these documents seem to be requirements on the services themselves, > and not on the protocol for accessing them. Yes "Some"! > > > For example, just to take the first MUST in > draft-ietf-ltans-notareqs-00.txt > > # The notary service has to record private transactions, e.g. > # transactions of ownership. Additionally to the recording it MUST > # be able to guarantee and provide documentation that all necessary > # information has been provided to all involved parties. > > This 'MUST' is not a protocol requirement. In many circumstances, > it's not even something that is possible to evaluate. I don't > think we will be in the business of judging the mechanisms by > which operations that function as a 'notary service' have realistic > means of guaranteeing what they say they guarantee. Ok also understood here as well... Nicely put as well.. > > > If there's a protocol requirement, it's that the protocol needs > some way of COMMUNICATING the notary service's statement of > guarantee. A guarantee is never a 100% guarantee anyway, there > are usually conditions and circumstances. Should the protocol > allow for those, or are they communicated out of band? I think > that's the design question before us. IMHO the protocol should provide for these conditions and circumstances as they are known today and than reviewed as part of the continuing development of the protocol. I recognize of course that this makes designing the protocol very much more difficult and complex, but we don't live or operate in a simple world either, hence that being a real consideration is why I have this opinion. > > > On the other hand, to pick another (not upper case) 'must' from > draft-ietf-ltans-reqs-01.txt, > > # Submitters must be able to specify an archivation period. > > It's not clear that this is a reasonable requirement to be > 'MUST', since it doesn't say what are reasonable > ranges, or whether a service must support all ranges, or > is free to ignore the archivation period. Also agreed and in part why I have trouble in how these "Terms" as used and/or potentially interpreted... Therefore a need to define them as they are intended or ARE used is necessary IMHO... > Is it possible > to have a long term archive service which doesn't support > deletion, for which all records are kept 'forever'? Yes, why not.. Whether or not keeping these records forever is a wise or good idea is another matter that IMHO is outside the scope really of the protocol design... > > > Larry > -- > http://larry.masinter.net > > Larry > -- > http://larry.masinter.net > > > -----Original Message----- > > From: Jeff Williams [mailto:jwkckid1@ix.netcom.com] > > Sent: Saturday, July 31, 2004 1:41 AM > > To: Larry Masinter > > Cc: 'Denis Pinkas'; 'IETF LTANS'; Harald@alvestrand.no > > Subject: Re: Use of RFC 2119 terms in requirements docs (was > > RE: Comments on LTANS documents) > > > > Larry and all, > > > > The use of certain terms and what the really mean as opposed to what > > they are considered amongst IETF/IAB self selected "Officials" is > > often times jux opposed as indicated in RFC 2119 as you rightly > > point out indirectly. Yet these debates/discussions have also been > > previously discussed hotly debated over two years ago on the > > "poised" IEFT forum by a number of active participant, including > > myself. > > > > Larry Masinter wrote: > > > > > Denis Pinkas wrote: > > > > > > # 1. Since the document is a requirements document, it should use a > > > # terminology in accordance with RFC 2119 and use the > > following key words: > > > # "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > > "SHOULD", "SHOULD > > > # NOT", "RECOMMENDED", "MAY", and "OPTIONAL". > > > > > > There's been considerable discussion in the 'newtrk' group > > > about the use of RFC 2119 terms for requirements documents. > > > See http://darkwing.uoregon.edu/~llynch/newtrk/msg00322.html > > > and the following discussion. > > > > > > Personally, I'm uncomfortable with the use of 2119 in requirements > > > documents, and have worked to avoid it in more recent requirements > > > documents I've worked on. It doesn't make the document > > > clearer, and the choices are usually fairly arbitrary. > > > > > > Larry > > > -- > > > http://larry.masinter.net > > > > Regards, > > > > -- > > Jeffrey A. Williams > > Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) > > "Be precise in the use of words and expect precision from others" - > > Pierre Abelard > > > > "If the probability be called P; the injury, L; and the burden, B; > > liability depends upon whether B is less than L multiplied by > > P: i.e., whether B is less than PL." > > United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] > > =============================================================== > > Updated 1/26/04 > > CSO/DIR. Internet Network Eng. SR. Eng. Network data security > > IDNS. div. of Information Network Eng. INEG. INC. > > E-Mail jwkckid1@ix.netcom.com > > Registered Email addr with the USPS > > Contact Number: 214-244-4827 > > > > Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1@ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6VINFcm085567; Sat, 31 Jul 2004 11:23:15 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6VINFvE085566; Sat, 31 Jul 2004 11:23:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from psmtp.com (exprod6ob1.obsmtp.com [12.158.35.211]) by above.proper.com (8.12.11/8.12.9) with SMTP id i6VINCbB085560 for <ietf-ltans@imc.org>; Sat, 31 Jul 2004 11:23:14 -0700 (PDT) (envelope-from LMM@acm.org) Received: from source ([192.150.22.7]) by exprod6ob1.obsmtp.com ([12.158.35.250]) with SMTP; Sat, 31 Jul 2004 11:23:16 PDT Received: from inner-relay-1.corp.adobe.com (inner-relay-1 [153.32.1.51]) by smtp-relay-7.sea.adobe.com (8.12.10/8.12.10) with ESMTP id i6VINGag026181 for <ietf-ltans@imc.org>; Sat, 31 Jul 2004 11:23:16 -0700 (PDT) Received: from calsj-dev (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-1.corp.adobe.com (8.12.9/8.12.9) with ESMTP id i6VINFvR000779 for <ietf-ltans@imc.org>; Sat, 31 Jul 2004 11:23:15 -0700 (PDT) Received: from MasinterT40 ([130.248.178.143]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I1Q00436B2RAR@mailsj-v1.corp.adobe.com> for ietf-ltans@imc.org; Sat, 31 Jul 2004 11:23:15 -0700 (PDT) Date: Sat, 31 Jul 2004 11:23:15 -0700 From: Larry Masinter <LMM@acm.org> Subject: RE: Use of "TAA" acronym (was Comments on LTANS documents) In-reply-to: <200407311411.i6VEBXOt009927@host13.websitesource.com> To: ietf-ltans@imc.org Message-id: <0I1Q00437B2RAR@mailsj-v1.corp.adobe.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcR3Bvb1SANLHI6xRFGfcNHtIUS+owAAEVMgAAjd1OA= Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/> List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe> List-ID: <ietf-ltans.imc.org> I think I wasn't clear about my opinion on this subject, so, for what it is worth: (a) I think choices of wording in a document should be left up to the editor; the working group can make suggestions and complain when the meaning is unclear or misleading, but in the end, it is an editorial function. Usually, word choices can't be made alone, there are many different terms in the document, we shouldn't spend a lot of working group time making suggestions about what they should be. (b) THAT SAID, personally, I prefer to avoid acronyms unless they're really necessary. I haven't seen the necessity of having a TAA or an SAS or a TS or whatever, when we can write it out, "Archive Service" and "Notary Service" For that matter, I prefer to try to use neutral terms "Archive Service", and then note that it would be good if the Archive Service were trusted, than to add the description to the label and then later on try to provide procedures for deciding whether the Archive Service we're talking to can be (or can't be) trusted. Larry -- http://larry.masinter.net Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6VIF8gc085154; Sat, 31 Jul 2004 11:15:08 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6VIF8t1085153; Sat, 31 Jul 2004 11:15:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from psmtp.com (exprod6ob4.obsmtp.com [12.158.35.214]) by above.proper.com (8.12.11/8.12.9) with SMTP id i6VIF805085147 for <ietf-ltans@imc.org>; Sat, 31 Jul 2004 11:15:08 -0700 (PDT) (envelope-from LMM@acm.org) Received: from source ([192.150.22.7]) by exprod6ob4.obsmtp.com ([12.158.35.250]) with SMTP; Sat, 31 Jul 2004 11:15:11 PDT Received: from inner-relay-3.corp.adobe.com (inner-relay-3 [153.32.251.51]) by smtp-relay-7.sea.adobe.com (8.12.10/8.12.10) with ESMTP id i6VIFBag026101 for <ietf-ltans@imc.org>; Sat, 31 Jul 2004 11:15:11 -0700 (PDT) Received: from calsj-dev (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-3.corp.adobe.com (8.12.9/8.12.9) with ESMTP id i6VIFBkq011304 for <ietf-ltans@imc.org>; Sat, 31 Jul 2004 11:15:11 -0700 (PDT) Received: from MasinterT40 ([130.248.178.143]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I1Q004NCAPAAR@mailsj-v1.corp.adobe.com> for ietf-ltans@imc.org; Sat, 31 Jul 2004 11:15:11 -0700 (PDT) Date: Sat, 31 Jul 2004 11:15:10 -0700 From: Larry Masinter <LMM@acm.org> Subject: RE: Use of RFC 2119 terms in requirements docs (was RE: Comments on LTANS documents) In-reply-to: <410B5B1B.6D77EE25@ix.netcom.com> To: "'IETF LTANS'" <ietf-ltans@imc.org> Message-id: <0I1Q004NDAPAAR@mailsj-v1.corp.adobe.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcR2yxefraTc4smiSJ2MJmbt4s+kEgAXBBwg Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/> List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe> List-ID: <ietf-ltans.imc.org> (assuming everyone is on the ltans mailing list and doesn't want to get two copies) Jeff, I can't tell, from your message, whether you are in favor or opposed to the use of RFC 2119 keywords in our document. In the case of these particular documents, I wonder a little about their positioning. It would seem that the business of the IETF isn't so much to define the functional characteristics of a long-term archive or a notary service 'must be', but rather to define an Internet protocol for accessing such services. >From that point of view, it's important to define what a long-term archive service does, what it's important characteristics are, and to define what a notary service might do, so that we can then define a standard protocol for accessing those services. But there's no point in defining what an archive service MUST do, except where it comes to its network interface. We can hardly mandate, oh, putting the service in a physically secure location, at least in the IETF. Perhaps if you're intending to purchase an archive service and writing an RFP, you'd want to use these kinds of terms, because you'll be judging compliance of your purchase against this. The charter says: # The objective of the LTANS working group is to define requirements, data # structures and protocols for the secure usage of the necessary archive # and notary services. and let me emphasize "THE SECURE USAGE OF". Some of the 'requirements' in these documents seem to be requirements on the services themselves, and not on the protocol for accessing them. For example, just to take the first MUST in draft-ietf-ltans-notareqs-00.txt # The notary service has to record private transactions, e.g. # transactions of ownership. Additionally to the recording it MUST # be able to guarantee and provide documentation that all necessary # information has been provided to all involved parties. This 'MUST' is not a protocol requirement. In many circumstances, it's not even something that is possible to evaluate. I don't think we will be in the business of judging the mechanisms by which operations that function as a 'notary service' have realistic means of guaranteeing what they say they guarantee. If there's a protocol requirement, it's that the protocol needs some way of COMMUNICATING the notary service's statement of guarantee. A guarantee is never a 100% guarantee anyway, there are usually conditions and circumstances. Should the protocol allow for those, or are they communicated out of band? I think that's the design question before us. On the other hand, to pick another (not upper case) 'must' from draft-ietf-ltans-reqs-01.txt, # Submitters must be able to specify an archivation period. It's not clear that this is a reasonable requirement to be 'MUST', since it doesn't say what are reasonable ranges, or whether a service must support all ranges, or is free to ignore the archivation period. Is it possible to have a long term archive service which doesn't support deletion, for which all records are kept 'forever'? Larry -- http://larry.masinter.net Larry -- http://larry.masinter.net > -----Original Message----- > From: Jeff Williams [mailto:jwkckid1@ix.netcom.com] > Sent: Saturday, July 31, 2004 1:41 AM > To: Larry Masinter > Cc: 'Denis Pinkas'; 'IETF LTANS'; Harald@alvestrand.no > Subject: Re: Use of RFC 2119 terms in requirements docs (was > RE: Comments on LTANS documents) > > Larry and all, > > The use of certain terms and what the really mean as opposed to what > they are considered amongst IETF/IAB self selected "Officials" is > often times jux opposed as indicated in RFC 2119 as you rightly > point out indirectly. Yet these debates/discussions have also been > previously discussed hotly debated over two years ago on the > "poised" IEFT forum by a number of active participant, including > myself. > > Larry Masinter wrote: > > > Denis Pinkas wrote: > > > > # 1. Since the document is a requirements document, it should use a > > # terminology in accordance with RFC 2119 and use the > following key words: > > # "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD > > # NOT", "RECOMMENDED", "MAY", and "OPTIONAL". > > > > There's been considerable discussion in the 'newtrk' group > > about the use of RFC 2119 terms for requirements documents. > > See http://darkwing.uoregon.edu/~llynch/newtrk/msg00322.html > > and the following discussion. > > > > Personally, I'm uncomfortable with the use of 2119 in requirements > > documents, and have worked to avoid it in more recent requirements > > documents I've worked on. It doesn't make the document > > clearer, and the choices are usually fairly arbitrary. > > > > Larry > > -- > > http://larry.masinter.net > > Regards, > > -- > Jeffrey A. Williams > Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) > "Be precise in the use of words and expect precision from others" - > Pierre Abelard > > "If the probability be called P; the injury, L; and the burden, B; > liability depends upon whether B is less than L multiplied by > P: i.e., whether B is less than PL." > United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] > =============================================================== > Updated 1/26/04 > CSO/DIR. Internet Network Eng. SR. Eng. Network data security > IDNS. div. of Information Network Eng. INEG. INC. > E-Mail jwkckid1@ix.netcom.com > Registered Email addr with the USPS > Contact Number: 214-244-4827 > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6VEBXEC071610; Sat, 31 Jul 2004 07:11:33 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6VEBXJW071609; Sat, 31 Jul 2004 07:11:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6VEBXmd071603 for <ietf-ltans@imc.org>; Sat, 31 Jul 2004 07:11:33 -0700 (PDT) (envelope-from cwallace@orionsec.com) Received: from wcwallace (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i6VEBXOt009927; Sat, 31 Jul 2004 10:11:33 -0400 Message-Id: <200407311411.i6VEBXOt009927@host13.websitesource.com> From: "Carl Wallace" <cwallace@orionsec.com> To: "'Peter Sylvester'" <Peter.Sylvester@edelweb.fr>, <ietf-ltans@imc.org>, <chokhani@orionsec.com> Subject: RE: Use of "TAA" acronym (was Comments on LTANS documents) Date: Sat, 31 Jul 2004 10:11:33 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcR3Bvb1SANLHI6xRFGfcNHtIUS+owAAEVMg In-Reply-To: <200407311351.i6VDpZK22127@chandon.edelweb.fr> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/> List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe> List-ID: <ietf-ltans.imc.org> I prefer your Secure Archive Service suggestion. Maybe TAA or TAS could represent a specific type of SAS that provides trusted key material. This would give terms that somewhat mirror the types of trust we have discussed investing in these services: - trusted time source = TSA - trusted key material source = TAA - secure preservation = SAS > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Peter Sylvester > Sent: Saturday, July 31, 2004 9:52 AM > To: ietf-ltans@imc.org; chokhani@orionsec.com > Subject: RE: Use of "TAA" acronym (was Comments on LTANS documents) > > > > I hope we do not remove the "T" or "A" since "TA" is Trust > Anchor" and "AA" > > is "Attribute Authority" > > > > Waht about replacing Authority with Service. > > Trust(ed/worthy) Archive Service = TAS , in French = heap. > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6VDpbRP070252; Sat, 31 Jul 2004 06:51:37 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6VDpbLU070250; Sat, 31 Jul 2004 06:51:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6VDpZ0x070243 for <ietf-ltans@imc.org>; Sat, 31 Jul 2004 06:51:36 -0700 (PDT) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i6VDpZN02463; Sat, 31 Jul 2004 15:51:35 +0200 (MEST) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Sat, 31 Jul 2004 15:51:35 +0200 (MET DST) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i6VDpZK22127; Sat, 31 Jul 2004 15:51:35 +0200 (MEST) Date: Sat, 31 Jul 2004 15:51:35 +0200 (MEST) From: Peter Sylvester <Peter.Sylvester@edelweb.fr> Message-Id: <200407311351.i6VDpZK22127@chandon.edelweb.fr> To: ietf-ltans@imc.org, chokhani@orionsec.com Subject: RE: Use of "TAA" acronym (was Comments on LTANS documents) X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/> List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe> List-ID: <ietf-ltans.imc.org> > I hope we do not remove the "T" or "A" since "TA" is Trust Anchor" and "AA" > is "Attribute Authority" > Waht about replacing Authority with Service. Trust(ed/worthy) Archive Service = TAS , in French = heap. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6VCJd3c063025; Sat, 31 Jul 2004 05:19:39 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6VCJdn7063022; Sat, 31 Jul 2004 05:19:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6VCJcWJ062948 for <ietf-ltans@imc.org>; Sat, 31 Jul 2004 05:19:39 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (pcp09271907pcs.arlngt01.va.comcast.net [69.143.130.247]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i6VCJbOt017812 for <ietf-ltans@imc.org>; Sat, 31 Jul 2004 08:19:37 -0400 From: "Santosh Chokhani" <chokhani@orionsec.com> To: "'IETF LTANS'" <ietf-ltans@imc.org> Subject: RE: Use of "TAA" acronym (was Comments on LTANS documents) Date: Sat, 31 Jul 2004 08:19:32 -0400 Message-ID: <00cd01c476f8$a615ccb0$aa02a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <0I1P005IGCIXN9@mailsj-v1.corp.adobe.com> Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6VCJdWJ063016 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/> List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe> List-ID: <ietf-ltans.imc.org> Larry: I agree with you. I hope we do not remove the "T" or "A" since "TA" is Trust Anchor" and "AA" is "Attribute Authority" -----Original Message----- From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Larry Masinter Sent: Saturday, July 31, 2004 1:57 AM To: 'Denis Pinkas'; 'IETF LTANS' Subject: Use of "TAA" acronym (was Comments on LTANS documents) (I thought these topics might deserve separate threads, so I am sending separate emails with different subject lines.) > 2. The document is using the word TAA. the T is for "Trusted". As soon > as > this word "trust" is being used, then it is necessary to say *WHO trusts > SOMEBODY for WHAT*. The acronym "TAA" should not be used, "Arch-A" could be > used instead, since AA already means Attribute Authority. The current definition is quite short, it says: Trusted Archive Authority (TAA): A service that is responsible for preserving data for long periods. I think the 'trust' here is that the service does what it is responsible for: it preserves data for long periods. It doesn't lose the data, and doesn't allow the data to change accidentally or maliciously. As for WHO is doing the trusting, well: everyone. In fact, you might argue that 'authority' might be redundtant with 'trusted by everyone', at least for the data that the authority is an authority for. If you're going to insist on precision about trust, you need *WHO trusts WHOM for WHAT, WHEN*; i.e., you also need the element of time. What makes a 'TAA' unusual is that the requirement for trustworthiness lasts for long periods, as well. Larry -- http://larry.masinter.net Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6VAhQcD051460; Sat, 31 Jul 2004 03:43:26 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6VAhQNX051459; Sat, 31 Jul 2004 03:43:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6VAhPue051443 for <ietf-ltans@imc.org>; Sat, 31 Jul 2004 03:43:26 -0700 (PDT) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i6VAhON00665; Sat, 31 Jul 2004 12:43:24 +0200 (MEST) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Sat, 31 Jul 2004 12:43:24 +0200 (MET DST) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i6VAhNv21837; Sat, 31 Jul 2004 12:43:23 +0200 (MEST) Date: Sat, 31 Jul 2004 12:43:23 +0200 (MEST) From: Peter Sylvester <Peter.Sylvester@edelweb.fr> Message-Id: <200407311043.i6VAhNv21837@chandon.edelweb.fr> To: ietf-ltans@imc.org, ErnstG.Giessmann@t-systems.com Subject: Roles and actors was: Comments on LTANS documents X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/> List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe> List-ID: <ietf-ltans.imc.org> Thanks for the comments. Very useful. I think we need to clarify some of the possible roles and actors or mention some important use cases. I had started a reply some time ago, so I am a little bit out of sync with the additional remarks from Larry and Jeff. > > >>As far as the WHO is concerned, there are: > >> > >> 1) the person or the application who did the deposit, > >> > >> 2) the persons or the applications allowed to retrieve the data > >> (not necessarily the same as 1)) > >> > >> 3) the persons or the applications wishing to make sure that > >> some data originates from a given Archiving Unit (Arch-Unit) > >> under the responsibility of a given Archiving Authority > >> (Arch-A) and has been stored by it at a given point of time. > > > > > > Could you write this a little bit simpler for me, I am not sure > > whether I understand the second line of point 3. Is this a relying party > > which 1) has to convince that some required archiving had been done? > > The players are similiar to the players in the signature game: > 1 someone signs a document > 2 someone receives the signed document > 3 someone validates the signature of the document > > Answering your question: > No, the relying party must not necessarily convinced by 1, and it may be > not sufficient to convince 3 that the archiving was done. > The target may be the fact of archiving but also the content archived or > the time of archiving. To me the situation is a little more complex as with a signed document since you have data, an attestation from an archiver, and the possiblities or need to verify some data against the attestation, or to retrieve them. > > I think there is some overlap with the existing players mentioned > > as Arbitrator, Submitter, Retriever, Originator. And there may be > > others, judge, software provider, operator, configurator, system maintainer, ... > > I guess that the three roles Denis mentioned are a good starting point. > Do you think that there are other important roles? The reqs already list different roles. To what degree does a very detailed list of roles/actors matter to definition of the service? At least, it is good for the common understanding of the problem space. A rough idea of the service: Someone submits and eventually(=after a short time) gets some attestation that convinces (not only the submitter) that some data have been stored and can be retrieved, and that destruction will be difficult and not undetected, except in nuc war where we don't really care at all anymore about our little security problems anyway. Peter Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6VATtHm047015; Sat, 31 Jul 2004 03:29:55 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6VATtUN047014; Sat, 31 Jul 2004 03:29:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6VATrbL046962 for <ietf-ltans@imc.org>; Sat, 31 Jul 2004 03:29:54 -0700 (PDT) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i6VATiN00552; Sat, 31 Jul 2004 12:29:44 +0200 (MEST) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Sat, 31 Jul 2004 12:29:44 +0200 (MET DST) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i6VATgH21805; Sat, 31 Jul 2004 12:29:42 +0200 (MEST) Date: Sat, 31 Jul 2004 12:29:42 +0200 (MEST) From: Peter Sylvester <Peter.Sylvester@edelweb.fr> Message-Id: <200407311029.i6VATgH21805@chandon.edelweb.fr> To: Denis.Pinkas@bull.net, ietf-ltans@imc.org, LMM@acm.org Subject: Re: Use of "TAA" acronym (was Comments on LTANS documents) X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/> List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe> List-ID: <ietf-ltans.imc.org> I had already prepared some text concerning this point, it is a little out of sync with jeff and larry's comment, but anyway: > >>As far as the WHAT is concerned, each of the previous players is trusting > >>the Arch-A for a different purpose which should be detailed. > > > > > > I think that all players want that the archival service stores the data > > correctly and can make it available to whoever is authorized, or do I > > miss something? Trust is always a problematic word. > > The word "correctly" is problematic as well. S oit is necessary to have > a defined unambigous set of rules, conditions that the verification > gives always the some result. Agreed. But where is the relationship to 'TRUST' ? Everybody trusts the archive service or/and a notary to provide a service that follows a defined set of conditions. the submitter trusts that the data will be stored and can be retrieved, a retriever that the data retrieved are the one stored by someone, i.e., the same. this does not mean that all players always and all the time have the same level of trust vis-a-vis the service provider. Or, one somehow has to compensate for the potential degradation in time by some techniques that the service can use to demonstrate his inability to create false positives, to deny having archived something, and to use auditing to 'control' the service, combine with redundancy not operated by the same people etc. We could name these beasts SAS "Secure Archive Service" . Peter Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6V71npO082809; Sat, 31 Jul 2004 00:01:49 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6V71n90082808; Sat, 31 Jul 2004 00:01:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from barry.mail.mindspring.net (barry.mail.mindspring.net [207.69.200.25]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6V71m2j082799 for <ietf-ltans@imc.org>; Sat, 31 Jul 2004 00:01:48 -0700 (PDT) (envelope-from jwkckid1@ix.netcom.com) Received: from 1cust17.tnt36.dfw9.da.uu.net ([67.234.81.17] helo=ix.netcom.com) by barry.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1Bqnrn-0008W3-00; Sat, 31 Jul 2004 03:01:15 -0400 Message-ID: <410B5CEF.FA4E5D56@ix.netcom.com> Date: Sat, 31 Jul 2004 01:48:48 -0700 From: Jeff Williams <jwkckid1@ix.netcom.com> Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Larry Masinter <LMM@acm.org> CC: "'Denis Pinkas'" <Denis.Pinkas@bull.net>, "'IETF LTANS'" <ietf-ltans@imc.org> Subject: Re: Use of "TAA" acronym (was Comments on LTANS documents) References: <0I1P005IGCIXN9@mailsj-v1.corp.adobe.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/> List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe> List-ID: <ietf-ltans.imc.org> Larry and all, Again a very good point brought out yet again as trust or whom, when for what as it accurately equates to "TAA" is well yet again discussed here. More and more such "Trust" is given to entities that are not broadly trusted or who's personnel are not trusted for some things as they are not adequately broadly trusted for a specific area or responsibility, and/or again "Selected" by less than well known other individuals for such levels or areas of trust. Larry Masinter wrote: > (I thought these topics might deserve separate threads, so > I am sending separate emails with different subject lines.) > > > 2. The document is using the word TAA. the T is for "Trusted". As soon as > > this word "trust" is being used, then it is necessary to say *WHO trusts > > SOMEBODY for WHAT*. The acronym "TAA" should not be used, "Arch-A" could > be > > used instead, since AA already means Attribute Authority. > > The current definition is quite short, it says: > > Trusted Archive Authority (TAA): A service that is responsible for > preserving data for long periods. > > I think the 'trust' here is that the service does what it is responsible > for: it preserves data for long periods. It doesn't lose the data, and > doesn't allow the data to change accidentally or maliciously. > > As for WHO is doing the trusting, well: everyone. In fact, you might > argue that 'authority' might be redundtant with 'trusted by everyone', > at least for the data that the authority is an authority for. > > If you're going to insist on precision about trust, you need > *WHO trusts WHOM for WHAT, WHEN*; i.e., you also need the element > of time. What makes a 'TAA' unusual is that the requirement > for trustworthiness lasts for long periods, as well. > > Larry > -- > http://larry.masinter.net Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1@ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6V6s3p3080399; Fri, 30 Jul 2004 23:54:03 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6V6s3EI080398; Fri, 30 Jul 2004 23:54:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from barry.mail.mindspring.net (barry.mail.mindspring.net [207.69.200.25]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6V6s2g1080383 for <ietf-ltans@imc.org>; Fri, 30 Jul 2004 23:54:02 -0700 (PDT) (envelope-from jwkckid1@ix.netcom.com) Received: from 1cust17.tnt36.dfw9.da.uu.net ([67.234.81.17] helo=ix.netcom.com) by barry.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1BqnkG-0006IN-00; Sat, 31 Jul 2004 02:53:29 -0400 Message-ID: <410B5B1B.6D77EE25@ix.netcom.com> Date: Sat, 31 Jul 2004 01:41:01 -0700 From: Jeff Williams <jwkckid1@ix.netcom.com> Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Larry Masinter <LMM@acm.org> CC: "'Denis Pinkas'" <Denis.Pinkas@bull.net>, "'IETF LTANS'" <ietf-ltans@imc.org>, "Harald@alvestrand.no" <Harald@alvestrand.no> Subject: Re: Use of RFC 2119 terms in requirements docs (was RE: Comments on LTANS documents) References: <0I1P00J1KC6FQJ@mailsj-v1.corp.adobe.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/> List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe> List-ID: <ietf-ltans.imc.org> Larry and all, The use of certain terms and what the really mean as opposed to what they are considered amongst IETF/IAB self selected "Officials" is often times jux opposed as indicated in RFC 2119 as you rightly point out indirectly. Yet these debates/discussions have also been previously discussed hotly debated over two years ago on the "poised" IEFT forum by a number of active participant, including myself. Larry Masinter wrote: > Denis Pinkas wrote: > > # 1. Since the document is a requirements document, it should use a > # terminology in accordance with RFC 2119 and use the following key words: > # "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD > # NOT", "RECOMMENDED", "MAY", and "OPTIONAL". > > There's been considerable discussion in the 'newtrk' group > about the use of RFC 2119 terms for requirements documents. > See http://darkwing.uoregon.edu/~llynch/newtrk/msg00322.html > and the following discussion. > > Personally, I'm uncomfortable with the use of 2119 in requirements > documents, and have worked to avoid it in more recent requirements > documents I've worked on. It doesn't make the document > clearer, and the choices are usually fairly arbitrary. > > Larry > -- > http://larry.masinter.net Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1@ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6V5vhB7059983; Fri, 30 Jul 2004 22:57:43 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6V5vhK0059982; Fri, 30 Jul 2004 22:57:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from psmtp.com (exprod6ob2.obsmtp.com [12.158.35.212]) by above.proper.com (8.12.11/8.12.9) with SMTP id i6V5vggF059970 for <ietf-ltans@imc.org>; Fri, 30 Jul 2004 22:57:43 -0700 (PDT) (envelope-from LMM@acm.org) Received: from source ([192.150.22.8]) by exprod6ob2.obsmtp.com ([12.158.35.250]) with SMTP; Fri, 30 Jul 2004 22:57:19 PDT Received: from inner-relay-1.corp.adobe.com (inner-relay-1 [153.32.1.51]) by smtp-relay-8.adobe.com (8.12.10/8.12.10) with ESMTP id i6V5uwJI014240; Fri, 30 Jul 2004 22:57:03 -0700 (PDT) Received: from calsj-dev (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-1.corp.adobe.com (8.12.9/8.12.9) with ESMTP id i6V5uwvR002004; Fri, 30 Jul 2004 22:56:58 -0700 (PDT) Received: from MasinterT40 ([130.248.178.143]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I1P005IFCIXN9@mailsj-v1.corp.adobe.com>; Fri, 30 Jul 2004 22:56:58 -0700 (PDT) Date: Fri, 30 Jul 2004 22:56:56 -0700 From: Larry Masinter <LMM@acm.org> Subject: Use of "TAA" acronym (was Comments on LTANS documents) In-reply-to: <40FCCB23.9060709@bull.net> To: "'Denis Pinkas'" <Denis.Pinkas@bull.net>, "'IETF LTANS'" <ietf-ltans@imc.org> Message-id: <0I1P005IGCIXN9@mailsj-v1.corp.adobe.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcRuLpm7p2bg9xXJRAyZ5aW88bRBOgIk5hEA Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/> List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe> List-ID: <ietf-ltans.imc.org> (I thought these topics might deserve separate threads, so I am sending separate emails with different subject lines.) > 2. The document is using the word TAA. the T is for "Trusted". As soon as > this word "trust" is being used, then it is necessary to say *WHO trusts > SOMEBODY for WHAT*. The acronym "TAA" should not be used, "Arch-A" could be > used instead, since AA already means Attribute Authority. The current definition is quite short, it says: Trusted Archive Authority (TAA): A service that is responsible for preserving data for long periods. I think the 'trust' here is that the service does what it is responsible for: it preserves data for long periods. It doesn't lose the data, and doesn't allow the data to change accidentally or maliciously. As for WHO is doing the trusting, well: everyone. In fact, you might argue that 'authority' might be redundtant with 'trusted by everyone', at least for the data that the authority is an authority for. If you're going to insist on precision about trust, you need *WHO trusts WHOM for WHAT, WHEN*; i.e., you also need the element of time. What makes a 'TAA' unusual is that the requirement for trustworthiness lasts for long periods, as well. Larry -- http://larry.masinter.net Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6V5nrwW056500; Fri, 30 Jul 2004 22:49:53 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6V5nrfk056499; Fri, 30 Jul 2004 22:49:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from psmtp.com (exprod6ob3.obsmtp.com [12.158.35.213]) by above.proper.com (8.12.11/8.12.9) with SMTP id i6V5nr02056491 for <ietf-ltans@imc.org>; Fri, 30 Jul 2004 22:49:53 -0700 (PDT) (envelope-from LMM@acm.org) Received: from source ([192.150.22.7]) by exprod6ob3.obsmtp.com ([12.158.35.250]) with SMTP; Fri, 30 Jul 2004 22:49:29 PDT Received: from inner-relay-1.corp.adobe.com (inner-relay-1 [153.32.1.51]) by smtp-relay-7.sea.adobe.com (8.12.10/8.12.10) with ESMTP id i6V5nSag011578; Fri, 30 Jul 2004 22:49:28 -0700 (PDT) Received: from calsj-dev (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-1.corp.adobe.com (8.12.9/8.12.9) with ESMTP id i6V5nRvR001453; Fri, 30 Jul 2004 22:49:28 -0700 (PDT) Received: from MasinterT40 ([130.248.178.143]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I1P00J1JC6FQJ@mailsj-v1.corp.adobe.com>; Fri, 30 Jul 2004 22:49:27 -0700 (PDT) Date: Fri, 30 Jul 2004 22:49:29 -0700 From: Larry Masinter <LMM@acm.org> Subject: Use of RFC 2119 terms in requirements docs (was RE: Comments on LTANS documents) In-reply-to: <40FCCB23.9060709@bull.net> To: "'Denis Pinkas'" <Denis.Pinkas@bull.net> Cc: "'IETF LTANS'" <ietf-ltans@imc.org> Message-id: <0I1P00J1KC6FQJ@mailsj-v1.corp.adobe.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcRuLpm7p2bg9xXJRAyZ5aW88bRBOgIkzsEw Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/> List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe> List-ID: <ietf-ltans.imc.org> Denis Pinkas wrote: # 1. Since the document is a requirements document, it should use a # terminology in accordance with RFC 2119 and use the following key words: # "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD # NOT", "RECOMMENDED", "MAY", and "OPTIONAL". There's been considerable discussion in the 'newtrk' group about the use of RFC 2119 terms for requirements documents. See http://darkwing.uoregon.edu/~llynch/newtrk/msg00322.html and the following discussion. Personally, I'm uncomfortable with the use of 2119 in requirements documents, and have worked to avoid it in more recent requirements documents I've worked on. It doesn't make the document clearer, and the choices are usually fairly arbitrary. Larry -- http://larry.masinter.net Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6V5Zp2J049089; Fri, 30 Jul 2004 22:35:51 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6V5Zpin049088; Fri, 30 Jul 2004 22:35:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from psmtp.com (exprod6ob1.obsmtp.com [12.158.35.211]) by above.proper.com (8.12.11/8.12.9) with SMTP id i6V5ZnMn049070 for <ietf-ltans@imc.org>; Fri, 30 Jul 2004 22:35:49 -0700 (PDT) (envelope-from LMM@acm.org) Received: from source ([192.150.22.7]) by exprod6ob1.obsmtp.com ([12.158.35.250]) with SMTP; Fri, 30 Jul 2004 22:35:56 PDT Received: from inner-relay-3.corp.adobe.com (inner-relay-3 [153.32.251.51]) by smtp-relay-7.sea.adobe.com (8.12.10/8.12.10) with ESMTP id i6V5Zuag011093; Fri, 30 Jul 2004 22:35:56 -0700 (PDT) Received: from calsj-dev (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-3.corp.adobe.com (8.12.9/8.12.9) with ESMTP id i6V5Zokq016491; Fri, 30 Jul 2004 22:35:56 -0700 (PDT) Received: from MasinterT40 ([130.248.178.143]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I1P00J66BJQQJ@mailsj-v1.corp.adobe.com>; Fri, 30 Jul 2004 22:35:50 -0700 (PDT) Date: Fri, 30 Jul 2004 22:35:48 -0700 From: Larry Masinter <LMM@acm.org> Subject: Scope of notary-requirements (was Comments on LTANS documents) In-reply-to: <002101c46e66$95a2cad0$9a00a8c0@hq.orionsec.com> To: "'Santosh Chokhani'" <chokhani@orionsec.com> Cc: "'IETF LTANS'" <ietf-ltans@imc.org> Message-id: <0I1P00J67BJQQJ@mailsj-v1.corp.adobe.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcRuaOKQ8D9tk1P4SrS4Xh4RzfooRQIVzjgQ Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/> List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe> List-ID: <ietf-ltans.imc.org> Santosh Chokhani wrote: # My primary question on the document is that of the scope. # The document seems to include (possibly imply) human in # the loop as the Notary. # I think the scope of IETF related work should be limited # to Electronic Notary. This also means dealing with electronic # documents only. There are lot of other non-IT related forensics # issues involved with paper. I wonder if IETF should deal with # those issues. I expect all of the discussion about notary services is as a means of motivation, not of scope. Perhaps this isn't clear that the introductory section is just giving a little bit of history about what notaries traditionally have done, and why we're looking for electronic analogs. Larry -- http://larry.masinter.net Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6UDN0xw061444; Fri, 30 Jul 2004 06:23:00 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6UDN0ql061441; Fri, 30 Jul 2004 06:23:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from iscan02.secomtrust.net (iscan01.secomtrust.net [61.114.177.102]) by above.proper.com (8.12.11/8.12.9) with SMTP id i6UDMnB2061408 for <ietf-ltans@imc.org>; Fri, 30 Jul 2004 06:22:49 -0700 (PDT) (envelope-from shimaoka@secom.ne.jp) Received: (qmail 15782 invoked by alias); 30 Jul 2004 13:22:42 -0000 Delivered-To: alias-map-ietf-ltans@imc.org@MAP Received: (qmail 15773 invoked by alias); 30 Jul 2004 13:22:41 -0000 Received: from localhost (HELO mail.secomtrust.net) (127.0.0.1) by localhost with SMTP; 30 Jul 2004 13:22:41 -0000 Received: (qmail 23911 invoked from network); 30 Jul 2004 13:22:41 -0000 Received: from unknown (HELO ?192.168.1.5?) (172.30.253.98) by mail with SMTP; 30 Jul 2004 13:22:41 -0000 Date: Fri, 30 Jul 2004 22:22:48 +0900 From: Masaki SHIMAOKA <shimaoka@secom.ne.jp> To: <ietf-ltans@imc.org>, <pki4ipsec@icsalabs.com>, <ietf-pkix@imc.org>, <ietf-smime@imc.org>, ietf-tls@lists.certicom.com Subject: multi-domain PKI unofficial BoF Cc: mpki@jnsa.org Message-Id: <20040730221340.7157.SHIMAOKA@secom.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.11.02 [ja] Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/> List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe> List-ID: <ietf-ltans.imc.org> All, # Sorry for any cross-postings. I am going to hold a unofficial BoF for Best Current Practice (BCP) of multi-domain PKI in the 60th IETF meeting at San Diego. Date/Time and Room are not decided yet, but it will be held at Aug 4 or 5. If you have interest in this issue, please check your mailing list and board at IETF reception. I will announce additional information there. Purpose of this BoF is to make a consensus of the following: * What is the multi-domain PKI? * What is the problem in multi-domain PKI? * Shall we solve this problem? Summary: There are many PKIs in the actual world, and they have of course different architectures and different policies. So when some PKIs assemble, it will bring some problems. Assembling the PKIs is hard problem because it may require full understanding of not only PKI but LDAP and so on. Therefore, I think that we should show some technical idea about assembling PKIs. My opinion for this theme is described in my following personal I-D: http://www.jnsa.org/mpki/draft-shimaoka-multidomain-pki-04-20040730r1.txt If we make a rough consensus, following this discussion I would like to review my I-D with you. Thanks, shima ----- Masaki SHIMAOKA SECOM Trust.net Tel: +81 422 91 8498 (ext.3635); Mitaka Tel: +81 3 5775 8661 (ext.3485); Harajuku Fax: +81 422 45 0536 e-mail: shimaoka@secom.ne.jp Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SFCmaB006983; Wed, 28 Jul 2004 08:12:48 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6SFCmGe006981; Wed, 28 Jul 2004 08:12:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mail4.telekom.de (mail4.telekom.de [195.243.210.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SFCkkO006920 for <ietf-ltans@imc.org>; Wed, 28 Jul 2004 08:12:47 -0700 (PDT) (envelope-from ErnstG.Giessmann@t-systems.com) Received: from U9JWN.mgb01.telekom.de by mail2.dmz.telekom.de with ESMTP for ietf-ltans@imc.org; Wed, 28 Jul 2004 17:12:30 +0200 Received: from mailgate9.telekom.de by U9JWN.mgb01.telekom.de with ESMTP for ietf-ltans@imc.org; Wed, 28 Jul 2004 17:12:17 +0200 Received: from bach.bln05.telekom.de by mailgate9.telekom.de (8.8.8/1.1.8.2/02Aug95-1122AM) id RAA0000009564; Wed, 28 Jul 2004 17:12:16 +0200 (MET DST) Received: from [172.23.7.12] ([172.23.7.12]) by bach.bln05.telekom.de (8.8.8+Sun/8.8.8) with ESMTP id RAA23735 for <ietf-ltans@imc.org>; Wed, 28 Jul 2004 17:13:25 +0200 (MET DST) Message-Id: <4107C240.5090000@t-systems.com> Date: Wed, 28 Jul 2004 17:12:00 +0200 From: Ernst G Giessmann <ErnstG.Giessmann@t-systems.com> User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-ltans@imc.org Subject: Re: Comments on LTANS documents References: <200407221419.i6MEJHr26100@chandon.edelweb.fr> In-Reply-To: <200407221419.i6MEJHr26100@chandon.edelweb.fr> X-Enigmail-Version: 0.84.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/> List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe> List-ID: <ietf-ltans.imc.org> Dear all, I'm new on the LTANS list too. Some remarks to Peter's reply to Denis (text shortened to save memory) Peter Sylvester wrote: .... >>As far as the WHO is concerned, there are: >> >> 1) the person or the application who did the deposit, >> >> 2) the persons or the applications allowed to retrieve the data >> (not necessarily the same as 1)) >> >> 3) the persons or the applications wishing to make sure that >> some data originates from a given Archiving Unit (Arch-Unit) >> under the responsibility of a given Archiving Authority >> (Arch-A) and has been stored by it at a given point of time. > > > Could you write this a little bit simpler for me, I am not sure > whether I understand the second line of point 3. Is this a relying party > which 1) has to convince that some required archiving had been done? The players are similiar to the players in the signature game: 1 someone signs a document 2 someone receives the signed document 3 someone validates the signature of the document Answering your question: No, the relying party must not necessarily convinced by 1, and it may be not sufficient to convince 3 that the archiving was done. It is a person that proves that some given data was archived under given conditions at a given time. The target may be the fact of archiving but also the content archived or the time of archiving. > I think there is some overlap with the existing players mentioned > as Arbitrator, Submitter, Retriever, Originator. And there may be > others, judge, software provider, operator, configurator, system maintainer, ... I guess that the three roles Denis mentioned are a good starting point. Do you think that there are other important roles? >>As far as the WHAT is concerned, each of the previous players is trusting >>the Arch-A for a different purpose which should be detailed. > > > I think that all players want that the archival service stores the data > correctly and can make it available to whoever is authorized, or do I > miss something? Trust is always a problematic word. The word "correctly" is problematic as well. S oit is necessary to have a defined unambigous set of rules, conditions that the verification gives always the some result. >>11. Retrieving of data should be done using information given in the "proof >>of deposit". > > > 'should' ?? > > One should be able to retrieve for example 'all data > for a particular client' without referencing all the stored items. > And 30 years later, I may only have a vague idea. > > IMO a search protocol allows to retrieve publicaly available > 'acknowledgement', the details of this are outside scope. > The actual retrieval must be done by such a reference. > > The basic archival server is not required to > provide a sophisticated search facility. Agree. We must differentiate between searching and retrieving. But it is important to identify unambigously the point of retrieval, otherwise you may get two different documents from two different sources both claiming that they are the archived documents. > The need of authenticity is IMO the right term here, electronic signature > is at best a means, unfortunately it has no final definition When a definition is finalized? Let us stick for a while at the formats of RFC 3126. > What service does an electronic signature provide? It is a rhetoric question isn't it? An electronic signature produced in accordance with RFC 3126 provides evidence that can be processed to get confidence that some commitment has been explicitly endorsed under a signature policy, at a given time, by a signer under an identifier, e.g., a name or a pseudonym, and optionally a role. >>15. Disclosing or not the archived data to the Arch-Unit is an interesting >>topic. Three cases should be identified: >> 1) the archived data is public data, >> 2) the archived data is private data, and only a hash of it >> is communicated, >> 3) the archived data is private data, and only encrypted data >> is communicated. ... >>In case 3) the user who made the deposit only needs to keep a private key >>corresponding to the public key used to perform the encryption (which is not >>what the second document is saying). > > No, a key to decrypt, e.g. a session key for example. Correct. It may be a private (asymmetric) key as well. >>20. For the intellectual property statements, it should noted that some >>companies have patents about hash-tree applied to Time-Stamping. If somebody >>participating to this working group has or knows some patents along >>hash-tree applied to Time-Stamping, it would be fair that this participant >>informs us of any patent that would be related to the ERS document. This >>point should be raised to all the participants of the WG session at the San >>Diego meeting. > > > I have made a list of potentially relevant patents is available to > stimulate the discussion. > > http://ltans.edelweb.fr/patents.html Thank you. I wish you a sucessfull meeting in San Diego. Regards, Ernst. -- Ernst G Giessmann T-Systems GmbH ITC-Security Goslarer Ufer 35, D-10589 Berlin phone:+49-30-3497-4342 mailto:ErnstG.Giessmann@t-systems.com Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6QG17nO090204; Mon, 26 Jul 2004 09:01:07 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6QG17u0090203; Mon, 26 Jul 2004 09:01:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx01.ixos.de (mucmx01.ixos.de [149.235.31.89]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6QG15TA090129 for <ietf-ltans@imc.org>; Mon, 26 Jul 2004 09:01:06 -0700 (PDT) (envelope-from tobias.gondrom@ixos.de) Received: from MUCXGC1.opentext.net (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.9/8.12.9) with ESMTP id i6QFxX0x015176; Mon, 26 Jul 2004 18:00:56 +0200 (MEST) Content-class: urn:content-classes:message Subject: LTANS: agenda for San Diego Date: Mon, 26 Jul 2004 17:57:06 +0200 Message-ID: <3C1BE8610E44734499EF92FB35F5B07007AEE6@MUCXGC1.opentext.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C47329.346103D9" X-MS-Has-Attach: X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Thread-Topic: LTANS: agenda for San Diego Thread-Index: AcRzKTMy77Y6Hfl8R2+ncm8yAeioKA== X-Priority: 1 Importance: high From: "Tobias Gondrom" <tobias.gondrom@ixos.de> To: <agenda@ietf.org> Cc: <cwallace@orionsec.com>, <ietf-ltans@imc.org> Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/> List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe> List-ID: <ietf-ltans.imc.org> This is a multi-part message in MIME format. ------_=_NextPart_001_01C47329.346103D9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, =20 The agenda for the LTANS meeting in San Diego: =20 Agenda for LTANS meeting: A. Notary Requirements 1. Opening Presentation of Notary Reqs (Tobias) - 15 Min. 2. Further presentations of notary reqs/ideas.... 5 minutes each - 10 = minutes 2.1 from Andreas Schmidt FHG (presented by Tobias) 3. Discussion about proceeding concerning notary services (Carl & = Tobias) - 40 minutes =20 B. long-term archive Protocol: 1. Presentation of protocol draft (Carl) - 15 Min. 2. Discussion (Carl & Tobias) - 30 Min. =20 =20 Regards =20 Tobias Chair of LTANS =20 __________________________________________=20 Tobias Gondrom Senior Software Architect PPMA, Engineering IXOS SOFTWARE AG Technopark 1 Bretonischer Ring 12 85630 Grasbrunn / Munich=20 Phone: +49 (0) 89 4629-1816 Telefax: +49 (0) 89 4629-33-1816 eMail: mailto:tobias.gondrom@ixos.de Internet: http://www.ixos.com/=20 This eMail may contain confidential and/or privileged information. If = you are not the intended recipient or have received this eMail in error, = please notify the sender immediately and destroy this eMail. Any use, = disclosure or distribution of the material in this eMail is strictly = forbidden. Diese eMail enth=E4lt vertrauliche und/oder rechtlich gesch=FCtzte = Informationen. Wenn Sie nicht der richtige Adressat sind oder diese = eMail irrt=FCmlich erhalten haben, informieren Sie bitte sofort den = Absender und vernichten Sie diese eMail. Jegliche Art der Verwendung, = Vervielf=E4ltigung oder Weitergabe ist nicht gestattet. =20 ------_=_NextPart_001_01C47329.346103D9 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" = xmlns=3D"http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3DContent-Type content=3D"text/html; = charset=3Diso-8859-1"> <meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)"> <o:SmartTagType = namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" name=3D"City"/> <o:SmartTagType = namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" name=3D"place"/> <!--[if !mso]> <style> st1\:*{behavior:url(#default#ieooui) } </style> <![endif]--> <style> <!-- /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman";} a:link, span.MsoHyperlink {color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {color:purple; text-decoration:underline;} p {mso-margin-top-alt:auto; margin-right:0in; mso-margin-bottom-alt:auto; margin-left:0in; font-size:12.0pt; font-family:"Times New Roman";} span.EmailStyle17 {mso-style-type:personal-compose; font-family:Arial; color:windowtext;} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.25in 1.0in 1.25in;} div.Section1 {page:Section1;} --> </style> </head> <body lang=3DEN-US link=3Dblue vlink=3Dpurple> <div class=3DSection1> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>Hello,<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>The agenda for the LTANS meeting in <st1:City = w:st=3D"on"><st1:place w:st=3D"on">San = Diego</st1:place></st1:City>:<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>Agenda for LTANS = meeting:<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>A. Notary Requirements<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>1. Opening Presentation of Notary Reqs (Tobias) = – 15 Min.<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>2. Further presentations of notary reqs/ideas…. = 5 minutes each - 10 minutes<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>2.1 from Andreas Schmidt FHG (presented by = Tobias)<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>3. Discussion about proceeding concerning notary = services (Carl & Tobias) - 40 minutes<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>B. long-term archive = Protocol:<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>1. Presentation of protocol draft (Carl) - 15 = Min.<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>2. Discussion (Carl & Tobias) – 30 = Min.<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>Regards<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = Tobias<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Chair of = LTANS<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'><o:p> </o:p></span></font></p> <p><b><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt;font-family:Arial; font-weight:bold'>__________________________________________</span></font= ></b> <br> <b><font size=3D2 color=3Dblack face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial;color:black;font-weight:bold'>Tobias = Gondrom</span></font></b><font size=3D2 color=3Dblack face=3DArial><span = style=3D'font-size:10.0pt;font-family:Arial; color:black'><br> Senior Software Architect<br> PPMA, Engineering<br> </span></font><br> <b><font size=3D2 color=3Dblack face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial;color:black;font-weight:bold'>IXOS SOFTWARE = AG</span></font></b><font size=3D2 color=3Dblack face=3DArial><span = style=3D'font-size:10.0pt;font-family:Arial; color:black'><br> Technopark 1<br> Bretonischer Ring 12<br> 85630 Grasbrunn / <st1:place w:st=3D"on"><st1:City = w:st=3D"on">Munich</st1:City></st1:place></span></font> <br> <font size=3D2 color=3Dblack face=3DArial><span = style=3D'font-size:10.0pt;font-family: Arial;color:black'>Phone: +49 (0) 89 4629-1816<br> Telefax: +49 (0) 89 = 4629-33-1816<br> eMail: </span></font> <font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'><a = href=3D"mailto:tobias.gondrom@ixos.de">mailto:tobias.gondrom@ixos.de</a><= br> <font color=3Dblack><span = style=3D'color:black'>Internet: </span= ></font></span></font><u> </u><u><font size=3D2 color=3Dblue face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial;color:blue'><a = href=3D"http://www.ixos.com/">http://www.ixos.com/</a></span></font></u> <o:p></o:p></p> <p><font size=3D2 color=3Dblack face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial;color:black'>This eMail may contain confidential = and/or privileged information. If you are not the intended recipient or have = received this eMail in error, please notify the sender immediately and destroy = this eMail. Any use, disclosure or distribution of the material in this eMail = is strictly forbidden.</span></font><o:p></o:p></p> <p><font size=3D2 face=3DArial><span lang=3DDE = style=3D'font-size:10.0pt;font-family: Arial'>Diese eMail enth=E4lt vertrauliche und/oder rechtlich = gesch=FCtzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese = eMail irrt=FCmlich erhalten haben, informieren Sie bitte sofort den Absender = und vernichten Sie diese eMail. Jegliche Art der Verwendung, = Vervielf=E4ltigung oder Weitergabe ist nicht gestattet.</span></font><span = lang=3DDE><o:p></o:p></span></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span = lang=3DDE style=3D'font-size:12.0pt'><o:p> </o:p></span></font></p> </div> </body> </html> ------_=_NextPart_001_01C47329.346103D9-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6MG2Ofv028710; Thu, 22 Jul 2004 09:02:24 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6MG2OoI028709; Thu, 22 Jul 2004 09:02:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx02.ixos.de (mucmx02.ixos.de [149.235.31.93]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6MG2MZb028700 for <ietf-ltans@imc.org>; Thu, 22 Jul 2004 09:02:23 -0700 (PDT) (envelope-from tobias.gondrom@ixos.de) Received: from mucxg01.opentext.net (localhost [127.0.0.1]) by mucmx02.ixos.de (8.12.9/8.12.9) with ESMTP id i6MFmeRN022167; Thu, 22 Jul 2004 18:00:30 +0200 (MEST) Content-class: urn:content-classes:message Subject: Agenda for San Diego meeting - proposals for presentations until July 25 - 22:00 ET ? Date: Thu, 22 Jul 2004 17:57:10 +0200 Message-ID: <077097E85A6BD3119E910800062786A90C3A75BD@muc-mail5.ixos.de> MIME-Version: 1.0 X-MS-Has-Attach: Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C47004.8BBFCF00" X-MS-TNEF-Correlator: Thread-Topic: Agenda for San Diego meeting - proposals for presentations until July 25 - 22:00 ET ? Thread-Index: AcRwBJb0nvA6XEDjRGKzMwe4zqFkaQ== X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-Priority: 1 Importance: high From: "Tobias Gondrom" <tobias.gondrom@ixos.de> To: <ietf-ltans@imc.org> Cc: "todd glassey" <todd.glassey@worldnet.att.net> Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/> List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe> List-ID: <ietf-ltans.imc.org> This is a multi-part message in MIME format. ------_=_NextPart_001_01C47004.8BBFCF00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, =20 As Carl and I are setting up the agenda for San Diego please submit your = proposals for presentations until=20 Sunday evening!=20 =20 As we see progress especially with notary services and protocol we = currently plan to focus on these two issues.=20 So if you would like to contribute please submit your proposal with = title, short (max. 3 lines) abstract and estimated duration. =20 Carl and I will go through the proposals and must submit the agenda = until July 26, 12:00 ET. =20 Best regards =20 Tobias Chair of LTANS =20 =20 Ps.: LTANS meeting will be August 5, 13:00-15:00 = (http://www.ietf.org/meetings/agenda_60.txt) =20 =20 __________________________________________=20 Tobias Gondrom Senior Software Architect Engineering IXOS SOFTWARE AG Technopark 1 Bretonischer Ring 12 85630 Grasbrunn / Munich=20 Phone: +49 (0) 89 4629-1816 Telefax: +49 (0) 89 4629-33-1816 eMail: mailto:tobias.gondrom@ixos.de Internet: http://www.ixos.com/=20 This eMail may contain confidential and/or privileged information. If = you are not the intended recipient or have received this eMail in error, = please notify the sender immediately and destroy this eMail. Any use, = disclosure or distribution of the material in this eMail is strictly = forbidden. Diese eMail enth=E4lt vertrauliche und/oder rechtlich gesch=FCtzte = Informationen. Wenn Sie nicht der richtige Adressat sind oder diese = eMail irrt=FCmlich erhalten haben, informieren Sie bitte sofort den = Absender und vernichten Sie diese eMail. Jegliche Art der Verwendung, = Vervielf=E4ltigung oder Weitergabe ist nicht gestattet. =20 ------_=_NextPart_001_01C47004.8BBFCF00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" = xmlns=3D"http://www.w3.org/TR/REC-html40"> <head> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Diso-8859-1"> <meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)"> <o:SmartTagType = namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" name=3D"City"/> <o:SmartTagType = namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" name=3D"place"/> <!--[if !mso]> <style> st1\:*{behavior:url(#default#ieooui) } </style> <![endif]--> <style> <!-- /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman";} a:link, span.MsoHyperlink {color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {color:purple; text-decoration:underline;} p {mso-margin-top-alt:auto; margin-right:0in; mso-margin-bottom-alt:auto; margin-left:0in; font-size:12.0pt; font-family:"Times New Roman";} span.EmailStyle17 {mso-style-type:personal-compose; font-family:Arial; color:windowtext;} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.25in 1.0in 1.25in;} div.Section1 {page:Section1;} --> </style> </head> <body lang=3DEN-US link=3Dblue vlink=3Dpurple> <div class=3DSection1> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>Hello,<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>As Carl and I are setting up the agenda for <st1:City = w:st=3D"on"><st1:place w:st=3D"on">San Diego</st1:place></st1:City> please submit your = proposals for presentations until <o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>Sunday evening! <o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>As we see progress especially with <b><span style=3D'font-weight:bold'>notary services</span></b> and <b><span style=3D'font-weight:bold'>protocol</span></b> we currently plan to = focus on these two issues. <o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>So if you would like to <b><span = style=3D'font-weight:bold'>contribute</span></b> please <b><span style=3D'font-weight:bold'>submit your = proposal</span></b> with title, short (max. 3 lines) abstract and estimated = duration.<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>Carl and I will go through the proposals and must = submit the agenda until July 26, 12:00 ET.<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>Best regards<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = Tobias<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Chair of = LTANS<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>Ps.: LTANS meeting will be August 5, 13:00-15:00=A0 = (<a href=3D"http://www.ietf.org/meetings/agenda_60.txt">http://www.ietf.org/m= eetings/agenda_60.txt</a>)<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'><o:p> </o:p></span></font></p> <p><b><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt;font-family:Arial; font-weight:bold'>__________________________________________</span></font= ></b> <br> <b><font size=3D2 color=3Dblack face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial;color:black;font-weight:bold'>Tobias = Gondrom</span></font></b><font size=3D2 color=3Dblack face=3DArial><span = style=3D'font-size:10.0pt;font-family:Arial; color:black'><br> Senior Software Architect<br> Engineering<br> </span></font><br> <b><font size=3D2 color=3Dblack face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial;color:black;font-weight:bold'>IXOS SOFTWARE = AG</span></font></b><font size=3D2 color=3Dblack face=3DArial><span = style=3D'font-size:10.0pt;font-family:Arial; color:black'><br> Technopark 1<br> Bretonischer Ring 12<br> 85630 Grasbrunn / <st1:place w:st=3D"on"><st1:City = w:st=3D"on">Munich</st1:City></st1:place></span></font> <br> <font size=3D2 color=3Dblack face=3DArial><span = style=3D'font-size:10.0pt;font-family: Arial;color:black'>Phone: +49 (0) 89 4629-1816<br> Telefax: +49 (0) 89 = 4629-33-1816<br> eMail: </span></font> <font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'><a = href=3D"mailto:tobias.gondrom@ixos.de">mailto:tobias.gondrom@ixos.de</a><= br> <font color=3Dblack><span = style=3D'color:black'>Internet: </span= ></font></span></font><u> </u><u><font size=3D2 color=3Dblue face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial;color:blue'><a = href=3D"http://www.ixos.com/">http://www.ixos.com/</a></span></font></u> <o:p></o:p></p> <p><font size=3D2 color=3Dblack face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial;color:black'>This eMail may contain confidential = and/or privileged information. If you are not the intended recipient or have = received this eMail in error, please notify the sender immediately and destroy = this eMail. Any use, disclosure or distribution of the material in this eMail = is strictly forbidden.</span></font><o:p></o:p></p> <p><font size=3D2 face=3DArial><span lang=3DDE = style=3D'font-size:10.0pt;font-family: Arial'>Diese eMail enth=E4lt vertrauliche und/oder rechtlich = gesch=FCtzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese = eMail irrt=FCmlich erhalten haben, informieren Sie bitte sofort den Absender = und vernichten Sie diese eMail. Jegliche Art der Verwendung, = Vervielf=E4ltigung oder Weitergabe ist nicht gestattet.</span></font><span = lang=3DDE><o:p></o:p></span></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span = lang=3DDE style=3D'font-size:12.0pt'><o:p> </o:p></span></font></p> </div> </body> </html> ------_=_NextPart_001_01C47004.8BBFCF00-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6MEK7oP017391; Thu, 22 Jul 2004 07:20:07 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6MEK7Os017390; Thu, 22 Jul 2004 07:20:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6MEK4CR017376 for <ietf-ltans@imc.org>; Thu, 22 Jul 2004 07:20:05 -0700 (PDT) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i6MEJJN07673; Thu, 22 Jul 2004 16:19:19 +0200 (MEST) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Thu, 22 Jul 2004 16:19:19 +0200 (MET DST) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i6MEJHr26100; Thu, 22 Jul 2004 16:19:17 +0200 (MEST) Date: Thu, 22 Jul 2004 16:19:17 +0200 (MEST) From: Peter Sylvester <Peter.Sylvester@edelweb.fr> Message-Id: <200407221419.i6MEJHr26100@chandon.edelweb.fr> To: ietf-ltans@imc.org, Denis.Pinkas@bull.net Subject: Re: Comments on LTANS documents X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/> List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe> List-ID: <ietf-ltans.imc.org> > Comments on LTANS documents > > I have only been recently aware of the existence of the LTANS working group. You are pardonned. Welcome on board. I am not answering on behalf of the authors nor do my comments necessarily reflect the authors' opinions. > While I believe that work should be done along an archive service, the > current documents still do not provide the right presentation of the > problem, nor the right answers. 27 comments follow. I think the participants of this group would like to read your presentation of the problem and your ideas for an answer. Your are probably aware of work that has been done be various people in that area in the IETF and also outside. Some of the work is referenced in the ltans web server, and people are discovering other related work regularily. The contributors on this list spend some time to identify common elements in order to fold out something which is acceptable to some large community, otherwise it would be 'YAS' (yet another standard). Well, then: > Comments on draft-ietf-ltans-requs-01.txt > > 1. Since the document is a requirements document, it should use a > terminology in accordance with RFC 2119 and use the following key words: > "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD > NOT", "RECOMMENDED", "MAY", and "OPTIONAL". At the current state I see the requirements documents as an attempt to get a common understanding of the problem to be solved, there are examples where the right usage of such terms is difficult, at least for non native english people, your point 16 seems to be an example (to me). But there will certainly a next round. > 2. The document is using the word TAA. the T is for "Trusted". As soon as > this word "trust" is being used, then it is necessary to say *WHO trusts > SOMEBODY for WHAT*. The acronym "TAA" should not be used, "Arch-A" could be > used instead, since AA already means Attribute Authority. > > As far as the WHO is concerned, there are: > > 1) the person or the application who did the deposit, > > 2) the persons or the applications allowed to retrieve the data > (not necessarily the same as 1)) > > 3) the persons or the applications wishing to make sure that > some data originates from a given Archiving Unit (Arch-Unit) > under the responsibility of a given Archiving Authority > (Arch-A) and has been stored by it at a given point of time. Could you write this a little bit simpler for me, I am not sure whether I understand the second line of point 3. Is this a relying party which 1) has to convince that some required archiving had been done? You have introduced a term Arch-unit without giving a definition. > The difference between the above "players" should be introduced in the > documents. I think there is some overlap with the existing players mentioned as Arbitrator, Submitter, Retriever, Originator. And there may be others, judge, software provider, operator, configurator, system maintainer, ... > > As far as the WHAT is concerned, each of the previous players is trusting > the Arch-A for a different purpose which should be detailed. I think that all players want that the archival service stores the data correctly and can make it available to whoever is authorized, or do I miss something? Trust is always a problematic word. > 3. When a person or an application makes deposit, it is of primary > importance that it gets back a "proof of deposit" from an Arch-Unit. In case > the deposited data would be lost, then the Arch-A would be responsible from > the loss. I am not sure that we are all thinkinn about the same thing. There is a difference between the technical element of a 'receipt' or 'acknowledge' of an operation, which is meantioned in the req text, and something which can have this receipt as a part, which can be considered by the participating legal entities as sufficiently binding to whatever. Data are submitted, and a receipt is obtained containing at least a reference allowing to obtain the data. All security additions are in outside this but are obviously necessary for various requierments. > Note that AFNOR has done some work to standardize different kinds of proof, > including a "proof of deposit" with a full description of the data structure > of that proof using ASN.1. This work should be published soon as an AFNOR > Experimental Standard. > > The concept of a "proof of deposit" should be introduced in the documents. Feel free to contribute a definition. > 4. The deposit is made for a given archiving time period. This period cannot > be shortened, unless the person who made the deposit signs a document > allowing the Arch-A to do so. In case the person who did the deposit > complains later on, then the Arch-A would be able to demonstrate that the > archiving period has been shortened. > > This concept should be introduced in the documents. Your example is only a special case of operations which are performed in more or less exceptional cases. A client may terminate a contract and ask to transfer all his data to some other provider for example, including a situation as in your comment 15. Whether a period can be shortend or not is not a question of whether a client has signed it, it is a question of whether this is possible at all inside the policy, it depends on the needs of relying parties. Anyway, the archiving service may itself need to archive of all transactions, to have evidence about what had been performed. > 5. The documents states that "a long-term archive service provides material > needed to demonstrate the existence and integrity of data object". This > definition is far from sufficient, since, it is missing two dimensions: > > 1) the fact to demonstrate that the archive was made > *at a given time*, > > 2) the fact to demonstrate that the archived data originates > *from a given Arch-Unit and Arch-A*. How to you link these with the existing text. These dimensions are to me optional and not required in all contexts. > > A better definition is present in section 4.3.1. > 6. A major component which is not sufficiently described is the Archive > Policy (Arch-Pol). The components of an Arch-Pol should be first identified, > before attempting to define any data structure or protocol. Section 4.4.2 > should grow from 3 lines to one or two pages and should be introduced much > earlier in the document. If you have some contributions about what things should be in a policy, please contribute. Reading your comment 3, you probably have that precious knowledge, since their is an protocol containing data structures etc. > 7. One of the several aspects to be developed about the Arch-Pol would be > how to relate the Arch-Pol under which the document is retrieved 30 years > later to the initial Arch-Pol under which the document has be deposited. > > These policies cannot be the same, since, for example Time-Stamping > Authorities used 30 years later could not be known initially. There may be a > chain of Arch-Pol to consider. I am not sure whether we talk about the same idea of the service to be provided. On of the first things to do is to agree on the same understanding of what means policy. I see the Policy under which a document is archived and accessed is mainly a configuration including default rules and parameters for processing, and maybe indications/references to rules, documents describing the policy of required feature. Other wording are: Requirements policy and derived operational policy. If something changes through the lifetime of the archived data, there are several possibilities. Either, the archive provider performs permitted changes to a policy and keeps track of them, and/or initiated a transfer of the re-achived data to itself. > 8. One of the several aspects to be developed about the Arch-Pol would be > the policy for the "automatic" maintenance of archived data. See above. > One obvious possibility is to time-stamp the archived data at the time of > the deposit. One or more time-stamps tokens (TST) may be applied (more than > one time-stamp token is not addressed in the documents). Aren't you commenting the requirements doc here? This sounds more a comment to either the ERS or to the not yet available protocol doc. or some best pracise doc on how to manage and create evidence under the assumption the only existing security meachnism are digital signatures. > > For the maintenance of these TSTs, there are then two options: > > a) apply a new TST before the end of the validity period of the > TSU certificate and then capture the CRL of the CA which has > produced the TSU certificate in order to demonstrate that the > TSU certificate was not revoked at the time the new TST was > applied (this point is not addressed in any of the current > two documents). > > b) rely on the Certificate Policy of the CA which has produced > the TSU certificate, which will impose a specific protection for > the TSU private key (key generation mandatory within a security > module and no key export possible, mandatory zeroization of the > private key at the end of the private key usage period. Once > the TSU certificate has expired, then the private key from the > TSU cannot be compromised anymore, except using brute force > attacks. In practice, the Archiving Unit will need to capture > the revocation status of the TSU certificate (usually a CRL), > once the TSU certificate has expired, in order to demonstrate > that the TSU certificate was not revoked at the end of the > validity period of the TSU certificate (this point is not > addressed in any of the current two documents). Such a discussion sounds premature, it is by no means obvious that relying on time stamping results requires signature validation for example. Anyway: relying on single potential point of failure, i.e. a broken chain doesn't seem to be an elegant approach for long term. redundancy, defense in depth techniques are needed. > > 9. When an archived data is retrieved, with the proof it was archived at a > given time, then the proof that the last TST is still valid has to be > produced. In practice this means (for case a) above) that the *current* CRL > of the last TSU has to be produced (this point is not addressed in any of > the current two documents). Another detail to early. you assume a particular implementation and technology. > 10. As noted "notarization" has many different definitions and this term > should not be used at all. the term 'Notarization' is not used in the doc. there are two occurences of the word 'notary service' refering to other documents to be developed by this working group. And since an appropriate definition will be given the Archiving also has many different definitions, some of them have few things to do of what is intende here. ... the word that I looked for is 'Archive Time Stamp'. > 11. Retrieving of data should be done using information given in the "proof > of deposit". 'should' ?? One should be able to retrieve for example 'all data for a particular client' without referencing all the stored items. And 30 years later, I may only have a vague idea. IMO a search protocol allows to retrieve publicaly available 'acknowledgement', the details of this are outside scope. The actual retrieval must be done by such a reference. The basic archival server is not required to provide a sophisticated search facility. > 12. The document states: "it must be possible to authenticate requests and > responses". This is not the right requirement. A "proof of deposit" response > must be electronically signed. Some requests for shortening the archiving > time period must also be electronically signed. Authentication is not enough. > It would be good if you can distingusih between several things. You are proposing some means that seems to be the one to cover different security needs. See also my remarks 3. The need of authenticity is IMO the right term here, electronic signature is at best a means, unfortunately it has no final definition (collection of time stamps of signed data etc is just one proposed way of adding evidence about authenticity.) We are not talking about digital signatures here. The 'client' can be directly connected without an possible interference, then the ack would not need any security envelope. As soon as the distance and network changes, strong authentication methods may or may not be needed, still a pure technical strong authentication. Question: Do you think that an archive service can operate, let's say on top of http, i.e., the client prepares a request, and gets (in your terms) a 'proof of deposit'? > 13. The documents states that "a long term archive service must be capable > of providing evidence records to support the long-term non repudiation of > data". Non-repudiation of data is not one of the possible variants of a non > repudiation service. Section 4.2 would need to be fully re-written. What does your proposed 'proof of deposit' provide? What service does an electronic signature provide? > > > 14. Transfer from one archive service to another one may only apply for the > same or compatible Archive Policies (Arch-Pol). 'may'? do you mean 'MUST'. > 15. Disclosing or not the archived data to the Arch-Unit is an interesting > topic. Three cases should be identified: > > 1) the archived data is public data, > > 2) the archived data is private data, and only a hash of it > is communicated, > > 3) the archived data is private data, and only encrypted data > is communicated. > > There is a difference between cases 2 and 3: > > In case 2) the user who made the deposit needs to keep the clear text of the > deposited data. Somehow this looks like extended time stamping to me, like the one in RFC 3029? > In case 3) the user who made the deposit only needs to keep a private key > corresponding to the public key used to perform the encryption (which is not > what the second document is saying). No, a key to decrypt, e.g. a session key for example. > > Only case 1) allows to perform self-maintenance of the validity of the > archived data in case a hash function originally used is becoming weak. But > what about the two other cases ? Some contact points should be given when > making the deposit, so that maintenance can be performed with the > cooperation of the person who did the deposit or of the persons allowed to > perform a retrieval. A lot of information needs to be provided to an authentication and authorisation service, customer handling, billing etc. It is useful to consider some of such data as part of metadata either of the data or the transaction, i.e. to have containers in the data structure where such information can be carried in an extensible way. You also need to provide (or not) information about what to do in case of cessation of activity, the weakness of a hash function can simply provoke a declaration: "We will cease out all activities under policies that used a weak hash function". > > 16. The documents states "where groups of data objects are submitted, > non-repudiation proof [of what ?] must still be available for each archived > data separately". This is not a MUST. This MAY be a feature. what mean MAY here? read this as your proposed 'proof of deposit'. The requirement proposes that a client can group together archived elements or elements to be archived and obtain evidence receipts for the group. If I understand your MAY I'd call them structured documents which are always handled together, and the individual parts are not distingusihable by the service, and cannot be obtained individually. > 17. The topic of the third paragraph security considerations section is > quite interesting. There is however no guidance to indicate how to deal with > that problem. Such a guidance should be provided. Do you propose something else than selecting identifications that tend to have some good redundancy or globality characteristics? Note also that authentication methods, customer handling, authorisations are outside of scope as far as I see. > Comments on draft-ietf-ltans-ers-00.txt > > 18. Since the requirements document is far from being stabilized, it is > rather premature to progress this document. See my initial comments. > 19. If an encryption method is supported (section 5.1), it should first be > based on a public key certificate value rather than a public key value, > since public key certificates make easier much easier to find out what/where > is the corresponding private key which shall be used. Why that? See your comment 18. > > > 20. For the intellectual property statements, it should noted that some > companies have patents about hash-tree applied to Time-Stamping. If somebody > participating to this working group has or knows some patents along > hash-tree applied to Time-Stamping, it would be fair that this participant > informs us of any patent that would be related to the ERS document. This > point should be raised to all the participants of the WG session at the San > Diego meeting. I have made a list of potentially relevant patents is available to stimulate the discussion. http://ltans.edelweb.fr/patents.html If some people know the actual status, ... > > Comments on draft-ietf-notareqs-00.txt > > 21. Since the document is a requirements document, it should use a > terminology in accordance with RFC 2119 and use the following key words: > "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD > NOT", "RECOMMENDED", "MAY", and "OPTIONAL". See above. > > > 22. The abstract does not provide yet a good summary of the content (and the > goals) of this document. Note that we are not aiming to define something that electronically does whatever a notary does. We are aiming IMO opinion to provide a system that provides some service that can be operated/used by different 'profession', but the primary goal is to determine some technical behaviour, which can be OMO something like - 'information reduction' to simplify work flows. - 'provide time verifications' - ... > 23. The definition of notary from the terminology section is far too vague. > Proposed definition inspired from section 3.2: > > Notary: An officer whose duties are generally prescribed by the laws of a > country, who attests deeds, agreements and other instruments, in order to > give them authenticity. > > When applied to agreements: a person who issues a document testifying that > all parties involved in the signature of an agreement understood and > received the whole information and consequences of the information being > signed by them; then applies his own signature on the signatures from the > other parties and finally provides the whole result to all the parties and > keeps at least one original. This is a particular way how one particular activity is performed and attested on paper. 'Apply a signature in the signatures' means what on paper? > 24. Technically speaking, it is a scheme where someone applies a > counter-signature, with a specific meaning (i.e. specified in a commitment > type), on already present signatures. This is already covered in RFC 3126. There are many things covered in existing texts. I could say that RFC 3029 already covers all needs for archiving, in a similar way as you could say that RFC 3161 already covers timestamping. > 25. The definition of notary service is not correct as well. Feel free to propose one that seems correct to you. I think I should read some of the patents that talk about electronic notaries. > 26. The definition of seal from the terminology section is not appropriate. > A seal for many people is done using secret key technology. If to be kept, > define it a " Notary seal". Sounds reasonable. > 27. The technical requirements from section 4 are not aligned with the text > from section 3. Ther seems some work to be done. > > Denis Peter Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LJlAXK020676; Wed, 21 Jul 2004 12:47:10 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6LJlAld020675; Wed, 21 Jul 2004 12:47:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LJl9J0020669 for <ietf-ltans@imc.org>; Wed, 21 Jul 2004 12:47:09 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17618; Wed, 21 Jul 2004 15:47:11 -0400 (EDT) Message-Id: <200407211947.PAA17618@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-ltans@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ltans-ers-01.txt Date: Wed, 21 Jul 2004 15:47:11 -0400 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/> List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe> List-ID: <ietf-ltans.imc.org> --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, B. Hunter Filename : draft-ietf-ltans-ers-01.txt Pages : 25 Date : 2004-7-21 In many scenarios, users need to be able to ensure and prove the existence and integrity of data, especially 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, designed for long-term non-repudiation of existence of data, which particularly can be used for conservation of evidence of digitally signed data. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltans-ers-01.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-01.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-01.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: <2004-7-21153232.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltans-ers-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltans-ers-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-21153232.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KNw9Jj004977; Tue, 20 Jul 2004 16:58:09 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6KNw9HR004976; Tue, 20 Jul 2004 16:58:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from PC_hipolito.com (dns.sil.edu.pe [64.76.72.108]) by above.proper.com (8.12.11/8.12.9) with SMTP id i6KNw2DR004963 for <ietf-ltans@imc.org>; Tue, 20 Jul 2004 16:58:08 -0700 (PDT) (envelope-from tobias.gondrom@ixos.de) Date: Tue, 20 Jul 2004 18:58:14 -0500 To: "Ietf-ltans" <ietf-ltans@imc.org> From: "Tobias.gondrom" <tobias.gondrom@ixos.de> Subject: Re: Message-ID: <ehljdwyjtsfrulknqhh@imc.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------dtjnmbvnjegenmbcawpv" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/> List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe> List-ID: <ietf-ltans.imc.org> ----------dtjnmbvnjegenmbcawpv Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit <html><body> >foto3 and MP3<br><br> <br> </body></html> ----------dtjnmbvnjegenmbcawpv Content-Type: application/octet-stream; name="New_MP3_Player.scr" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="New_MP3_Player.scr" ----------dtjnmbvnjegenmbcawpv-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KEXtrr033599; Tue, 20 Jul 2004 07:33:55 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6KEXtjf033598; Tue, 20 Jul 2004 07:33:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KEXsI1033589 for <ietf-ltans@imc.org>; Tue, 20 Jul 2004 07:33:55 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i6KEXswc003249 for <ietf-ltans@imc.org>; Tue, 20 Jul 2004 10:33:54 -0400 From: "Santosh Chokhani" <chokhani@orionsec.com> To: "'IETF LTANS'" <ietf-ltans@imc.org> Subject: RE: Comments on LTANS documents Date: Tue, 20 Jul 2004 10:33:54 -0400 Message-ID: <002101c46e66$95a2cad0$9a00a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <40FCCB23.9060709@bull.net> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6KEXtI1033593 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/> List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe> List-ID: <ietf-ltans.imc.org> I agree with several of Denis's comments with the following exception. The Archive Requirements document is not the appropriate place to describe the mechanisms. Many of the mechanisms Denis is suggesting should be considered for ERS and for the protocol. The protocol spec has not yet been released. Also, note that the February 2003 version of the Protocol Spec had the applicable mechanisms in it. -----Original Message----- From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Denis Pinkas Sent: Tuesday, July 20, 2004 3:35 AM To: IETF LTANS Subject: Comments on LTANS documents Comments on LTANS documents I have only been recently aware of the existence of the LTANS working group. While I believe that work should be done along an archive service, the current documents still do not provide the right presentation of the problem, nor the right answers. 27 comments follow. Comments on draft-ietf-ltans-requs-01.txt 1. Since the document is a requirements document, it should use a terminology in accordance with RFC 2119 and use the following key words: "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL". 2. The document is using the word TAA. the T is for "Trusted". As soon as this word "trust" is being used, then it is necessary to say *WHO trusts SOMEBODY for WHAT*. The acronym "TAA" should not be used, "Arch-A" could be used instead, since AA already means Attribute Authority. As far as the WHO is concerned, there are: 1) the person or the application who did the deposit, 2) the persons or the applications allowed to retrieve the data (not necessarily the same as 1)) 3) the persons or the applications wishing to make sure that some data originates from a given Archiving Unit (Arch-Unit) under the responsibility of a given Archiving Authority (Arch-A) and has been stored by it at a given point of time. The difference between the above "players" should be introduced in the documents. As far as the WHAT is concerned, each of the previous players is trusting the Arch-A for a different purpose which should be detailed. 3. When a person or an application makes deposit, it is of primary importance that it gets back a "proof of deposit" from an Arch-Unit. In case the deposited data would be lost, then the Arch-A would be responsible from the loss. Note that AFNOR has done some work to standardize different kinds of proof, including a "proof of deposit" with a full description of the data structure of that proof using ASN.1. This work should be published soon as an AFNOR Experimental Standard. The concept of a "proof of deposit" should be introduced in the documents. 4. The deposit is made for a given archiving time period. This period cannot be shortened, unless the person who made the deposit signs a document allowing the Arch-A to do so. In case the person who did the deposit complains later on, then the Arch-A would be able to demonstrate that the archiving period has been shortened. This concept should be introduced in the documents. 5. The documents states that " a long-term archive service provides material needed to demonstrate the existence and integrity of data object". This definition is far from sufficient, since, it is missing two dimensions: 1) the fact to demonstrate that the archive was made *at a given time*, 2) the fact to demonstrate that the archived data originates *from a given Arch-Unit and Arch-A*. A better definition is present in section 4.3.1. 6. A major component which is not sufficiently described is the Archive Policy (Arch-Pol). The components of an Arch-Pol should be first identified, before attempting to define any data structure or protocol. Section 4.4.2 should grow from 3 lines to one or two pages and should be introduced much earlier in the document. 7. One of the several aspects to be developed about the Arch-Pol would be how to relate the Arch-Pol under which the document is retrieved 30 years later to the initial Arch-Pol under which the document has be deposited. These policies cannot be the same, since, for example Time-Stamping Authorities used 30 years later could not be known initially. There may be a chain of Arch-Pol to consider. 8. One of the several aspects to be developed about the Arch-Pol would be the policy for the "automatic" maintenance of archived data. One obvious possibility is to time-stamp the archived data at the time of the deposit. One or more time-stamps tokens (TST) may be applied (more than one time-stamp token is not addressed in the documents). For the maintenance of these TSTs, there are then two options: a) apply a new TST before the end of the validity period of the TSU certificate and then capture the CRL of the CA which has produced the TSU certificate in order to demonstrate that the TSU certificate was not revoked at the time the new TST was applied (this point is not addressed in any of the current two documents). b) rely on the Certificate Policy of the CA which has produced the TSU certificate, which will impose a specific protection for the TSU private key (key generation mandatory within a security module and no key export possible, mandatory zeroization of the private key at the end of the private key usage period. Once the TSU certificate has expired, then the private key from the TSU cannot be compromised anymore, except using brute force attacks. In practice, the Archiving Unit will need to capture the revocation status of the TSU certificate (usually a CRL), once the TSU certificate has expired, in order to demonstrate that the TSU certificate was not revoked at the end of the validity period of the TSU certificate (this point is not addressed in any of the current two documents). 9. When an archived data is retrieved, with the proof it was archived at a given time, then the proof that the last TST is still valid has to be produced. In practice this means (for case a) above) that the *current* CRL of the last TSU has to be produced (this point is not addressed in any of the current two documents). 10. As noted "notarization" has many different definitions and this term should not be used at all. 11. Retrieving of data should be done using information given in the "proof of deposit". 12. The document states: "it must be possible to authenticate requests and responses". This is not the right requirement. A "proof of deposit" response must be electronically signed. Some requests for shortening the archiving time period must also be electronically signed. Authentication is not enough. 13. The documents states that "a long term archive service must be capable of providing evidence records to support the long-term non repudiation of data". Non-repudiation of data is not one of the possible variants of a non repudiation service. Section 4.2 would need to be fully re-written. 14. Transfer from one archive service to another one may only apply for the same or compatible Archive Policies (Arch-Pol). 15. Disclosing or not the archived data to the Arch-Unit is an interesting topic. Three cases should be identified: 1) the archived data is public data, 2) the archived data is private data, and only a hash of it is communicated, 3) the archived data is private data, and only encrypted data is communicated. There is a difference between cases 2 and 3: In case 2) the user who made the deposit needs to keep the clear text of the deposited data. In case 3) the user who made the deposit only needs to keep a private key corresponding to the public key used to perform the encryption (which is not what the second document is saying). Only case 1) allows to perform self-maintenance of the validity of the archived data in case a hash function originally used is becoming weak. But what about the two other cases ? Some contact points should be given when making the deposit, so that maintenance can be performed with the cooperation of the person who did the deposit or of the persons allowed to perform a retrieval. 16. The documents states "where groups of data objects are submitted, non-repudiation proof [of what ?] must still be available for each archived data separately". This is not a MUST. This MAY be a feature. 17. The topic of the third paragraph security considerations section is quite interesting. There is however no guidance to indicate how to deal with that problem. Such a guidance should be provided. Comments on draft-ietf-ltans-ers-00.txt 18. Since the requirements document is far from being stabilized, it is rather premature to progress this document. 19. If an encryption method is supported (section 5.1), it should first be based on a public key certificate value rather than a public key value, since public key certificates make easier much easier to find out what/where is the corresponding private key which shall be used. 20. For the intellectual property statements, it should noted that some companies have patents about hash-tree applied to Time-Stamping. If somebody participating to this working group has or knows some patents along hash-tree applied to Time-Stamping, it would be fair that this participant informs us of any patent that would be related to the ERS document. This point should be raised to all the participants of the WG session at the San Diego meeting. Comments on draft-ietf-notareqs-00.txt 21. Since the document is a requirements document, it should use a terminology in accordance with RFC 2119 and use the following key words: "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL". 22. The abstract does not provide yet a good summary of the content (and the goals) of this document. 23. The definition of notary from the terminology section is far too vague. Proposed definition inspired from section 3.2: Notary: An officer whose duties are generally prescribed by the laws of a country, who attests deeds, agreements and other instruments, in order to give them authenticity. When applied to agreements: a person who issues a document testifying that all parties involved in the signature of an agreement understood and received the whole information and consequences of the information being signed by them; then applies his own signature on the signatures from the other parties and finally provides the whole result to all the parties and keeps at least one original. 24. Technically speaking, it is a scheme where someone applies a counter-signature, with a specific meaning (i.e. specified in a commitment type), on already present signatures. This is already covered in RFC 3126. 25. The definition of notary service is not correct as well. 26. The definition of seal from the terminology section is not appropriate. A seal for many people is done using secret key technology. If to be kept, define it a " Notary seal". 27. The technical requirements from section 4 are not aligned with the text from section 3. Denis Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6K7aG00011192; Tue, 20 Jul 2004 00:36:16 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6K7aGSe011191; Tue, 20 Jul 2004 00:36:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6K7aEan011123 for <ietf-ltans@imc.org>; Tue, 20 Jul 2004 00:36:15 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from clbull.frcl.bull.fr (IDENT:root@clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA21824; Tue, 20 Jul 2004 09:46:27 +0200 Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id JAA25234; Tue, 20 Jul 2004 09:35:52 +0200 Message-ID: <40FCCB23.9060709@bull.net> Date: Tue, 20 Jul 2004 09:34:59 +0200 From: Denis Pinkas <Denis.Pinkas@bull.net> Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: IETF LTANS <ietf-ltans@imc.org> Subject: Comments on LTANS documents Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6K7aGan011185 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/> List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe> List-ID: <ietf-ltans.imc.org> Comments on LTANS documents I have only been recently aware of the existence of the LTANS working group. While I believe that work should be done along an archive service, the current documents still do not provide the right presentation of the problem, nor the right answers. 27 comments follow. Comments on draft-ietf-ltans-requs-01.txt 1. Since the document is a requirements document, it should use a terminology in accordance with RFC 2119 and use the following key words: "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL". 2. The document is using the word TAA. the T is for âTrustedâ. As soon as this word âtrustâ is being used, then it is necessary to say *WHO trusts SOMEBODY for WHAT*. The acronym âTAAâ should not be used, âArch-Aâ could be used instead, since AA already means Attribute Authority. As far as the WHO is concerned, there are: 1) the person or the application who did the deposit, 2) the persons or the applications allowed to retrieve the data (not necessarily the same as 1)) 3) the persons or the applications wishing to make sure that some data originates from a given Archiving Unit (Arch-Unit) under the responsibility of a given Archiving Authority (Arch-A) and has been stored by it at a given point of time. The difference between the above âplayersâ should be introduced in the documents. As far as the WHAT is concerned, each of the previous players is trusting the Arch-A for a different purpose which should be detailed. 3. When a person or an application makes deposit, it is of primary importance that it gets back a âproof of depositâ from an Arch-Unit. In case the deposited data would be lost, then the Arch-A would be responsible from the loss. Note that AFNOR has done some work to standardize different kinds of proof, including a âproof of depositâ with a full description of the data structure of that proof using ASN.1. This work should be published soon as an AFNOR Experimental Standard. The concept of a âproof of depositâ should be introduced in the documents. 4. The deposit is made for a given archiving time period. This period cannot be shortened, unless the person who made the deposit signs a document allowing the Arch-A to do so. In case the person who did the deposit complains later on, then the Arch-A would be able to demonstrate that the archiving period has been shortened. This concept should be introduced in the documents. 5. The documents states that â a long-term archive service provides material needed to demonstrate the existence and integrity of data objectâ. This definition is far from sufficient, since, it is missing two dimensions: 1) the fact to demonstrate that the archive was made *at a given time*, 2) the fact to demonstrate that the archived data originates *from a given Arch-Unit and Arch-A*. A better definition is present in section 4.3.1. 6. A major component which is not sufficiently described is the Archive Policy (Arch-Pol). The components of an Arch-Pol should be first identified, before attempting to define any data structure or protocol. Section 4.4.2 should grow from 3 lines to one or two pages and should be introduced much earlier in the document. 7. One of the several aspects to be developed about the Arch-Pol would be how to relate the Arch-Pol under which the document is retrieved 30 years later to the initial Arch-Pol under which the document has be deposited. These policies cannot be the same, since, for example Time-Stamping Authorities used 30 years later could not be known initially. There may be a chain of Arch-Pol to consider. 8. One of the several aspects to be developed about the Arch-Pol would be the policy for the âautomaticâ maintenance of archived data. One obvious possibility is to time-stamp the archived data at the time of the deposit. One or more time-stamps tokens (TST) may be applied (more than one time-stamp token is not addressed in the documents). For the maintenance of these TSTs, there are then two options: a) apply a new TST before the end of the validity period of the TSU certificate and then capture the CRL of the CA which has produced the TSU certificate in order to demonstrate that the TSU certificate was not revoked at the time the new TST was applied (this point is not addressed in any of the current two documents). b) rely on the Certificate Policy of the CA which has produced the TSU certificate, which will impose a specific protection for the TSU private key (key generation mandatory within a security module and no key export possible, mandatory zeroization of the private key at the end of the private key usage period. Once the TSU certificate has expired, then the private key from the TSU cannot be compromised anymore, except using brute force attacks. In practice, the Archiving Unit will need to capture the revocation status of the TSU certificate (usually a CRL), once the TSU certificate has expired, in order to demonstrate that the TSU certificate was not revoked at the end of the validity period of the TSU certificate (this point is not addressed in any of the current two documents). 9. When an archived data is retrieved, with the proof it was archived at a given time, then the proof that the last TST is still valid has to be produced. In practice this means (for case a) above) that the *current* CRL of the last TSU has to be produced (this point is not addressed in any of the current two documents). 10. As noted ânotarizationâ has many different definitions and this term should not be used at all. 11. Retrieving of data should be done using information given in the âproof of depositâ. 12. The document states: âit must be possible to authenticate requests and responsesâ. This is not the right requirement. A âproof of depositâ response must be electronically signed. Some requests for shortening the archiving time period must also be electronically signed. Authentication is not enough. 13. The documents states that âa long term archive service must be capable of providing evidence records to support the long-term non repudiation of dataâ. Non-repudiation of data is not one of the possible variants of a non repudiation service. Section 4.2 would need to be fully re-written. 14. Transfer from one archive service to another one may only apply for the same or compatible Archive Policies (Arch-Pol). 15. Disclosing or not the archived data to the Arch-Unit is an interesting topic. Three cases should be identified: 1) the archived data is public data, 2) the archived data is private data, and only a hash of it is communicated, 3) the archived data is private data, and only encrypted data is communicated. There is a difference between cases 2 and 3: In case 2) the user who made the deposit needs to keep the clear text of the deposited data. In case 3) the user who made the deposit only needs to keep a private key corresponding to the public key used to perform the encryption (which is not what the second document is saying). Only case 1) allows to perform self-maintenance of the validity of the archived data in case a hash function originally used is becoming weak. But what about the two other cases ? Some contact points should be given when making the deposit, so that maintenance can be performed with the cooperation of the person who did the deposit or of the persons allowed to perform a retrieval. 16. The documents states âwhere groups of data objects are submitted, non-repudiation proof [of what ?] must still be available for each archived data separatelyâ. This is not a MUST. This MAY be a feature. 17. The topic of the third paragraph security considerations section is quite interesting. There is however no guidance to indicate how to deal with that problem. Such a guidance should be provided. Comments on draft-ietf-ltans-ers-00.txt 18. Since the requirements document is far from being stabilized, it is rather premature to progress this document. 19. If an encryption method is supported (section 5.1), it should first be based on a public key certificate value rather than a public key value, since public key certificates make easier much easier to find out what/where is the corresponding private key which shall be used. 20. For the intellectual property statements, it should noted that some companies have patents about hash-tree applied to Time-Stamping. If somebody participating to this working group has or knows some patents along hash-tree applied to Time-Stamping, it would be fair that this participant informs us of any patent that would be related to the ERS document. This point should be raised to all the participants of the WG session at the San Diego meeting. Comments on draft-ietf-notareqs-00.txt 21. Since the document is a requirements document, it should use a terminology in accordance with RFC 2119 and use the following key words: "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL". 22. The abstract does not provide yet a good summary of the content (and the goals) of this document. 23. The definition of notary from the terminology section is far too vague. Proposed definition inspired from section 3.2: Notary: An officer whose duties are generally prescribed by the laws of a country, who attests deeds, agreements and other instruments, in order to give them authenticity. When applied to agreements: a person who issues a document testifying that all parties involved in the signature of an agreement understood and received the whole information and consequences of the information being signed by them; then applies his own signature on the signatures from the other parties and finally provides the whole result to all the parties and keeps at least one original. 24. Technically speaking, it is a scheme where someone applies a counter-signature, with a specific meaning (i.e. specified in a commitment type), on already present signatures. This is already covered in RFC 3126. 25. The definition of notary service is not correct as well. 26. The definition of seal from the terminology section is not appropriate. A seal for many people is done using secret key technology. If to be kept, define it a â Notary sealâ. 27. The technical requirements from section 4 are not aligned with the text from section 3. Denis Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GKMaH8033992; Fri, 16 Jul 2004 13:22:36 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6GKMaSx033991; Fri, 16 Jul 2004 13:22:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GKMZ0l033984 for <ietf-ltans@imc.org>; Fri, 16 Jul 2004 13:22:36 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00408; Fri, 16 Jul 2004 16:22:38 -0400 (EDT) Message-Id: <200407162022.QAA00408@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-ltans@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ltans-notareqs-00.txt Date: Fri, 16 Jul 2004 16:22:38 -0400 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/> List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe> List-ID: <ietf-ltans.imc.org> --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 : Notary Services requirements Author(s) : T. Gondrom Filename : draft-ietf-ltans-notareqs-00.txt Pages : 12 Date : 2004-7-16 Notary services are available today in a wide variety for paper based processes and documents. To define the needs, requirements and future world for notary services in the elctronic world, this document describes use cases and scenarios as base for further discussion and work of the LTANS WG in this area. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltans-notareqs-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-notareqs-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-notareqs-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: <2004-7-16152810.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltans-notareqs-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltans-notareqs-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-16152810.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GA97n5026132; Fri, 16 Jul 2004 03:09:07 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6GA97q0026131; Fri, 16 Jul 2004 03:09:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from sonne.sit.fraunhofer.de (sonne.sit.fraunhofer.de [141.12.62.20]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GA95gW026032 for <ietf-ltans@imc.org>; Fri, 16 Jul 2004 03:09:06 -0700 (PDT) (envelope-from Andreas.U.Schmidt@sit.fraunhofer.de) Received: from sit.fraunhofer.de (pc-aragorn [141.12.86.73]) by sonne.sit.fraunhofer.de (8.8.8/8.8.5) with ESMTP id MAA09849 for <ietf-ltans@imc.org>; Fri, 16 Jul 2004 12:08:52 +0200 (MET DST) Message-ID: <40F7A930.9020100@sit.fraunhofer.de> Date: Fri, 16 Jul 2004 12:08:48 +0200 From: "Andreas U. Schmidt" <Andreas.U.Schmidt@sit.fraunhofer.de> Reply-To: Andreas.U.Schmidt@sit.fraunhofer.de User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us MIME-Version: 1.0 To: ietf-ltans@imc.org Subject: RE: LTANS: first draft of requirements for notary services Content-Type: multipart/alternative; boundary="------------090601020003010802070401" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/> List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe> List-ID: <ietf-ltans.imc.org> This is a multi-part message in MIME format. --------------090601020003010802070401 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Tobias, on behalf of my institution, Fraunhofer SIT, I wouold like to contribute to the Notary Services part of ltans and become an author of the pertinent requirements document. Our institute has taken part in ltans and co-authored the ERS and LTAS requirements IDs. I am leading the starting project TransiDok, funded by the German ministry of economics, on the secure transformation of signed documents. This comprises applications to e-government, public healthcare, and notaries public. We cooperate, amongst others, with the German federal chamber of notaries public. Since the first phase of our project will be a thorough requirements engineering, I would presume that we can contribute considerably to the requirements document for notary services. Regards, AUS -- Dr. Andreas U. Schmidt Fraunhofer-Institut SIT Dolivostr. 15, 64293 Darmstadt, Germany Tel. +49 (0)6151 869 60227, Fax. +49 (0)6151 869 704 e-mail Andreas.U.Schmidt@sit.fraunhofer.de -- Private Homepage http://www.math.uni-frankfurt.de/~aschmidt --------------090601020003010802070401 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1"> <title></title> </head> <body text="#000000" bgcolor="#ffffff"> <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1"> <title></title> <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1"> <title></title> <tt>Tobias,<br> <br> on behalf of my institution</tt><tt>, Fraunhofer SIT,<br> I wouold like to contribute to the Notary <br> Services part of ltans and become an author<br> of the pertinent requirements document.<br> <br> </tt><tt>Our institute has taken part in ltans and <br> co-authored the ERS and LTAS requirements<br> IDs. I am leading the starting project TransiDok,<br> funded by the German<font color="#000000"></font><font color="#000000"> ministry of economics, on<br> the secure transformation of signed documents.<br> This comprises applications to e-government,<br> public healthcare, and notaries public.<br> We cooperate, amongst others, with the German<br> federal chamber of notaries public.<br> <br> Since the first phase of our project will be<br> a thorough requirements engineering, I would <br> presume that we can contribute considerably to <br> the requirements document for notary services.<br> <br> Regards, AUS<br> </font></tt><tt>--<br> Dr. Andreas U. Schmidt<br> Fraunhofer-Institut SIT<br> Dolivostr. 15, 64293 Darmstadt, Germany<br> Tel. +49 (0)6151 869 60227, Fax. +49 (0)6151 869 704<br> </tt><tt>e-mail <a class="moz-txt-link-abbreviated" href="mailto:Andreas.U.Schmidt@sit.fraunhofer.de">Andreas.U.Schmidt@sit.fraunhofer.de</a><br> --<br> Private Homepage <a class="moz-txt-link-freetext" href="http://www.math.uni-frankfurt.de/%7Easchmidt">http://www.math.uni-frankfurt.de/~aschmidt</a></tt> </body> </html> --------------090601020003010802070401-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6F10EBl012954; Wed, 14 Jul 2004 18:00:14 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6F10Dos012953; Wed, 14 Jul 2004 18:00:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6F10DRm012946 for <ietf-ltans@imc.org>; Wed, 14 Jul 2004 18:00:13 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (pcp09271907pcs.arlngt01.va.comcast.net [69.143.130.247]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i6F10IcD012232 for <ietf-ltans@imc.org>; Wed, 14 Jul 2004 21:00:18 -0400 From: "Santosh Chokhani" <chokhani@orionsec.com> To: <ietf-ltans@imc.org> Subject: RE: LTANS: first draft of requirements for notary services Date: Wed, 14 Jul 2004 21:00:13 -0400 Message-ID: <008c01c46a07$189c5370$aa02a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_008D_01C469E5.918AB370" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <077097E85A6BD3119E910800062786A90C3A6928@muc-mail5.ixos.de> Importance: Normal Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/> List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe> List-ID: <ietf-ltans.imc.org> This is a multi-part message in MIME format. ------=_NextPart_000_008D_01C469E5.918AB370 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Tobias: =20 My primary question on the document is that of the scope. The document seems to include (possibly imply) human in the loop as the Notary. =20 I think the scope of IETF related work should be limited to Electronic Notary. This also means dealing with electronic documents only. There = are lot of other non-IT related forensics issues involved with paper. I = wonder if IETF should deal with those issues. -----Original Message----- From: owner-ietf-ltans@mail.imc.org = [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Tobias Gondrom Sent: Tuesday, July 13, 2004 6:54 AM To: ietf-ltans@imc.org Subject: LTANS: first draft of requirements for notary services Importance: High Hello, =20 After a long pause we finished the first draft =93requirements for = notary services=94 and submitted it yesterday around 8:58 a.m. ET to IETF ;-) =20 Attached you find the draft. Please consider it really just as the first draft to start the = discussion of the future work of LTANS after we complete the work on the long-term archiving (ERS, reqs and prot). I just started as the author and would be really happy if a second = author would like to join me, or even if we find another author/editor for this draft to replace me. (following recommendations IETF considering the separation of the chair and editor role) =20 So I hope this first draft is an acceptable base to start the discussion = on what is needed concerning notary services. =20 Best regards =20 Tobias =20 =20 __________________________________________=20 Tobias Gondrom Senior Software Architect PPMA, Engineering IXOS SOFTWARE AG Technopark 1 Bretonischer Ring 12 85630 Grasbrunn / Munich=20 Phone: +49 (0) 89 4629-1816 Telefax: +49 (0) 89 4629-33-1816 eMail: mailto:tobias.gondrom@ixos.de Internet: http://www.ixos.com/=20 This eMail may contain confidential and/or privileged information. If = you are not the intended recipient or have received this eMail in error, = please notify the sender immediately and destroy this eMail. Any use, = disclosure or distribution of the material in this eMail is strictly forbidden. Diese eMail enth=E4lt vertrauliche und/oder rechtlich gesch=FCtzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese = eMail irrt=FCmlich erhalten haben, informieren Sie bitte sofort den Absender = und vernichten Sie diese eMail. Jegliche Art der Verwendung, = Vervielf=E4ltigung oder Weitergabe ist nicht gestattet. =20 ------=_NextPart_000_008D_01C469E5.918AB370 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:o =3D=20 "urn:schemas-microsoft-com:office:office" xmlns:w =3D=20 "urn:schemas-microsoft-com:office:word" xmlns:st1 =3D=20 "urn:schemas-microsoft-com:office:smarttags"><HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Diso-8859-1"> <TITLE>Message</TITLE> <META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR><o:SmartTagType = name=3D"City"=20 namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT= ype><o:SmartTagType=20 name=3D"place"=20 namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT= ype><o:SmartTagType=20 name=3D"PersonName"=20 namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT= ype><!--[if !mso]> <STYLE>st1\:* { BEHAVIOR: url(#default#ieooui) } </STYLE> <![endif]--> <STYLE>@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in = 1.25in; } P.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman" } LI.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman" } DIV.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman" } A:link { COLOR: blue; TEXT-DECORATION: underline } SPAN.MsoHyperlink { COLOR: blue; TEXT-DECORATION: underline } A:visited { COLOR: purple; TEXT-DECORATION: underline } SPAN.MsoHyperlinkFollowed { COLOR: purple; TEXT-DECORATION: underline } P { FONT-SIZE: 12pt; MARGIN-LEFT: 0in; MARGIN-RIGHT: 0in; FONT-FAMILY: = "Times New Roman"; mso-margin-top-alt: auto; mso-margin-bottom-alt: auto } SPAN.EmailStyle17 { COLOR: windowtext; FONT-FAMILY: Arial; mso-style-type: personal-compose } DIV.Section1 { page: Section1 } </STYLE> </HEAD> <BODY lang=3DEN-US vLink=3Dpurple link=3Dblue> <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20 class=3D200135600-15072004>Tobias:</SPAN></FONT></DIV> <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20 class=3D200135600-15072004></SPAN></FONT> </DIV> <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN = class=3D200135600-15072004>My=20 primary question on the document is that of the scope. The = document seems=20 to include (possibly imply) human in the loop as the = Notary.</SPAN></FONT></DIV> <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20 class=3D200135600-15072004></SPAN></FONT> </DIV> <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN = class=3D200135600-15072004>I=20 think the scope of IETF related work should be limited = to Electronic=20 Notary. This also means dealing with electronic documents = only. =20 There are lot of other non-IT related forensics issues involved with=20 paper. I wonder if IETF should deal with those = issues.</SPAN></FONT></DIV> <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px"> <DIV></DIV> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr = align=3Dleft><FONT=20 face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20 owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] = <B>On=20 Behalf Of </B>Tobias Gondrom<BR><B>Sent:</B> Tuesday, July 13, 2004 = 6:54=20 AM<BR><B>To:</B> ietf-ltans@imc.org<BR><B>Subject:</B> LTANS: first = draft of=20 requirements for notary services<BR><B>Importance:</B>=20 High<BR><BR></FONT></DIV> <DIV class=3DSection1> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: = Arial">Hello,<o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: = Arial"><o:p> </o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">After a long pause we = finished the=20 first draft “requirements for notary services” and = submitted it yesterday=20 around 8:58 a.m. ET to IETF ;-)<o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: = Arial"><o:p> </o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Attached you find the=20 draft.<o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Please consider it = really just as=20 the first draft to start the discussion of the future work of LTANS = after we=20 complete the work on the long-term archiving (ERS, reqs and=20 prot).<o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">I just started as the = author and=20 would be really happy if a second author would like to join me, or = even if we=20 find another author/editor for this draft to replace me. (following=20 recommendations IETF considering the separation of the chair and = editor=20 role)<o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: = Arial"><o:p> </o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">So I hope this first = draft is an=20 acceptable base to start the discussion on what is needed concerning = notary=20 services.<o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: = Arial"><o:p> </o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Best=20 regards<o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: = Arial"><o:p> </o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: = Arial"> = =20 Tobias<o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: = Arial"><o:p> </o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: = Arial"><o:p> </o:p></SPAN></FONT></P> <P><B><FONT face=3DArial size=3D2><SPAN=20 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: = Arial">__________________________________________</SPAN></FONT></B>=20 <BR><st1:PersonName=20 style=3D"BACKGROUND-POSITION: left bottom; BACKGROUND-IMAGE: = url(res://ietag.dll/#34/#1001); BACKGROUND-REPEAT: repeat-x"=20 w:st=3D"on"><B><FONT face=3DArial color=3Dblack size=3D2><SPAN=20 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: black; = FONT-FAMILY: Arial">Tobias=20 Gondrom</SPAN></FONT></B></st1:PersonName><FONT face=3DArial = color=3Dblack=20 size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Arial"><BR>Senior = Software=20 Architect<BR>PPMA, Engineering<BR></SPAN></FONT><BR><B><FONT = face=3DArial=20 color=3Dblack size=3D2><SPAN=20 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: black; = FONT-FAMILY: Arial">IXOS=20 SOFTWARE AG</SPAN></FONT></B><FONT face=3DArial color=3Dblack = size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: = Arial"><BR>Technopark=20 1<BR>Bretonischer Ring 12<BR>85630 Grasbrunn / <st1:place = w:st=3D"on"><st1:City=20 w:st=3D"on">Munich</st1:City></st1:place></SPAN></FONT> <BR><FONT = face=3DArial=20 color=3Dblack size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: = Arial">Phone: +49 (0)=20 89 4629-1816<BR>Telefax: +49 = (0) 89=20 4629-33-1816<BR>eMail: </SPAN></FONT> <FONT face=3DArial = size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"><A=20 = href=3D"mailto:tobias.gondrom@ixos.de">mailto:tobias.gondrom@ixos.de</A><= BR><FONT=20 color=3Dblack><SPAN=20 style=3D"COLOR: = black">Internet: </SPAN></FONT></SPAN>= </FONT><U>=20 </U><U><FONT face=3DArial color=3Dblue size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial"><A=20 = href=3D"http://www.ixos.com/">http://www.ixos.com/</A></SPAN></FONT></U> = <o:p></o:p></P> <P><FONT face=3DArial color=3Dblack size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Arial">This eMail = may=20 contain confidential and/or privileged information. If you are not the = intended recipient or have received this eMail in error, please notify = the=20 sender immediately and destroy this eMail. Any use, disclosure or = distribution=20 of the material in this eMail is strictly=20 forbidden.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DDE=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Diese eMail enth=E4lt = vertrauliche=20 und/oder rechtlich gesch=FCtzte Informationen. Wenn Sie nicht der = richtige=20 Adressat sind oder diese eMail irrt=FCmlich erhalten haben, = informieren Sie=20 bitte sofort den Absender und vernichten Sie diese eMail. Jegliche Art = der=20 Verwendung, Vervielf=E4ltigung oder Weitergabe ist nicht=20 gestattet.</SPAN></FONT><SPAN lang=3DDE><o:p></o:p></SPAN></P> <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN = lang=3DDE=20 style=3D"FONT-SIZE: = 12pt"><o:p> </o:p></SPAN></FONT></P></DIV></BLOCKQUOTE></BODY></HTML= > ------=_NextPart_000_008D_01C469E5.918AB370-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EI2Vcn042208; Wed, 14 Jul 2004 11:02:31 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6EI2Vn2042207; Wed, 14 Jul 2004 11:02:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EI2Uqn042191 for <ietf-ltans@imc.org>; Wed, 14 Jul 2004 11:02:31 -0700 (PDT) (envelope-from cwallace@orionsec.com) Received: from wcwallace (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i6EI1kcD027099 for <ietf-ltans@imc.org>; Wed, 14 Jul 2004 14:01:46 -0400 Message-Id: <200407141801.i6EI1kcD027099@host13.websitesource.com> From: "Carl Wallace" <cwallace@orionsec.com> To: <ietf-ltans@imc.org> Subject: LTANS at the 60th IETF Date: Wed, 14 Jul 2004 14:01:46 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0021_01C469AB.19918DB0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcRpzKAnUlDUa1//SV67fS7I610J4g== Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/> List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe> List-ID: <ietf-ltans.imc.org> This is a multi-part message in MIME format. ------=_NextPart_000_0021_01C469AB.19918DB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit All, The LTANS WG will be meeting in San Diego on Thursday August 5th at 13:00. As with previous meetings, if anyone would like to give a briefing during the session please send a note to me and Tobias by the 23rd. We'll post the meeting agenda during the last week of July. Carl ------=_NextPart_000_0021_01C469AB.19918DB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Dus-ascii"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version = 6.5.7036.0"> <TITLE>LTANS at the 60th IETF</TITLE> </HEAD> <BODY> <!-- Converted from text/rtf format --> <P><FONT SIZE=3D2 FACE=3D"Arial">All,</FONT> </P> <P><FONT SIZE=3D2 FACE=3D"Arial">The LTANS WG will be meeting in San = Diego on Thursday August 5th at 13:00. As with previous meetings, = if anyone would like to give a briefing during the session please send a = note to me and Tobias by the 23rd. We'll post the meeting agenda = during the last week of July.</FONT></P> <P><FONT SIZE=3D2 FACE=3D"Arial">Carl</FONT> </P> </BODY> </HTML> ------=_NextPart_000_0021_01C469AB.19918DB0-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EHUTf3036704; Wed, 14 Jul 2004 10:30:29 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6EHUTgI036703; Wed, 14 Jul 2004 10:30:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from smtp-relay-7.sea.adobe.com (smtp-relay-7.adobe.com [192.150.22.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EHUPsx036631 for <ietf-ltans@imc.org>; Wed, 14 Jul 2004 10:30:25 -0700 (PDT) (envelope-from LMM@acm.org) Received: from inner-relay-1.corp.adobe.com (inner-relay-1 [153.32.1.51]) by smtp-relay-7.sea.adobe.com (8.12.10/8.12.10) with ESMTP id i6EHUJBR005663; Wed, 14 Jul 2004 10:30:19 -0700 (PDT) Received: from calsj-dev (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-1.corp.adobe.com (8.12.9/8.12.9) with ESMTP id i6EHUIvR020454; Wed, 14 Jul 2004 10:30:18 -0700 (PDT) Received: from MasinterT40 ([130.248.178.153]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I0U002P2RAIV7@mailsj-v1.corp.adobe.com>; Wed, 14 Jul 2004 10:30:18 -0700 (PDT) Date: Wed, 14 Jul 2004 10:30:18 -0700 From: Larry Masinter <LMM@acm.org> Subject: RE: LTANS: first draft of requirements for notary services In-reply-to: <077097E85A6BD3119E910800062786A90C3A6928@muc-mail5.ixos.de> To: "'Tobias Gondrom'" <tobias.gondrom@ixos.de> Cc: ietf-ltans@imc.org Message-id: <0I0U002P3RAIV7@mailsj-v1.corp.adobe.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcRoxwqQykDxkaVQRwa6/QayTEgY3QBAOctQ Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/> List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe> List-ID: <ietf-ltans.imc.org> I'm willing to help with document editing in the working group, and this document in particular. I'm familiar with the technical concepts, and I have some experience with editing IETF documents. Larry -- http://larry.masinter.net Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DMgMld089122; Tue, 13 Jul 2004 15:42:22 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6DMgMOO089121; Tue, 13 Jul 2004 15:42:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from MessageInpector.nationalnotary.org (mail.nationalnotary.org [65.115.114.141]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DMgMlQ089115 for <ietf-ltans@imc.org>; Tue, 13 Jul 2004 15:42:22 -0700 (PDT) (envelope-from rhansberger@nationalnotary.org) Received: from louise2.nationalnotary.org (LOUISE2 [192.168.1.247]) by MessageInpector.nationalnotary.org (Switch-2.2.8/Switch-2.2.4) with ESMTP id W6DN23XQ00000620 for <ietf-ltans@imc.org>; Tue, 13 Jul 2004 15:39:33 -0800 Received: by Louise2 with Internet Mail Service (5.5.2657.72) id <3VQPSF7M>; Tue, 13 Jul 2004 15:40:18 -0800 Message-ID: <561F9357D239EB428AE3A4F142444313038B80@Louise2> From: Richard Hansberger <rhansberger@nationalnotary.org> To: "'ietf-ltans@imc.org'" <ietf-ltans@imc.org> Subject: RE: LTANS: first draft of requirements for notary services Date: Tue, 13 Jul 2004 15:40:13 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/mixed; boundary="--123456789-987654321-abcdefg" X-MessageInspectorSig: 588c6b20614da430b7d4234b90c30df2 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/> List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe> List-ID: <ietf-ltans.imc.org> ----123456789-987654321-abcdefg Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C46932.BE401AD0" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C46932.BE401AD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Tobias, Thanks for this first draft. I've been lurking on this list for some time and now will offer my assistance and hope I don't overstep any bounds. I will gladly join the effort as a second author or editor. I do not pretend= to have the technical expertise you all do, but I can certainly offer technical guidance with business rules and system requirements. I work for the National Notary Association, by the way, so I'm confident I can provide = assistance with understanding the need for Notary services to support our work as Notaries Public. I can also bridge this initial draft effort with work we're doing through the American Bar Association to define best practices for electronic notarization, as necessary or appropriate. Because I'm new to this process, I'll need some guidance from you, Tobias, on how to proceed. I'm at your disposal. Take care, Richard J. Hansberger eNotarization Manager National Notary Association 818-739-4027 -----Original Message----- From: Tobias Gondrom =5Bmailto:tobias.gondrom=40ixos.de=5D Sent: Tuesday, July 13, 2004 2:54 AM To: ietf-ltans=40imc.org Subject: LTANS: first draft of requirements for notary services Importance: High Hello, After a long pause we finished the first draft =22requirements for notary services=22 and submitted it yesterday around 8:58 a.m. ET to IETF ;-) Attached you find the draft. Please consider it really just as the first draft to start the discussion of= the future work of LTANS after we complete the work on the long-term archiving (ERS, reqs and prot). I just started as the author and would be really happy if a second author would like to join me, or even if we find another author/editor for this draft to replace me. (following recommendations IETF considering the separation of the chair and editor role) So I hope this first draft is an acceptable base to start the discussion on = what is needed concerning notary services. Best regards Tobias __________________________________________ Tobias Gondrom Senior Software Architect PPMA, Engineering IXOS SOFTWARE AG Technopark 1 Bretonischer Ring 12 85630 Grasbrunn / Munich Phone: +49 (0) 89 4629-1816 Telefax: +49 (0) 89 4629-33-1816 eMail: mailto:tobias.gondrom=40ixos.de <mailto:tobias.gondrom=40ixos.de> Internet: http://www.ixos.com/ <http://www.ixos.com/> This eMail may contain confidential and/or privileged information. If you are not the intended recipient or have received this eMail in error, please = notify the sender immediately and destroy this eMail. Any use, disclosure or= distribution of the material in this eMail is strictly forbidden. Diese eMail enth=E4lt vertrauliche und/oder rechtlich gesch=FCtzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese eMail irrt=FCmlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese eMail. Jegliche Art der Verwendung, Vervielf=E4ltigung = oder Weitergabe ist nicht gestattet. ------_=_NextPart_001_01C46932.BE401AD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <=21DOCTYPE HTML PUBLIC =22-//W3C//DTD HTML 4.0 Transitional//EN=22> <HTML xmlns=3D=22http://www.w3.org/TR/REC-html40=22 xmlns:o =3D =22urn:schemas-microsoft-com:office:office=22 xmlns:w =3D =22urn:schemas-microsoft-com:office:word=22 xmlns:st1 =3D =22urn:schemas-microsoft-com:office:smarttags=22><HEAD> <META HTTP-EQUIV=3D=22Content-Type=22 CONTENT=3D=22text/html; charset=3Diso-= 8859-1=22> <TITLE>Message</TITLE> <META content=3D=22MSHTML 6.00.2800.1400=22 name=3DGENERATOR><o:SmartTagType= name=3D=22City=22 namespaceuri=3D=22urn:schemas-microsoft-com:office:smarttags=22></o:SmartTag= Type><o:SmartTagType name=3D=22place=22 namespaceuri=3D=22urn:schemas-microsoft-com:office:smarttags=22></o:SmartTag= Type><o:SmartTagType name=3D=22PersonName=22 namespaceuri=3D=22urn:schemas-microsoft-com:office:smarttags=22></o:SmartTag= Type><=21--=5Bif =21mso=5D> <STYLE>st1=5C:* =7B BEHAVIOR: url(=23default=23ieooui) =7D </STYLE> <=21=5Bendif=5D--> <STYLE>=40page Section1 =7Bsize: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in 1.= 25in; =7D P.MsoNormal =7B FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: =22Times New Roman=22 =7D LI.MsoNormal =7B FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: =22Times New Roman=22 =7D DIV.MsoNormal =7B FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: =22Times New Roman=22 =7D A:link =7B COLOR: blue; TEXT-DECORATION: underline =7D SPAN.MsoHyperlink =7B COLOR: blue; TEXT-DECORATION: underline =7D A:visited =7B COLOR: purple; TEXT-DECORATION: underline =7D SPAN.MsoHyperlinkFollowed =7B COLOR: purple; TEXT-DECORATION: underline =7D P =7B FONT-SIZE: 12pt; MARGIN-LEFT: 0in; MARGIN-RIGHT: 0in; FONT-FAMILY: =22Times= New Roman=22; mso-margin-top-alt: auto; mso-margin-bottom-alt: auto =7D SPAN.EmailStyle17 =7B COLOR: windowtext; FONT-FAMILY: Arial; mso-style-type: personal-compose =7D DIV.Section1 =7B page: Section1 =7D </STYLE> </HEAD> <BODY lang=3DEN-US vLink=3Dpurple link=3Dblue> <DIV><FONT face=3DArial color=3D=230000ff size=3D2><SPAN class=3D356523623-13072004>Tobias,</SPAN></FONT></DIV> <DIV><FONT face=3DArial color=3D=230000ff size=3D2><SPAN class=3D356523623-13072004></SPAN></FONT> </DIV> <DIV><FONT face=3DArial color=3D=230000ff size=3D2><SPAN class=3D356523623-1= 3072004>Thanks for this first draft. I've been lurking on this list for some time and now w= ill offer my assistance and hope I don't overstep any bounds.</SPAN></FONT></DIV= > <DIV><FONT face=3DArial color=3D=230000ff size=3D2><SPAN class=3D356523623-13072004></SPAN></FONT> </DIV> <DIV><FONT face=3DArial color=3D=230000ff size=3D2><SPAN class=3D356523623-1= 3072004>I will gladly join the effort as a second author or editor. I do not pretend t= o have the technical expertise you all do, but I can certainly offer technical= guidance with business rules and system requirements. I work for the Nationa= l Notary Association, by the way, so I'm confident I can provide assistance wi= th understanding the need for Notary services to support our work as Notaries = Public. I can also bridge this initial draft effort with work we're doing through the American Bar Association to define best practices for electronic= notarization, as necessary or appropriate.</SPAN></FONT></DIV> <DIV><FONT face=3DArial color=3D=230000ff size=3D2><SPAN class=3D356523623-13072004></SPAN></FONT> </DIV> <DIV><FONT face=3DArial color=3D=230000ff size=3D2><SPAN class=3D356523623-13072004>Because I'm new to this process, I'll need some = guidance from you, Tobias, on how to proceed. I'm at your disposal.</SPAN></FONT></DIV> <DIV><FONT face=3DArial color=3D=230000ff size=3D2><SPAN class=3D356523623-13072004></SPAN></FONT> </DIV> <DIV><FONT face=3DArial color=3D=230000ff size=3D2><SPAN class=3D356523623-1= 3072004>Take care,</SPAN></FONT></DIV> <DIV><FONT face=3DArial color=3D=230000ff size=3D2><SPAN class=3D356523623-13072004></SPAN></FONT> </DIV> <DIV align=3Dleft><FONT face=3DArial size=3D2><STRONG>Richard J. Hansberger</STRONG></FONT></DIV> <DIV align=3Dleft><FONT face=3DArial size=3D2>eNotarization Manager</FONT></= DIV> <DIV align=3Dleft><FONT face=3DArial size=3D2>National Notary Association</F= ONT></DIV> <DIV align=3Dleft><FONT face=3DArial size=3D2>818-739-4027</FONT></DIV> <BLOCKQUOTE dir=3Dltr style=3D=22MARGIN-RIGHT: 0px=22> <DIV></DIV> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft><FON= T face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B> Tobias G= ondrom =5Bmailto:tobias.gondrom=40ixos.de=5D <BR><B>Sent:</B> Tuesday, July 13, 2= 004 2:54 AM<BR><B>To:</B> ietf-ltans=40imc.org<BR><B>Subject:</B> LTANS: first draf= t of requirements for notary services<BR><B>Importance:</B> High<BR><BR></FONT></DIV> <DIV class=3DSection1> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN style=3D=22FONT-SIZE: 10pt; FONT-FAMILY: Arial=22>Hello,<o:p></o:p></SPAN>= </FONT></P> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN style=3D=22FONT-SIZE: 10pt; FONT-FAMILY: Arial=22><o:p> </o:p></SPAN>= </FONT></P> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN style=3D=22FONT-SIZE: 10pt; FONT-FAMILY: Arial=22>After a long pause we fi= nished the first draft =22requirements for notary services=22 and submitted it yester= day around 8:58 a.m. ET to IETF ;-)<o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN style=3D=22FONT-SIZE: 10pt; FONT-FAMILY: Arial=22><o:p> </o:p></SPAN>= </FONT></P> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN style=3D=22FONT-SIZE: 10pt; FONT-FAMILY: Arial=22>Attached you find the draft.<o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN style=3D=22FONT-SIZE: 10pt; FONT-FAMILY: Arial=22>Please consider it reall= y just as the first draft to start the discussion of the future work of LTANS after = we complete the work on the long-term archiving (ERS, reqs and prot).<o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN style=3D=22FONT-SIZE: 10pt; FONT-FAMILY: Arial=22>I just started as the au= thor and would be really happy if a second author would like to join me, or even if= we find another author/editor for this draft to replace me. (following recommendations IETF considering the separation of the chair and editor role)<o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN style=3D=22FONT-SIZE: 10pt; FONT-FAMILY: Arial=22><o:p> </o:p></SPAN>= </FONT></P> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN style=3D=22FONT-SIZE: 10pt; FONT-FAMILY: Arial=22>So I hope this first dra= ft is an acceptable base to start the discussion on what is needed concerning notar= y services.<o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN style=3D=22FONT-SIZE: 10pt; FONT-FAMILY: Arial=22><o:p> </o:p></SPAN>= </FONT></P> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN style=3D=22FONT-SIZE: 10pt; FONT-FAMILY: Arial=22>Best regards<o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN style=3D=22FONT-SIZE: 10pt; FONT-FAMILY: Arial=22><o:p> </o:p></SPAN>= </FONT></P> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN style=3D=22FONT-SIZE: 10pt; FONT-FAMILY: Arial=22> = Tobias<o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN style=3D=22FONT-SIZE: 10pt; FONT-FAMILY: Arial=22><o:p> </o:p></SPAN>= </FONT></P> <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN style=3D=22FONT-SIZE: 10pt; FONT-FAMILY: Arial=22><o:p> </o:p></SPAN>= </FONT></P> <P><B><FONT face=3DArial size=3D2><SPAN style=3D=22FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: Arial=22>_____= _____________________________________</SPAN></FONT></B> <BR><st1:PersonName w:st=3D=22on=22><B><FONT face=3DArial color=3Dblack si= ze=3D2><SPAN style=3D=22FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: = Arial=22>Tobias Gondrom</SPAN></FONT></B></st1:PersonName><FONT face=3DArial color=3Dblack= size=3D2><SPAN style=3D=22FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Arial=22><BR>Senior= Software Architect<BR>PPMA, Engineering<BR></SPAN></FONT><BR><B><FONT face=3DArial = color=3Dblack size=3D2><SPAN style=3D=22FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: = Arial=22>IXOS SOFTWARE AG</SPAN></FONT></B><FONT face=3DArial color=3Dblack size=3D2><SP= AN style=3D=22FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Arial=22><BR>Techno= park 1<BR>Bretonischer Ring 12<BR>85630 Grasbrunn / <st1:place w:st=3D=22on=22>= <st1:City w:st=3D=22on=22>Munich</st1:City></st1:place></SPAN></FONT> <BR><FONT face= =3DArial color=3Dblack size=3D2><SPAN style=3D=22FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Arial=22>Phone:&nbs= p; +49 (0) 89 4629-1816<BR>Telefax: +49 (0)= 89 4629-33-1816<BR>eMail: </SPAN></FONT> <FONT face=3DArial size=3D2><SP= AN style=3D=22FONT-SIZE: 10pt; FONT-FAMILY: Arial=22><A href=3D=22mailto:tobias.gondrom=40ixos.de=22>mailto:tobias.gondrom=40ixos.= de</A><BR><FONT color=3Dblack><SPAN style=3D=22COLOR: black=22>Internet: </= SPAN></FONT></SPAN></FONT><U> </U><U><FONT face=3DArial color=3Dblue size=3D2><SPAN style=3D=22FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial=22><A href=3D=22http://www.ixos.com/=22>http://www.ixos.com/</A></SPAN></FONT></= U> <o:p></o:p></P> <P><FONT face=3DArial color=3Dblack size=3D2><SPAN style=3D=22FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Arial=22>This eMail= may contain confidential and/or privileged information. If you are not the intended recipient or have received this eMail in error, please notify the= sender immediately and destroy this eMail. Any use, disclosure or distribu= tion of the material in this eMail is strictly forbidden.</SPAN></FONT><o:p></o:p></P> <P><FONT face=3DArial size=3D2><SPAN lang=3DDE style=3D=22FONT-SIZE: 10pt; FONT-FAMILY: Arial=22>Diese eMail enth=E4lt ve= rtrauliche und/oder rechtlich gesch=FCtzte Informationen. Wenn Sie nicht der richtige= Adressat sind oder diese eMail irrt=FCmlich erhalten haben, informieren Si= e bitte sofort den Absender und vernichten Sie diese eMail. Jegliche Art der= Verwendung, Vervielf=E4ltigung oder Weitergabe ist nicht gestattet.</SPAN></FONT><SPAN lang=3DDE><o:p></o:p></SPAN></P> <P class=3DMsoNormal><FONT face=3D=22Times New Roman=22 size=3D3><SPAN lan= g=3DDE style=3D=22FONT-SIZE: 12pt=22><o:p> </o:p></SPAN></FONT></P></DIV></B= LOCKQUOTE></BODY></HTML> ------_=_NextPart_001_01C46932.BE401AD0-- ----123456789-987654321-abcdefg Content-Type: text/plain Content-Disposition: inline This email message and any files transmitted with it contain confidential information intended only for the person(s) to whom this email message is addressed. If you have received this email message in error, please notify the sender immediately. ----123456789-987654321-abcdefg-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DAosiZ095377; Tue, 13 Jul 2004 03:50:54 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6DAosrI095376; Tue, 13 Jul 2004 03:50:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx02.ixos.de (mucmx02.ixos.de [149.235.31.93]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DAomjA095338 for <ietf-ltans@imc.org>; Tue, 13 Jul 2004 03:50:53 -0700 (PDT) (envelope-from tobias.gondrom@ixos.de) Received: from mucxg01.opentext.net (localhost [127.0.0.1]) by mucmx02.ixos.de (8.12.9/8.12.9) with ESMTP id i6DAnPD1006416 for <ietf-ltans@imc.org>; Tue, 13 Jul 2004 12:49:25 +0200 (MEST) Content-class: urn:content-classes:message Subject: LTANS: first draft of requirements for notary services Date: Tue, 13 Jul 2004 12:53:45 +0200 Message-ID: <077097E85A6BD3119E910800062786A90C3A6928@muc-mail5.ixos.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C468C7.AB3849F0" X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: LTANS: first draft of requirements for notary services Thread-Index: AcRoxwqQykDxkaVQRwa6/QayTEgY3Q== X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-Priority: 1 Importance: high From: "Tobias Gondrom" <tobias.gondrom@ixos.de> To: <ietf-ltans@imc.org> Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/> List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe> List-ID: <ietf-ltans.imc.org> This is a multi-part message in MIME format. ------_=_NextPart_001_01C468C7.AB3849F0 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C468C7.AB3849F0" ------_=_NextPart_002_01C468C7.AB3849F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, =20 After a long pause we finished the first draft "requirements for notary = services" and submitted it yesterday around 8:58 a.m. ET to IETF ;-) =20 Attached you find the draft. Please consider it really just as the first draft to start the = discussion of the future work of LTANS after we complete the work on the = long-term archiving (ERS, reqs and prot). I just started as the author and would be really happy if a second = author would like to join me, or even if we find another author/editor = for this draft to replace me. (following recommendations IETF = considering the separation of the chair and editor role) =20 So I hope this first draft is an acceptable base to start the discussion = on what is needed concerning notary services. =20 Best regards =20 Tobias =20 =20 __________________________________________=20 Tobias Gondrom Senior Software Architect PPMA, Engineering IXOS SOFTWARE AG Technopark 1 Bretonischer Ring 12 85630 Grasbrunn / Munich=20 Phone: +49 (0) 89 4629-1816 Telefax: +49 (0) 89 4629-33-1816 eMail: mailto:tobias.gondrom@ixos.de Internet: http://www.ixos.com/=20 This eMail may contain confidential and/or privileged information. If = you are not the intended recipient or have received this eMail in error, = please notify the sender immediately and destroy this eMail. Any use, = disclosure or distribution of the material in this eMail is strictly = forbidden. Diese eMail enth=E4lt vertrauliche und/oder rechtlich gesch=FCtzte = Informationen. Wenn Sie nicht der richtige Adressat sind oder diese = eMail irrt=FCmlich erhalten haben, informieren Sie bitte sofort den = Absender und vernichten Sie diese eMail. Jegliche Art der Verwendung, = Vervielf=E4ltigung oder Weitergabe ist nicht gestattet. =20 ------_=_NextPart_002_01C468C7.AB3849F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" = xmlns=3D"http://www.w3.org/TR/REC-html40"> <head> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Diso-8859-1"> <meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)"> <o:SmartTagType = namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" name=3D"City"/> <o:SmartTagType = namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" name=3D"place"/> <o:SmartTagType = namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" name=3D"PersonName"/> <!--[if !mso]> <style> st1\:*{behavior:url(#default#ieooui) } </style> <![endif]--> <style> <!-- /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman";} a:link, span.MsoHyperlink {color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {color:purple; text-decoration:underline;} p {mso-margin-top-alt:auto; margin-right:0in; mso-margin-bottom-alt:auto; margin-left:0in; font-size:12.0pt; font-family:"Times New Roman";} span.EmailStyle17 {mso-style-type:personal-compose; font-family:Arial; color:windowtext;} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.25in 1.0in 1.25in;} div.Section1 {page:Section1;} --> </style> </head> <body lang=3DEN-US link=3Dblue vlink=3Dpurple> <div class=3DSection1> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>Hello,<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>After a long pause we finished the first draft = “requirements for notary services” and submitted it yesterday around 8:58 a.m. = ET to IETF ;-)<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>Attached you find the = draft.<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>Please consider it really just as the first draft to = start the discussion of the future work of LTANS after we complete the work on = the long-term archiving (ERS, reqs and prot).<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>I just started as the author and would be really = happy if a second author would like to join me, or even if we find another = author/editor for this draft to replace me. (following recommendations IETF considering = the separation of the chair and editor role)<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>So I hope this first draft is an acceptable base to = start the discussion on what is needed concerning notary = services.<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>Best regards<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = Tobias<o:p></o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'><o:p> </o:p></span></font></p> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'><o:p> </o:p></span></font></p> <p><b><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt;font-family:Arial; font-weight:bold'>__________________________________________</span></font= ></b> <br> <st1:PersonName w:st=3D"on"><b><font size=3D2 color=3Dblack = face=3DArial><span = style=3D'font-size:10.0pt;font-family:Arial;color:black;font-weight:bold'= >Tobias Gondrom</span></font></b></st1:PersonName><font size=3D2 color=3Dblack = face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial;color:black'><br> Senior Software Architect<br> PPMA, Engineering<br> </span></font><br> <b><font size=3D2 color=3Dblack face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial;color:black;font-weight:bold'>IXOS SOFTWARE = AG</span></font></b><font size=3D2 color=3Dblack face=3DArial><span = style=3D'font-size:10.0pt;font-family:Arial; color:black'><br> Technopark 1<br> Bretonischer Ring 12<br> 85630 Grasbrunn / <st1:place w:st=3D"on"><st1:City = w:st=3D"on">Munich</st1:City></st1:place></span></font> <br> <font size=3D2 color=3Dblack face=3DArial><span = style=3D'font-size:10.0pt;font-family: Arial;color:black'>Phone: +49 (0) 89 4629-1816<br> Telefax: +49 (0) 89 = 4629-33-1816<br> eMail: </span></font> <font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'><a = href=3D"mailto:tobias.gondrom@ixos.de">mailto:tobias.gondrom@ixos.de</a><= br> <font color=3Dblack><span = style=3D'color:black'>Internet: </span= ></font></span></font><u> </u><u><font size=3D2 color=3Dblue face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial;color:blue'><a = href=3D"http://www.ixos.com/">http://www.ixos.com/</a></span></font></u> <o:p></o:p></p> <p><font size=3D2 color=3Dblack face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial;color:black'>This eMail may contain confidential = and/or privileged information. If you are not the intended recipient or have = received this eMail in error, please notify the sender immediately and destroy = this eMail. Any use, disclosure or distribution of the material in this eMail = is strictly forbidden.</span></font><o:p></o:p></p> <p><font size=3D2 face=3DArial><span lang=3DDE = style=3D'font-size:10.0pt;font-family: Arial'>Diese eMail enth=E4lt vertrauliche und/oder rechtlich = gesch=FCtzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese = eMail irrt=FCmlich erhalten haben, informieren Sie bitte sofort den Absender = und vernichten Sie diese eMail. Jegliche Art der Verwendung, = Vervielf=E4ltigung oder Weitergabe ist nicht gestattet.</span></font><span = lang=3DDE><o:p></o:p></span></p> <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span = lang=3DDE style=3D'font-size:12.0pt'><o:p> </o:p></span></font></p> </div> </body> </html> ------_=_NextPart_002_01C468C7.AB3849F0-- ------_=_NextPart_001_01C468C7.AB3849F0 Content-Type: text/plain; name="draft-ietf-ltans-notareqs-00.txt" Content-Transfer-Encoding: base64 Content-Description: draft-ietf-ltans-notareqs-00.txt Content-Disposition: attachment; filename="draft-ietf-ltans-notareqs-00.txt" DQpMb25nLXRlcm0gQXJjaGl2ZSBBbmQgTm90YXJ5ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFQuIEdvbmRyb20NClNlcnZpY2VzIChMVEFOUykgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgSVhPUyBTb2Z0d2FyZSBBRw0KSW50ZXJuZXQtRHJhZnQgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KRXhwaXJlczogSmFudWFyeSAxLCAyMDA1ICAg ICAgICAgICAgICAgICAgICAgICAgDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgSnVseSAxMiwgMjAwNA0KDQoNCg0KICAgICAgICAg ICAgICAgICBOb3RhcnkgU2VydmljZXMgcmVxdWlyZW1lbnRzDQogICAgICAgICAgICAgICAgIGRy YWZ0LWlldGYtbHRhbnMtbm90YXJlcXMtMDAudHh0DQoNCg0KU3RhdHVzIG9mIHRoaXMgTWVtbw0K DQogICBUaGlzIGRvY3VtZW50IGlzIGFuIEludGVybmV0LURyYWZ0IGFuZCBpcyBpbiBmdWxsIGNv bmZvcm1hbmNlIHdpdGgNCiAgIGFsbCBwcm92aXNpb25zIG9mIFNlY3Rpb24gMTAgb2YgUkZDMjAy Ni4NCg0KICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50 ZXJuZXQgRW5naW5lZXJpbmcNCiAgIFRhc2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBp dHMgd29ya2luZyBncm91cHMuIE5vdGUgdGhhdCBvdGhlcg0KICAgZ3JvdXBzIG1heSBhbHNvIGRp c3RyaWJ1dGUgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRzLg0KDQogICBJbnRl cm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNp eCBtb250aHMNCiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBi eSBvdGhlciBkb2N1bWVudHMgYXQgYW55DQogICB0aW1lLiBJdCBpcyBpbmFwcHJvcHJpYXRlIHRv IHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlDQogICBtYXRlcmlhbCBvciB0byBjaXRl IHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iDQoNCiAgIFRoZSBsaXN0IG9m IGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBhdCBodHRwOi8vDQogICB3 d3cuaWV0Zi5vcmcvaWV0Zi8xaWQtYWJzdHJhY3RzLnR4dC4NCg0KICAgVGhlIGxpc3Qgb2YgSW50 ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBhdA0KICAgaHR0 cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbC4NCg0KICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3 aWxsIGV4cGlyZSBvbiBKYW51YXJ5IDEyLCAyMDA1Lg0KDQpDb3B5cmlnaHQgTm90aWNlDQoNCiAg IENvcHlyaWdodCAoQykgVGhlIEludGVybmV0IFNvY2lldHkgKDIwMDQpLiBBbGwgUmlnaHRzIFJl c2VydmVkLg0KDQpBYnN0cmFjdA0KDQogICBOb3Rhcnkgc2VydmljZXMgYXJlIGF2YWlsYWJsZSB0 b2RheSBpbiBhIHdpZGUgdmFyaWV0eSBmb3IgcGFwZXIgYmFzZWQgDQogICBwcm9jZXNzZXMgYW5k IGRvY3VtZW50cy4gVG8gZGVmaW5lIHRoZSBuZWVkcywgcmVxdWlyZW1lbnRzIGFuZCBmdXR1cmUg DQogICB3b3JsZCBmb3Igbm90YXJ5IHNlcnZpY2VzIGluIHRoZSBlbGN0cm9uaWMgd29ybGQsIHRo aXMgZG9jdW1lbnQgDQogICBkZXNjcmliZXMgdXNlIGNhc2VzIGFuZCBzY2VuYXJpb3MgYXMgYmFz ZSBmb3IgZnVydGhlciBkaXNjdXNzaW9uIGFuZCANCiAgIHdvcmsgb2YgdGhlIExUQU5TIFdHIGlu IHRoaXMgYXJlYS4NCg0KDQoNCg0KDQoNCkdvbmRyb20sIGV0IGFsLiAgICAgICAgIEV4cGlyZXMg SmFudWFyeSAgMSwgMjAwNCAgICAgICAgICAgICAgICBbUGFnZSAxXQ0KDA0KSW50ZXJuZXQtRHJh ZnQgICAgTm90YXJ5IFNlcnZpY2VzIHJlcXVpcmVtZW50cwkJCSAgIEp1bHkgMjAwNA0KDQoNClRh YmxlIG9mIENvbnRlbnRzDQoNCiAgIDEuICBJbnRyb2R1Y3Rpb24gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMw0KICAgMi4gIFRlcm1pbm9sb2d5ICAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA1DQogICAz LiAgVXNlIGNhc2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gIDYNCiAgIDQuICBUZWNobmljYWwgUmVxdWlyZW1lbnRzIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNw0KICAgNS4gIE9wZXJhdGlvbmFsIENvbnNpZGVy YXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEyDQogICA2LiAgU2Vj dXJpdHkgQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gMTMNCiAgIDcuICBBY2tub3dsZWRnZW1lbnRzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAxNA0KICAgOC4gIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE0DQogICAgICAgQXV0aG9ycycg QWRkcmVzc2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTQN CiAgICAgICBJbnRlbGxlY3R1YWwgUHJvcGVydHkgYW5kIENvcHlyaWdodCBTdGF0ZW1lbnRzIC4g LiAuIC4gLiAuIC4gLiAxNw0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KR29uZHJvbSwgZXQgYWwuICAg ICAgICAgRXhwaXJlcyBKYW51YXJ5ICAxLCAyMDA0ICAgICAgICAgICAgICAgIFtQYWdlIDJdDQoM DQpJbnRlcm5ldC1EcmFmdCAgICBOb3RhcnkgU2VydmljZXMgcmVxdWlyZW1lbnRzCQkJICAgSnVs eSAyMDA0DQoNCg0KMS4gIEludHJvZHVjdGlvbg0KDQogICBUaGUgb2ZmaWNlIG9mIG5vdGFyeSBk YXRlcyBiYWNrIHRvIHRoZSBSb21hbiBFbXBpcmUuIFNpbmNlIGFib3V0IA0KICAgMjAwMCB5ZWFy cyB0cnVzdHdvcnRoeSBwZXJzb25zIGFjdCBhcyBub3RhcmllcyB0byBhcHByb3ZlIHRoYXQgdGhl eSANCiAgIGhhdmUgd2l0bmVzc2VkIHNvbWV0aGluZy4gDQogICBBIE5vdGFyeSBpbiBjb21tb24g bGF3IGp1cmlzZGljdGlvbnMgaXMgYSBxdWFsaWZpZWQgbGF3eWVyLiANCiAgIFRoZSBvZmZpY2Ug b2YgYSBub3RhcnkgaXMgYWx3YXlzIGNvbW1pc3Npb25lZCBieSB0aGUgc3RhdGUuICAgDQogICBU cmFkaXRpb25hbGx5LCBub3RhcmllcyByZWNvcmRlZCBtYXR0ZXJzIG9mIGp1ZGljaWFsIGltcG9y dGFuY2UgYXMgDQogICB3ZWxsIGFzIHByaXZhdGUgdHJhbnNhY3Rpb25zIG9yIGV2ZW50cyB3aGVy ZSBhbiBvZmZpY2lhbGx5IA0KICAgYXV0aGVudGljYXRlZCByZWNvcmQgb3IgYSBkb2N1bWVudCBk cmF3biB1cCB3aXRoIHByb2Zlc3Npb25hbCBza2lsbCANCiAgIG9yIGtub3dsZWRnZSB3YXMgcmVx dWlyZWQuIFNwZWNpZmljYWxseSwgdGhlIGZ1bmN0aW9ucyBvZiBub3RhcmllcyANCiAgIGluY2x1 ZGUgdGhlIGF0dGVzdGF0aW9uIG9mIGRvY3VtZW50cyBhbmQgY2VydGlmaWNhdGlvbiBvZiB0aGVp ciBkdWUgDQogICBleGVjdXRpb24sIGFkbWluaXN0ZXJpbmcgb2Ygb2F0aHMsIHdpdG5lc3Npbmcg YWZmaWRhdml0cyBhbmQgDQogICBzdGF0dXRvcnkgZGVjbGFyYXRpb25zLCBjZXJ0aWZpY2F0aW9u IG9mIGNvcHkgZG9jdW1lbnRzLCBub3RpbmcgYW5kIA0KICAgcHJvdGVzdGluZyBvZiBiaWxscyBv ZiBleGNoYW5nZSBhbmQgdGhlIHByZXBhcmF0aW9uIG9mIHNoaXBzJyANCiAgIHByb3Rlc3RzLg0K ICAgDQogICBTaWduaWZpY2FudCB3ZWlnaHQgYXR0YWNoZXMgdG8gZG9jdW1lbnRzIGNlcnRpZmll ZCBieSBub3Rhcmllcy4gDQogICBEb2N1bWVudHMgY2VydGlmaWVkIGJ5IG5vdGFyaWVzIGFyZSBz ZWFsZWQgd2l0aCB0aGUgbm90YXJ5J3Mgc2VhbCANCiAgIGFuZCBhcmUgcmVjb3JkZWQgYnkgdGhl IG5vdGFyeSBpbiBhIHJlZ2lzdGVyIG1haW50YWluZWQgYnkgaGltL2hlci4gDQogICBUaGVzZSBh cmUga25vd24gYXMgIm5vdGFyaWFsIGFjdHMiLiBOb3RhcmlhbCBhY3RzIGFuZCBjZXJ0aWZpY2F0 ZXMgDQogICBhcmUgcmVjb2duaXNlZCBieSBzb21lIGNvdW50cmllcyB3aXRob3V0IHRoZSBuZWVk IGZvciBhbnkgZnVydGhlciANCiAgIGNlcnRpZmljYXRpb24gZnJvbSB0aGUgcmVzcGVjdGl2ZSBG b3JlaWduIE1pbmlzdHJ5IG9yIGZvcmVpZ24gDQogICBkaXBsb21hdGljIG1pc3Npb25zLiAoSW4g Y291bnRyaWVzIHN1YnNjcmliaW5nIHRvIHRoZSBIYWd1ZSANCiAgIENvbnZlbnRpb24gQWJvbGlz aGluZyB0aGUgUmVxdWlyZW1lbnQgZm9yIExlZ2FsaXNhdGlvbiBmb3IgRm9yZWlnbiANCiAgIFB1 YmxpYyBEb2N1bWVudHMgb25seSBvbmUgZnVydGhlciBhY3Qgb2YgY2VydGlmaWNhdGlvbiBpcyBy ZXF1aXJlZCwgDQogICBrbm93biBhcyBhbiBhcG9zdGlsbGUpLiAoc291cmNlOiB3aWtpcGVkaWEu b3JnKQ0KDQoNCiAgIEEgbm90YXJ5IHNlcnZpY2Ugc2hvdWxkIHN1cHBvcnQgYW5kIGVuYWJsZSBh IGh1bWFuIG5vdGFyeSB0byBmdWxsZmlsbCANCiAgIGhpcyB0YXNrcyB3aXRoIGVsZWN0cm9uaWMg ZG9jdW1lbnRzIGFzIHdlbGwgYXMgaGUgYWxyZWFkeSBkb2VzIHdpdGggDQogICBwYXBlciBiYXNl ZCBkb2N1bWVudHMgYW5kIHByb2Nlc3Nlcy4NCg0KICAgTm90YXJ5IHNlcnZpY2VzIG1pZ2h0IGJl IGxvY2F0ZWQgYXQgYSBnb3Zlcm5tZW50IGZhY2lsaXR5LCBhdCB0aGUgDQogICBvZmZpY2Ugb2Yg YSBjaXZpbCBub3Rhcnkgb3IgYSBsYXd5ZXIgb3Igb3RoZXIgcGxhY2VzIHRoYXQgYXJlIGhvbm9y ZWQgDQogICBieSB0aGUgdHJ1c3Qgb2YgdGhlIHB1YmxpYy4NCg0KICAgSW4gdGhlIHRoZSBkaWZm ZXJlbnQgY291bnRyaWVzIHRoZSBjaGFyYWN0ZXJpc3RpY3Mgb2YgYSB0cnVzdGVkIA0KICAgbm90 YXJ5IGFuZCB0aGVpciAibm90YXJpYWwgYWN0cyIgY2FuIHZhcnkgd2lkZWx5IHNvIGEgY29tcHV0 ZXIgYmFzZWQgDQogICBub3Rhcnkgc2VydmljZSBoYXMgdG8gbWVldCB0aGVpciBpbmRpdmlkdWFs IGNvbmNlcm5zIGFuZCANCiAgIHJlcXVpcmVtZW50cy4NCg0KICAgRXhhbXBsZXMgb2Ygbm90YXJ5 IHNlcnZpY2UgdXNhZ2UgYnkgc3VibWl0dGVycyBpbmNsdWRlOg0KDQogICAgICAtIGFuIGVudGl0 eSAocGVyc29uIG9yIGNvbXBhbnkpIHdhbnRzIGEgbm90YXJ5IHRvIGZ1bmN0aW9uIGFzIGEgDQog ICAgICAgIHdpdG5lc3MgZm9yIHRoZSBleGlzdGVuY2Ugb2YgYSBkb2N1bWVudCBvciB0aGUgY2xr b3Npbmcgb2YgYSANCiAgICAgICAgY29udHJhY3QNCiAgICAgIA0KDQoNCg0KR29uZHJvbSwgZXQg YWwuICAgICAgICAgRXhwaXJlcyBKYW51YXJ5ICAxLCAyMDA0ICAgICAgICAgICAgICAgIFtQYWdl IDNdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICBOb3RhcnkgU2VydmljZXMgcmVxdWlyZW1lbnRzCQkJ ICAgSnVseSAyMDA0DQoNCg0KICAgICAgLSBlbnRpdGllcyBuZWVkIGEgdHJ1c3RlZCB0aGlyZCBw YXJ0eSB0byBnYXRoZXIgYW5kIHN0b3JlIA0KICAgICAgICBkb2N1bWVudHMsIG1ha2luZyBpdCBp bXBvc3NpYmxlIGZvciB0aGVtIHRvIGRlbGV0ZSB0aGUgZG9jdW1lbnQsIA0KICAgICAgICBvciB0 YWtpbmcgY2FyZSwgdGhhdCBzb21lIGluZm9ybWF0aW9uIGhhcyB0byBiZSBzdWJtaXR0ZWQgYnkg YSANCiAgICAgICAgc2VuZGVyIHVudGlsIGEgY2VydGFpbiB0aW1lIGFuZCBhbHNvIGd1YXJhbnRl ZWluZyB0aGF0IHRoZSANCiAgICAgICAgcmVjZXBpZW50IGRvZXNuJ3QgcmVjZWl2ZSB0aGUgZG9j dW1lbnQgYmVmb3JlIGEgZ2l2aW5nIHRpbWUuIA0KICAgICAgICAoYW4gaW1wb3J0YW50IHJlcXVp cm1lbnQgZm9yIGF3YXJkaW5nIGNvbnRyYWN0cyBieSBwdWJsaWMgDQogICAgICAgIGF1dGhvcml0 aWVzKQ0KICAgICAgLSBmb3JtYXQgdHJhbnNmb3JtYXRpb25zDQogICAgICAgIENsYXNzaWNhbGx5 LCB2aXJ0dWFsbHkgdGhlIG9ubHkgImZvcm1hdCBjb252ZXJzaW9uIiBleGVydGVkIGJ5IA0KICAg ICAgICBub3RhcmllcyBpcyB0aGUgZXhlbXBsaWZpY2F0aW9uIG9mIGF0dGVzdGVkIGNvcGllcyBv ZiBkb2N1bWVudHMuIA0KICAgICAgICBCZXNpZGVzIHRoaXMgcGFwZXItdG8tcGFwZXIgdHJhbnNm b3JtYXRpb24sIHdpdGggZWxlY3Ryb25pYyANCiAgICAgICAgZG9jdW1lbnRzIHRocmVlIG90aGVy IGZvcm1hdCBjaGFuZ2VzIGJlY29tZSBwb3NzaWJsZTogDQogICAgICAgIHBhcGVyLXRvLWVsZWN0 cm9uaWMsIGVsZWN0cm9uaWMtdG8tcGFwZXIsIGFuZCBtb3N0IGltcG9ydGFudGx5IA0KICAgICAg ICBlbGVjdHJvbmljLXRvLWVsZWN0cm9uaWMgZm9ybWF0IHRyYW5zZm9ybWF0aW9ucy4NCiAgICAg IC0gdmVyaWZpY2F0aW9uIGFuZCB0ZXN0YXRpb24gb2YgdGhlIGxlZ2FsIHZhbGlkaXR5IG9mIHNp Z25lZCANCiAgICAgICAgZG9jdW1lbnRzDQogICAgICAtIC4uLg0KDQoNCg0KICAgSW4gcGFyYWxs ZWxzIHRvIHRoZSBkb2N1bWVudCAiTG9uZyB0ZXJtIGFyY2hpdmUgc2VydmljZSByZXF1aXJlbWVu dHMiDQogICBkcmFmdC1pZXRmLWx0YW5zLXJlcXMtMDEudHh0LCB3aGljaCBhaW1zIHRvIGlkZW50 aWZ5IHRoZSB0ZWNobmljYWwgDQogICByZXF1aXJlbWVudHMgZm9yIGEgbG9uZy10ZXJtIGFyY2hp dmUgc2VydmljZSwgdGhpcyBkb2N1bWVudCB0cmllcyB0byANCiAgIGlkZW50aWZ5IHBvc3NpYmxl IHVzZSBjYXNlcyBhbmQgdGVjaG5pY2FsIHJlcXVpcmVtZW50cyBmb3Igbm90YXJ5IA0KICAgc2Vy dmljZXMuIA0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCkdvbmRyb20sIGV0IGFsLiAgICAgICAgIEV4cGlyZXMgSmFudWFyeSAgMSwgMjAwNCAgICAg ICAgICAgICAgICBbUGFnZSA0XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgTm90YXJ5IFNlcnZpY2Vz IHJlcXVpcmVtZW50cwkJCSAgIEp1bHkgMjAwNA0KDQoNCjIuICBUZXJtaW5vbG9neQ0KDQoNCiAg ICAgIE5vdGFyeTogYSBwZXJzb24gb3IgaW5zdGl0dXRpb24gd2hpY2ggaXMgdHJ1c3RlZCBieSB0 aGUgcHVibGljIA0KICAgICAgYW5kIG90aGVyIGludm9sdmVkIHBhcnRpZXMuIA0KDQogICAgICBT ZWFsOiBUaGUgc2lnbiBvZiBhIG5vdGFyeSBzZXQgdG8gY2VydGlmeSBhIG5vdGFyaWFsIGFjdC4N Cg0KICAgICAgVXNlcjogUGVyc29uIG9yIGluc3RpdHV0aW9uIHRoYXQgbmVlZHMgdGhlIHNlcnZp Y2Ugb2YgYSBub3RhcnkgDQogICAgICBvciBvdGhlciB0cnVzdGVkIHRoaXJkIHBhcnR5Lg0KDQog ICAgICBOb3Rhcnkgc2VydmljZTogZWxlY3Ryb25pYyBzZXJ2aWNlIHRoYXQgc3VwcG9ydHMgYSBo dW1hbiBub3RhcnkNCiAgICAgIHRvIHByb3ZpZGUgaGlzL2hlciBzZXJ2aWNlcyBvbiBlbGVjdHJv bmljIGJhc2VkIHByb2Nlc3NlcyBhbmQgDQogICAgICBkb2N1bWVudHMuIEFuIGVsZWN0cm9uaWMg bm90YXJ5IHNlcnZpY2UgY2Fubm90IGZ1bmN0aW9uIHdpdGhvdXQgDQogICAgICB0aGUgdHJ1c3Qg ZWFybmVkIGJ5IHRoZSBodW1hbiBiZWhpbmQgaXQgYW5kIHRoZSBmYWN0IHRoYXQgdGhlDQogICAg ICBodW1hbiBub3RhcnkgaGFzIGFic29sdXQgY29udHJvbCBvdmVyIHRoZSB0aGUgbWFjaGluZS4N CiAgICAgIA0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQpHb25kcm9tLCBldCBhbC4gICAgICAgICBFeHBpcmVzIEphbnVh cnkgIDEsIDIwMDQgICAgICAgICAgICAgICAgW1BhZ2UgNV0NCgwNCkludGVybmV0LURyYWZ0ICAg IE5vdGFyeSBTZXJ2aWNlcyByZXF1aXJlbWVudHMJCQkgICBKdWx5IDIwMDQNCg0KDQozLiAgVXNl IGNhc2VzDQoNCiAgIDMuMSByZWNvcmQgdHJhbnNhY3Rpb25zOiANCiAgIFRoZSBub3Rhcnkgc2Vy dmljZSBoYXMgdG8gcmVjb3JkIHByaXZhdGUgdHJhbnNhY3Rpb25zLCBlLmcuIA0KICAgdHJhbnNh Y3Rpb25zIG9mIG93bmVyc2hpcC4gQWRkaXRpb25hbGx5IHRvIHRoZSByZWNvcmRpbmcgaXQgTVVT VCANCiAgIGJlIGFibGUgdG8gZ3VhcmFudGVlIGFuZCBwcm92aWRlIGRvY3VtZW50YXRpb24gdGhh dCBhbGwgbmVjZXNzYXJ5IA0KICAgaW5mb3JtYXRpb24gaGFzIGJlZW4gcHJvdmlkZWQgdG8gYWxs IGludm9sdmVkIHBhcnRpZXMuIA0KDQoNCiAgIDMuMi4gcmVjb3JkIGV2ZW50czogDQogICBUaGUg bm90YXJ5IHNlcnZpY2UgaGFzIHRvIGRvY3VtZW50IGFuZCBwcm9vZiB0aGF0IGEgY2VydGFpbiBl dmVudCANCiAgIGhhcyBoYXBwZW5lZC4gQXQgZmlyc3QgdGhlIHNlcnZpY2UgaGFzIHRvIGlkZW50 aWZ5IHRoZSBpbnZvbHZlZCANCiAgIGVudGl0aWVzIGFuZCB2ZXJpZnkgdGhhdCBhbGwgbmVjZXNz YXJ5IHByZWNvbmRpdGlvbnMgYXJlIG1ldC4gDQogICBBZnRlciB0aGlzIHRoZSBldmVudCBvciBj ZXJlbW9ueSBjYW4gYmUgaGVsZC4gRHVyaW5nIHdoaWNoIHRoZSANCiAgIG5vdGFyeSBzZXJ2aWNl IGhhcyB0byBlbnN1cmUgdGhhdCBhbGwgZW50aXRpZXMgdW5kZXJzdG9vZCBhbmQgDQogICByZWNl aXZlZCB0aGUgd2hvbGUgaW5mb3JtYXRpb24gYW5kIGNvbnNlcXVlbmNlcyBvZiB0aGUgZXZlbnQu IA0KICAgQWZ0ZXIgdGhlIGV2ZW50IGFuIG9mZmljaWFsbHkgYXV0aGVudGljYXRlZCByZWNvcmQg aGFzIHRvIGJlIA0KICAgaXNzdWVkIHRvIGFsbCBlbnRpdGllcyBhbmQgb25lIGNvcHkga2VwdCBm b3IgbGF0ZXIgZG9jdW1lbnRhdGlvbi4gDQogICAoZXZlbnRzIG1pZ2h0IGJlIGUuZy4gbWFycmlh Z2UsIIUpIA0KDQoNCiAgIDMuMy4gY2VydGlmaWNhdGlvbiBvZiBjb3B5IGRvY3VtZW50cw0KICAg VGhlIG5vdGFyeSBzZXJ2aWNlIG11c3QgYmUgYWJsZSB0byBhdHRlc3QgdGhhdCBvbmUgZG9jdW1l bnQgY29udGFpbnMgDQogICB0aGUgc2FtZSBpbmZvcm1hdGlvbiBhcyBhbm90aGVyIGFuZCB0aGUg dmFsaWRpdHkgb2YgYWxsIGNvbnRhaW5lZCANCiAgIGRpZ2l0YWwgc2lnbmF0dXJlcyBhbmQgdGhl IGlkZW50aXR5IG9mIHRoZSBzaWduZXJzLiBXaXRoIHRoaXMgdGhlIA0KICAgdHJhbnNmb3JtYXRp b24gb2Ygb25lIGRvY3VtZW50IGZvcm1hdCBpbnRvIGFub3RoZXIgY2FuIGJlIGFjaGlldmVkLiAN Cg0KDQogICAzLjQuIGFkbWluaXN0ZXJpbmcgb2Ygb2F0aHMNCiAgIE9uZSBTZXJ2aWNlIGNhbiBi ZSB0aGF0IHRoZSBhZG1pbmlzdGVyaW5nIG9mIG9hdGhzIGNhbiBpbiB0aGUgZnV0dXJlIA0KICAg YmUgZG9jdW1lbnRlZCBlbGVjdHJvbmljYWxseSBpbnN0ZWFkIG9mIGFwcGx5aW5nIHRoZSBzZWFs IG9mIGEgbm90YXJ5IA0KICAgb24gYSBwaWVjZSBvZiBwYXBlci4gRS5nLiB0aGUgY2xpZW50IGNh biB2aXNpdCB0aGUgb2ZmaWNlIG9mIGEgbm90YXJ5IA0KICAgKG1heWJlIGV2ZW4gb25seSB2aXJ0 dWFsbHkpLCB0YWtlIGFuIG9hdGggYW5kIHRoZSBub3RhcnkgY2FuIHJlY29yZCANCiAgIHRoYXQg d2l0aCBhbiBlbGVjdHJvbmljIGRvY3VtZW50LCBsaWtlIGEgZGlnaXRhbCBzaWduZWQgZG9jdW1l bnQuIA0KDQoNCiAgIDMuNS4gYXR0ZXN0YXRpb24gYW5kIGNlcnRpZmljYXRpb24gb2YgZG9jdW1l bnRzIGFuZCBldmVudHMNCiAgIFRoZSBub3RhcnkgY2FuIGF0dGVzdCBhbmQgY2VydGlmeSB0aGUg Y29ycmVjdG5lc3MgYW5kIGV4aXN0ZW5jZSBvZiBhIA0KICAgZG9jdW1lbnQgYW5kIGFsbCBjb250 YWluZWQgc2lnbmF0dXJlcyBhcyB0aGUgbm90YXJ5IHNlcnZpY2UgdG9vayBwYXJ0IA0KICAgaW4g dGhlIGNyZWF0aW9uIGFuZCBzaWduaW5nIG9mIHRoZSBkb2N1bWVudCBhbmQgYnkgdGhpcyBlbnN1 cmVkIHRoZSANCiAgIGludGVncml0eSBvZiB0aGUgZW52aXJvbm1lbnQgZm9yIGFsbCBwYXJ0aWNp cGFudHMuIA0KDQoNCg0KDQoNCg0KDQoNCg0KDQpHb25kcm9tLCBldCBhbC4gICAgICAgICBFeHBp cmVzIEphbnVhcnkgIDEsIDIwMDQgICAgICAgICAgICAgICAgW1BhZ2UgNl0NCgwNCkludGVybmV0 LURyYWZ0ICAgIE5vdGFyeSBTZXJ2aWNlcyByZXF1aXJlbWVudHMJCQkgICBKdWx5IDIwMDQNCg0K DQo0LiAgVGVjaG5pY2FsIFJlcXVpcmVtZW50cw0KDQogICBUaGlzIHNlY3Rpb24gZGVzY3JpYmVz IGEgKHRlY2huaWNhbCkgc3lzdGVtIGRlbGl2ZXJpbmcgDQogICBub3Rhcnkgc2VydmljZXMuDQog ICBQb3NzaWJsZSBzZXJ2aWNlcyBNVVNUIHN1cHBvcnQgYXQgbGVhc3Qgb25lIHVzZSBjYXNlcyBj b21wbGV0ZWx5IA0KICAgYnV0IE5FRUQgTk9UIHN1cHBvcnQgYWxsIHBvc3NpYmxlIHVzZSBjYXNl cyBmb3Igbm90YXJ5IHN5c3RlbXMgDQogICBhbmQgc2VydmljZXMuIFRoaXMgd2F5IG9uZSBjYW4g aGF2ZSBhIHNlbGYtY29udGFpbmVkIHN5c3RlbSBmb3IgDQogICBlYWNoIHNlcGFyYXRlIHRhc2su DQogICANCg0KNC4xICBFbmFibGUgc3VibWlzc2lvbiwgcmV0cmlldmFsIGFuZCBkZWxldGlvbg0K DQo0LjEuMSAgRnVuY3Rpb25hbCBSZXF1aXJlbWVudHMNCg0KICAgQSBub3Rhcnkgc2VydmljZSBt dXN0IHBlcm1pdCBlbnRpdGllcyB0byBwZXJmb3JtIHRoZQ0KICAgZm9sbG93aW5nIGJhc2ljIG9w ZXJhdGlvbnM6DQoNCiAgICAgIC0gc3VibWl0IGRhdGENCiAgICAgIC0gcmV0cmlldmUgZGF0YSwN CiAgICAgIC0gZGVsZXRlIGRhdGEgKGlmIHRoZSBub3Rhcnkgc2VydmljZXMgaXMgYXV0aG9yaXNl ZCB0byBhbGxvdyANCiAgICAgICAgZGVsZXRpb24gYXQgYSBnaXZlbiBwb2ludCBpbiB0aW1lKQ0K DQogICBVc2VycyBtdXN0IGJlIGFibGUgdG8gcmVxdWVzdCBhIHNwZWNpZmljIHNlcnZpY2UgdGhl eSB3YW50IHRvIGFjY2VzcywgDQogICBhbmQgcmVjZWl2ZSBhbiBhdHRlc3RhdGlvbiAocG9zc2li bHkgYSBkaWdpdGFsbHkgc2lnbmVkIGRvY3VtZW50KSANCiAgIGFmdGVyIHRoZSBjb21wbGV0aW9u IG9mIHRoZSBzZXJ2aWNlLiBUaGUgZm9ybWF0IGZvciB0aGUgDQogICBhY2tub3dsZWRnZW1lbnRz IG11c3QgYWxsb3cgdGhlIGlkZW50aWZpY2F0aW9uIG9mIHRoZSBub3Rhcnkgc2VydmljZSANCiAg IHByb3ZpZGVyOyBpbiBzcGVjaWZpYyBjYXNlcyBhbHNvIHRoZSBpZGVudGl0eSBvZiB0aGUgaW5k aXZpZHVhbCBodW1hbiANCiAgIG5vdGFyeS4gVGhlIGFja25vd2xlZGdlbWVudCBvZiBhIHN1Y2Nl c3NmdWwgZXhlY3V0aW9uIG9mIHRoZSBub3RhcnkgDQogICBzZXJ2aWNlIHNob3VsZCBwZXJtaXQg dGhlIHN1Ym1pdHRlciB0byB2ZXJpZnkgdGhhdCB0aGUgY29ycmVjdCBkYXRhIA0KICAgd2FzIHJl Y2VpdmVkIGJ5IHRoZSBzZXJ2aWNlIGFuZCB0aGUgY29ycmVjdCBraW5kIG9mIHNlcnZpY2Ugd2Fz IA0KICAgZXhlY3V0ZWQuIA0KICAgDQogICBBbGwgcmVxdWVzdHMgdG8gYSBub3Rhcnkgc2Vydmlj ZSBNVVNUIGJlIGF1dGhlbnRpY2F0ZWQuIA0KICAgDQogICBGb2xsb3dpbmcgc3VibWlzc2lvbiwg dGhlIHNlcnZpY2UgbXVzdCBzdGFydCBhIHdvcmtmbG93IHRvIGVuYWJsZSB0aGUgDQogICBodW1h biBub3RhcnkgdG8gZnVsZmlsbCBhbmQgc3VwZXJ2aXNlIGl0cyB3b3JrLiBJZiBzdXBlcnZpc2lv biBvciBhIA0KICAgcmVzcG9uc2Ugd2l0aGluIGEgZ2l2ZW4gdGltZWZyYW1lIGlzIG5vdCBwb3Nz aWJsZSB0aGUgc2VydmljZSBtdXN0IA0KICAgcmVwb3J0IGFuIGVycm9yIHRvIHRoZSB1c2VyLg0K DQogICBBZnRlciBzdWJtaXNzaW9uIGFuZCBiZWZvcmUgY29tcGxldGlvbiBvZiB0aGUgc2Vydmlj ZSB0aGUgdXNlciBTSE9VTEQgDQogICBhbHdheXMgYmUgYWJsZSB0byByZWNlaXZlIGluZm9ybWF0 aW9uIGFib3V0IHRoZSBzdGF0dXMgb2YgdGhlIA0KICAgcHJvY2Vzcy4gVGhlIGFjY2VzcyB0byB0 aGUgc3RhdHVzIGluZm9ybWF0aW9uIE1VU1Qgb25seSBiZSBhY2Nlc3NpYmxlIA0KICAgdG8gYXV0 aG9yaXNlZCBlbnRpdGllcy4NCg0KICAgRGVsZXRpb24gcmVxdWVzdHMgYWxzbyBNVVNUIGJlIGF1 dGhvcmlzZWQgYW5kIGFkZGl0aW9uYWxseSB0aGVpciBNVVNUIA0KICAgYmUgYSBraW5kIG9mIGF1 dGhvcmlzYXRpb24gcG9saWN5IHdoaWNoIGNvbnRyb2xzIHRoYXQgdGhlIG5vdGFyeSANCiAgIHNl cnZpY2UgZG9lcyBub3QgZGVsZXRlIGluZm9ybWF0aW9uIHRoYXQgbXVzdCBiZSBrZXB0Lg0KDQog ICBJdCBtdXN0IGJlIHBvc3NpYmxlIHRvIGF1dGhlbnRpY2F0ZSByZXF1ZXN0cyBhbmQgcmVzcG9u c2VzLiBUaGlzIG1heQ0KICAgYmUgYWNjb21wbGlzaGVkIHVzaW5nIHRyYW5zcG9ydCBzZWN1cml0 eSBtZWNoYW5pc21zLg0KDQpHb25kcm9tLCBldCBhbC4gICAgICAgICBFeHBpcmVzIEphbnVhcnkg IDEsIDIwMDQgICAgICAgICAgICAgICAgW1BhZ2UgN10NCgwNCkludGVybmV0LURyYWZ0ICAgIE5v dGFyeSBTZXJ2aWNlcyByZXF1aXJlbWVudHMJCQkgICBKdWx5IDIwMDQNCg0KICAgDQo0LjIgUHJv dmlkZSBzZXJ2aWNlcw0KDQo0LjIuMSAgRnVuY3Rpb25hbCBSZXF1aXJlbWVudHMNCg0KICAgQWxs IHNlcnZpY2VzIG11c3QgYmUgd2VsbCBkb2N1bWVudGVkIGFuZCB0aGUgbm90YXJ5IHNlcnZpY2Ug TVVTVCANCiAgIGNyZWF0ZSByZXBvcnRzIHdob3NlIGF1dGhlbml0aWNpdHkgY2FuIGJlIHZlcmlm aWVkIGJ5IGFuIGluaXRpYWwgDQogICBjbGllbnQgYW5kIGFueSBvdGhlciBpbnRlcmVzdGVkIGF1 dGhvcmlzZWQgcGFydHksIGZvciBhIGxvbmcgdGltZSANCiAgIGFmdGVyIHRoZSBjcmVhdGlvbiBv ZiB0aGUgcmVwb3J0Lg0KDQogICBEZXBlbmRpbmcgb24gdGhlIGtpbmQgb2Ygc2VydmljZSBvbmxp bmUgaW50ZXJhY3Rpb24gYmV0d2VlbiB0aGUgDQogICBwYXJ0aWNpcGFudHMgTVVTVCBiZSBwb3Nz aWJsZS4NCg0KDQo0LjMgIFN1cHBvcnQgRGVtb25zdHJhdGlvbiBvZiBTZXJ2aWNlIEludGVncml0 eSBhbmQgVHJ1c3QNCg0KNC4zLjEgIEZ1bmN0aW9uYWwgUmVxdWlyZW1lbnRzDQoNCiAgIEEgbm90 YXJ5IHNlcnZpY2UgTVVTVCBiZSBhYmxlIHRvIGRlbW9uc3RyYXRlIHRoYXQgdGhlIGNsaWVudHMg YW5kIA0KICAgdXNlcnMgY2FuIHRydXN0IGl0LiBGb3IgdGhpcyBldmFsdWF0aW9uIHJlY29yZHMg Ynkgb3RoZXIgdHJ1c3RlZCANCiAgIHBhcnRpZXMgKGUuZy4gZ292ZXJubWVudCBhdXRob3JpdGll cyksIHRoZSBpZGVudGl0eSBvZiBtZW1iZXJzIG9mIA0KICAgdGhlIG5vdGFyeSBvZmZpY2UgYW5k IGZ1cnRoZXIgZG9jdW1lbnRhdGlvbiBNVVNUIGJlIGVhc2lseSBhY2Nlc3NpYmxlIA0KICAgdG8g dGhlIGNsaWVudC4gRm9yIGV2ZXJ5IHVzZXIgYW5kIGNsaWVudCBNVVNUIGJlIG9idmlvdXMgaWYg DQogICBzeXN0ZW1zIGFyZSB0ZW1wZXJlZCBvciBtYW5pcHVsYXRlZC4gDQogICANCg0KNC40ICBP cGVyYXRpb24NCg0KNC40LjEgIEZ1bmN0aW9uYWwgUmVxdWlyZW1lbnRzDQoNCiAgIFRoZSBvcGVy YXRpb24gb2YgdGhlIG5vdGFyeSBzZXJ2aWNlIG11c3QgYmUgdW5kZXIgdGhlIGNvbXBsZXRlIGFu ZCANCiAgIHVuY29uZGl0aW9uYWwgY29udHJvbCBvZiB0aGUgbm90YXJ5IG9mZmljZS4gSXQgTVVT VCBiZSBpbXBvc3NpYmxlIA0KICAgdG8gbWFuaXB1bGF0ZSB0aGUgc3lzdGVtIHdpdGhvdXQgdGhl IGh1bWFuIG5vdGFyaWVzIGZyb20gdGhlIG9mZmljZSANCiAgIG5vdGljaW5nIGl0LiANCg0KNC41 ICBEYXRhIGNvbmZpZGVudGlhbGl0eQ0KDQo0LjUuMSAgRnVuY3Rpb25hbCBSZXF1aXJlbWVudHMN Cg0KICAgVGhlIG5vdGFyeSBzZXJ2aWNlIE1VU1QgYWxsb3cgdG8gcmVzcGVjdCB0aGUgY29uZmlk ZW50aWFsaXR5IA0KICAgcmVxdWlyZW1lbnQgb2YgYSBwYXJ0aWN1bGFyIHByb2NlZHVyZSB0byBi ZSBleGVjdXRlZC4NCg0KICAgSWYgaW5mb3JtYXRpb24gaXMgZGVwbG95ZWQgb24gc3lzdGVtcyBv dXRzaWRlIHRoZSBkaXJlY3Qgc3VwZXJ2aXNpb24gDQogICBvZiB0aGUgbm90YXJ5IG9mZmljZSBp dCBpcyBNQU5EQVRPUlkgdG8gZW5jcnlwdCB0aGUgaW5mb3JtYXRpb24gd2l0aCANCiAgIG1heGlt dW0gc2VjdXJpdHkuIElmIGVuY3J5cHRpb24gYmVjb21lcyB3ZWFrLCBkdWUgdG8gaW1wcm92ZW1l bnRzIGluIA0KICAgY3J5cHRvZ3JhcGh5IHRoZSBub3Rhcnkgb2ZmaWNlIGhhcyB0byBiZSBpbmZv cm1lZCBhbmQgYWxsIA0KICAgaW5mb3JtYXRpb24gaGFzIHRvIGVuY3J5cHRlZCB3aXRoIGJldHRl ciBhbGdvcml0aG1zIGFnYWluLiANCg0KICAgQWxsIGNvbW11bmljYXRpb25zIHdpdGggYSBub3Rh cnkgc2VydmljZSBNVVNUIGJlIGVuY3J5cHRlZC4gDQogICAoZS5nLiBTU0wpICBUcmFkaXRpb25h bCBzdGFuZGFyZGl6ZWQgZW5jcnlwdGluZyBtZXRob2RzIGFuZCBmb3JtYXRzLCANCiAgIGUuZy4g Q01TLCBzaG91bGQgYmUgc3VwcG9ydGVkLg0KDQpHb25kcm9tLCBldCBhbC4gICAgICAgICBFeHBp cmVzIEphbnVhcnkgIDEsIDIwMDQgICAgICAgICAgICAgICAgW1BhZ2UgOF0NCgwNCkludGVybmV0 LURyYWZ0ICAgIE5vdGFyeSBTZXJ2aWNlcyByZXF1aXJlbWVudHMJCQkgICBKdWx5IDIwMDQNCg0K DQo1LiAgT3BlcmF0aW9uYWwgQ29uc2lkZXJhdGlvbnMNCg0KICAgQSBub3Rhcnkgc2VydmljZSBt dXN0IGJlIGFibGUgdG8gd29yayBlZmZpY2llbnRseSBldmVuIGZvciBsYXJnZSANCiAgIGFtb3Vu dHMgb2YgZGF0YSBvYmplY3RzIGFuZCByZXF1ZXN0cy4gDQogICANCiAgIEluIG9yZGVyIHRvIGxp bWl0IGV4cGVuc2VzIGFuZCB0byBhY2hpZXZlIGhpZ2ggcGVyZm9ybWFuY2UsIHRoZSANCiAgIGlu dm9sdmVtZW50IG9mIG90aGVyIHRydXN0ZWQgdGhpcmQgcGFydGllcyBzaG91bGQgYmUgbWluaW1p emVkLg0KDQoNCg0KDQo2LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMNCg0KICAgVHJ1c3QgaXMg dGhlIHByaW5jaXBhbCBhc3NldCBvZiBhIG5vdGFyeSBzZXJ2aWNlLiBDb25jZXJuaW5nIHRoYXQg dGhlIA0KICAgaW1wbGVtZW50YXRpb24gb2Ygc3VjaCBhIHNlcnZpY2UgbXVzdCBiZSB2ZXJ5IGNh cmVmdWwgc28gdGhhdCBubyBkYXRhIA0KICAgaW50ZWdyaXR5IGNhbiBiZSBsb3N0IG9yIG1hbmlw dWxhdGlvbiBvZiB0aGUgc3lzdGVtIGNhbiBiZSBkb25lLiANCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpHb25kcm9t LCBldCBhbC4gICAgICAgICBFeHBpcmVzIEphbnVhcnkgIDEsIDIwMDQgICAgICAgICAgICAgICAg W1BhZ2UgOV0NCgwNCkludGVybmV0LURyYWZ0ICAgIE5vdGFyeSBTZXJ2aWNlcyByZXF1aXJlbWVu dHMJCQkgICBKdWx5IDIwMDQNCg0KDQo3LiAgQWNrbm93bGVkZ2VtZW50cw0KDQogICBUaGFua3Mg dG8gbWVtYmVycyBvZiB0aGUgTFRBTlMgbWFpbGluZyBsaXN0IGZvciByZXZpZXcgb2YgZWFybGll cg0KICAgZHJhZnRzIGFuZCBtYW55IHN1Z2dlc3Rpb25zLg0KDQoNCg0KQXV0aG9ycycgQWRkcmVz c2VzDQoNCiAgIFRvYmlhcyBHb25kcm9tDQogICBJWE9TIFNvZnR3YXJlIEFHDQogICBCcmV0b25p c2NoZXIgUmluZyAxMg0KICAgODU2MzAgR3Jhc2JydW5uIC8gTXVuaWNoIA0KICAgR2VybWFueQ0K DQogICBGYXg6ICs0OSAoODkpIDQ2MjktMzMtMTgxNg0KICAgZU1haWw6IHRvYmlhcy5nb25kcm9t QGl4b3MuZGUNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KR29uZHJvbSwgZXQgYWwuICAgICAgICAgRXhwaXJlcyBKYW51 YXJ5ICAxLCAyMDA0ICAgICAgICAgICAgICAgW1BhZ2UgMTBdDQoMDQpJbnRlcm5ldC1EcmFmdCAg ICBOb3RhcnkgU2VydmljZXMgcmVxdWlyZW1lbnRzCQkJICAgSnVseSAyMDA0DQoNCg0KSW50ZWxs ZWN0dWFsIFByb3BlcnR5IFN0YXRlbWVudA0KDQogICBUaGUgSUVURiB0YWtlcyBubyBwb3NpdGlv biByZWdhcmRpbmcgdGhlIHZhbGlkaXR5IG9yIHNjb3BlIG9mIGFueQ0KICAgaW50ZWxsZWN0dWFs IHByb3BlcnR5IG9yIG90aGVyIHJpZ2h0cyB0aGF0IG1pZ2h0IGJlIGNsYWltZWQgdG8NCiAgIHBl cnRhaW4gdG8gdGhlIGltcGxlbWVudGF0aW9uIG9yIHVzZSBvZiB0aGUgdGVjaG5vbG9neSBkZXNj cmliZWQgaW4NCiAgIHRoaXMgZG9jdW1lbnQgb3IgdGhlIGV4dGVudCB0byB3aGljaCBhbnkgbGlj ZW5zZSB1bmRlciBzdWNoIHJpZ2h0cw0KICAgbWlnaHQgb3IgbWlnaHQgbm90IGJlIGF2YWlsYWJs ZTsgbmVpdGhlciBkb2VzIGl0IHJlcHJlc2VudCB0aGF0IGl0DQogICBoYXMgbWFkZSBhbnkgZWZm b3J0IHRvIGlkZW50aWZ5IGFueSBzdWNoIHJpZ2h0cy4gSW5mb3JtYXRpb24gb24gdGhlDQogICBJ RVRGJ3MgcHJvY2VkdXJlcyB3aXRoIHJlc3BlY3QgdG8gcmlnaHRzIGluIHN0YW5kYXJkcy10cmFj ayBhbmQNCiAgIHN0YW5kYXJkcy1yZWxhdGVkIGRvY3VtZW50YXRpb24gY2FuIGJlIGZvdW5kIGlu IEJDUC0xMS4gQ29waWVzIG9mDQogICBjbGFpbXMgb2YgcmlnaHRzIG1hZGUgYXZhaWxhYmxlIGZv ciBwdWJsaWNhdGlvbiBhbmQgYW55IGFzc3VyYW5jZXMgb2YNCiAgIGxpY2Vuc2VzIHRvIGJlIG1h ZGUgYXZhaWxhYmxlLCBvciB0aGUgcmVzdWx0IG9mIGFuIGF0dGVtcHQgbWFkZSB0bw0KICAgb2J0 YWluIGEgZ2VuZXJhbCBsaWNlbnNlIG9yIHBlcm1pc3Npb24gZm9yIHRoZSB1c2Ugb2Ygc3VjaA0K ICAgcHJvcHJpZXRhcnkgcmlnaHRzIGJ5IGltcGxlbWVudG9ycyBvciB1c2VycyBvZiB0aGlzIHNw ZWNpZmljYXRpb24gY2FuDQogICBiZSBvYnRhaW5lZCBmcm9tIHRoZSBJRVRGIFNlY3JldGFyaWF0 Lg0KDQogICBUaGUgSUVURiBpbnZpdGVzIGFueSBpbnRlcmVzdGVkIHBhcnR5IHRvIGJyaW5nIHRv IGl0cyBhdHRlbnRpb24gYW55DQogICBjb3B5cmlnaHRzLCBwYXRlbnRzIG9yIHBhdGVudCBhcHBs aWNhdGlvbnMsIG9yIG90aGVyIHByb3ByaWV0YXJ5DQogICByaWdodHMgd2hpY2ggbWF5IGNvdmVy IHRlY2hub2xvZ3kgdGhhdCBtYXkgYmUgcmVxdWlyZWQgdG8gcHJhY3RpY2UNCiAgIHRoaXMgc3Rh bmRhcmQuIFBsZWFzZSBhZGRyZXNzIHRoZSBpbmZvcm1hdGlvbiB0byB0aGUgSUVURiBFeGVjdXRp dmUNCiAgIERpcmVjdG9yLg0KDQoNCkZ1bGwgQ29weXJpZ2h0IFN0YXRlbWVudA0KDQogICBDb3B5 cmlnaHQgKEMpIFRoZSBJbnRlcm5ldCBTb2NpZXR5ICgyMDA0KS4gQWxsIFJpZ2h0cyBSZXNlcnZl ZC4NCg0KICAgVGhpcyBkb2N1bWVudCBhbmQgdHJhbnNsYXRpb25zIG9mIGl0IG1heSBiZSBjb3Bp ZWQgYW5kIGZ1cm5pc2hlZCB0bw0KICAgb3RoZXJzLCBhbmQgZGVyaXZhdGl2ZSB3b3JrcyB0aGF0 IGNvbW1lbnQgb24gb3Igb3RoZXJ3aXNlIGV4cGxhaW4gaXQNCiAgIG9yIGFzc2lzdCBpbiBpdHMg aW1wbGVtZW50YXRpb24gbWF5IGJlIHByZXBhcmVkLCBjb3BpZWQsIHB1Ymxpc2hlZA0KICAgYW5k IGRpc3RyaWJ1dGVkLCBpbiB3aG9sZSBvciBpbiBwYXJ0LCB3aXRob3V0IHJlc3RyaWN0aW9uIG9m IGFueQ0KICAga2luZCwgcHJvdmlkZWQgdGhhdCB0aGUgYWJvdmUgY29weXJpZ2h0IG5vdGljZSBh bmQgdGhpcyBwYXJhZ3JhcGggYXJlDQogICBpbmNsdWRlZCBvbiBhbGwgc3VjaCBjb3BpZXMgYW5k IGRlcml2YXRpdmUgd29ya3MuIEhvd2V2ZXIsIHRoaXMNCiAgIGRvY3VtZW50IGl0c2VsZiBtYXkg bm90IGJlIG1vZGlmaWVkIGluIGFueSB3YXksIHN1Y2ggYXMgYnkgcmVtb3ZpbmcNCiAgIHRoZSBj b3B5cmlnaHQgbm90aWNlIG9yIHJlZmVyZW5jZXMgdG8gdGhlIEludGVybmV0IFNvY2lldHkgb3Ig b3RoZXINCiAgIEludGVybmV0IG9yZ2FuaXphdGlvbnMsIGV4Y2VwdCBhcyBuZWVkZWQgZm9yIHRo ZSBwdXJwb3NlIG9mDQogICBkZXZlbG9waW5nIEludGVybmV0IHN0YW5kYXJkcyBpbiB3aGljaCBj YXNlIHRoZSBwcm9jZWR1cmVzIGZvcg0KICAgY29weXJpZ2h0cyBkZWZpbmVkIGluIHRoZSBJbnRl cm5ldCBTdGFuZGFyZHMgcHJvY2VzcyBtdXN0IGJlDQogICBmb2xsb3dlZCwgb3IgYXMgcmVxdWly ZWQgdG8gdHJhbnNsYXRlIGl0IGludG8gbGFuZ3VhZ2VzIG90aGVyIHRoYW4NCiAgIEVuZ2xpc2gu DQoNCiAgIFRoZSBsaW1pdGVkIHBlcm1pc3Npb25zIGdyYW50ZWQgYWJvdmUgYXJlIHBlcnBldHVh bCBhbmQgd2lsbCBub3QgYmUNCiAgIHJldm9rZWQgYnkgdGhlIEludGVybmV0IFNvY2lldHkgb3Ig aXRzIHN1Y2Nlc3NvcnMgb3IgYXNzaWduZWVzLg0KDQogICBUaGlzIGRvY3VtZW50IGFuZCB0aGUg aW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBpcyBwcm92aWRlZCBvbiBhbg0KICAgIkFTIElT IiBiYXNpcyBhbmQgVEhFIElOVEVSTkVUIFNPQ0lFVFkgQU5EIFRIRSBJTlRFUk5FVCBFTkdJTkVF UklORw0KICAgVEFTSyBGT1JDRSBESVNDTEFJTVMgQUxMIFdBUlJBTlRJRVMsIEVYUFJFU1MgT1Ig SU1QTElFRCwgSU5DTFVESU5HDQogICBCVVQgTk9UIExJTUlURUQgVE8gQU5ZIFdBUlJBTlRZIFRI QVQgVEhFIFVTRSBPRiBUSEUgSU5GT1JNQVRJT04NCg0KDQoNCkdvbmRyb20sIGV0IGFsLiAgICAg ICAgIEV4cGlyZXMgSmFudWFyeSAgMSwgMjAwNCAgICAgICAgICAgICAgIFtQYWdlIDExXQ0KDA0K SW50ZXJuZXQtRHJhZnQgICAgTm90YXJ5IFNlcnZpY2VzIHJlcXVpcmVtZW50cwkJCSAgIEp1bHkg MjAwNA0KDQoNCiAgIEhFUkVJTiBXSUxMIE5PVCBJTkZSSU5HRSBBTlkgUklHSFRTIE9SIEFOWSBJ TVBMSUVEIFdBUlJBTlRJRVMgT0YNCiAgIE1FUkNIQU5UQUJJTElUWSBPUiBGSVRORVNTIEZPUiBB IFBBUlRJQ1VMQVIgUFVSUE9TRS4NCg0KDQpBY2tub3dsZWRnbWVudA0KDQogICBGdW5kaW5nIGZv ciB0aGUgUkZDIEVkaXRvciBmdW5jdGlvbiBpcyBjdXJyZW50bHkgcHJvdmlkZWQgYnkgdGhlDQog ICBJbnRlcm5ldCBTb2NpZXR5Lg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpHb25kcm9t LCBldCBhbC4gICAgICAgICBFeHBpcmVzIEphbnVhcnkgIDEsIDIwMDQgICAgICAgICAgICAgICBb UGFnZSAxMl0NCg0K ------_=_NextPart_001_01C468C7.AB3849F0--
- Re: Use of "TAA" acronym (was Comments on LTANS d… Peter Sylvester
- RE: Use of "TAA" acronym (was Comments on LTANS d… Peter Sylvester
- RE: Use of "TAA" acronym (was Comments on LTANS d… Carl Wallace
- RE: Use of "TAA" acronym (was Comments on LTANS d… Larry Masinter
- Re: Use of "TAA" acronym (was Comments on LTANS d… Jeff Williams