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>&nbsp;</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>&nbsp;</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) =
&#8211; 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&#8230;. =
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 &amp; 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>&nbsp;</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 &amp; Tobias) &#8211; 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>&nbsp;</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>&nbsp;</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>&nbsp;</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>&nbsp;</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:&nbsp; +49 (0) 89 4629-1816<br>
Telefax:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +49 (0) 89 =
4629-33-1816<br>
eMail:&nbsp;</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:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</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>&nbsp;</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>&nbsp;</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>&nbsp;</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>&nbsp;</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>&nbsp;</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>&nbsp;</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>&nbsp;</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>&nbsp;</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>&nbsp;</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>&nbsp;</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:&nbsp; +49 (0) 89 4629-1816<br>
Telefax:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +49 (0) 89 =
4629-33-1816<br>
eMail:&nbsp;</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:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</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>&nbsp;</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>&nbsp;</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.&nbsp; 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>&nbsp;</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&nbsp;Electronic=20
Notary.&nbsp; This also means dealing with electronic documents =
only.&nbsp;=20
There are lot of other non-IT related forensics issues involved with=20
paper.&nbsp; 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>&nbsp;</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 &#8220;requirements for notary services&#8221; 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>&nbsp;</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>&nbsp;</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>&nbsp;</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>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=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>&nbsp;</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>&nbsp;</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:&nbsp; +49 (0)=20
  89 4629-1816<BR>Telefax:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +49 =
(0) 89=20
  4629-33-1816<BR>eMail:&nbsp;</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:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</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>&nbsp;</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.&nbsp; 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.&nbsp; 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>&nbsp;</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>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D=230000ff size=3D2><SPAN class=3D356523623-1=
3072004>I will 
gladly join the effort&nbsp;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>&nbsp;</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,&nbsp;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>&nbsp;</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>&nbsp;</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>&nbsp;</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>&nbsp;</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>&nbsp;</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>&nbsp;</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>&nbsp;</o:p></SPAN>=
</FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN 
  style=3D=22FONT-SIZE: 10pt; FONT-FAMILY: Arial=22>&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  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>&nbsp;</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>&nbsp;</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:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +49 (0)=
 89 
  4629-33-1816<BR>eMail:&nbsp;</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:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</=
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>&nbsp;</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>&nbsp;</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 =
&#8220;requirements
for notary services&#8221; 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>&nbsp;</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>&nbsp;</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>&nbsp;</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>&nbsp;</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>&nbsp;</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>&nbsp;</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:&nbsp; +49 (0) 89 4629-1816<br>
Telefax:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +49 (0) 89 =
4629-33-1816<br>
eMail:&nbsp;</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:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</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>&nbsp;</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--