Subject: A question about requirements

From: Avri Doria <[email-masked]>
Date: Fri, 19 Sep 2003 10:47:34 +0900

Hi,

As I watch discussions in some other groups, and am possibly 
approaching such an issue in my WG, I have started wondering about the 
force of requirements documents published as Informational.

By 2026 definition:

>    An "Informational" specification is published for the general
>    information of the Internet community, and does not represent an
>    Internet community consensus or recommendation.  The Informational
>    designation is intended to provide for the timely publication of a
>    very broad range of responsible informational documents from many
>    sources, subject only to editorial considerations and to 
> verification
>    that there has been adequate coordination with the standards process

yet fill them with words like MUST, MUST NOT, SHOULD etc...

My question is, what force do words like these have in a document that 
is merely informational.

Are IETF 'requirements' only guidelines that MAY or MAY NOT be minded?  
Or have I missed some BCP that defines such force?

thanks

a.

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 19 Sep 2003 23:05:50 -0700 (PDT)

> yet fill them with words like MUST, MUST NOT, SHOULD etc...

One thing to understand is that these terms do not have the same meaning
in a requirements document as they do in a specification fulfilling the
requirements.   For example, saying that a protocol satisfying the requirements
MUST support encryption is not the same thing as saying that encryption
MUST be mandatory-to-implement or mandatory to use within the protocol itself.
One might even argue that optional encryption support could satisfy the
requirement.  This means that in requirements documents normative language
is inherently weaker than in a protocol specification.

> My question is, what force do words like these have in a document that

They have whatever force the WG (and the IESG) wishes to give them.  Many
of the recent requirements documents might be better off being forgotten
entirely -- and some have been deemed so valuable as to not even be worth
finishing.

> Or have I missed some BCP that defines such force?

In practice there are elements of requirements documents which appear
foolish in hindsight -- and I would argue that they only need be minded
to the extent that they make sense once the WG understands the problem
better.

---

From: Bob Hinden <[email-masked]>
Date: Mon, 22 Sep 2003 10:21:44 -0700

Bernard,

>entirely -- and some have been deemed so valuable as to not even be worth

...

>to the extent that they make sense once the WG understands the problem

I agree that writing a requirement documents is a good way for the working
group to agree on what the problem is they are tasked to solve.  I think
there is starting to be a lot of experience that completing the
requirements document and publishing it as an Info RFC is not worth the
effort.  I am starting to think that most requirements documents should be
"working" documents and never be published as RFCs.

I also think that developing requirements and a solution in parallel is
preferable to doing them sequentially.  It is too easy to write conflicting
or impossible requirements, where developing them in parallel allows for
feedback between the two and improves both.  It's also easier at times to
reach consensus on a solution (that generally meets the requirements) than
on the requirements document itself.  I think we tend to evaluate them
differetly.

Bob

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 24 Sep 2003 07:42:15 -0700

> "working" documents and never be published as RFCs.

my somewhat facile remark about requirements documents this month is that a 
good requirements document should be something like 4 pages - large enough 
for anyone to read to figure out what the effort's supposed to help with, 
short enough that people will actually read it.

But I suspect that the effort to write and get consensus on a short 
document is often larger than the effort to write a long one, so this might 
not be helpful. (Can you imagine a WG agreeing on a 4-page requirements 
document for requirements documents? :-)

                          Harald

---

From: Stephen Kent <[email-masked]>
Date: Wed, 24 Sep 2003 12:57:24 -0400

>"working" documents and never be published as RFCs.

I have had the opposite experience in PKIX. in working on SCVP, we 
encountered debates about functionality that might have run on for 
some time, but the existence of a requirements RFC allowed us to 
quickly focus the debate.

>on the requirements document itself.  I think we tend to evaluate them

I agree that parallel development can be attractive, but it does not 
help resolve the requirements debate sooner rather than later, a 
two-edged sword.