[rfc-i] Possiable April 1st contribution....

Warren Kumari warren at kumari.net
Fri Mar 23 08:14:55 PDT 2012


Whee! Autocomplete fail…

Sad panda :-(
W


On Mar 23, 2012, at 4:12 PM, Warren Kumari wrote:

> Still needs some work, if you think it is worth the trouble…
> 
> W
> 
> ------------------
> 
> 
> template                                                       W. Kumari
> Internet-Draft                                                    Google
> Intended status: Standards Track                               R. Bonica
> Expires: September 10, 2012                             Juniper Networks
>                                                           March 9, 2012
> 
> 
>             Granular words to Indicate Requirement Levels
>                       draft-wkumari-template-00
> 
> Abstract
> 
>   A common problem encountered in forming consensus on a document is
>   the strength of the requirement.  For each recommendation or
>   requirement a large amount of time is often spent discussing if a
>   "should" or a "SHOULD" is appropriate, and these discussions can
>   often become heated.  If additional levels of granularity could be
>   provided, much animosity could be avoided, and much more time could
>   be devoted to publishing useful documents.
> 
>   This document provides a means to provide additional levels of
>   granularity to the requirements language in RFC 2119 and introduces
>   two additional keywords.
> 
> Status of this Memo
> 
>   This Internet-Draft is submitted in full conformance with the
>   provisions of BCP 78 and BCP 79.
> 
>   Internet-Drafts are working documents of the Internet Engineering
>   Task Force (IETF).  Note that other groups may also distribute
>   working documents as Internet-Drafts.  The list of current Internet-
>   Drafts is at http://datatracker.ietf.org/drafts/current/.
> 
>   Internet-Drafts are draft documents valid for a maximum of six months
>   and may be updated, replaced, or obsoleted by other documents at any
>   time.  It is inappropriate to use Internet-Drafts as reference
>   material or to cite them other than as "work in progress."
> 
>   This Internet-Draft will expire on September 10, 2012.
> 
> Copyright Notice
> 
>   Copyright (c) 2012 IETF Trust and the persons identified as the
>   document authors.  All rights reserved.
> 
>   This document is subject to BCP 78 and the IETF Trust's Legal
>   Provisions Relating to IETF Documents
> 
> 
> 
> Kumari & Bonica        Expires September 10, 2012               [Page 1]
> Internet-Draft              granular-rfc2119/                 March 2012
> 
> 
>   (http://trustee.ietf.org/license-info) in effect on the date of
>   publication of this document.  Please review these documents
>   carefully, as they describe your rights and restrictions with respect
>   to this document.  Code Components extracted from this document must
>   include Simplified BSD License text as described in Section 4.e of
>   the Trust Legal Provisions and are provided without warranty as
>   described in the Simplified BSD License.
> 
> 
> Table of Contents
> 
>   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
>     1.1.  Requirements notation . . . . . . . . . . . . . . . . . . . 3
>   2.  Granularity within levels . . . . . . . . . . . . . . . . . . . 4
>   3.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
>   4.  Additional Keywords . . . . . . . . . . . . . . . . . . . . . . 5
>   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
>   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
>   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 6
>   8.  Normative References  . . . . . . . . . . . . . . . . . . . . . 6
>   Appendix A.  Changes / Author Notes.  . . . . . . . . . . . . . . . 6
>   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 6
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Kumari & Bonica        Expires September 10, 2012               [Page 2]
> Internet-Draft              granular-rfc2119/                 March 2012
> 
> 
> 1.  Introduction
> 
>   [RFC2119] provides a number of key words to be used in RFCs to
>   indicate requirement levels.  It provides 3 main levels of
>   requirements, in decreasing order or "strictness" these are MUST,
>   SHOULD and MAY.  There are also negated forms of two of these (MUST
>   NOT, SHOULD NOT), and various forms of some of the words (for
>   example, RECOMMENDED is the adjective form of SHOULD), but these are
>   sill only 3 major levels.  The lowercase versions of each of these
>   terms is viewed more as a recommendations (or advice), and not a
>   requirement.
> 
>   During the creation and review of Internet Drafts there is often a
>   large amount of discussion regarding which requirement language
>   should be used for a particular item withing the document.  These
>   discussions are often taken very seriously by participants and often
>   end up becoming very contentions and heated.  This has led to
>   animosity and is often a huge time sink.
> 
>   Many of the discussions is disagreement over just how important a
>   particular point is implementations of the protocol.  For example, if
>   a specific error condition is uncounted and the document recommends
>   that the error be logged, which is appropriate:
> 
>   o  If an error is detected in processing the additional data, an
>      error SHOULD be logged so the operator can troubleshoot the error.
>   o  If an error is detected in processing the additional data, an
>      error should be logged so the operator can troubleshoot the error.
> 
>   Newcomers to the IETF may think that the difference between the two
>   options is very minor and could not possibly cause discourse, but
>   these sorts of discussion have destroyed friendships.  Different
>   participants may have different use cases in mind for the protocol.
>   White it may be appropriate for a server (or other device with large
>   amounts of storage) to log errors for later review, the same advice
>   many not work (or even be possible) for a small embedded device.
> 
>   At the root of the problem is the limited number of requirement
>   levels, and so this document provides a means to provide granularity
>   within each of the major levels.  This is intended to create a more
>   harmonious IETF.
> 
> 1.1.  Requirements notation
> 
>   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 [RFC2119].
> 
> 
> 
> 
> Kumari & Bonica        Expires September 10, 2012               [Page 3]
> Internet-Draft              granular-rfc2119/                 March 2012
> 
> 
> 2.  Granularity within levels
> 
>   From following many of the disagreements over which requirement
>   language to use (and if the formal (RFC 2119) language should be used
>   at all) it appears that the disagreements become more heated (and
>   longer) depending on which particular level is being discussed.  In
>   increasing order of discord the levels are:
> 
>   o  MAY
>   o  MUST
>   o  SHOULD
> 
>   It can be seen that number of letters in the requirements level word
>   maps to the level of arguments created by the use of the word.
>   Simply replacing each requirement level word with a single character
>   (A, B, C) was briefly considered before it was realized that this was
>   just a coincidence.  It is however a lucky coincidence as it means
>   that we can use the length of the word to build in additional levels
>   of requirements within each major level.
> 
>   The basic idea uses the observation that the lower cased version of
>   each level (may, must, should) is viewed as less "strong" than the
>   uppercase versions (MAY, MUST, SHOULD) with the length observations
>   and encode (using binary) additional levels.
> 
>   By treating each letter position of the word as a bitmap, with an
>   uppercase being a 1 and lowercase being a 0 we can create 6 (2^3 - 2)
>   additional levels of granularity for the lest contentious requirement
>   level (MAY), 14 additional levels for MUST, and a staggering 62
>   additional levels for SHOULD.
> 
>   The bitmap should be treated as a "network order" field (with the
>   most significant bit first).
> 
>   In order to demonstrate this, a worked example is provided:
> 
>   There is disagreement over whether an implementation is supposed to
>   populate a specific field in a protocol unit.  One group of
>   participants feels that this is entirely up to the implementors and
>   that the word "should" explains this best.  Another group of
>   participants feels that this will cause interoperability problems and
>   that "SHOULD" is much more appropriate.  This discussion has been
>   taking up a large amount of the working groups time and is becoming
>   contentious.  Both sides raise good points, and both sides would be
>   willing to compromise on something between the two extremes.  The
>   working group decides that the interoperability concern has some
>   validity, and so the compromise should favor the "SHOULD" side of the
>   compromise.  The working group decides the "SHOULD" side of the
> 
> 
> 
> Kumari & Bonica        Expires September 10, 2012               [Page 4]
> Internet-Draft              granular-rfc2119/                 March 2012
> 
> 
>   argument is a little more than twice as strong as the "should" side,
>   and so the granularity of the requirements text should reflect this
> 
>   With 64 granularity levels available for SHOULD, a ratio of 52:12 in
>   favor of SHOULD is deemed appropriate. 52 decimal in binary is 110100
> 
>      5 4 3 2 1 0
>     +-+-+-+-+-+-+
>     |1|1|0|1|0|0|
>     +-+-+-+-+-+-+
>   Now, we simply overlay 110100 on the word "should", replacing the
>   lowercase letters with uppercase letters where ever there is a 1.
>      5 4 3 2 1 0
>     +-+-+-+-+-+-+
>     |1|1|0|1|0|1|
>     +-+-+-+-+-+-+
>     |S|H|o|U|l|d|
>     +-+-+-+-+-+-+
> 
>   This provides us with our final result, "SHoUld" -- this can easily
>   be seen be the reader as being somewhere between a "SHOULD" and a
>   "should", and weighted towards the former.
> 
> 
> 3.  Examples
> 
>   During discussions on the draft,it was felt that "This technique
>   should only be used on April 1st" was to weak, but "This technique
>   SHOULD only be used on April 1st" was much too strong, so the authors
>   settled on "This document shouLD only be used on April 1st."  This
>   allowed us to stop bickering and go have a tasty dinner.
> 
> 
> 4.  Additional Keywords
> 
>   This section introduces two additional keywords, for use in special
>   situations.
> 
>   1.  THOU SHALL / SHALL NOT These words indicate requirements that are
>       included purely for religious reasons.  An example of where these
>       mAy be used is in any draft that discusses NAT, Path MTU
>       discovery or buffering.
>   2.  SHALST The term "SHALST" should be used to indicate requirement
>       that is so poorly stated that nobody will ever be able to figure
>       out whether or not you are compliant.  This is often appropriate
>       for drafts that have been introduced to the IETF from other
>       standard development organizations, or vendors who one secretly
>       believes don't really want interoperable implementations.
> 
> 
> 
> Kumari & Bonica        Expires September 10, 2012               [Page 5]
> Internet-Draft              granular-rfc2119/                 March 2012
> 
> 
> 5.  IANA Considerations
> 
>   While this document requests no actions from the IANA, it is expected
>   that these terms may show up in future document's IANA Considerations
>   sections, and so the IANA should be aware of their meanings.
> 
> 
> 6.  Security Considerations
> 
>   This document aims to remove much of the animosity from some of the
>   more contentious discussions, and in doing so will allow participants
>   to focus more on writing better drafts.  While it may be a stretch,
>   it should also avoid physical violence (like tugging of beards) and
>   so will make participants feel more secure.
> 
> 
> 7.  Acknowledgements
> 
>   The authors wish to thank all of the participants who have been
>   involved in SHOULD vs should discussions for providing the impetus
>   for this draft...
> 
> 
> 8.  Normative References
> 
>   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
>              Requirement Levels", BCP 14, RFC 2119, March 1997.
> 
> 
> Appendix A.  Changes / Author Notes.
> 
>   [RFC Editor: Please remove this section before publication ]
> 
>   From -00 to -01.
> 
>   o  Nothing changed in the template!
> 
> 
> Authors' Addresses
> 
>   Warren Kumari
>   Google
>   1600 Amphitheatre Parkway
>   Mountain View, CA  94043
>   US
> 
>   Email: warren at kumari.net
> 
> 
> 
> 
> Kumari & Bonica        Expires September 10, 2012               [Page 6]
> Internet-Draft              granular-rfc2119/                 March 2012
> 
> 
>   Ron Bonica
>   Juniper Networks
>   Sterling, Virginia  20164
>   USA
> 
>   Email: rbonica at juniper.net
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Kumari & Bonica        Expires September 10, 2012               [Page 7]
> 
> --
> Don't be impressed with unintelligible stuff said condescendingly.
>    -- Radia Perlman.
> 
> 
> 
> 
> 
> _______________________________________________
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest
> 

--
Don't be impressed with unintelligible stuff said condescendingly.
    -- Radia Perlman.







More information about the rfc-interest mailing list