Question on security document

[Robert Snively <rsnively@Brocade.COM>]

I have a recommendation to the authors of the security 
document:

	draft-ietf-ips-security-03.txt

There are a number of places where sentences like:

	"Conformant iSCSI, FCIP and iFCP security 
	implementations MUST support
	both IKE Main Mode and Aggressive Mode."

are used.  I propose that all those "MUSTs", "SHOULDs", and similar
words in the security document be changed to lower case as
explained below.

According to the security document, it is informational, and never
aspires to be more than an informational RFC.  If I
understand RFC 2026 properly, Section 4.2.2 (attached below
for reference) strongly implies that these documents cannot
be used for verifying compliance.  However, RFC 2119 has
a somewhat conflicted definition of how words like "MUST" 
should be interpreted.  It says that they are rare
and precious words that prevent very bad things from happening.
It is implied that non-interoperability is one of those things and
security failure is another.  It also implies that they rise
no higher in requirement than the document itself.

I had expected that the iSCSI, FCIP, and iFCP documents
were required to define their security compliance requirements.
However, here we have an informational draft taking over that
same job and using language that implies a compliance failure
if the "MUSTs" are ignored.  It is not at all clear what would
happen if one of the primary documents accidentally or purposely
conflicted with the "MUSTs" of the security document.

I believe the best solution for this is to change all words
in the security document with possible keyword meaning 
to lower case, using the
corresponding wording in each of the primary documents to 
to uniquely specify by capitalization the truly important
special keywords that will actually be used for conformance
verification.  That keeps the informational document
informational, prevents irresolvable keyword conflicts between
the informational document and the primary documents, and allows
the primary documents to do their compliance specification 
without any danger of misinterpretation.
By changing all words in the informational document to lower
case, it will be very clear that the details contained in the
primary documents supercede the text of the informational document.

----------  Reference text from RFC 2026  -------------------------

4.2.2  Informational

   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
   (see section 4.2.3).

   Specifications that have been prepared outside of the Internet
   community and are not incorporated into the Internet Standards
   Process by any of the provisions of section 10 may be published as
   Informational RFCs, with the permission of the owner and the
   concurrence of the RFC Editor.


--------------  Reference text from RFC 2119  -------------------


   In many standards track documents several words are used to signify
   the requirements in the specification.  These words are often
   capitalized.  This document defines these words as they should be
   interpreted in IETF documents.  Authors who follow these guidelines
   should incorporate this phrase near the beginning of their document:

      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
      "OPTIONAL" in this document are to be interpreted as described in
      RFC 2119.

   Note that the force of these words is modified by the requirement
   level of the document in which they are used.

1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
   definition is an absolute requirement of the specification.

......

6. Guidance in the use of these Imperatives

   Imperatives of the type defined in this memo must be used with care
   and sparingly.  In particular, they MUST only be used where it is
   actually required for interoperation or to limit behavior which has
   potential for causing harm (e.g., limiting retransmisssions)  For
   example, they must not be used to try to impose a particular method
   on implementors where the method is not required for
   interoperability.

7. Security Considerations

   These terms are frequently used to specify behavior with security
   implications.  The effects on security of not implementing a MUST or
   SHOULD, or doing something the specification says MUST NOT or SHOULD
   NOT be done may be very subtle. Document authors should take the time
   to elaborate the security implications of not following
   recommendations or requirements as most implementors will not have
   had the benefit of the experience and discussion that produced the
   specification.


Bob Snively                        e-mail:    rsnively@brocade.com
Brocade Communications Systems     phone:  408 487 8135
1745 Technology Drive
San Jose, CA 95110