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

[Larry Masinter <[e-mail]>]

(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:[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
> 
>