Subject: [ipfix] [new IPFIX requirements draft

From: Juergen Quittek <[email-masked]>
Date: Sat, 17 Jan 2004 23:24:54 +0100

Dear all,

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

Until it gets posted you can cpreview it at

<ftp://ftp.ccrle.nec.de/pub/internet-drafts/draft-ietf-ipfix-reqs-14.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
=========================

========================================================================
22. IPR boilerplate missing
========================================================================
Problem Description:
------------------------------------------------------------------------
There is no IPR boilerplate.

raised by Ned Fred
========================================================================
Suggested solution:
------------------------------------------------------------------------
add new Section 16:

   "16.  IPR Notices

      The IETF takes no position regarding the validity or scope of any
      intellectual property or other rights that might be claimed to
      pertain to the implementation or use of the technology described in
      this document or the extent to which any license under such rights
      might or might not be available; neither does it represent that it
      has made any effort to identify any such rights.  Information on the
      IETF's procedures with respect to rights in standards-track and
      standards-related documentation can be found in BCP-11.  Copies of
      claims of rights made available for publication and any assurances of
      licenses to be made available, or the result of an attempt made to
      obtain a general license or permission for the use of such
      proprietary rights by implementors or users of this specification can
      be obtained from the IETF Secretariat.

      The IETF invites any interested party to bring to its attention any
      copyrights, patents or patent applications, or other proprietary
      rights which may cover technology that may be required to practice
      this standard.  Please address the information to the IETF Executive
      Director."
========================================================================
Status: solution committed
========================================================================

========================================================================
23. Section on metering process requirement for encrypted packets
========================================================================
Problem Description:
------------------------------------------------------------------------
Section 4.6 explains that some of the requirements listed in Sections
4.1 - 4.5 do not apply to encrypted packets. This should be mentioned
before describing the requirements in Sections 4.1 - 4.5.

raised by Ted Hardie and Russ Housley
========================================================================
Suggested solution:
------------------------------------------------------------------------
move Section 4.6 up to become Section 4.1
========================================================================
Status: solution committed
========================================================================

========================================================================
24. Term "flow specific data" in Section 6.3.3 unclear
========================================================================
Problem Description:
------------------------------------------------------------------------
Section 6.3.3 requires integrity and authenticity for "IPFIX data"
but confidentiality is only required for flow-specific data.  This
might lead to confusion.

raised by Russ Housley
========================================================================
Suggested solution:
------------------------------------------------------------------------
replace "flow specific data" by "IPFIX data".
========================================================================
Status: solution committed
========================================================================

========================================================================
25. Wrong confidentiality requirement in appendix
========================================================================
Problem Description:
------------------------------------------------------------------------
The appendix states the confidentiality requirement for application
Attack/Intrusion Detection as "SHOULD".  This does not match with
the arguments given in the Security Considerations.

raised by Russ Housley
========================================================================
Suggested solution:
------------------------------------------------------------------------
replace "S" by "M" for entry "6.3.3 Confidentiality" in the appendix
========================================================================
Status: solution committed
========================================================================

========================================================================
26. Badly structured Section 4.2
========================================================================
Problem Description:
------------------------------------------------------------------------
I find the structure of section 4.2 very awkward.  There has to be a
better way to say the same thing.  Also, there are no MAY requirements
in the list that follows the introductory sentence.

raised by Russ Housley and Margaret Wasserman
========================================================================
Suggested solution:
------------------------------------------------------------------------
replace

  "The metering process MUST, SHOULD, or MAY be able to separate flows
   by the following fields of the IP header as indicated.

      1. source IP address (MUST)

      2. destination IP address (MUST)

      3. protocol type (TCP,UDP,ICMP,...) (MUST)

      4. IP version number (SHOULD)
         This requirement only applies if the observation point is
         located at a device that is supporting more than IP version.

   For source address and destination address, separating by full match
   MUST be supported as well as separation by prefix match."

by

  "The metering process MUST, SHOULD, or MAY be able to separate flows
   by the following fields of the IP header as indicated.

      1. source IP address

      2. destination IP address

      3. protocol type (TCP, UDP, ICMP, ...)

   For source address and destination address, separating by full match
   MUST be supported as well as separation by prefix match.

   The metering process SHOULD be able to separate flows by the IP
   version number if the observation point is located at a device that
   is supporting more than IP version."
========================================================================
Status: solution committed
========================================================================

========================================================================
27. Confusion about significance of MUST, SHOULD, and MAY
========================================================================
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:
------------------------------------------------------------------------
replace confusing 'MANDATORY' by 'REQUIRED' in section 1, paragraph 3
and section 3, paragraph 3.
========================================================================
Status: solution committed
========================================================================

========================================================================
28. Confusion about significance of MUST, SHOULD, and MAY
========================================================================
Problem Description:
------------------------------------------------------------------------
The list of information that an exporting process must be
able to report in section 6.1 includes several items that
may not be constant for a given flow, given the definition
of "flow" in this document, so it isn't clear how they can
be reported for all flows.

raised by Margaret Wasserman
========================================================================
Suggested solution:
------------------------------------------------------------------------
The introduction of section 6.1 explains that the exporting process
MUST SHOULD or MAY be >>able<< to report the listed flow attributes,
not that they are necessarily constant for each flow.  Certainly,
they it does not make sense to report them if they are not constant
for a certain flow.  But (as the introduction of section 6.1 says)
which attributes are to be reported depends on the configuration of
the exporting process.
========================================================================
Status: no document change required
========================================================================

========================================================================
29. IPv6 Flow ID required for distinguishing flows?
========================================================================
Problem Description:
------------------------------------------------------------------------
Shouldn't you be able to identify a flow based on the IPv6
Flow ID?

raised by Margaret Wasserman
========================================================================
Suggested solution:
------------------------------------------------------------------------
This requirement was discussed some time ago.  The outcome was that
we did not find a relevant usage scenario that would have justified
such a requirement.
========================================================================
Status: no document change required
========================================================================

========================================================================
30. Why DSCP and not full traffic class
========================================================================
Problem Description:
------------------------------------------------------------------------
Why do we want to be able to identify flows based on the DSCP,
but not the full traffic class?

raised by Margaret Wasserman
========================================================================
Suggested solution:
------------------------------------------------------------------------
We found relevant scenarios where distinguishing by
DSCP was considered important enough for having this requirement.
We did not find relevant scenarios that required including the
remaining bits of the traffic class octet.  That was also the
reason why it was not listed as header field. Note that
not having a requirement does not exclude implementing it.
========================================================================
Status: no document change required
========================================================================

--
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/