Please read 'very IPv4 centric' rather than 'very IPv6 centric' in the
first paragraph.
Dan
-----Original Message-----
From: majordomo listserver
[mailto:majordomo(_at_)mil(_dot_)doit(_dot_)wisc(_dot_)edu] On Behalf Of
Romascanu, Dan (Dan)
Sent: Thursday, June 22, 2006 3:39 PM
To: iesg(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org
Cc: ipfix(_at_)net(_dot_)doit(_dot_)wisc(_dot_)edu
Subject: [ipfix] RE: Last Call: 'IPFIX Applicability' to
Informational RFC (draft-ietf-ipfix-as)
Please find below my comments:
1. The orientation of the document seems to be very IPv6
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.
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 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'.
4. It is not clear why congestion awareness is considered to
be an inter-domain issue and is mentioned in 2.6.
5. Typo in 3.2 s/addressd/addressed
6. Syntax : 'The TPM-MIB breaks out the APM-MIB transactions
into sub-application level transaction'
s/transaction/transactions/ 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.
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.
9. Question - was section 3.4 (and the whole document
actually) reviewed with the AAA Doctors team?
10. Why is section 4.6 located under 'Limitations'?
Dan
-----Original Message-----
From: The IESG [mailto:iesg-secretary(_at_)ietf(_dot_)org]
Sent: Friday, June 09, 2006 1:45 AM
To: IETF-Announce
Cc: ipfix(_at_)net(_dot_)doit(_dot_)wisc(_dot_)edu
Subject: Last Call: 'IPFIX Applicability' to Informational RFC
(draft-ietf-ipfix-as)
The IESG has received a request from the IP Flow
Information Export WG
to consider the following document:
- 'IPFIX Applicability '
<draft-ietf-ipfix-as-08.txt> as an Informational RFC
The IESG plans to make a decision in the next few weeks,
and solicits
final comments on this action. Please send any comments to the
iesg(_at_)ietf(_dot_)org or ietf(_at_)ietf(_dot_)org mailing lists by
2006-06-22.
The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-as-08.txt
_______________________________________________
IETF-Announce mailing list
IETF-Announce(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf-announce
--
Help mailto:majordomo(_at_)net(_dot_)doit(_dot_)wisc(_dot_)edu and say
"help"
in message body
Unsubscribe mailto:majordomo(_at_)net(_dot_)doit(_dot_)wisc(_dot_)edu and say
"unsubscribe ipfix" in message body
Archive http://ipfix.doit.wisc.edu/archive/
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf