RE: Last Call: 'IPFIX Applicability' to Informational RFC (draft-ietf-ipfix-as)

["Romascanu, Dan \(Dan\)" <dromasca at avaya.com>]

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. RMOFrom ietf-bounces at ietf.org Thu Jun 22 08:44:01 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FtOVd-0007HC-VO; Thu, 22 Jun 2006 08:42:09 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FtOVa-0007CR-I4; Thu, 22 Jun 2006 08:42:06 -0400
Received: from nj300815-ier2.net.avaya.com ([198.152.12.103])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FtOSE-0000gf-As; Thu, 22 Jun 2006 08:38:39 -0400
Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com
	[135.64.105.51])
	by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP
	id k5MCYfEO005824; Thu, 22 Jun 2006 08:34:42 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 22 Jun 2006 15:38:36 +0300
Message-ID: <AAB4B3D3CF0F454F98272CBE187FDE2F0AB49278 at is0004avexu1.global.avaya.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Last Call: 'IPFIX Applicability' to Informational RFC
	(draft-ietf-ipfix-as)
Thread-Index: AcaLVGnXAxP2SlK0S2ywtePRPylJSAKmSYwg
From: "Romascanu, Dan \(Dan\)" <dromasca at avaya.com>
To: <iesg at ietf.org>, <ietf at ietf.org>
X-Scanner: InterScan AntiVirus for Sendmail
X-Spam-Score: 0.0 (/)
X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81
Cc: ipfix at net.doit.wisc.edu
Subject: RE: Last Call: 'IPFIX Applicability' to Informational RFC
	(draft-ietf-ipfix-as)
X-BeenThere: ietf at ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf at ietf.org>
List-Help: <mailto:ietf-request at ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=subscribe>
Errors-To: ietf-bounces at ietf.org

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.org] 
> Sent: Friday, June 09, 2006 1:45 AM
> To: IETF-Announce
> Cc: ipfix at net.doit.wisc.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.org or ietf at ietf.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.org
> https://www1.ietf.org/mailman/listinfo/ietf-announce
> 

_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf