Subject: [ipfix] new IPFIX requirements draft

From: Juergen Quittek <[email-masked]>
Date: Thu, 03 Jun 2004 17:50:19 +0200

Dear all,

During IESG review, Margaret Wasserman made comments that were not yet
appropriately addressed by the last version of the requirements draft (-15).
Now we have a new version (-16) doing so.

Below please find the list of changes from version -15 to the new
version -16 of the IPFIX requirements draft.

I just submitted the new version.
Until it gets posted you can preview it at

<ftp://ftp.ccrle.nec.de/pub/internet-drafts/draft-ietf-ipfix-reqs-16.txt>.

Cheers,

    Juergen
-- 
Juergen Quittek        [email-masked]        Tel: +49 6221 90511-15
NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.ccrle.nec.de

=========================
IPFIX Requirements Issues
=========================

========================================================================
33. Confusion about significance of MUST, SHOULD, and MAY
    (issue 12 revisited)
========================================================================
Problem Description:
------------------------------------------------------------------------
Margaret Wasserman:
"I don't understand the section that discusses the significance
of how the terms MUST, SHOULD or MAY are used in this document."
========================================================================
Suggested solution:
------------------------------------------------------------------------
The use of capitalized MUST, SHOULD, MAY, etc. according to RFC 2119
is not appropriate for a requirements document that is intended to be
turned into an informational RFC.  RFC 2119 is intended to be applied
to standard track documents.

remove
   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].
from section 2.

remove
   [RFC2119]   S. Bradner "Key words for use in RFCs to Indicate
               Requirement Levels", RFC 2119, March 1997.
from section 14

replace all occurrances of
   'MUST', 'REQUIRED', 'SHOULD', 'RECOMMENDED', 'MAY', 'OPTIONAL', 'NOT'
by
   'must', 'required', 'should', 'recommended', 'may', 'optional', 'not',
respectively

replace the following paragraphs in section 1
   Many requirements in this document are not explicitly stated as IPFIX
   protocol requirements, but as requirements for the metering process,
   the exporting process, or for other traffic measurement components.
   However, every requirement that needs support from the IPFIX protocol
   MUST be covered by the IPFIX protocol specification and related
   standard documents independent of the significance of the
   requirement, which can be REQUIRED (MUST), RECOMMENDED (SHOULD), or
   OPTIONAL (MAY).

   Note that the protocol specification and related standard documents
   themselves also assign significance attributes to its features, such
   that a protocol implementation does not necessarily need to implement
   all features.  However, the implementations significance atributes
   need to match those of the corresponding IPFIX requirements.
by
   In its early discussions the IPFIX Working Group chose to evaluate existing
   flow export protocols at the same time as it was developing this
   'requirements' document.

   Flow export, however, is not performed by a protocol acting alone, it
   also requires a system of co-operating processes.  In producing IPFIX
   requirements, therefore, the Working Group decided to specify what was
   required by thse various processes - the metering process, the
   exporting process, etc.  In these specifications we use lower-case for
   the words must, may and should, to indicate that IPFIX implementors
   have some freedom as to how to meet the requirements.

   The Working Group's goal is to produce standards-track documents
   describing the IPFX architecture, i.e. information model and flow export
   protocol RFCs.  As well as meeting the requirements set out in this
   document, the information model and protocol documents will provide a full
   specification of the IPFIX system, and will use uppercase [RFC 2119]
   keywords as is usual in standards-track RFCs.
========================================================================
Status: solution committed
========================================================================

--
Help        mailto:[email-masked] and say "help" in message body
Unsubscribe mailto:[email-masked] and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/