Subject: 3. Volunteers to work on Requirements (was RE: [Asrg] voting?)

From: Paul Judge <[email-masked]>
Date: Wed, 2 Apr 2003 09:38:13 -0500

Eric, if you wish to work on requirements, you should begin with the work
that has already been done in the group. Please see my message from March
19th.
https://www1.ietf.org/mail-archive/working-groups/asrg/current/msg01721.html
Also, Russell Brand volunteered to work on requirements, so I suggest that
the two of you touch bases.

> -----Original Message-----
> From: Eric D. Williams [mailto:[email-masked]] 
> Sent: Tuesday, April 01, 2003 6:49 PM
> To: 'matthew richards'; [email-masked]'
> Subject: RE: [Asrg] voting?

> So for the past few days that is the task I have been 
> monitoring and trying to 
> tackle by participating (where I can) and soliciting 
> information on the 
> consensus or merely 'thinking' on some of the issues.  So far 
> a paper-man of 
> requirements has emerged, but there is (quite) a bit more to 
> go before I can 
> present a draft.
> 
> The draft of requirements ToC will include information (I 
> suggest if anyone has 
> any advice or wants to help now would be as good a time as 
> any) on requirements 
> in the following formats:
> 
> Section #. Requirement
> Section #.1 Requirement Rationale
> Section #.1.1 Scenario (optional)
> 
> I will not use the RFC2119 the convention for keywords, but 
> will flow with 
> consensus as follows:
> 
> "  keywords MUST, MUST NOT, SHOULD, and MAY are NOT as in RFC 2119,
>    but rather:
> 
>    o  MUST: This word, or the terms "REQUIRED" or "SHALL", means that
>       the described behavior or characteristic is an absolute
>       requirement for a proposed ASRG specification.
> 
>    o  MUST NOT: This phrase, or the phrase "SHALL NOT", means that the
>       described behavior or characteristic is an absolute 
> prohibition of
>       a proposed ASRG specification.
> 
>    o  SHOULD: This word, or the adjective "RECOMMENDED", means that
>       there may exist valid reasons in particular circumstances for a
>       proposed ASRG specification to ignore described behavior or
>       characteristics.
> 
>    o  MAY: This word, or the adjective "OPTIONAL", means that 
> described
>       behavior or characteristics are truly optional for a 
> proposed ASRG
>       specification.  One proposed specification may choose to include
>       the described behavior or characteristic while another proposed
>       specification may omit the same behavior or 
> characteristic.         "
> 

Why not use RFC2119 conventions? This could lead to much confusion.

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Eric D. Williams" <[email-masked]>
Date: Wed, 2 Apr 2003 11:15:49 -0500

On Wednesday, April 02, 2003 9:38 AM, Paul Judge 
[SMTP:[email-masked]] wrote:
8<...>8
> Why not use RFC2119 conventions? This could lead to much confusion.

While I concede some confusion could result, given an environment where 
requirements are being developed the 2119 definitions do not all aptly apply. 
 This divergence allows us to develop a set of definitions that encompasses the 
intent of the requirements implementation conformance, rather than pro forma 
compliance with some standard.

>       proposed ASRG specification to ignore described behavior or

Where in the case of defining requirements perhaps the full implications of 
ignoring a particular characteristic we describe may not be necessary of 
applicable to the methodology. This and the exclusion of SHOULD NOT, where we 
would not want to limit the proposal to the constraints of a particular 
methodology when proposal may be offering completely different approaches that 
satisfy the requirements. And;

>    o  MAY: This word, or the adjective "OPTIONAL", means that described
>       behavior or characteristics are truly optional for a proposed ASRG
>       specification may omit the same behavior or characteristic.

Where in the case of a proposal we again do not want to limit the methodologies 
to any specific subset of solutions.  In the 2119 parlance the use of MAY 
connotes that interoperation considerations with different implementations that 
do or do not support a specific option or characteristic, MUST be considered. 
 In the case of these requirements I would propose that the interoperability 
considerations would be left either to the IETF or not considered as the 
proposal would constitute the basis for operation.

-e