RE: [ipfix-eval] Some comments on the evaluation team draft

"Reinaldo Penno" <rpenno@nortelnetworks.com> Thu, 14 November 2002 16:30 UTC

Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23572 for <ipfix-archive@lists.ietf.org>; Thu, 14 Nov 2002 11:30:36 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18CMkI-0002sc-00 for ipfix-list@mil.doit.wisc.edu; Thu, 14 Nov 2002 10:21:34 -0600
Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18CMkH-0002rp-00 for ipfix-eval@net.doit.wisc.edu; Thu, 14 Nov 2002 10:21:33 -0600
Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gAEGL7l16808; Thu, 14 Nov 2002 10:21:07 -0600 (CST)
Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <VDYB1HVG>; Thu, 14 Nov 2002 08:20:52 -0800
Message-ID: <0A11633F61BD9F40B43ABCC694004F931821C6@zsc3c026.us.nortel.com>
From: Reinaldo Penno <rpenno@nortelnetworks.com>
To: Benoit Claise <bclaise@cisco.com>, ipfix-eval@net.doit.wisc.edu
Subject: RE: [ipfix-eval] Some comments on the evaluation team draft
Date: Thu, 14 Nov 2002 08:20:51 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C28BF9.CCA71FDC"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

Hello Benoit,
 
some answers...

-----Original Message-----
From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: Thursday, November 14, 2002 10:53 AM
To: ipfix-eval@net.doit.wisc.edu
Subject: [ipfix-eval] Some comments on the evaluation team draft


All,



I have 2 coments regarding the following draft
http://www2.auckland.ac.nz/net//ipfix/draft-ietf-ipfix-protocol-eval-00.txt
<http://www2.auckland.ac.nz/net//ipfix/draft-ietf-ipfix-protocol-eval-00.txt
> 





4.5 Time Synchronization  (5.5) 



LFAP: T     CRANE: T     IPDR: T     NetFlow: P     Diameter: T



In my draft
http://www.ietf.org/internet-drafts/draft-claise-ipfix-eval-netflow-03.txt
<http://www.ietf.org/internet-drafts/draft-claise-ipfix-eval-netflow-03.txt>
, I wrote

3.4.5 Time Synchronization (5.5) 

Total Compliance. 
The export packet header contains the UTC time of the export packet 
generation. This header also contains the router sysUpTime at the 
time of the export packet generation. The UTC time the router booted 
can therefore be deduced. The flow records contain the flow start 
and flow end sysUpTime, so that the NetFlow collector can deduce the 
flow start and flow end UTC time. 



5.7 Anonymization  (6.7) 

    

LFAP: E     CRANE: E     IPDR: E     NetFlow: E     Diameter: E
In my draft
http://www.ietf.org/internet-drafts/draft-claise-ipfix-eval-netflow-03.txt
<http://www.ietf.org/internet-drafts/draft-claise-ipfix-eval-netflow-03.txt>
, I wrote


3.5.7 Anonymization (6.6) 
    
   "The exporting process MAY be capable of anonymizing source and 
   destination IP addresses in flow data before exporting them."
   Total Compliance. 


You can export the prefix is you want to and not the specific source and
destination IP addresses. 
 
From my point of view exporting only the prefix is not considered
anonymization. I'm not sure this got into the recent requirements draft, but
was the conclusion of some discussions that I actually think (but not
posisitive) you were copied.  I should put that as a open item....

I would appreciate if those two points above could be changed.


BTW, maybe I misunderstood the idea of the evaluation team, but from
http://ipfix.doit.wisc.edu/archive/1000.html
<http://ipfix.doit.wisc.edu/archive/1000.html> 


3) Evaluation Team met by teleconference for an hour on Wed 26 June



   The team was strongly influenced by the MIDCOM WG's recent

   evaluation effort; the IPFIX process will be similar.



   a) The team will publish a 'Protocol Advocacy' draft, to be used

      by the Protocol Advocates in making their submissions to the

      Evaluation team.



   b) They will also publish a 'call for IPFIX protocol submissions,'

      most probably via the IPFIX list, referring to a web page on

      the IPFIX web site.  The call for submissions will set out

      preconditions (e.g. 'must be documented in an Internet Draft

      or RFC'), as discussed previously.



   c) Once all the submissions are in, the team will publish them,

      and call for comments about them on the IPFIX list.

      In addition, the team will read all the drafts and form their

      own opionions of them.



   d) The team will publish an 'Evaluation' draft, using the same

      outline as the Protocol Advocacy drafts; this will conclude

      with a recommendation on which protocol most nearly meets the

      IPFIX requirements.



   e) The Evaluation draft will be discussed on the IPFIX list, 

      until we reach WG consensus.

From above, you can read "this will conclude with a recommendation on which
protocol most nearly meets the IPFIX requirements."
And it seems that we miss that part in
http://www2.auckland.ac.nz/net//ipfix/draft-ietf-ipfix-protocol-eval-00.txt
<http://www2.auckland.ac.nz/net//ipfix/draft-ietf-ipfix-protocol-eval-00.txt
> . 
 
that's because the draft will still got through revisions after the
advocates have a chance to comment on the items they find relevant (just
like you did), and also after the open requirements that are relevant to the
evaluation are closed (e.g. reliability). Only after that we will issue a
final recommendation
 
regards,
 
Reinaldo
 
The only exception was  in the initial draft from Simon Leinen. But the
"conclusion" section was removed in the second version of his draft.

Regards, Benoit.