Re: Use of RFC 2119 terms in requirements docs (was RE: Comments on LTANS documents)

[Jeff Williams <[e-mail]>]

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:[e-mail]]
> > Sent: Saturday, July 31, 2004 1:41 AM
> > To: Larry Masinter
> > Cc: 'Denis Pinkas'; 'IETF LTANS'; [e-mail]
> > 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 [e-mail]
> >  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 [e-mail]
 Registered Email addr with the USPS
Contact Number: 214-244-4827