Please read 'very IPv4 centric' rather than 'very IPv6 centric' in the first paragraph. Dan > -----Original Message----- > From: majordomo listserver > [mailto:majordomo@xxxxxxxxxxxxxxxxx] On Behalf Of Romascanu, Dan (Dan) > Sent: Thursday, June 22, 2006 3:39 PM > To: iesg@xxxxxxxx; ietf@xxxxxxxx > Cc: ipfix@xxxxxxxxxxxxxxxxx > 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@xxxxxxxx] > > Sent: Friday, June 09, 2006 1:45 AM > > To: IETF-Announce > > Cc: ipfix@xxxxxxxxxxxxxxxxx > > 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@xxxxxxxx or ietf@xxxxxxxx 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@xxxxxxxx > > https://www1.ietf.org/mailman/listinfo/ietf-announce > > > > -- > Help mailto:majordomo@xxxxxxxxxxxxxxxxx and say "help" > in message body > Unsubscribe mailto:majordomo@xxxxxxxxxxxxxxxxx and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ > _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf