Subject: [ipfix] new version of IPFIX AS draft

From: "Tanja Zseby" <[email-masked]>
Date: Fri, 4 Aug 2006 17:46:01 +0200

Hi all,

I submitted a new version of the IPFIX applicability statement
(attached).

Changes:

Bernard Aboba: ...my recommendation is to replace "commercial-grade
billing" with "usage-based billing".  
==> Done. 

Dan Romascanu 1: The orientation of the document seems to be very IPv4
centric. Yes, there is a 'IPFIX and IPv6' section, but it's very limited
in scope, and then all examples in the text use IPv4 addresses for
example. I suggest that at least a note is included in the 'IPFIX and
IPv6' section mentioning that although examples use IPv4, all
applicability statements apply in IPv6 networks. If there are any
exceptions, these need to be mentioned, obviously. 
==> added a sentence in Introduction to clarify that the applicability
statements also apply to IPv6

Dan 2: The last but one paragraph in Section 2.4 (the one starting with
'Security incidents can become a threat ...' seems to belong more in the
Security Considerations section, rather than being a security
application applicability statement 
==> moved to Security Considerations 

Dan 3: Section 2.5: to 'The calculation of those QoS metrics requires
per-packet processing.' it would be good to add '... and clock
synchronization of multiple observation points'.
==> not changed because not all of the metrics require clock sync.
Multipoint measurements are addressed in an extra section.

Dan 4: It is not clear why congestion awareness is considered to be an
inter-domain issue and is mentioned in 2.6. 
==> re-phrased the sentence. "...data transfer should be
congestion-aware in order to allow untroubled co-existence with other
data flows in public or foreign networks."

Dan 5: Typo in 3.2 s/addressd/addressed
==> done.

Dan 6: Syntax : 
'The TPM-MIB breaks out the APM-MIB transactions into sub-application
level transaction' s/transaction/transactions/ 
==> done

Dan 7: 'Again sub-application level transaction could be measured using
IPFIX with an appropriate flow definition and by combining the reporting
of both directions of the data transfer (for reporting bi-directional
flow information see also section 4.5).'
This sentence is broken in multiple ways. What is being measure? Maybe
application level transaction performance? Or maybe we are talking about
transactions? Then, what is the meaning of 'Again'? In the previous
paragraphs the editors seem to be of opinion that IPFIX does not map
well into APM MIB, here they suggest some kind of usage of IPFIX to map
with into TPM MIB sub-transactions.  
==> re-phrased paragraph:
Such sub-transactions can be considered as bi-directional flows. With an
appropriate flow definitions and the ability to map both directions of a
flow (see section 4.6), one could measure and report flow
characteristics of such sub-application level transaction with IPFIX.

Dan 8: In Section 3.3 I would prefer to see a stronger statement that
IPM metrics should be used to the possible extend, and wherever
applicable - e.g. for measurements of delay, delay variation, packet
loss, etc. RMON documents for example follow a similar strategy. 
==> added a sentence in 2.5 (QoS Monitoring): "Whenever applicable the
metric definitions of the IPPM group should be used when reporting QoS
Metrics." 
and in 2.7: "For most QoS metrics like like loss, delay, delay variation
etc. standard definitions exist from the IPPM group. In case such
metrics are reported with IPIFX, the IPPM standard definition should be
used. Furthermore IPPM metrics already have IANA numbers. Those should
be used as element identifiers for QoS metric information elements with
IPPM metrics." (See also Emile Stephans comments below) 

Dan 9: Question - was section 3.4 (and the whole document actually)
reviewed with the AAA Doctors team? 
==> at least Bernard Aboba had a look

Dan 10: Why is section 4.6 located under 'Limitations'? 
==> moved section to chapter 3

Emile Stephan 1: I think that it (section 2.5) may refer to the RFCs
which define the IPPM metrics presented.
==> But RFCs for the IPPM metrics are already listetd in 2.5 ?

Emile 2: As IPFIX (section 2.7) can also be used to transfer metrics
result I consider that the Applicability Statement has to propose to
transfer the result conjointly with its corresponding metric identifier
in the IANA IPPM registry
(http://www.iana.org/assignments/ianaippmmetricsregistry-mib). 
==> added in 2.7: "For most QoS metrics like like loss, delay, delay
variation etc. standard definitions exist from the IPPM group. In case
such metrics are reported with IPIFX, the IPPM standard definition
should be used. " 

Still to do:
- check usability of IPPM IANA numbers for reporting of QoS metrics
- small update on section 2.4. when TCP flag counter and flow counter
are integrated in info model

Regards,
Tanja