SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    IPS: shall, SHALL, must, MUST, etc.



    In response to a couple of Thomas's comments on requirements
    terminology, let me offer some general guidance:
    
    First, "SHALL" is acceptable IETF terminology, and is equivalent to "MUST"
    - see RFC 2119.  Second, let me try to explain the distinction between
    upper case lower case versions of these and other terms/phrases defined
    in RFC 2119.  Upper case versions of MUST, SHOULD, MAY, etc. are used to
    specify requirements imposed upon implementations - as indicated by
    Section 6 of RFC 2119, they MUST be used only when necessary.  Lower case
    versions of these terms are potentially ambiguous - they may indicate
    requirements or may be descriptive of what happens as a consequence of
    other requirements, constraints, etc.  If the intent is to impose a
    requirement, the upper case versions are appropriate to avoid this
    ambiguity, as if it's possible to interpret a lower case version as
    not imposing a requirement, someone will interpret it in that fashion.
    
    As to Thomas's specific comments on iSCSI requirements:
    
    > Comment 6:
    > 
    > Section 5.2 on Page 115:
    > 
    > "If the security negotiation fails at the target then the target MUST
    > send the appropriate Login Response PDU. If the security negotiation
    > fails at the initiator, the initiator [shall] drop the connection."
    > 
    > - Do you really mean "shall"? Shall is IEEE terminology do 
    > you not mean
    > "MUST"? This is a recurring problem in many places in the draft, for
    > brevity I would suggest a text search and examination of each "shall".
    >
    > Comment 8:
    > 
    > Section 6 on Page 116:
    > 
    > "If the target responds to a text request with the F bit set to 1,
    > with a text response with the F bit set to 0, the initiator 
    > [must] keep
    > sending the text request (even empty) with the F bit set to 1 until
    > it gets the text response with the F bit set to 1. Responding to a
    > text request with the F bit set to 1 with an empty (no key=value
    > pairs) is not an error but is discouraged."
    > 
    > - "must" versus "MUST"! Do you not mean "MUST"? This is a recurring
    > problem in many places in the draft, for brevity I would suggest a
    > text search and examination of each "must'.
    
    
    For comment 6, upper case is in order, and "SHALL" is acceptable; this falls
    under the "limit behavior which has the potential to cause harm" language in
    Section 6 of RFC 2119.  This particular instance needs to be checked to
    determine if "SHOULD" is more appropriate (i.e., an Initiator who proceeds
    with connection setup despite security negotiation failure gets what it
    deserves in the area of security properties, and hence a strong warning
    rather than an absolute prohibition may be in order). 
    
    For comment 8, upper case is again in order for the "MUST", and
    "is discouraged" needs to be replaced by language containing either
    "SHOULD NOT" or "NOT RECOMMENDED".
    
    Thanks,
    --David
    
    ---------------------------------------------------
    David L. Black, Senior Technologist
    EMC Corporation, 42 South St., Hopkinton, MA  01748
    +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
    black_david@emc.com       Mobile: +1 (978) 394-7754
    ---------------------------------------------------
    


Home

Last updated: Wed Oct 03 16:17:22 2001
7011 messages in chronological order