From majordomo@mil.doit.wisc.edu Fri Aug 1 04:54:08 2003 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 EAA02998 for ; Fri, 1 Aug 2003 04:54:08 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 19iVIx-0003C5-00 for ipfix-list@mil.doit.wisc.edu; Fri, 01 Aug 2003 03:30:27 -0500 Received: from cms1.etri.re.kr ([129.254.16.11] helo=cms1.cms.etri.re.kr) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 19iVIw-0003Bz-00 for ipfix@net.doit.wisc.edu; Fri, 01 Aug 2003 03:30:26 -0500 Received: from etri.re.kr (TASSAJARA [129.254.70.152]) by cms1.cms.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id P8CRN0K5; Fri, 1 Aug 2003 17:29:46 +0900 Message-ID: <3F2A252D.5000509@etri.re.kr> Date: Fri, 01 Aug 2003 17:30:37 +0900 From: Changhoon Kim Organization: ETRI User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nevil Brownlee , ipfix Subject: Re: [ipfix] Requirements: Encryption and Anonymozation References: <1059583948.419d0eb2488eb@hotlava.auckland.ac.nz> Content-Type: multipart/alternative; boundary="------------080409080201020303070008" Precedence: bulk Sender: majordomo listserver --------------080409080201020303070008 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Altough I still have some doubt even on the necessity of "encryption", anyway, I vote against "anonymization." Unanonymized flow records play a crucial role in many applications, let alone TE. - Chang Nevil Brownlee wrote: >Hello all: > >I've been thinking about Allison's rejection of our Anonymization >and Encrytpion SHOULD implement position. >Allison (supported by Randy) believes that they should be 'MUST >implement's, on the grounds that if they were, people would use them. > >My first thought was 'IPFIX charter says "standardize existing >practice",' but I checked it, and it doesn't actually say that. >It does say we'll > * Identify and address any security privacy concerns affecting > flow data. Determine technology for securing the flow information > export data, e.g. TLS. >so we clearly have to address encryption. We didn't mention >anonymization in the charter though, it just crept in to the >Requirements draft. > >In an attempt to move forward, I've had some email discussions >with the Requirements Draft editors and co-chairs. Based on that, >I propose the following: > > a) A fair proportion of users probably would use encryption to > get their IPFIX data safely across the Internet. We've said > all along that we'd use IPSEC or IPSEC for that, rather than > try to do it at the application layer in IPFIX. So ... > we should write a 'requirements' sentence saying that "IPFIX > implementations MUST provide for encryption of exported IPFIX > data, e.g. by using IPSEC or TLS." [We need to verify that > TLS would be suitable for this.] > > b) For anonymization, we should remove any mention of it from > the Requirements Draft, because: > - IPFIX data will normally be collected by network operators > for traffic engineering and/or accounting purposes. In both > these cases raw (un-anonymized) data is needed; again, since > IPFIX data can be encrypted in transit, there is no operational > need for further privacy protection. > - Although it may be useful for operators to anonymize traffic > data before giving researchers access to it, that is easily done > (as at present) using anonymization tools. > - At this stage there are several anonymoization tools one could > use. tcpdpriv is the most common, but it has known > vulnerabilities. Crypto-PaN is probably better, but has high > processor demands. Overall, good algorithms for anonymization > are still a research issue, not something which is ready to go > into production network devices. > > >In a more detailed comment on 'privacy' vs 'security', Sebastian Zander said: > > > >>I think that IPFIX must deal with privacy issues somehow. Afterall we >>are standardizing something which could be used to get a detailed log >>of a users activities. >> >>Different countries may have completly different laws on privacy. But >>there are laws (e.g. in the EU). So what may be a privacy violation in one >>country may not be a privacy violation in another. >> >>In general i agree to your proposal. However i think some of the arguments >>against a MUST are not too strong. If i have a flat rate why would my >>provider need to record my flow data? What would prevent someone to give >>a 3rd party access to ipfix informtion? Technically nothing... >>(but there are laws). >> >>I think there are differences between security and privacy which justify >>a different treatment IMO: >>- Security/encryption can *always* be used for ipfix although it means >> using more resources etc. whereas privacy/anonymization can *not* be >> used in any case (e.g. in case of accounting srcip must not be >> anonymized). >>- We have to assume that in those cases the people who use ipfix comply to >> the relevant privacy laws. Privacy can't be enforced by the protocol >> itself, only by laws or social norms. >>- The scenarios where people would like to access ipfix data and can do >> this only through the use of anonymization are currently rare and out >> of scope(?). >>- Encryption techniques are more mature and widely understood whereas >> anonymization techniques are still research and therefore its more >> difficult to put them into a standard now. >>- I think its not the scope of this group to develop and/or standard >> anonymization techniques. There are standards for encryption but for >> anonymization? >> >>Maybe it would be a good idea to have some text on privacy considerations >>in the draft (similar to security considerations). >> >> > >I like the idea of a 'privacy considerations' section, probably in the >Architecture draft (rather than the Requirements draft). > >What do you think? Lets have some feedback on the list, please, just >a line saying 'yes for encryption, no for anonymization' would be fine. >But we want to get the Requirements Draft finished, so please respond >quickly! > >Cheers, Nevil > >----------------------------------------------------------------------- > Nevil Brownlee Director, Technology Development > Phone: +64 9 373 7599 x88941 ITSS, The University of Auckland > FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand > > >------------------------------------------------- >This mail sent through University of Auckland >http://www.auckland.ac.nz/ > >-- >Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body >Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >"unsubscribe ipfix" in message body >Archive http://ipfix.doit.wisc.edu/archive/ > > > --------------080409080201020303070008 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Altough I still have some doubt even on the necessity of "encryption", anyway, I vote against "anonymization."
Unanonymized flow records play a crucial role in many applications, let alone TE.

- Chang


Nevil Brownlee wrote:
Hello all:

I've been thinking about Allison's rejection of our Anonymization
and Encrytpion SHOULD implement position.
Allison (supported by Randy) believes that they should be 'MUST 
implement's, on the grounds that if they were, people would use them.

My first thought was 'IPFIX charter says "standardize existing
practice",' but I checked it, and it doesn't actually say that.
It does say we'll
  * Identify and address any security privacy concerns affecting
    flow data.  Determine technology for securing the flow information
    export data, e.g. TLS.
so we clearly have to address encryption.  We didn't mention
anonymization in the charter though, it just crept in to the 
Requirements draft.

In an attempt to move forward, I've had some email discussions
with the Requirements Draft editors and co-chairs.  Based on that, 
I propose the following:

 a) A fair proportion of users probably would use encryption to
    get their IPFIX data safely across the Internet.  We've said
    all along that we'd use IPSEC or IPSEC for that, rather than
    try to do it at the application layer in IPFIX.  So ...
    we should write a 'requirements' sentence saying that "IPFIX
    implementations MUST provide for encryption of exported IPFIX
    data, e.g. by using IPSEC or TLS."  [We need to verify that
    TLS would be suitable for this.]

 b) For anonymization, we should remove any mention of it from
    the Requirements Draft, because:
    - IPFIX data will normally be collected by network operators
      for traffic engineering and/or accounting purposes.  In both
      these cases raw (un-anonymized) data is needed; again, since
      IPFIX data can be encrypted in transit, there is no operational
      need for further privacy protection.  
    - Although it may be useful for operators to anonymize traffic
      data before giving researchers access to it, that is easily done
      (as at present) using anonymization tools.
    - At this stage there are several anonymoization tools one could
      use.  tcpdpriv is the most common, but it has known
      vulnerabilities.  Crypto-PaN is probably better, but has high
      processor demands.  Overall, good algorithms for anonymization
      are still a research issue, not something which is ready to go
      into production network devices.


In a more detailed comment on 'privacy' vs 'security', Sebastian Zander said:

  
I think that IPFIX must deal with privacy issues somehow. Afterall we
are standardizing something which could be used to get a detailed log
of a users activities.

Different countries may have completly different laws on privacy. But
there are laws (e.g. in the EU). So what may be a privacy violation in one
country may not be a privacy violation in another.

In general i agree to your proposal. However i think some of the arguments
against a MUST are not too strong. If i have a flat rate why would my
provider need to record my flow data? What would prevent someone to give
a 3rd party access to ipfix informtion? Technically nothing...
(but there are laws).

I think there are differences between security and privacy which justify
a different treatment IMO:
- Security/encryption can *always* be used for ipfix although it means
   using more resources etc. whereas privacy/anonymization can *not* be
   used in any case (e.g. in case of accounting srcip must not be
   anonymized).
- We have to assume that in those cases the people who use ipfix comply to
   the relevant privacy laws. Privacy can't be enforced by the protocol
   itself, only by laws or social norms.
- The scenarios where people would like to access ipfix data and can do
   this only through the use of anonymization are currently rare and out
 of scope(?).
- Encryption techniques are more mature and widely understood whereas
   anonymization techniques are still research and therefore its more
   difficult to put them into a standard now.
- I think its not the scope of this group to develop and/or standard
   anonymization techniques. There are standards for encryption but for
   anonymization?

Maybe it would be a good idea to have some text on privacy considerations
in the draft (similar to security considerations).
    

I like the idea of a 'privacy considerations' section, probably in the
Architecture draft (rather than the Requirements draft).

What do you think?  Lets have some feedback on the list, please, just
a line saying 'yes for encryption, no for anonymization' would be fine.
But we want to get the Requirements Draft finished, so please respond
quickly!

Cheers, Nevil

-----------------------------------------------------------------------
   Nevil Brownlee                   Director, Technology Development
   Phone: +64 9 373 7599 x88941     ITSS, The University of Auckland
   FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand


-------------------------------------------------
This mail sent through University of Auckland
http://www.auckland.ac.nz/

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/

  







--------------080409080201020303070008--


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Fri Aug  1 11:44:45 2003
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 LAA27057
	for ; Fri, 1 Aug 2003 11:44:44 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19ibpx-000248-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 01 Aug 2003 10:28:57 -0500
Received: from psg.com ([147.28.0.62])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19ibpw-000242-00
	for ipfix@net.doit.wisc.edu; Fri, 01 Aug 2003 10:28:56 -0500
Received: from [127.0.0.1] (helo=roam.psg.com)
	by psg.com with esmtp (Exim 4.20)
	id 19ibpv-000NkR-E7; Fri, 01 Aug 2003 15:28:55 +0000
Received: from localhost
	([127.0.0.1] helo=roam.psg.com ident=randy)
	by roam.psg.com with esmtp (Exim 4.20)
	id 19ibpt-000LJL-FF; Fri, 01 Aug 2003 08:28:53 -0700
From: Randy Bush 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Fri, 1 Aug 2003 08:28:32 -0700
To: Changhoon Kim 
Cc: Nevil Brownlee ,
        ipfix 
Subject: Re: [ipfix] Requirements: Encryption and Anonymozation
References: <1059583948.419d0eb2488eb@hotlava.auckland.ac.nz>
	<3F2A252D.5000509@etri.re.kr>
Message-Id: 
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit

> Altough I still have some doubt even on the necessity of "encryption", 
> anyway, I vote against "anonymization."

this is the ietf.  we don't vote here.

and we are dealing with an inter-area privacy concern.  the iesg will
and has taken this quite seriously.

randy


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Fri Aug  1 12:00:42 2003
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 MAA28029
	for ; Fri, 1 Aug 2003 12:00:41 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19ibzs-0002Mc-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 01 Aug 2003 10:39:12 -0500
Received: from relay.pair.com ([209.68.1.20])
	by mil.doit.wisc.edu with smtp (Exim 3.13 #1)
	id 19ibzq-0002MT-00
	for ipfix@net.doit.wisc.edu; Fri, 01 Aug 2003 10:39:10 -0500
Received: (qmail 94176 invoked from network); 1 Aug 2003 15:39:10 -0000
Received: from 207-237-37-137.c3-0.nyr-ubr3.nyr.ny.cable.rcn.com (HELO newyork.qosient.com) (207.237.37.137)
  by relay.pair.com with SMTP; 1 Aug 2003 15:39:10 -0000
X-pair-Authenticated: 207.237.37.137
Received: from osiris (osiris.newyork.qosient.com [192.168.0.163])
	by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id h71Fd3907764;
	Fri, 1 Aug 2003 11:39:05 -0400
Reply-To: 
From: "Carter Bullard" 
To: "'Randy Bush'" , "'Changhoon Kim'" 
Cc: "'Nevil Brownlee'" ,
        "'ipfix'" 
Subject: RE: [ipfix] Requirements: Encryption and Anonymozation
Date: Fri, 1 Aug 2003 11:39:03 -0400
Organization: QoSient, LLC
Message-ID: <5C8959A16A71B449AE793CF52FBBED6607A660@ptah.newyork.qosient.com>
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
In-Reply-To: <5C8959A16A71B449AE793CF52FBBED6618B368@ptah.newyork.qosient.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
Precedence: bulk
Sender: majordomo listserver 

What kind of nonsense is "we don't vote here".
Has the concept of mailing list concensus been
thrown out the window?

The IESG should pay attention to whatever it is
that they have some experience in, whatever that is.

Carter


> -----Original Message-----
> From: majordomo listserver
> [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Randy Bush
> Sent: Friday, August 01, 2003 10:29 AM
> To: Changhoon Kim
> Cc: Nevil Brownlee; ipfix
> Subject: Re: [ipfix] Requirements: Encryption and Anonymozation
>
>
> > Altough I still have some doubt even on the necessity of
> "encryption",
> > anyway, I vote against "anonymization."
>
> this is the ietf.  we don't vote here.
>
> and we are dealing with an inter-area privacy concern.  the iesg will
> and has taken this quite seriously.
>
> randy
>
>
> --
> Help        mailto:majordomo@net.doit.wisc.edu and say "help"
> in message body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
>



--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Fri Aug  1 13:26:25 2003
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 NAA01039
	for ; Fri, 1 Aug 2003 13:26:25 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19idV0-0005gL-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 01 Aug 2003 12:15:26 -0500
Received: from mailhost2.auckland.ac.nz ([130.216.191.4])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19idUz-0005gG-00
	for ipfix@net.doit.wisc.edu; Fri, 01 Aug 2003 12:15:25 -0500
Received: from mailhost.auckland.ac.nz (IDENT:mirapoint@mailhost [130.216.191.61])
	by mailhost2.auckland.ac.nz (8.12.9/8.12.9/8.12.9-ua) with ESMTP id h71HFJaD011882;
	Sat, 2 Aug 2003 05:15:20 +1200 (NZST)
Received: from hotlava.auckland.ac.nz (hotlava.auckland.ac.nz [130.216.191.123])
	by mailhost.auckland.ac.nz (Mirapoint Messaging Server MOS 3.3.5-GR)
	with ESMTP id ASX68033;
	Sat, 2 Aug 2003 05:15:19 +1200 (NZST)
Received: (from apache@localhost)
	by hotlava.auckland.ac.nz (8.11.6/8.11.6) id h71HFIW26646;
	Sat, 2 Aug 2003 05:15:18 +1200
X-Authentication-Warning: hotlava.auckland.ac.nz: apache set sender to n.brownlee@auckland.ac.nz using -f
Received: from dyn54.caida.org (dyn54.caida.org [192.172.226.54]) by
	hotlava.auckland.ac.nz (Horde) with HTTP for
	; Sat,  2 Aug 2003 05:15:18 +1200
Message-ID: <1059758118.40ade331cb66e@hotlava.auckland.ac.nz>
Date: Sat,  2 Aug 2003 05:15:18 +1200
From: Nevil Brownlee 
To: carter@qosient.com
Cc: "'Randy Bush'" , "'Changhoon Kim'" ,
        "'ipfix'" 
Subject: [ipfix] Requirements: reaching consensus
References: 	<5C8959A16A71B449AE793CF52FBBED6607A660@ptah.newyork.qosient.com>
In-Reply-To: 	<5C8959A16A71B449AE793CF52FBBED6607A660@ptah.newyork.qosient.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
User-Agent: Internet Messaging Program (IMP) 4.0-cvs
X-Originating-IP:  192.172.226.54
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit


Now then, people:

This thread is about reaching WG consensus on one particular issue,
requirements for anonymization and encryption - lets keep it
focussed on that,please.

When I asked everyone to express an opinion, that's all I was looking
for - we're certainly not holding any sort of a vote.

To respond to Randy's point, at this stage it appears - from watching
the responses to the list - that:
 * we have clear support for encrypted transport of flow data
 * no-one on the list has expressed support for anonymization as 
   a 'must implement' standaqrds requirement.  Several people
   (independently) have pointed out that there is no agreed-on
   anonymization technique at this stage.
 * we have a clearly expressed (by Sebastian) concern for privacy,
   and the proposal that we address this with a 'Privacy Concerns'
   section, probably in the Architecture Draft.

Any further comment/opinion on the aononymization issue, let's hear
it now.

Cheers, Nevil

-----------------------------------------------------------------------
   Nevil Brownlee                   Director, Technology Development
   Phone: +64 9 373 7599 x88941     ITSS, The University of Auckland
   FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand


-------------------------------------------------
This mail sent through University of Auckland
http://www.auckland.ac.nz/

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Fri Aug  1 15:38:08 2003
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 PAA07743
	for ; Fri, 1 Aug 2003 15:38:08 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19ifGZ-0001K7-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 01 Aug 2003 14:08:39 -0500
Received: from relay.pair.com ([209.68.1.20])
	by mil.doit.wisc.edu with smtp (Exim 3.13 #1)
	id 19ifGY-0001K0-00
	for ipfix@net.doit.wisc.edu; Fri, 01 Aug 2003 14:08:38 -0500
Received: (qmail 79418 invoked from network); 1 Aug 2003 19:08:37 -0000
Received: from 207-237-37-137.c3-0.nyr-ubr3.nyr.ny.cable.rcn.com (HELO newyork.qosient.com) (207.237.37.137)
  by relay.pair.com with SMTP; 1 Aug 2003 19:08:37 -0000
X-pair-Authenticated: 207.237.37.137
Received: from osiris (osiris.newyork.qosient.com [192.168.0.163])
	by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id h71J8a910188;
	Fri, 1 Aug 2003 15:08:36 -0400
Reply-To: 
From: "Carter Bullard" 
To: "'Nevil Brownlee'" 
Cc: "'ipfix'" 
Subject: RE: [ipfix] Requirements: reaching consensus
Date: Fri, 1 Aug 2003 15:08:36 -0400
Organization: QoSient, LLC
Message-ID: <5C8959A16A71B449AE793CF52FBBED6607A661@ptah.newyork.qosient.com>
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
In-Reply-To: <5C8959A16A71B449AE793CF52FBBED6618B3DC@ptah.newyork.qosient.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
Precedence: bulk
Sender: majordomo listserver 

Hey Nevil,
   I am in support of a MUST for the indication
of anonymization.  I am against the WG designing an
anonymization algorithm because it is a bit more complex
than the WG should take on.  Argus data has this indication
support embedded in each record because users use anonymization
more often than even aggregation, both of which are a pretty
high percentage of users.  Only a very small number use
encryption.  This is my experience, my opinion and my vote.

   So just for the record, any expression of opinion that
can be used to determine concensus is a vote.  At least the
Oxford English Dictionary and Webster's agree on that.  You
yourself tallied the expression of opinions just now.  I
believe that the correct statement is that the IETF does
not use an election process to determine concensus.


Carter



> -----Original Message-----
> From: majordomo listserver
> [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Nevil Brownlee
> Sent: Friday, August 01, 2003 12:15 PM
> To: carter@qosient.com
> Cc: 'Randy Bush'; 'Changhoon Kim'; 'ipfix'
> Subject: [ipfix] Requirements: reaching consensus
>
>
>
> Now then, people:
>
> This thread is about reaching WG consensus on one particular issue,
> requirements for anonymization and encryption - lets keep it
> focussed on that,please.
>
> When I asked everyone to express an opinion, that's all I was looking
> for - we're certainly not holding any sort of a vote.
>
> To respond to Randy's point, at this stage it appears - from watching
> the responses to the list - that:
>  * we have clear support for encrypted transport of flow data
>  * no-one on the list has expressed support for anonymization as
>    a 'must implement' standaqrds requirement.  Several people
>    (independently) have pointed out that there is no agreed-on
>    anonymization technique at this stage.
>  * we have a clearly expressed (by Sebastian) concern for privacy,
>    and the proposal that we address this with a 'Privacy Concerns'
>    section, probably in the Architecture Draft.
>
> Any further comment/opinion on the aononymization issue, let's hear
> it now.
>
> Cheers, Nevil
>
> --------------------------------------------------------------
> ---------
>    Nevil Brownlee                   Director, Technology Development
>    Phone: +64 9 373 7599 x88941     ITSS, The University of Auckland
>    FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand
>
>
> -------------------------------------------------
> This mail sent through University of Auckland
> http://www.auckland.ac.nz/
>
> --
> Help        mailto:majordomo@net.doit.wisc.edu and say "help"
> in message body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
>



--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Fri Aug  1 15:43:41 2003
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 PAA08447
	for ; Fri, 1 Aug 2003 15:43:40 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19ifTy-0001ke-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 01 Aug 2003 14:22:30 -0500
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19ifTx-0001kW-00
	for ipfix@net.doit.wisc.edu; Fri, 01 Aug 2003 14:22:29 -0500
Received: from cisco.com (171.71.177.237)
  by sj-iport-2.cisco.com with ESMTP; 01 Aug 2003 12:25:53 -0700
Received: from ios-xdm4.cisco.com (ios-xdm4.cisco.com [171.70.69.142])
	by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h71JMNPY012908;
	Fri, 1 Aug 2003 12:22:26 -0700 (PDT)
Received: from cisco.com (dhcp-171-71-204-109.cisco.com [171.71.204.109]) by ios-xdm4.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id MAA24950; Fri, 1 Aug 2003 12:22:23 -0700 (PDT)
Message-ID: <3F2ABDEF.7D4C423A@cisco.com>
Date: Fri, 01 Aug 2003 12:22:23 -0700
From: Ganesh Sadasivan 
Organization: Cisco Systems Inc
X-Mailer: Mozilla 4.79 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ipfix@net.doit.wisc.edu
CC: n.brownlee@auckland.ac.nz, Ganesh Sadasivan 
Subject: [ipfix] Section on special devices (a.k.a middlebox)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit


One of the action items in IETF -57 was to include in the arch. doc.a
section on
special devices/traffic and mention that it would be described in detail

as to how IPFIX would handle these in a separate document. Here is
some text on this topic that can go into the arch. doc. Please send
your comments/corrections on the sections below.

Thanks
Ganesh

12.2. IPFIX flow collection from special devices

   IPFIX could be implemented on devices which perform one or more of
   the following special services :

     * Explicitly drop packets. For example, a device which provides
       firewall service drops packets based on some administrative
       policy.
     * Alter the flow keys of interest. For example a device which
       provides NAT service can change source or(and) destination IP
       address.

   In the cases above, there should be clear guidelines as to

     - How and when to classify the packets as flows in the IPFIX device

     - What extra information be  exported so that the collector can
       make a clear interpretation of the received flow records.

   This topic is out of scope in this document and would be discussed in

   detail in another TBD document.



12.3. IPFIX flow collection for special traffic

   An IPFIX device could be doing one or more of generating, receiving,
   altering special traffic types which are listed below.

     * Tunnel traffic: The IPFIX device could be head, midpoint or
       endpoint of a tunnel. For example, GRE, IPinIP, UTI traffic.
     * VPN traffic: The IPFIX device could be a Provider Edge device
       which receives traffic from customer sites belonging to different

       Virtual Private Networks.


   In the cases above, there should be clear guidelines as to
     - How and when to classify the packets as flows in the IPFIX
       device.
     - If multiple encapsulation are used to define flows how to convey
       the same fields (e.g. IP address) in different layers.
     - How to differentiate flows based on different private domains.
       For example, Overlapping IP addresses in Layer-3 VPNs

   This topic is out of scope in this document and would be discussed in

   detail in another TBD document.




--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Fri Aug  1 15:55:26 2003
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 PAA09677
	for ; Fri, 1 Aug 2003 15:55:26 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19iflO-0002Lr-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 01 Aug 2003 14:40:30 -0500
Received: from mailhost2.auckland.ac.nz ([130.216.1.4])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19iflM-0002Li-00
	for ipfix@net.doit.wisc.edu; Fri, 01 Aug 2003 14:40:29 -0500
Received: from mailhost.auckland.ac.nz (IDENT:mirapoint@mailhost [130.216.191.61])
	by mailhost2.auckland.ac.nz (8.12.9/8.12.9/8.12.9-ua) with ESMTP id h71JeQaB025930;
	Sat, 2 Aug 2003 07:40:26 +1200 (NZST)
Received: from hotlava.auckland.ac.nz (hotlava.auckland.ac.nz [130.216.191.123])
	by mailhost.auckland.ac.nz (Mirapoint Messaging Server MOS 3.3.5-GR)
	with ESMTP id ASX74278;
	Sat, 2 Aug 2003 07:40:25 +1200 (NZST)
Received: (from apache@localhost)
	by hotlava.auckland.ac.nz (8.11.6/8.11.6) id h71JePe27689;
	Sat, 2 Aug 2003 07:40:25 +1200
X-Authentication-Warning: hotlava.auckland.ac.nz: apache set sender to n.brownlee@auckland.ac.nz using -f
Received: from dyn54.caida.org (dyn54.caida.org [192.172.226.54]) by
	hotlava.auckland.ac.nz (Horde) with HTTP for
	; Sat,  2 Aug 2003 07:40:25 +1200
Message-ID: <1059766825.99a131a2e0289@hotlava.auckland.ac.nz>
Date: Sat,  2 Aug 2003 07:40:25 +1200
From: Nevil Brownlee 
To: carter@qosient.com
Cc: "'ipfix'" 
Subject: RE: [ipfix] Requirements: reaching consensus
References: 	<5C8959A16A71B449AE793CF52FBBED6607A661@ptah.newyork.qosient.com>
In-Reply-To: 	<5C8959A16A71B449AE793CF52FBBED6607A661@ptah.newyork.qosient.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
User-Agent: Internet Messaging Program (IMP) 4.0-cvs
X-Originating-IP:  192.172.226.54
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit

Hello Carter:

>    I am in support of a MUST for the indication
> of anonymization.  I am against the WG designing an
> anonymization algorithm because it is a bit more complex
> than the WG should take on.  Argus data has this indication
> support embedded in each record because users use anonymization
> more often than even aggregation, both of which are a pretty
> high percentage of users.  Only a very small number use
> encryption.  This is my experience, my opinion and my vote.
> 
>    So just for the record, any expression of opinion that
> can be used to determine concensus is a vote.  At least the
> Oxford English Dictionary and Webster's agree on that.  You
> yourself tallied the expression of opinions just now.  I
> believe that the correct statement is that the IETF does
> not use an election process to determine concensus.

Fair enough.  Thanks, Nevil

-----------------------------------------------------------------------
   Nevil Brownlee                   Director, Technology Development
   Phone: +64 9 373 7599 x88941     ITSS, The University of Auckland
   FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand


-------------------------------------------------
This mail sent through University of Auckland
http://www.auckland.ac.nz/

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Fri Aug  1 16:53:01 2003
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 QAA11887
	for ; Fri, 1 Aug 2003 16:53:00 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19igmu-0004Te-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 01 Aug 2003 15:46:08 -0500
Received: from auds953.usa.alcatel.com ([143.209.238.6])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19igmt-0004TX-00
	for ipfix@net.doit.wisc.edu; Fri, 01 Aug 2003 15:46:07 -0500
Received: from alcatel.com (localhost [127.0.0.1])
	by auds953.usa.alcatel.com (8.12.8p1/8.12.8) with ESMTP id h71KjuLX001114;
	Fri, 1 Aug 2003 15:45:56 -0500 (CDT)
Message-ID: <3F2AD183.C8973685@alcatel.com>
Date: Fri, 01 Aug 2003 15:45:55 -0500
From: Alex Audu 
Reply-To: alex.audu@alcatel.com
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: carter@qosient.com
CC: "'Nevil Brownlee'" ,
        "'ipfix'" 
Subject: Re: [ipfix] Requirements: reaching consensus
References: <5C8959A16A71B449AE793CF52FBBED6607A661@ptah.newyork.qosient.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit

I am also for IPFIX to be able to handle anonymized packets ( MUST),..but
not to anonymize packets.

Regards,
Alex.

Carter Bullard wrote:

> Hey Nevil,
>    I am in support of a MUST for the indication
> of anonymization.  I am against the WG designing an
> anonymization algorithm because it is a bit more complex
> than the WG should take on.  Argus data has this indication
> support embedded in each record because users use anonymization
> more often than even aggregation, both of which are a pretty
> high percentage of users.  Only a very small number use
> encryption.  This is my experience, my opinion and my vote.
>
>    So just for the record, any expression of opinion that
> can be used to determine concensus is a vote.  At least the
> Oxford English Dictionary and Webster's agree on that.  You
> yourself tallied the expression of opinions just now.  I
> believe that the correct statement is that the IETF does
> not use an election process to determine concensus.
>
> Carter
>
> > -----Original Message-----
> > From: majordomo listserver
> > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Nevil Brownlee
> > Sent: Friday, August 01, 2003 12:15 PM
> > To: carter@qosient.com
> > Cc: 'Randy Bush'; 'Changhoon Kim'; 'ipfix'
> > Subject: [ipfix] Requirements: reaching consensus
> >
> >
> >
> > Now then, people:
> >
> > This thread is about reaching WG consensus on one particular issue,
> > requirements for anonymization and encryption - lets keep it
> > focussed on that,please.
> >
> > When I asked everyone to express an opinion, that's all I was looking
> > for - we're certainly not holding any sort of a vote.
> >
> > To respond to Randy's point, at this stage it appears - from watching
> > the responses to the list - that:
> >  * we have clear support for encrypted transport of flow data
> >  * no-one on the list has expressed support for anonymization as
> >    a 'must implement' standaqrds requirement.  Several people
> >    (independently) have pointed out that there is no agreed-on
> >    anonymization technique at this stage.
> >  * we have a clearly expressed (by Sebastian) concern for privacy,
> >    and the proposal that we address this with a 'Privacy Concerns'
> >    section, probably in the Architecture Draft.
> >
> > Any further comment/opinion on the aononymization issue, let's hear
> > it now.
> >
> > Cheers, Nevil
> >
> > --------------------------------------------------------------
> > ---------
> >    Nevil Brownlee                   Director, Technology Development
> >    Phone: +64 9 373 7599 x88941     ITSS, The University of Auckland
> >    FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand
> >
> >
> > -------------------------------------------------
> > This mail sent through University of Auckland
> > http://www.auckland.ac.nz/
> >
> > --
> > Help        mailto:majordomo@net.doit.wisc.edu and say "help"
> > in message body
> > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> > "unsubscribe ipfix" in message body
> > Archive     http://ipfix.doit.wisc.edu/archive/
> >
>
> --
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Fri Aug  1 18:02:41 2003
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 SAA14083
	for ; Fri, 1 Aug 2003 18:02:40 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19ihrJ-0006eQ-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 01 Aug 2003 16:54:45 -0500
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19ihrI-0006eH-00
	for ipfix@net.doit.wisc.edu; Fri, 01 Aug 2003 16:54:44 -0500
Received: from cisco.com (171.71.177.237)
  by sj-iport-3.cisco.com with ESMTP; 01 Aug 2003 14:54:44 -0700
Received: from ios-xdm4.cisco.com (ios-xdm4.cisco.com [171.70.69.142])
	by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h71Lsfh2028350
	for ; Fri, 1 Aug 2003 14:54:41 -0700 (PDT)
Received: from cisco.com (dhcp-171-71-204-109.cisco.com [171.71.204.109]) by ios-xdm4.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id OAA25275 for ; Fri, 1 Aug 2003 14:54:40 -0700 (PDT)
Message-ID: <3F2AE1A0.22A39E4B@cisco.com>
Date: Fri, 01 Aug 2003 14:54:40 -0700
From: Ganesh Sadasivan 
Organization: Cisco Systems Inc
X-Mailer: Mozilla 4.79 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ipfix@net.doit.wisc.edu
Subject: [ipfix] Encoding the fields in flow records/templates
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit


Should IPFIX mention anything about the order in which fields
in flow records/templates are encoded, i.e.
network order/host order? Any suggestions?

Thanks
Ganesh


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Fri Aug  1 18:10:37 2003
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 SAA14853
	for ; Fri, 1 Aug 2003 18:10:37 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19ihzP-0006wp-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 01 Aug 2003 17:03:07 -0500
Received: from atlrel6.hp.com ([156.153.255.205])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19ihzP-0006wk-00
	for ipfix@net.doit.wisc.edu; Fri, 01 Aug 2003 17:03:07 -0500
Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191])
	by atlrel6.hp.com (Postfix) with ESMTP id 36C4E1C020FA
	for ; Fri,  1 Aug 2003 18:03:06 -0400 (EDT)
Received: from xatlbh3.atl.hp.com (xatlbh3.atl.hp.com [15.45.89.188])
	by xatlrelay2.atl.hp.com (Postfix) with ESMTP id 26A331C00A76
	for ; Fri,  1 Aug 2003 18:03:06 -0400 (EDT)
Received: by xatlbh3.atl.hp.com with Internet Mail Service (5.5.2655.55)
	id ; Fri, 1 Aug 2003 18:03:05 -0400
Message-ID: <1D3D2C371FCBD947A7897FABBD3533A502960235@xsun01.ptp.hp.com>
From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" 
To: ipfix@net.doit.wisc.edu
Subject: RE: [ipfix] Encoding the fields in flow records/templates
Date: Fri, 1 Aug 2003 18:02:59 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Precedence: bulk
Sender: majordomo listserver 

Hi,

  I'd strongly recommend network byte order like most other IETF
protocols use (and current NFvX uses).

  I would expect this to be in the protocol draft and used in 
reference to encoding of types defined in the information model.

Regards,

  Jeff Meyer

> -----Original Message-----
> From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com]
> Sent: Friday, August 01, 2003 2:55 PM
> To: ipfix@net.doit.wisc.edu
> Subject: [ipfix] Encoding the fields in flow records/templates
> 
> 
> 
> Should IPFIX mention anything about the order in which fields
> in flow records/templates are encoded, i.e.
> network order/host order? Any suggestions?
> 
> Thanks
> Ganesh
> 
> 
> --
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" 
> in message body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
> 

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Mon Aug  4 05:24:54 2003
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA20504
	for ; Mon, 4 Aug 2003 05:24:54 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19jb5q-0005Lg-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 04 Aug 2003 03:53:26 -0500
Received: from [195.92.98.65] (helo=rikwade.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19jb5o-0005LU-00
	for ipfix@net.doit.wisc.edu; Mon, 04 Aug 2003 03:53:25 -0500
Received: by rikwade.com (Postfix, from userid 1001)
	id BC4C620AA; Mon,  4 Aug 2003 08:53:23 +0000 (GMT)
Date: Mon, 4 Aug 2003 08:53:23 +0000
From: Rik Wade 
To: "'Nevil Brownlee'" ,
        "'ipfix'" 
Subject: Re: [ipfix] Requirements: reaching consensus
Message-ID: <20030804085323.GG88159@mango.rikwade.com>
References: <5C8959A16A71B449AE793CF52FBBED6618B3DC@ptah.newyork.qosient.com> <5C8959A16A71B449AE793CF52FBBED6607A661@ptah.newyork.qosient.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5C8959A16A71B449AE793CF52FBBED6607A661@ptah.newyork.qosient.com>
User-Agent: Mutt/1.4.1i
Precedence: bulk
Sender: majordomo listserver 

On Fri, 01 Aug 2003, Carter Bullard wrote:

>    I am in support of a MUST for the indication
> of anonymization.  I am against the WG designing an
> anonymization algorithm because it is a bit more complex
> than the WG should take on.  
[edited]

In summary, I would like to see support in IPFIX for packet anonymization
but can only see a small number of applications for it in our evironment.

Encryption support should (in my opinion) be a MUST for implementation
but should certainly be optional in its use. There is no predicting the
performance impact that using encryption would have in real-world
implementations.
--
rik wade

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Tue Aug  5 09:36:05 2003
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 JAA10449
	for ; Tue, 5 Aug 2003 09:36:05 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19k1d2-0000HM-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 05 Aug 2003 08:13:28 -0500
Received: from sj-core-4.cisco.com ([171.68.223.138])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19k1d1-0000HC-00
	for ipfix@net.doit.wisc.edu; Tue, 05 Aug 2003 08:13:27 -0500
Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17])
	by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h75DDFpp019850;
	Tue, 5 Aug 2003 06:13:16 -0700 (PDT)
Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134])
	by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AKL88817;
	Tue, 5 Aug 2003 06:13:13 -0700 (PDT)
Message-ID: <3F2FAD68.8010005@cisco.com>
Date: Tue, 05 Aug 2003 08:13:12 -0500
From: "Randall Stewart (cisco)" 
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3b) Gecko/20030323
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: David Moore 
CC: Nevil Brownlee , ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] Requirements: Encryption and Anonymozation
References: <1059583948.419d0eb2488eb@hotlava.auckland.ac.nz> <20030730105742.Z78801@login.caida.org>
In-Reply-To: <20030730105742.Z78801@login.caida.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit

David Moore wrote:

>On Thu, Jul 31, 2003 at 04:52:28AM +1200, Nevil Brownlee wrote:
>  
>
>> a) A fair proportion of users probably would use encryption to
>>    get their IPFIX data safely across the Internet.  We've said
>>    all along that we'd use IPSEC or IPSEC for that, rather than
>>    try to do it at the application layer in IPFIX.  So ...
>>    we should write a 'requirements' sentence saying that "IPFIX
>>    implementations MUST provide for encryption of exported IPFIX
>>    data, e.g. by using IPSEC or TLS."  [We need to verify that
>>    TLS would be suitable for this.]
>>    
>>
>
>How do IPSEC and TLS interact with not using TCP as the transport
>protocol?  For IPSEC, I presume you just tunnel SCTP in it since
>it is packet based, but I have no idea how you'd do TLS with SCTP.
>  
>

David:

RFC3436 details how you use TLS over SCTP.. this works fine but there
is one cavet to using TLS with SCTP... not all of the features will
work... in particular the un-ordered and the soon to be an RFC pr-sctp
cannot be used. This makes sense if one thinks about it since TLS uses
cipher block chaining.. which means everything MUST be delivered in
order for it to work. Note UDP and DCCP have the same issues as well... 
I believe
that Allision was going to work on a "modified" TLS (at least I have heard
that second hand) that might be capable of handling things like UDP, 
DCCP and
PR-SCTP... but this is several years away at best...

>Probably saying that they MUST provide for encryption is fine.
>It's just likely that the preferred format may come down related
>to if there is a mandatory minimal transport protocol to be supported.
>  
>
SCTP or TCP works fine with TLS so it should not be a problem ....
And of course all of them TCP/UDP/SCTP/DCCP work fine with
IP-Sec...


R

>Also, as written, implementations might chose to do encryption in
>some proprietary way and therefore prevent interoperability.  Although,
>obviously one would hope they wouldn't.
>
>  
>
>> b) For anonymization, we should remove any mention of it from
>>    the Requirements Draft, because:
>>    
>>
>
>In a perfect world, I'd like to see ipfix support anonymization,
>but I'm not sure what the right approach to suggest is.  And I'm
>not sure that I really like the idea that by having a 'MUST support
>anonymization", that every vendor will go off an implement an ad-hoc
>anonymization scheme.
>
>-- david
>
>--
>Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>"unsubscribe ipfix" in message body
>Archive     http://ipfix.doit.wisc.edu/archive/
>
>  
>


-- 
Randall R. Stewart
ITD
Cisco Systems Inc.
rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office)



--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Fri Aug  8 03:17:13 2003
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 DAA02082
	for ; Fri, 8 Aug 2003 03:17:13 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19l18x-0000Ms-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 08 Aug 2003 01:54:31 -0500
Received: from babar.switch.ch ([130.59.4.85])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19l18w-0000Mh-00
	for ipfix@net.doit.wisc.edu; Fri, 08 Aug 2003 01:54:30 -0500
Received: from babar.switch.ch (localhost [IPv6:::1])
	by babar.switch.ch (8.12.9+Sun/8.12.2) with ESMTP id h786sJiM017963;
	Fri, 8 Aug 2003 08:54:19 +0200 (CEST)
Received: (from leinen@localhost)
	by babar.switch.ch (8.12.9+Sun/8.12.2/Submit) id h786sInW017962;
	Fri, 8 Aug 2003 08:54:18 +0200 (CEST)
X-Authentication-Warning: babar.switch.ch: leinen set sender to simon@limmat.switch.ch using -f
To: Ganesh Sadasivan 
Cc: ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] Encoding the fields in flow records/templates
X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7,F
   7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z,@ttmwYVO7l`6OXXYR`
From: Simon Leinen 
In-Reply-To: <3F2AE1A0.22A39E4B@cisco.com> (Ganesh Sadasivan's message of
 "Fri, 01 Aug 2003 14:54:40 -0700")
References: <3F2AE1A0.22A39E4B@cisco.com>
Date: Fri, 08 Aug 2003 08:54:18 +0200
Message-ID: 
User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (usg-unix-v)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Precedence: bulk
Sender: majordomo listserver 

Ganesh Sadasivan writes:
> Should IPFIX mention anything about the order in which fields in
> flow records/templates are encoded, i.e.  network order/host order?

Of course this must be mentioned in the protocol definition.
Otherwise there will be an interoperability issue.

> Any suggestions?

I suggest using network byte order (big-endian), in the interest of
protocol and implementation simplicity, as well as consistency with
earlier versions of NetFlow and with other IETF protocols.
-- 
Simon.

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Tue Aug 12 15:56:48 2003
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 PAA27724
	for ; Tue, 12 Aug 2003 15:56:47 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19melQ-0002oc-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 12 Aug 2003 14:25:00 -0500
Received: from mailhost2.auckland.ac.nz ([130.216.1.4])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19melO-0002oR-00
	for ipfix@net.doit.wisc.edu; Tue, 12 Aug 2003 14:24:58 -0500
Received: from mailhost.auckland.ac.nz (IDENT:mirapoint@mailhost [130.216.191.61])
	by mailhost2.auckland.ac.nz (8.12.9/8.12.9/8.12.9-ua) with ESMTP id h7CJOukl000517
	for ; Wed, 13 Aug 2003 07:24:56 +1200 (NZST)
Received: from hotlava.auckland.ac.nz (hotlava.auckland.ac.nz [130.216.191.123])
	by mailhost.auckland.ac.nz (Mirapoint Messaging Server MOS 3.3.5-GR)
	with ESMTP id ATJ28309;
	Wed, 13 Aug 2003 07:24:55 +1200 (NZST)
Received: (from apache@localhost)
	by hotlava.auckland.ac.nz (8.11.6/8.11.6) id h7CJOtg07467
	for ipfix@net.doit.wisc.edu; Wed, 13 Aug 2003 07:24:55 +1200
X-Authentication-Warning: hotlava.auckland.ac.nz: apache set sender to n.brownlee@auckland.ac.nz using -f
Received: from dyn54.caida.org (dyn54.caida.org [192.172.226.54]) by
	hotlava.auckland.ac.nz (Horde) with HTTP for
	; Wed, 13 Aug 2003 07:24:54 +1200
Message-ID: <1060716294.7652aed6fe52b@hotlava.auckland.ac.nz>
Date: Wed, 13 Aug 2003 07:24:54 +1200
From: Nevil Brownlee 
To: ipfix@net.doit.wisc.edu
Subject: RE: [ipfix] Encoding the fields in flow records/templates
References: <1D3D2C371FCBD947A7897FABBD3533A502960235@xsun01.ptp.hp.com>
In-Reply-To: <1D3D2C371FCBD947A7897FABBD3533A502960235@xsun01.ptp.hp.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
User-Agent: Internet Messaging Program (IMP) 4.0-cvs
X-Originating-IP:  192.172.226.54
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit


I agree with Jeff Meyer, who said:

>   I'd strongly recommend network byte order like most other IETF
> protocols use (and current NFvX uses).
> 
>   I would expect this to be in the protocol draft and used in
> reference to encoding of types defined in the information model.

This seems obvious, but it does need to be said explicitly.

Cheers, Nevil

> > From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com]
> > Sent: Friday, August 01, 2003 2:55 PM
> >
> > Should IPFIX mention anything about the order in which fields
> > in flow records/templates are encoded, i.e.
> > network order/host order? Any suggestions?

-----------------------------------------------------------------------
   Nevil Brownlee                   Director, Technology Development
   Phone: +64 9 373 7599 x88941     ITSS, The University of Auckland
   FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand


-------------------------------------------------
This mail sent through University of Auckland
http://www.auckland.ac.nz/

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Tue Aug 12 22:45:49 2003
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 WAA07578
	for ; Tue, 12 Aug 2003 22:45:49 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19mlKE-00002b-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 12 Aug 2003 21:25:22 -0500
Received: from mailhost2.auckland.ac.nz ([130.216.1.4])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19mlKD-00002V-00
	for ipfix@net.doit.wisc.edu; Tue, 12 Aug 2003 21:25:21 -0500
Received: from mailhost.auckland.ac.nz (IDENT:mirapoint@mailhost [130.216.191.61])
	by mailhost2.auckland.ac.nz (8.12.9/8.12.9/8.12.9-ua) with ESMTP id h7D2PHkn008938
	for ; Wed, 13 Aug 2003 14:25:19 +1200 (NZST)
Received: from hotlava.auckland.ac.nz (hotlava.auckland.ac.nz [130.216.191.123])
	by mailhost.auckland.ac.nz (Mirapoint Messaging Server MOS 3.3.5-GR)
	with ESMTP id ATJ81600;
	Wed, 13 Aug 2003 14:25:15 +1200 (NZST)
Received: (from apache@localhost)
	by hotlava.auckland.ac.nz (8.11.6/8.11.6) id h7D2PFo11204
	for ipfix@net.doit.wisc.edu; Wed, 13 Aug 2003 14:25:15 +1200
X-Authentication-Warning: hotlava.auckland.ac.nz: apache set sender to n.brownlee@auckland.ac.nz using -f
Received: from dyn54.caida.org (dyn54.caida.org [192.172.226.54]) by
	hotlava.auckland.ac.nz (Horde) with HTTP for
	; Wed, 13 Aug 2003 14:25:15 +1200
Message-ID: <1060741515.99c4bdc92726a@hotlava.auckland.ac.nz>
Date: Wed, 13 Aug 2003 14:25:15 +1200
From: Nevil Brownlee 
To: ipfix@net.doit.wisc.edu
Subject: [ipfix] Nevil's IPFIX current issues
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
User-Agent: Internet Messaging Program (IMP) 4.0-cvs
X-Originating-IP:  192.172.226.54
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit


Hi all:

Back in early July - when I'd just finished reading all the IPFIX drafts -
I sent out a list of issues which I thought needed some discussion.
There was some discussion on some of the issues, but not a lot.  Now that
we've had a chance to recover from IETF, it's time to get back to work
on the drafts, we need to rev them at least once or twice between now and
mid-October.  

The following is my current issues list, I've added one on 'default transport
protocol.'  Please think about these, and send some comment/opinion to the
list.


Ng1: Timestamps
Drafts: Protocol, Info Model

>      a) How many bytes do we really need?  If seconds is precise enough,
>         4 bytes is fine.  If we need more, or should we could go to 8?
>      b) If we feel that we can afford 8-byte precision, what time base
>         should we use, sysUpTime or time of day.  Time of day would mean
>         that collectors didn't have to convert from sysUpTime.  Can we
>         assume that Metering Processes will have a reliable time-of-day
>         clock?
>      c) Format of 8-byte times.  The most common Unix one is (sec, usec).
>         (sec, nsec) is also widely available.  My favourite is
>         (sec, binary fraction of sec) [NTP 64-bit timestamp, Section
>         3.1 of RFC 1305], because you
>         can compute time differences with a single 64-bit subtraction.

There wasn't much reaction, but the few who did respond said yes,
we need better resolution than seconds.  That implies that the answer 
to (a) is "8-byte timestamps."

Now we need to decide on (b) and (c).  For (b), I'd like to see
Unix-epoch times (i.e. relative to 1 Jan 1970) in UTC timezone.
Anyone care to offer a different position on that?
[Note that where an IPFIX metering process doesn't have access to
an ntp-synchronised (or GPS-synchronised, CDMA-synchronised, etc.)
clock, IPFIX collectors - which I presume will at least have an
ntp-synchronised clock - can verify that the reported timestamps
aren't too far away from actual time.]

As for the timestamp data type, I'd still like to see IPFIX use the
NTP 64-bit format.  It's easy to get seconds from that (the high-order
32 bits), and the metering process can fill in as many of the low-order
bits as its clock will allow.  That makes it a clean, universal 
timestamp data type.
Failing that, another possibility would be a Unix timeval, (seconds 
in the high-order 32 bits, and microseconds in the low-order 32).
What do others, particularly implementors of IPFIX meters and
collectors, prefer?
[We need to decide this, it needs to go into the drafts now!]


Ng-2: Encoding for variable-length data types
Drafts: Protocol

There's been a little discussion of byte ordering, let's agree on
network byte order.

>                                                               For the
>      variable length fields, there seemed to be some discussion around
>      the use of 1,2 or 4 byte length indicators.   There also remains
>      the question of whether or not padding is used for any sort of
>      word alignment.

This one hasn't been discussed further.  Let's hear your opinion now!
Which flow attributes will be variable-length?
The Info Model draft only has one variable-length type, 'string,'
i.e. a UTF8 string.  Can someone please tell us how that should be 
carried on the wire - e.g. first byte carries the length, followed
by the data bytes.  Or what?


Ng4: Flow Sampling.  
Drafts: Architecture, ?

>      This is mentioned in both the Requirements I-D
>      and the AS I-D.  We need to decide how it should be covered in the
>      IPFIX drafts.

No discussion on this one so far.  But it could be a useful tool
to reduce the amount of flow data one needs to export/collect.
Comments?  Suggestions??


Ng5: IPFIX Default Transport Protocol
Drafts: Protocol

I went to the NETCONF WG session at the Vienna IETF; they have a list
of three transport protocols which would be suitable for NETCONF.  They
discussed the question of whether one of them should be the NETCONF
default, i.e. a 'MUST implement,' and if so, which one.  We need to
consider this question for IPFIX.

When I asked our Area Directors about this, they both said that IPFIX
ought to have a default transport protocol, so that users know they
can plug in an IPFIX device and have it work with other IPFIX devices.

The question now is, which protocol?  The candidates available now
are SCTP and TCP.  Now's the time to send your opinions (with reasoned
technical arguments) to the list so that we can form a WG consensus!


Cheers, Nevil

-----------------------------------------------------------------------
   Nevil Brownlee                   Director, Technology Development
   Phone: +64 9 373 7599 x88941     ITSS, The University of Auckland
   FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand


-------------------------------------------------
This mail sent through University of Auckland
http://www.auckland.ac.nz/

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Tue Aug 12 23:58:54 2003
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 XAA10132
	for ; Tue, 12 Aug 2003 23:58:53 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19mmaS-0002Z3-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 12 Aug 2003 22:46:12 -0500
Received: from palrel12.hp.com ([156.153.255.237])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19mmaR-0002Yw-00
	for ipfix@net.doit.wisc.edu; Tue, 12 Aug 2003 22:46:11 -0500
Received: from xparelay1.ptp.hp.com (xparelay1.ptp.hp.com [15.1.28.62])
	by palrel12.hp.com (Postfix) with ESMTP id 435E81C010BE
	for ; Tue, 12 Aug 2003 20:46:10 -0700 (PDT)
Received: from xpabh3.ptp.hp.com (xpabh3.ptp.hp.com [15.1.28.63])
	by xparelay1.ptp.hp.com (Postfix) with ESMTP id 3E1841004BA0
	for ; Tue, 12 Aug 2003 20:46:10 -0700 (PDT)
Received: by xpabh3.ptp.hp.com with Internet Mail Service (5.5.2655.55)
	id ; Tue, 12 Aug 2003 20:46:10 -0700
Message-ID: <1D3D2C371FCBD947A7897FABBD3533A502960281@xsun01.ptp.hp.com>
From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" 
To: "'ipfix@net.doit.wisc.edu'" 
Subject: [ipfix] Update available: draft-ietf-ipfix-info-01.txt
Date: Tue, 12 Aug 2003 20:46:03 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Precedence: bulk
Sender: majordomo listserver 

Hi,

  A revised version of the IPFIX Information Model has been submitted.

  While this is getting uploaded, the document (and other artifacts) may be
found at the following location:

    - IETF formatted .txt file is available at:
 
http://www.ipdr.org/documents/ipfix/infomodel/draft-ietf-ipfix-info-01.txt

    - The HTML formatted and source XML documents are also available:
 
http://www.ipdr.org/documents/ipfix/infomodel/draft-ietf-ipfix-info-01.html
 
http://www.ipdr.org/documents/ipfix/infomodel/draft-ietf-ipfix-info-01.xml

    - The Change History for the -01 draft is at:
         http://www.ipdr.org/documents/ipfix/infomodel/changehistory.txt

    - The README document describing the artifacts from this process and
with
      pointers to historical documents is available at:

         http://www.ipdr.org/documents/ipfix/infomodel/README.html


Regards,

  Jeff Meyer

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Wed Aug 13 08:14:33 2003
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 IAA16854
	for ; Wed, 13 Aug 2003 08:14:32 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19mu9U-00037V-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 13 Aug 2003 06:50:52 -0500
Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19mu9T-00037O-00
	for ipfix@net.doit.wisc.edu; Wed, 13 Aug 2003 06:50:51 -0500
Received: from cisco.com (dhcp-peg3-vl30-144-254-7-226.cisco.com [144.254.7.226])
	by strange-brew.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id h7DBokp23731;
	Wed, 13 Aug 2003 13:50:47 +0200 (CEST)
Message-ID: <3F3A2614.3030100@cisco.com>
Date: Wed, 13 Aug 2003 13:50:44 +0200
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Nevil Brownlee 
CC: ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] Encoding the fields in flow records/templates
References: <1D3D2C371FCBD947A7897FABBD3533A502960235@xsun01.ptp.hp.com> <1060716294.7652aed6fe52b@hotlava.auckland.ac.nz>
In-Reply-To: <1060716294.7652aed6fe52b@hotlava.auckland.ac.nz>
Content-Type: multipart/alternative;
 boundary="------------060008080600030608090504"
Precedence: bulk
Sender: majordomo listserver 

This is a multi-part message in MIME format.
--------------060008080600030608090504
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Nevil Brownlee wrote:

>I agree with Jeff Meyer, who said:
>
>  
>
>>  I'd strongly recommend network byte order like most other IETF
>>protocols use (and current NFvX uses).
>>
>>  I would expect this to be in the protocol draft and used in
>>reference to encoding of types defined in the information model.
>>    
>>
>
>This seems obvious, but it does need to be said explicitly.
>
It will be added in the protocol draft.

Regards, Benoit.

>
>Cheers, Nevil
>
>  
>
>>>From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com]
>>>Sent: Friday, August 01, 2003 2:55 PM
>>>
>>>Should IPFIX mention anything about the order in which fields
>>>in flow records/templates are encoded, i.e.
>>>network order/host order? Any suggestions?
>>>      
>>>
>
>-----------------------------------------------------------------------
>   Nevil Brownlee                   Director, Technology Development
>   Phone: +64 9 373 7599 x88941     ITSS, The University of Auckland
>   FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand
>
>
>-------------------------------------------------
>This mail sent through University of Auckland
>http://www.auckland.ac.nz/
>
>--
>Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>"unsubscribe ipfix" in message body
>Archive     http://ipfix.doit.wisc.edu/archive/
>  
>


--------------060008080600030608090504
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit




  
  


Nevil Brownlee wrote:



  
I agree with Jeff Meyer, who said:

  

  

    
  I'd strongly recommend network byte order like most other IETF
protocols use (and current NFvX uses).

  I would expect this to be in the protocol draft and used in
reference to encoding of types defined in the information model.
    

  

  

This seems obvious, but it does need to be said explicitly.



It will be added in the protocol draft.



Regards, Benoit.





  

Cheers, Nevil

  

  

    

      
From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com]
Sent: Friday, August 01, 2003 2:55 PM

Should IPFIX mention anything about the order in which fields
in flow records/templates are encoded, i.e.
network order/host order? Any suggestions?
      

    

  

  

-----------------------------------------------------------------------
   Nevil Brownlee                   Director, Technology Development
   Phone: +64 9 373 7599 x88941     ITSS, The University of Auckland
   FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand


-------------------------------------------------
This mail sent through University of Auckland
http://www.auckland.ac.nz/

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/
  








--------------060008080600030608090504--


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Wed Aug 13 08:45:18 2003
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 IAA17757
	for ; Wed, 13 Aug 2003 08:45:18 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19muoe-0004Ym-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 13 Aug 2003 07:33:24 -0500
Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19muoc-0004Yd-00
	for ipfix@net.doit.wisc.edu; Wed, 13 Aug 2003 07:33:23 -0500
Received: from cisco.com (dhcp-peg3-vl30-144-254-7-226.cisco.com [144.254.7.226])
	by strange-brew.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id h7DCXBp14216;
	Wed, 13 Aug 2003 14:33:11 +0200 (CEST)
Message-ID: <3F3A3005.7040503@cisco.com>
Date: Wed, 13 Aug 2003 14:33:09 +0200
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "MEYER,JEFFREY D (HP-Cupertino,ex1)" 
CC: "'ipfix@net.doit.wisc.edu'" 
Subject: Re: [ipfix] Update available: draft-ietf-ipfix-info-01.txt
References: <1D3D2C371FCBD947A7897FABBD3533A502960281@xsun01.ptp.hp.com>
In-Reply-To: <1D3D2C371FCBD947A7897FABBD3533A502960281@xsun01.ptp.hp.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit

Jeff,

>Hi,
>
>  A revised version of the IPFIX Information Model has been submitted.
>
>  While this is getting uploaded, the document (and other artifacts) may be
>found at the following location:
>
>    - IETF formatted .txt file is available at:
> 
>http://www.ipdr.org/documents/ipfix/infomodel/draft-ietf-ipfix-info-01.txt
>
One quick comment, from the Vienna meeting minutes
http://ipfix.doit.wisc.edu/IETF57/minutes.txt
        Juergen mentioned that the the definitions named with the "ipdr" 
prefix should change.

Regards, Benoit.

>
>    - The HTML formatted and source XML documents are also available:
> 
>http://www.ipdr.org/documents/ipfix/infomodel/draft-ietf-ipfix-info-01.html
> 
>http://www.ipdr.org/documents/ipfix/infomodel/draft-ietf-ipfix-info-01.xml
>
>    - The Change History for the -01 draft is at:
>         http://www.ipdr.org/documents/ipfix/infomodel/changehistory.txt
>
>    - The README document describing the artifacts from this process and
>with
>      pointers to historical documents is available at:
>
>         http://www.ipdr.org/documents/ipfix/infomodel/README.html
>
>
>Regards,
>
>  Jeff Meyer
>
>--
>Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>"unsubscribe ipfix" in message body
>Archive     http://ipfix.doit.wisc.edu/archive/
>  
>



--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Wed Aug 13 12:29:07 2003
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 MAA25072
	for ; Wed, 13 Aug 2003 12:29:06 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19myJV-0003mU-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 13 Aug 2003 11:17:29 -0500
Received: from ams-iport-1.cisco.com ([144.254.74.5])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19myJU-0003mJ-00
	for ipfix@net.doit.wisc.edu; Wed, 13 Aug 2003 11:17:28 -0500
Received: from cisco.com (144.254.74.60)
  by ams-iport-1.cisco.com with ESMTP; 13 Aug 2003 18:16:54 +0200
Received: from cisco.com (localhost [127.0.0.1])
	by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h7DGFBwb024437;
	Wed, 13 Aug 2003 18:15:12 +0200 (MET DST)
Received: from cisco.com (dhcp-rea-gp250-64-103-65-15.cisco.com [64.103.65.15])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id RAA29000;
	Wed, 13 Aug 2003 17:17:25 +0100 (BST)
Message-ID: <3F3A6495.7030806@cisco.com>
Date: Wed, 13 Aug 2003 17:17:25 +0100
From: Stewart Bryant 
Reply-To: stbryant@cisco.com
Organization: Cisco Systems, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "MEYER,JEFFREY D (HP-Cupertino,ex1)" 
CC: "'ipfix@net.doit.wisc.edu'" 
Subject: Re: [ipfix] Update available: draft-ietf-ipfix-info-01.txt
References: <1D3D2C371FCBD947A7897FABBD3533A502960281@xsun01.ptp.hp.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit

Jeff

Some comments on :

             Information Model for IP Flow Information Export
                         draft-ietf-ipfix-info-01

SB> An (IETF) information model shows the relationship between abstract
SB> information objects. I don't think that there are any we need
SB> to be concerned about here. This is surely a data model.



2. Scope

    This document defines an information model for the IP Flow
    Information eXport (IPFIX) protocol. The model consists of of a set
    of information elements, each one defining a single attribute of a
    flow. For each individual attribute, the semantics is clearly
    specified and a data type is assigned to it.

SB> Surely this is a data model that should be shared from day one
SB> with PSAMP. That being so perhaps PSAMP should be referenced
SB> here.




4. Type Space

SB> I think that you need another type, the unsigned variant integer.
SB> If you look at the netflow V9 draft you will see that this is
SB> used extensively, but in the current version is not explicitly
SB> called out. Look for the integer-like objects of length N.
SB> I believe that the next version of the draft will provide more
SB> detail on how to interpret numeric objects of length N.
SB>
SB> Unsigned variant integers are used where the precision of the
SB> object is implementation dependent. This has the advantage
SB> that we can have large counters on fast interfaces, but do
SB> not need to waste cache space in the exporter, nor do we need
SB> to waste export bandwidth when a smaller counter will suffice.
SB> There are other objects that can also usefully use this,
SB> for example AS numbers.
SB>
SB> Ganesh Sadasivan and I and worked on this and our conclusion
SB> was that you need to define an unsigned variant integer
SB> as follows:
SB>
SB> type varUnsignedInt
SB>    if (element.length == 1)
SB>          type = unsignedByte
SB>    else if (element.length == 2)
SB>         type = unsignedShort
SB>    else if (element.length <= 4)
SB>         type = unsignedInt
SB>    else if (element.length <= 8)
SB>         type = usignedLong
SB>   else type = undefined
SB>
SB> I show where these need to be used in the comments that follow.
SB>
SB> Ganesh also noted that in a 32 bit machine unsignedInt &
SB> unsignedLong are used used interchangeably. It might therefore be
SB> clearer if you used the terms uint8_t, uint16_t, uint32_t and uint64_t
SB> to make things more explicit.
SB>
SB>



4.9 boolean

    The type "boolean" represents the values for binary logic. (i.e.
    "true/false" or "1/0").

SB> We are never going to export a data unit of less than 8 bits
SB> and normally we will just export some flag field from a packet
SB> so I wonder if this serves any purpose other than completeness.



6. Flow Attributes



6.5 protocolIdentifier

    Description:

    Protocol number identified in the IP packet.

    In the Internet Protocol version 4 (IPv4) [RFC791] there is a field,
    called "Protocol", to identify the next level protocol.  This is an 8
    bit field.  In Internet Protocol version 6 (IPv6) [RFC1883] this
    field is called the "Next Header" field.

    These numbers are administered by IANA.

    Type:  The protocolIdentifier element is of type int.

SB> Surely it should be unsignedByte to match the definition in both
SB> RFC791 and RFC1883?

    Reference:  Additional information on this element can be found at
    http://www.iana.org/assignments/protocol-numbers.

    Field Id:  4



6.8 ingressPort

    Description:

    The ifIndex where the packets for the flow are being received.
    ifIndex is defined by RFC 2233.

    Type:  The ingressPort element is of type unsignedShort.

    Field Id:  10

SB> This should be an unsigned variant integer, because some systems
SB> will have more than 64K ports.

6.9 egressPort

    Description:

    The ifIndex where the packets for the flow are exiting. ifIndex is
    defined by RFC 2233.

    Type:  The egressPort element is of type unsignedShort.

SB> This should be an unsigned variant integer, because some systems
SB> will have more than 64K ports.


    Field Id:  14

6.10 packetCount

    Description:

    Contains the count of packets sent and received associated with the
    identified flow.

    The packet count can be for packets received (towards source) or
    packets sent (towards destination) or both (bi-directional flow).

    The packet count can be a running counter and is the count from the
    beginning of the flow establishment.

    The packet count can be a delta counter and is the count since the
    last report for this flow.

    Type:  The packetCount element is of type int.

SB> This cannot be a signed number, -1 packets has no meaning. In
SB> any case it needs to be an unsigned variant integer, because
SB> some interfaces will need 32 bit counters and some will need
SB> 64 bit counters.

    Units:  The unit of measure is  packets.

    Field Id:  2

6.11 byteCount

    Description:

    Contains the count of octets sent and received associated with the
    identified flow.

    The byte count can be for bytes received (towards source) or bytes
    sent (towards destination) or both (bi-directional flow).

    The byte count can be a running counter and is the count from the
    beginning of the flow establishment.

    The byte count can be a delta counter and is the count since the last
    report for this flow.

    Type:  The byteCount element is of type int.

SB> This cannot be a signed number, -1 bytes has no meaning. In
SB> any case it needs to be an unsigned variant integer, because
SB> some interfaces will need 32 bit counters and some will need
SB> 64 bit counters.

    Units:  The unit of measure is  bytes.

    Field Id:  1

6.12 classOfService

    Description:

    The class of service associated with a flow.

    Class of Service Received

    Class of Service Transmitted

    1. IPv4, CoS value is defined by ToS in RFC 791 2. IPv6, CoS value is
    defined by Traffic Class in RFC 2460 3. MPLS, CoS value is defined by
    Exp in RFC 3032 4. VLAN, CoS value is defined by user_priority in
    IEEE802.1q[802.1q] and IEEE 802.1p[802.1p]

    Type:  The classOfService element is of type byte.

SB> This should be unsignedByte

    Field Id:  5

6.13 flowLabel

    Description:

    The Flow Label information element contains the IPV6 Flow Label
    information as defined by RFC 2460.

    Type:  The flowLabel element is of type int.

SB> This cannot be an int. It might be an unsignedInt, but that
SB> wastes a byte. It could be an unsigned variant integer of length
SB> 3, or it could be a hexbyte of length 3.

    Field Id:  31

6.14 flowCreationTime

    Description:

    The timestamp of the first packet of the flow.  (Ed. note:  current
    NFv9 protocol uses sysuptime vs. direct time.  Not interesting from
    an info model perspective, an artifact (and an annoying one from a
    consumer perspective) of the protocol implementation details. How to
    address?)

    Type:  The flowCreationTime element is of type dateTime.

    Field Id:  21

SB> For consistency with Netflow v9 this should be 22 (FIRST_SWITCHED)

6.15 flowEndTime

    Description:

    The timestamp of the last packet of the flow.  (Ed. note:  current
    NFv9 protocol uses sysuptime vs. direct time.  Not interesting from
    an info model perspective, an artifact (and an annoying one from a
    consumer perspective) of the protocol implementation details. How to
    address?)

    Type:  The flowEndTime element is of type dateTime.

    Field Id:  22
SB> For consistency with Netflow v9 this should be 21 (LAST_SWITCHED)

6.16 sourceAS

    Description:

    The Autonomous System (AS) numbers for the source address associated
    with a flow. Autonomous System (AS) number is defined by RFC 1930 and
    RFC 1771 (BGP-4):

    Type:  The sourceAS element is of type int.

SB> This cannot be an int, it must be an unsignedInt. However the change
SB> from unsignedShort to unsignedInt is still a draft and in any case
SB> much of the world will remain unsignedShort for a long time. I think
SB> that this needs to be an unsigned variant integer. I think that some
SB> netflow v9 systems export this as an unsignedShort.

    Field Id:  16

6.17 destinationAS

    Description:

    The Autonomous System (AS) numbers for the destination address
    associated wit a flow. Autonomous System (AS) number is defined by
    RFC 1930 and RFC 1771 (BGP-4).

    Type:  The destinationAS element is of type int.

SB> This cannot be an int, it must be an unsignedInt. However the change
SB> from unsignedShort to unsignedInt is still a draft and in any case
SB> much of the world will remain unsignedShort for a long time. I think
SB> that this needs to be an unsigned variant integer. I think that some
SB> netflow v9 systems export this as an unsignedShort.

    Field Id:  17

6.18 nextHopAS

    Description:

    The Autonomous System (AS) numbers for the next hop IP. Autonomous
    System (AS) number is defined by RFC 1930 and RFC 1771 (BGP-4).

    Type:  The nextHopAS element is of type int.

SB> This cannot be an int, it must be an unsignedInt. However the change
SB> from unsignedShort to unsignedInt is still a draft and in any case
SB> much of the world will remain unsignedShort for a long time. I think
SB> that this needs to be an unsigned variant integer.

    Field Id:  -1

6.19 tcpControlBits

    Description:

    The TCP control bits seen for this flow. Note a 0 value for each bit
    only indicates that the flag was not detected (i.e. it may have
    occurred but was not detected by the reporting CCE). TCP Control Bits
    are defined by RFC 793.

    Type:  The tcpControlBits element is of type int.

SB> RFC 793 defines this as a set of flags that ocupy a byte. Making
SB> it a signed object is wrong. It should surely be an unsignedByte
SB> since it can never get to be any longer.

    Field Id:  6

6.22 droppedPacketCount

    Description:

    Contains the count of packets dropped at the observation point
    associated with the identified flow.

    The dropped packet count can be a running counter and is the count
    from the beginning of the flow establishment.

    The dropped packet count can be a delta counter and is the count
    since the last report for this flow.

    Type:  The droppedPacketCount element is of type int.

    Units:  The unit of measure is  packets.

SB> This cannot be a signed number, -1 packets has no meaning. In
SB> any case it needs to be an unsigned variant integer, because
SB> some interfaces will need 32 bit counters and some will need
SB> 64 bit counters.

    Field Id:  -1

6.23 samplingInterval

    Description:

    When using Sampling, the rate at which packets is sampled. For
    example, a value of 100 indicates that one of every hundred packets
    is sampled.

    Type:  The samplingInterval element is of type int.

SB> This must be an unsignedInt, because a negative interval has no meaning.
SB> The netflow V9 informational draft has this as 4 bytes, but I think
SB> that there are some netflow V9 systems that implemented it as an
SB> unsignedShort, so it would useful if we made it an unsigned
SB> variant integer to gain backwards compatibility.

    Field Id:  34

6.24 samplingAlgorithm

    Description:

    The type of algorithm used for sampling data. Currently, the only
    sampling algorithm defined  is: 0x02 packet-sampling

    Type:  The samplingAlgorithm element is of type int.

SB> This must be an unsigned int, although I think that some netflow V9
SB> implementations implemented it as an unsignedShort. Again unsigned
SB> variant integer would fix this.

    Field Id:  35

6.25 flowEndState

    Description:

    The reason the flow has ended. 1. Inactivity timeout 2. End of flow
    detected (e.g. TCP FIN) 3. Forced end ???? 4. Cache full
    [enumerations in IPDR service def schemas are recommended to be of
    form string, w/ integer values (for Compact format) defined via
    annotation]

    Type:  The flowEndState element is of type int.

SB> I am not sure we need 4G states, but in any case it should
SB> be unsigned.

    Field Id:  -1

6.26 droppedByteCount

    Description:

    Contains the count of octets dropped at the observation point
    associated with the identified flow.

    The dropped byte count can be a running counter and is the count from
    the beginning of the flow establishment.

    The byte count can be a delta counter and is the count since the last
    report for this flow.

    Type:  The droppedByteCount element is of type int.

    Units:  The unit of measure is  bytes.

    Field Id:  -1

SB> This cannot be a signed number, -1 bytes has no meaning. In
SB> any case it needs to be an unsigned variant integer, because
SB> some interfaces will need 32 bit counters and some will need
SB> 64 bit counters.

7. The Benefits of a Formal Machine Readable Information Model

SB> This is something of a sales pitch. I think that you will have
SB> to cut this down by the time the draft goes for IESG review

    Appendix A. expresses the IPFIX Information model as an XML-Schema.
    Using a formal and machine readable syntax for the Information model
    enables the creation of IPFIX aware tools which can automatically
    adapt to extensions to the information model, by simply reading
    updated information model specifications.

    The use of XML-Schema as the formal specification language is modeled
    after the techniques employed by the IPDR NDM-U specification.

    The wide availability of XML aware tools and libraries for client
    devices is a primary consideration for this choice.  In particular
    libraries for parsing XML documents are readily available.  Also
    mechanisms such as the Extensible Stylesheet Language (XSL) allow for
    transforming a source XML document into other documents.  This draft
    was initially authored in XML and transformed according to RFC2629.

    It should be noted that the use of XML in exporters, collectors or
    other tools is not mandatory for the deployment of IPFIX.  In
    particular exporting processes do not produce or consume XML as part
    of their operation.  It is expected that IPFIX collectors MAY take
    advantage of the machine readability of the Information Model vs.
    hardcoding their behavior or inventing proprietary means for
    accomodating extensions.






Appendix A. IPFIX IPDR Service Definition

    This proposal does not currently address possible IANA implications
    associated with XML Namespace URIs. The use of Namespaces as an
    extension mechanism implies that an IANA registered Namespace URI
    should be available and that directory names below this base URI be
    assigned for relevant IETF specifications. The author is not aware of
    this mechanism today. Alternatively IPDR.org could fulfill this role.
    The sample uses the IPDR.org namespace.

    The normative status of this appendix versus the section "Flow
    Attributes" is a point of discussion.  The "Flow Attributes" section
    is simply machine generated from the formal XML document below.  As
    such using the formal XML document would seem preferable.  However
    historical conventions and IETF's overall level of XML adoption may
    lead to selection of the human readable text in the "Flow Attributes"
    section as being preferable as normative.

SB> The fact that the body is machine generated from this XML does
SB> not rescue you from the fact that the RFC editor will use some
SB> other process to produce the final document that may result in errors.
SB> You will need some means to check the consistency of the two
SB> definitions after than process. In any case as a final backstop
SB> in the event of some unforeseen gremlin creeping into the process
SB> one or the other definitions must be given priority.


Regards

Stewart


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Wed Aug 13 12:35:27 2003
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 MAA25406
	for ; Wed, 13 Aug 2003 12:35:27 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19myQM-0003vV-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 13 Aug 2003 11:24:34 -0500
Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19myQL-0003vQ-00
	for ipfix@net.doit.wisc.edu; Wed, 13 Aug 2003 11:24:33 -0500
Received: from fokus.fraunhofer.de (dhcp109 [195.37.78.109])
	by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id h7DGOLv19002;
	Wed, 13 Aug 2003 18:24:21 +0200 (MEST)
Message-ID: <3F3A6472.6050203@fokus.fraunhofer.de>
Date: Wed, 13 Aug 2003 18:16:50 +0200
From: Sebastian Zander 
Organization: Fraunhofer FOKUS
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "MEYER,JEFFREY D (HP-Cupertino,ex1)" 
CC: "'ipfix@net.doit.wisc.edu'" 
Subject: Re: [ipfix] Update available: draft-ietf-ipfix-info-01.txt
References: <1D3D2C371FCBD947A7897FABBD3533A502960281@xsun01.ptp.hp.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit

Hi Jeff,

i have some comments and questions for you:

section 4.19
	dateTimeUsec is 64bit as on common operating systems i assume.
section 5
	i guess the idea of the unique vendor ids is to allow non unique field ids.
	however this requires protocol support.	
section 6.5
	IPv6 next header is 8 bit as well so it should be byte instead of int.
section 6.8, 6.9
	ifIndex is 32 bit (as far as RFC 2233 is concerned) so it should be (unsigned)int
section 6.10, 6.11, 6.22, 6.26
	shouldn't the counters be unsigned and of type long (wrap around)?
	how does a collector know whether a counter is an absolute or delta counter?
	how does a collector know whether a counter is forward, backward, bidirectional?
section 6.23
	why not unsigned?
section 6.24
	what is the meaning of "packet-sampling"? shouldn't this field describe the type of 		 
sampling?
	can something from PSAMP be referenced here?
	what about sampling algorithm parameters? are they fixed for a samplingAlgorithm
	or communicated as separate fields?
section 6
	There is no IP version attribute defined. is the idea to get the ip protocol
	version by looking at the address attributes? Because the information is mandatory
	in the req draft.

Cheers,

Sebastian

MEYER,JEFFREY D (HP-Cupertino,ex1) wrote:
> Hi,
> 
>   A revised version of the IPFIX Information Model has been submitted.
> 
>   While this is getting uploaded, the document (and other artifacts) may be
> found at the following location:
> 
>     - IETF formatted .txt file is available at:
>  
> http://www.ipdr.org/documents/ipfix/infomodel/draft-ietf-ipfix-info-01.txt
> 
>     - The HTML formatted and source XML documents are also available:
>  
> http://www.ipdr.org/documents/ipfix/infomodel/draft-ietf-ipfix-info-01.html
>  
> http://www.ipdr.org/documents/ipfix/infomodel/draft-ietf-ipfix-info-01.xml
> 
>     - The Change History for the -01 draft is at:
>          http://www.ipdr.org/documents/ipfix/infomodel/changehistory.txt
> 
>     - The README document describing the artifacts from this process and
> with
>       pointers to historical documents is available at:
> 
>          http://www.ipdr.org/documents/ipfix/infomodel/README.html
> 
> 
> Regards,
> 
>   Jeff Meyer
> 
> --
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
> 


-- 
Sebastian Zander                         E-mail: zander@fokus.fraunhofer.de
Fraunhofer FOKUS / METEOR                Tel: +49-30-3463-7287
Kaiserin-Augusta-Allee 31                Fax: +49-30-3463-8287
D-10589 Berlin, Germany                  www.fokus.fraunhofer.de/usr/sebastian.zander





--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Wed Aug 13 12:56:02 2003
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 MAA25803
	for ; Wed, 13 Aug 2003 12:56:01 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19mymk-0004im-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 13 Aug 2003 11:47:42 -0500
Received: from usmail.xacct.com ([204.253.100.12])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19mymi-0004ic-00
	for ipfix@net.doit.wisc.edu; Wed, 13 Aug 2003 11:47:40 -0500
Received: from Givoly (inside.us.xacct.com [204.253.100.102])
	by usmail.xacct.com (8.11.2/8.11.2) with SMTP id h7DGtv122969;
	Wed, 13 Aug 2003 09:55:58 -0700
From: "Tal Givoly" 
To: "Nevil Brownlee" , 
Subject: RE: [ipfix] Nevil's IPFIX current issues
Date: Wed, 13 Aug 2003 09:47:23 -0700
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <1060741515.99c4bdc92726a@hotlava.auckland.ac.nz>
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit

Hi,

Ng-1: Timetamps:
- I'd prefer 8-byte time, may allow some detection of ordering of packets
within the second at minimal expense.
- Base should be current time rather than sysUpTime as has more benefit and
avoid conversion and logic at collector. Using sysUpTime requires also
another interface to the device to detect offset of sysUpTime.
- Format - both 8-byte options have pros/cons and either would work.

Ng-2: Encoding:
- Byte order: I too support the forming consensus regarding network byte
order.
- Length for fields of known length should be spared. This is especially
true for "small" fields. Anything known to be 1, 2, 4, 8 or 16 bytes in
length should be implicit from its identifier. It would be best if the
identifier value implicitly indicates to the collector whether the field is
of fixed or variable length. For instance, a range of identifiers could be
used for known-length values while another range could be used for
variable-length values.

Ng-5: Default Transport:
- For cost-effective interoperability we should have a default that is known
to be supported = mandatory.
- Obviously, TCP is still more appropriate than SCTP to allow a wide variety
of collectors to adopt IPFIX quickly.

Tal


-----Original Message-----
From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf
Of Nevil Brownlee
Sent: Tuesday, August 12, 2003 7:25 PM
To: ipfix@net.doit.wisc.edu
Subject: [ipfix] Nevil's IPFIX current issues



Hi all:

Back in early July - when I'd just finished reading all the IPFIX drafts -
I sent out a list of issues which I thought needed some discussion.
There was some discussion on some of the issues, but not a lot.  Now that
we've had a chance to recover from IETF, it's time to get back to work
on the drafts, we need to rev them at least once or twice between now and
mid-October.

The following is my current issues list, I've added one on 'default
transport
protocol.'  Please think about these, and send some comment/opinion to the
list.


Ng1: Timestamps
Drafts: Protocol, Info Model

>      a) How many bytes do we really need?  If seconds is precise enough,
>         4 bytes is fine.  If we need more, or should we could go to 8?
>      b) If we feel that we can afford 8-byte precision, what time base
>         should we use, sysUpTime or time of day.  Time of day would mean
>         that collectors didn't have to convert from sysUpTime.  Can we
>         assume that Metering Processes will have a reliable time-of-day
>         clock?
>      c) Format of 8-byte times.  The most common Unix one is (sec, usec).
>         (sec, nsec) is also widely available.  My favourite is
>         (sec, binary fraction of sec) [NTP 64-bit timestamp, Section
>         3.1 of RFC 1305], because you
>         can compute time differences with a single 64-bit subtraction.

There wasn't much reaction, but the few who did respond said yes,
we need better resolution than seconds.  That implies that the answer
to (a) is "8-byte timestamps."

Now we need to decide on (b) and (c).  For (b), I'd like to see
Unix-epoch times (i.e. relative to 1 Jan 1970) in UTC timezone.
Anyone care to offer a different position on that?
[Note that where an IPFIX metering process doesn't have access to
an ntp-synchronised (or GPS-synchronised, CDMA-synchronised, etc.)
clock, IPFIX collectors - which I presume will at least have an
ntp-synchronised clock - can verify that the reported timestamps
aren't too far away from actual time.]

As for the timestamp data type, I'd still like to see IPFIX use the
NTP 64-bit format.  It's easy to get seconds from that (the high-order
32 bits), and the metering process can fill in as many of the low-order
bits as its clock will allow.  That makes it a clean, universal
timestamp data type.
Failing that, another possibility would be a Unix timeval, (seconds
in the high-order 32 bits, and microseconds in the low-order 32).
What do others, particularly implementors of IPFIX meters and
collectors, prefer?
[We need to decide this, it needs to go into the drafts now!]


Ng-2: Encoding for variable-length data types
Drafts: Protocol

There's been a little discussion of byte ordering, let's agree on
network byte order.

>                                                               For the
>      variable length fields, there seemed to be some discussion around
>      the use of 1,2 or 4 byte length indicators.   There also remains
>      the question of whether or not padding is used for any sort of
>      word alignment.

This one hasn't been discussed further.  Let's hear your opinion now!
Which flow attributes will be variable-length?
The Info Model draft only has one variable-length type, 'string,'
i.e. a UTF8 string.  Can someone please tell us how that should be
carried on the wire - e.g. first byte carries the length, followed
by the data bytes.  Or what?


Ng4: Flow Sampling.
Drafts: Architecture, ?

>      This is mentioned in both the Requirements I-D
>      and the AS I-D.  We need to decide how it should be covered in the
>      IPFIX drafts.

No discussion on this one so far.  But it could be a useful tool
to reduce the amount of flow data one needs to export/collect.
Comments?  Suggestions??


Ng5: IPFIX Default Transport Protocol
Drafts: Protocol

I went to the NETCONF WG session at the Vienna IETF; they have a list
of three transport protocols which would be suitable for NETCONF.  They
discussed the question of whether one of them should be the NETCONF
default, i.e. a 'MUST implement,' and if so, which one.  We need to
consider this question for IPFIX.

When I asked our Area Directors about this, they both said that IPFIX
ought to have a default transport protocol, so that users know they
can plug in an IPFIX device and have it work with other IPFIX devices.

The question now is, which protocol?  The candidates available now
are SCTP and TCP.  Now's the time to send your opinions (with reasoned
technical arguments) to the list so that we can form a WG consensus!


Cheers, Nevil

-----------------------------------------------------------------------
   Nevil Brownlee                   Director, Technology Development
   Phone: +64 9 373 7599 x88941     ITSS, The University of Auckland
   FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand


-------------------------------------------------
This mail sent through University of Auckland
http://www.auckland.ac.nz/

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message
body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Wed Aug 13 13:08:53 2003
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 NAA26152
	for ; Wed, 13 Aug 2003 13:08:53 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19myxO-00051A-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 13 Aug 2003 11:58:42 -0500
Received: from ams-iport-1.cisco.com ([144.254.74.5])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19myxN-000510-00
	for ipfix@net.doit.wisc.edu; Wed, 13 Aug 2003 11:58:41 -0500
Received: from cisco.com (144.254.74.60)
  by ams-iport-1.cisco.com with ESMTP; 13 Aug 2003 18:58:07 +0200
Received: from cisco.com (localhost [127.0.0.1])
	by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h7DGuPqU000864;
	Wed, 13 Aug 2003 18:56:25 +0200 (MET DST)
Received: from cisco.com (dhcp-rea-gp250-64-103-65-15.cisco.com [64.103.65.15])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id RAA00418;
	Wed, 13 Aug 2003 17:58:39 +0100 (BST)
Message-ID: <3F3A6E3F.8000109@cisco.com>
Date: Wed, 13 Aug 2003 17:58:39 +0100
From: Stewart Bryant 
Reply-To: stbryant@cisco.com
Organization: Cisco Systems, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Sebastian Zander 
CC: "MEYER,JEFFREY D (HP-Cupertino,ex1)" ,
        "'ipfix@net.doit.wisc.edu'"
 
Subject: Re: [ipfix] Update available: draft-ietf-ipfix-info-01.txt
References: <1D3D2C371FCBD947A7897FABBD3533A502960281@xsun01.ptp.hp.com> <3F3A6472.6050203@fokus.fraunhofer.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit



Sebastian Zander wrote:
> Hi Jeff,
> 
> i have some comments and questions for you:
> 
> section 4.19
>     dateTimeUsec is 64bit as on common operating systems i assume.
> section 5
>     i guess the idea of the unique vendor ids is to allow non unique 
> field ids.
>     however this requires protocol support.   
> section 6.5
>     IPv6 next header is 8 bit as well so it should be byte instead of int.
> section 6.8, 6.9
>     ifIndex is 32 bit (as far as RFC 2233 is concerned) so it should be 
> (unsigned)int
> section 6.10, 6.11, 6.22, 6.26
>     shouldn't the counters be unsigned and of type long (wrap around)?
>     how does a collector know whether a counter is an absolute or delta 
> counter?

I also noted that in the first set of comments that I sent to Jeff re
the 00 draft, but did not pick it up again in the set I just sent to
the list re the 01 draft.

I think that we need to define the counters as absolute, because that
way they are idenpotent (i.e. it does not matter if you miss a data
record). That also give compatibility with NFv9. If anyone wants a
delta counter it should be a new information element.

>     how does a collector know whether a counter is forward, backward, 
> bidirectional?

All of the counters defined so far only have any meaning as a forward
counter.

> section 6.23
>     why not unsigned?
> section 6.24
>     what is the meaning of "packet-sampling"? shouldn't this field 
> describe the type of          sampling?
>     can something from PSAMP be referenced here?
>     what about sampling algorithm parameters? are they fixed for a 
> samplingAlgorithm
>     or communicated as separate fields?
> section 6
>     There is no IP version attribute defined. is the idea to get the ip 
> protocol
>     version by looking at the address attributes? Because the 
> information is mandatory
>     in the req draft.
> 
> Cheers,
> 
> Sebastian
> 




Stewart


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Thu Aug 14 04:54:14 2003
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 EAA03687
	for ; Thu, 14 Aug 2003 04:54:14 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19nDY2-0002MJ-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 14 Aug 2003 03:33:30 -0500
Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19nDY1-0002M9-00
	for ipfix@net.doit.wisc.edu; Thu, 14 Aug 2003 03:33:29 -0500
Received: from fokus.fraunhofer.de (dhcp109 [195.37.78.109])
	by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id h7E8XGv00216;
	Thu, 14 Aug 2003 10:33:16 +0200 (MEST)
Message-ID: <3F3B4789.8070207@fokus.fraunhofer.de>
Date: Thu, 14 Aug 2003 10:25:45 +0200
From: Sebastian Zander 
Organization: Fraunhofer FOKUS
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: stbryant@cisco.com
CC: "MEYER,JEFFREY D (HP-Cupertino,ex1)" ,
        "'ipfix@net.doit.wisc.edu'"
 
Subject: Re: [ipfix] Update available: draft-ietf-ipfix-info-01.txt
References: <1D3D2C371FCBD947A7897FABBD3533A502960281@xsun01.ptp.hp.com> <3F3A6472.6050203@fokus.fraunhofer.de> <3F3A6E3F.8000109@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit

Stewart Bryant wrote:
> 
> 
> Sebastian Zander wrote:
> 
>> Hi Jeff,
>>
>> i have some comments and questions for you:
>>
>> section 4.19
>>     dateTimeUsec is 64bit as on common operating systems i assume.
>> section 5
>>     i guess the idea of the unique vendor ids is to allow non unique 
>> field ids.
>>     however this requires protocol support.   section 6.5
>>     IPv6 next header is 8 bit as well so it should be byte instead of 
>> int.
>> section 6.8, 6.9
>>     ifIndex is 32 bit (as far as RFC 2233 is concerned) so it should 
>> be (unsigned)int
>> section 6.10, 6.11, 6.22, 6.26
>>     shouldn't the counters be unsigned and of type long (wrap around)?
>>     how does a collector know whether a counter is an absolute or 
>> delta counter?
> 
> 
> I also noted that in the first set of comments that I sent to Jeff re
> the 00 draft, but did not pick it up again in the set I just sent to
> the list re the 01 draft.
> 
> I think that we need to define the counters as absolute, because that
> way they are idenpotent (i.e. it does not matter if you miss a data
> record). That also give compatibility with NFv9. If anyone wants a
> delta counter it should be a new information element.

i agree that absolute counters are a must in case of not 100% reliable
transport because otherwise information can be lost forever. however the
data type should then be 64bit (or var int supporting up to 64bit) to
make wrap-arounds more infrequent and the wrap-around issue should be
addressed (don't know if this is already done in the protocol spec).

cheers,

Sebastian

-- 
Sebastian Zander                         E-mail: zander@fokus.fraunhofer.de
Fraunhofer FOKUS / METEOR                Tel: +49-30-3463-7287
Kaiserin-Augusta-Allee 31                Fax: +49-30-3463-8287
D-10589 Berlin, Germany                  www.fokus.fraunhofer.de/usr/sebastian.zander





--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Thu Aug 14 05:17:50 2003
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 FAA03997
	for ; Thu, 14 Aug 2003 05:17:50 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19nDxE-0003KP-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 14 Aug 2003 03:59:32 -0500
Received: from ams-iport-1.cisco.com ([144.254.74.5])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19nDxD-0003Jf-00
	for ipfix@net.doit.wisc.edu; Thu, 14 Aug 2003 03:59:31 -0500
Received: from cisco.com (144.254.74.60)
  by ams-iport-1.cisco.com with ESMTP; 14 Aug 2003 10:58:57 +0200
Received: from cisco.com (localhost [127.0.0.1])
	by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h7E8vFT0000189;
	Thu, 14 Aug 2003 10:57:15 +0200 (MET DST)
Received: from cisco.com (ams-clip-vpn-dhcp4270.cisco.com [10.61.80.173])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id JAA23610;
	Thu, 14 Aug 2003 09:59:29 +0100 (BST)
Message-ID: <3F3B4F70.10804@cisco.com>
Date: Thu, 14 Aug 2003 09:59:28 +0100
From: Stewart Bryant 
Reply-To: stbryant@cisco.com
Organization: Cisco Systems, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Sebastian Zander 
CC: "MEYER,JEFFREY D (HP-Cupertino,ex1)" ,
        "'ipfix@net.doit.wisc.edu'"
 
Subject: Re: [ipfix] Update available: draft-ietf-ipfix-info-01.txt
References: <1D3D2C371FCBD947A7897FABBD3533A502960281@xsun01.ptp.hp.com> <3F3A6472.6050203@fokus.fraunhofer.de> <3F3A6E3F.8000109@cisco.com> <3F3B4789.8070207@fokus.fraunhofer.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit



Sebastian Zander wrote:
> Stewart Bryant wrote:
> 
>>
>>
>> Sebastian Zander wrote:
>>
>>> Hi Jeff,
>>>
>>> i have some comments and questions for you:
>>>
>>> section 4.19
>>>     dateTimeUsec is 64bit as on common operating systems i assume.
>>> section 5
>>>     i guess the idea of the unique vendor ids is to allow non unique 
>>> field ids.
>>>     however this requires protocol support.   section 6.5
>>>     IPv6 next header is 8 bit as well so it should be byte instead of 
>>> int.
>>> section 6.8, 6.9
>>>     ifIndex is 32 bit (as far as RFC 2233 is concerned) so it should 
>>> be (unsigned)int
>>> section 6.10, 6.11, 6.22, 6.26
>>>     shouldn't the counters be unsigned and of type long (wrap around)?
>>>     how does a collector know whether a counter is an absolute or 
>>> delta counter?
>>
>>
>>
>> I also noted that in the first set of comments that I sent to Jeff re
>> the 00 draft, but did not pick it up again in the set I just sent to
>> the list re the 01 draft.
>>
>> I think that we need to define the counters as absolute, because that
>> way they are idenpotent (i.e. it does not matter if you miss a data
>> record). That also give compatibility with NFv9. If anyone wants a
>> delta counter it should be a new information element.
> 
> 
> i agree that absolute counters are a must in case of not 100% reliable
> transport because otherwise information can be lost forever. however the
> data type should then be 64bit (or var int supporting up to 64bit) to
> make wrap-arounds more infrequent and the wrap-around issue should be
> addressed (don't know if this is already done in the protocol spec).
> 

Actually I disagree with you about 64bit. It should be up to the
implementation to decide the appropriate counter length. In systems
with very large numbers of low bandwidth links, using 64bit counters
at least doubles the memory needed by the exporter and at least doubles
the export bandwidth. The exporter know the characteristics of the system
that it is monitoring the reliability of the transport etc, and is best
placed to determine optimum the length.

Stewart


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Thu Aug 14 05:43:55 2003
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 FAA04375
	for ; Thu, 14 Aug 2003 05:43:55 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19nESU-0004uY-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 14 Aug 2003 04:31:50 -0500
Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19nEST-0004uO-00
	for ipfix@net.doit.wisc.edu; Thu, 14 Aug 2003 04:31:49 -0500
Received: from fokus.fraunhofer.de (dhcp109 [195.37.78.109])
	by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id h7E9Vfv06132;
	Thu, 14 Aug 2003 11:31:41 +0200 (MEST)
Message-ID: <3F3B553A.1010708@fokus.fraunhofer.de>
Date: Thu, 14 Aug 2003 11:24:10 +0200
From: Sebastian Zander 
Organization: Fraunhofer FOKUS
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: stbryant@cisco.com
CC: "MEYER,JEFFREY D (HP-Cupertino,ex1)" ,
        "'ipfix@net.doit.wisc.edu'"
 
Subject: Re: [ipfix] Update available: draft-ietf-ipfix-info-01.txt
References: <1D3D2C371FCBD947A7897FABBD3533A502960281@xsun01.ptp.hp.com> <3F3A6472.6050203@fokus.fraunhofer.de> <3F3A6E3F.8000109@cisco.com> <3F3B4789.8070207@fokus.fraunhofer.de> <3F3B4F70.10804@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit



Stewart Bryant wrote:
> 
> 
> Sebastian Zander wrote:
> 
>> Stewart Bryant wrote:
>>
>>>
>>>
>>> Sebastian Zander wrote:
>>>
>>>> Hi Jeff,
>>>>
>>>> i have some comments and questions for you:
>>>>
>>>> section 4.19
>>>>     dateTimeUsec is 64bit as on common operating systems i assume.
>>>> section 5
>>>>     i guess the idea of the unique vendor ids is to allow non unique 
>>>> field ids.
>>>>     however this requires protocol support.   section 6.5
>>>>     IPv6 next header is 8 bit as well so it should be byte instead 
>>>> of int.
>>>> section 6.8, 6.9
>>>>     ifIndex is 32 bit (as far as RFC 2233 is concerned) so it should 
>>>> be (unsigned)int
>>>> section 6.10, 6.11, 6.22, 6.26
>>>>     shouldn't the counters be unsigned and of type long (wrap around)?
>>>>     how does a collector know whether a counter is an absolute or 
>>>> delta counter?
>>>
>>>
>>>
>>>
>>> I also noted that in the first set of comments that I sent to Jeff re
>>> the 00 draft, but did not pick it up again in the set I just sent to
>>> the list re the 01 draft.
>>>
>>> I think that we need to define the counters as absolute, because that
>>> way they are idenpotent (i.e. it does not matter if you miss a data
>>> record). That also give compatibility with NFv9. If anyone wants a
>>> delta counter it should be a new information element.
>>
>>
>>
>> i agree that absolute counters are a must in case of not 100% reliable
>> transport because otherwise information can be lost forever. however the
>> data type should then be 64bit (or var int supporting up to 64bit) to
>> make wrap-arounds more infrequent and the wrap-around issue should be
>> addressed (don't know if this is already done in the protocol spec).
>>
> 
> Actually I disagree with you about 64bit. It should be up to the
> implementation to decide the appropriate counter length. In systems
> with very large numbers of low bandwidth links, using 64bit counters
> at least doubles the memory needed by the exporter and at least doubles
> the export bandwidth. The exporter know the characteristics of the system
> that it is monitoring the reliability of the transport etc, and is best
> placed to determine optimum the length.

I see that my previous statement wasn't too clear. Using counters <64bit for
optimization purposes is fine but there must be the option of having 64bit
counters for high bandwidth links IMO. I'm wondering whether his would double
the overall export bandwidth because the protocol does transmit more information
than just the counters. Do you have some numbers on that?

-- 
Sebastian Zander                         E-mail: zander@fokus.fraunhofer.de
Fraunhofer FOKUS / METEOR                Tel: +49-30-3463-7287
Kaiserin-Augusta-Allee 31                Fax: +49-30-3463-8287
D-10589 Berlin, Germany                  www.fokus.fraunhofer.de/usr/sebastian.zander





--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Thu Aug 14 06:32:52 2003
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 GAA05580
	for ; Thu, 14 Aug 2003 06:32:52 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19nF7J-0006ng-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 14 Aug 2003 05:14:01 -0500
Received: from [212.216.176.185] (helo=vsmtp9.tin.it)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19nF7H-0006nU-00
	for ipfix@net.doit.wisc.edu; Thu, 14 Aug 2003 05:14:00 -0500
Received: from vsmtp8.tin.it (212.216.176.235) by vsmtp9.tin.it (7.0.019)
        id 3F1BE73600B92E45; Thu, 14 Aug 2003 12:13:40 +0200
Received: from truciolo (80.180.147.77) by vsmtp8.tin.it (7.0.019)
        id 3F2F40CF00BF01E2; Thu, 14 Aug 2003 12:13:40 +0200
From: "Fulvio Risso" 
To: , "Sebastian Zander" 
Cc: 
Subject: RE: [ipfix] Update available: draft-ietf-ipfix-info-01.txt
Date: Thu, 14 Aug 2003 12:14:00 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <3F3B4F70.10804@cisco.com>
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit



> -----Original Message-----
> From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf
> Of Stewart Bryant
> Sent: giovedi 14 agosto 2003 10.59
> To: Sebastian Zander
> Cc: MEYER,JEFFREY D (HP-Cupertino,ex1); 'ipfix@net.doit.wisc.edu'
> Subject: Re: [ipfix] Update available: draft-ietf-ipfix-info-01.txt
>
>
>
>
> Sebastian Zander wrote:
> > Stewart Bryant wrote:
> >
> >>
> >>
> >> Sebastian Zander wrote:
> >>
> >>> Hi Jeff,
> >>>
> >>> i have some comments and questions for you:
> >>>
> >>> section 4.19
> >>>     dateTimeUsec is 64bit as on common operating systems i assume.
> >>> section 5
> >>>     i guess the idea of the unique vendor ids is to allow non unique
> >>> field ids.
> >>>     however this requires protocol support.   section 6.5
> >>>     IPv6 next header is 8 bit as well so it should be byte instead of
> >>> int.
> >>> section 6.8, 6.9
> >>>     ifIndex is 32 bit (as far as RFC 2233 is concerned) so it should
> >>> be (unsigned)int
> >>> section 6.10, 6.11, 6.22, 6.26
> >>>     shouldn't the counters be unsigned and of type long (wrap around)?
> >>>     how does a collector know whether a counter is an absolute or
> >>> delta counter?
> >>
> >>
> >>
> >> I also noted that in the first set of comments that I sent to Jeff re
> >> the 00 draft, but did not pick it up again in the set I just sent to
> >> the list re the 01 draft.
> >>
> >> I think that we need to define the counters as absolute, because that
> >> way they are idenpotent (i.e. it does not matter if you miss a data
> >> record). That also give compatibility with NFv9. If anyone wants a
> >> delta counter it should be a new information element.
> >
> >
> > i agree that absolute counters are a must in case of not 100% reliable
> > transport because otherwise information can be lost forever. however the
> > data type should then be 64bit (or var int supporting up to 64bit) to
> > make wrap-arounds more infrequent and the wrap-around issue should be
> > addressed (don't know if this is already done in the protocol spec).
> >
>
> Actually I disagree with you about 64bit. It should be up to the
> implementation to decide the appropriate counter length.

This means that the collector is more complicated, because it must have to
code to handle 64bit counters, 32 bit ones, etc.
I prefer a unique size for counters (which makes the code simpler).
For that, 64bits seem to me more appropriate.


> In systems
> with very large numbers of low bandwidth links, using 64bit counters
> at least doubles the memory needed by the exporter and at least doubles
> the export bandwidth. The exporter know the characteristics of the system
> that it is monitoring the reliability of the transport etc, and is best
> placed to determine optimum the length.

... and the collector must handle several counters with different sizes. And
the same for the application (e.g. GUI) that display results. And when we
compare results, the programmer has to take care about these differences.
In my opinion, let's keep things simpler. Less optimized, but simpler.

Cheers,

	fulvio

>
> Stewart
>
>
> --
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in
> message body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Wed Aug 27 16:19:33 2003
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 QAA05158
	for ; Wed, 27 Aug 2003 16:19:33 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19s6Kq-0002h3-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 27 Aug 2003 14:52:04 -0500
Received: from babar.switch.ch ([130.59.4.85])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19s6Kp-0002gu-00
	for ipfix-info@net.doit.wisc.edu; Wed, 27 Aug 2003 14:52:03 -0500
Received: from babar (localhost [IPv6:::1])
	by babar.switch.ch (8.12.9+Sun/8.12.2) with ESMTP id h7RJq0dg020794;
	Wed, 27 Aug 2003 21:52:00 +0200 (CEST)
From: Simon Leinen 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16205.3040.455674.3102@limmat.switch.ch>
Date: Wed, 27 Aug 2003 21:52:00 +0200
To: ipfix-info@net.doit.wisc.edu
Subject: [ipfix-info] draft-ietf-ipfix-info-01 issue: 64-bit timestamp type(s)
X-Mailer: VM 7.17 under Emacs 21.3.1
X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7,F
 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z,@ttmwYVO7l`6OXXYR`
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit

The current -ipfix-info- draft specifies three types to represent
"specific instant[s] of time", namely dateTime, ipdr:dateTimeMsec, and
ipdr:dateTimeUsec, with second, millisecond, and microsecond
resolution, respectively.  DateTime can be represented in 32 bits, the
other two in 64 bits each.

I don't think all three of these types are useful.  In particular, if
you have ipdr:dateTimeUsec, why would you use ipdr:dateTimeMsec at
all?

My suggestion would be to define "dateTimeNsec", which would fit in 64
bits just as nicely as ipdr:dateTimeMsec and ipdr:dateTimeUsec, and
remove the latter two.

Suggested text changes:

4.15 (ipdr:dateTimeMsec) and
4.19 (ipdr:dateTimeUsec) should be removed and replaced with

    4.15 dateTimeNsec
    
    The "dateTimeNsec" type represents a specific instant of time.  It
    is further restricted from the basic XL dateTime type to having a
    precision of nanoseconds and normalized to the GMT timezone.
    
    Such types are in common use on many Operating Systems
    (e.g. "struct timespec" in POSIX.1b) and have the advantage that
    they can be stored in 64 bits.

Note that the text - for whatever timestamp types we decide to specify
- should say how the timestamps should be represented, i.e. relative
to what "epoch", and whether the integer components of the
representation should be interpreted as signed or unsigned.
-- 
Simon.


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Wed Aug 27 16:25:11 2003
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 QAA05594
	for ; Wed, 27 Aug 2003 16:25:11 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19s6XK-00039A-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 27 Aug 2003 15:04:58 -0500
Received: from babar.switch.ch ([130.59.4.85])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19s6XJ-000393-00
	for ipfix-info@net.doit.wisc.edu; Wed, 27 Aug 2003 15:04:57 -0500
Received: from babar (localhost [IPv6:::1])
	by babar.switch.ch (8.12.9+Sun/8.12.2) with ESMTP id h7RK4tdg020846;
	Wed, 27 Aug 2003 22:04:55 +0200 (CEST)
From: Simon Leinen 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16205.3815.373852.245262@limmat.switch.ch>
Date: Wed, 27 Aug 2003 22:04:55 +0200
To: ipfix-info@net.doit.wisc.edu
Subject: [ipfix-info] draft-ietf-ipfix-info-01 issue: 32-bit timestamp type
X-Mailer: VM 7.17 under Emacs 21.3.1
X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7,F
 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z,@ttmwYVO7l`6OXXYR`
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit

The current -ipfix-info- draft specifies three types to represent
"specific instant[s] of time", namely dateTime, ipdr:dateTimeMsec, and
ipdr:dateTimeUsec, with second, millisecond, and microsecond
resolution, respectively.  DateTime can be represented in 32 bits, the
other two in 64 bits each.

I don't see a pressing need to have "dateTime".  It is nice to have a
timestamp type that can fit into 32 bits, but the resolution will be
insufficient for many applications.  If we want such a compact
timestamp type, I'd propose to define one that has better resolution,
at the cost of a smaller range: 32 bits can accomodate 136 years at
1-second resolution, almost 50 days at millisecond resolution, or 1
hour 19 minutes at microsecond resolution.  The last combination would
be perfectly adequate for commonly flow timeouts today.

Suggested text changes:

4.14 (dateTime) should be replaced with

    4.14 timeStampUsec

    The "timeStampUsec" type represents a specific instant of time.
    It is further restricted from the basic XML dateTime type to
    having a precision of microseconds.

    It is represented as the number of microseconds between 0:00:00 on
    January 1, 1970 (UTC) and the time in question, modulo 2^32.

    Note that timestamps of this type can only be unambiguously
    interpreted in a context where the range of feasible times is
    limited to 4294.9673 seconds or around 1 hour 19 minutes.
-- 
Simon.


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Wed Aug 27 16:41:52 2003
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 QAA06981
	for ; Wed, 27 Aug 2003 16:41:51 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19s6ps-0003sg-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 27 Aug 2003 15:24:08 -0500
Received: from babar.switch.ch ([130.59.4.85])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19s6pr-0003sY-00
	for ipfix-info@net.doit.wisc.edu; Wed, 27 Aug 2003 15:24:07 -0500
Received: from babar (localhost [IPv6:::1])
	by babar.switch.ch (8.12.9+Sun/8.12.2) with ESMTP id h7RKO5dg020888;
	Wed, 27 Aug 2003 22:24:05 +0200 (CEST)
From: Simon Leinen 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16205.4964.531817.785901@limmat.switch.ch>
Date: Wed, 27 Aug 2003 22:24:04 +0200
To: ipfix-info@net.doit.wisc.edu
Subject: [ipfix-info] draft-ietf-ipfix-info-01 issue: ingressPort/egressPort
X-Mailer: VM 7.17 under Emacs 21.3.1
X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7,F
 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z,@ttmwYVO7l`6OXXYR`
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit

The types for the "ingressPort" and "egressPort" fields is specified
as unsignedShort (0...65535).  But ifIndex values can have a range of
1...2147483647 (see the InterfaceIndex textual convention in RFC
2863, which obsoletes RFC 2233).

Also, I would prefer to use names with "interface" for these fields,
because (1) we already have the sourcePort/destinationPort fields,
which refer to transport-level ports, and (2) in this context, "port"
could tempt people to think of physical ports, where a logical
"sub-layer" interface may be more suitable.

In addition, I suggest using the special value of zero for the case
where a flow's packets weren't forwarded at all.

[We could also use this value for the multicast case... or use
negative values to specify the "replication factor" if we don't mind
the overloading - I think overloading is good because it saves
valuable space, but maybe one would use a different template for
multicast flows anyway.]

Suggested text changes:

6.8 (IngressPort), and
6.9 (EgressPort)

Replace with:

    6.8 IngressInterface
    
    Description: The ifIndex of the interface on which the packets for the
    flow have been received.  IfIndex is defined by RFC 2863.
    
    Type: The IngressInterface element is of type int.
    
    FieldId: 10
    
    6.9 EgressInterface
    
    Description: The ifIndex of the interface to which the packets for the
    flow have been forwarded, or zero if no packets of the flow were
    forwarded to an interface.  IfIndex is defined by RFC 2863.
    
    Type: The EgressInterface element is of type int.
    
    FieldId: 11
-- 
Simon.


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Wed Aug 27 17:03:11 2003
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 RAA08352
	for ; Wed, 27 Aug 2003 17:03:11 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19s7Ir-0004qm-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 27 Aug 2003 15:54:05 -0500
Received: from babar.switch.ch ([130.59.4.85])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19s7Iq-0004qe-00
	for ipfix-info@net.doit.wisc.edu; Wed, 27 Aug 2003 15:54:04 -0500
Received: from babar (localhost [IPv6:::1])
	by babar.switch.ch (8.12.9+Sun/8.12.2) with ESMTP id h7RKs2dg020987;
	Wed, 27 Aug 2003 22:54:02 +0200 (CEST)
From: Simon Leinen 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16205.6762.302196.561189@limmat.switch.ch>
Date: Wed, 27 Aug 2003 22:54:02 +0200
To: ipfix-info@net.doit.wisc.edu
Subject: [ipfix-info] draft-ietf-ipfix-info-01 issue: byte/packet count sign/direction
X-Mailer: VM 7.17 under Emacs 21.3.1
X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7,F
 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z,@ttmwYVO7l`6OXXYR`
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit

The current definitions for the packetCount, byteCount, and
droppedPacketCount fields specify their types as "int" (signed
32-bit).  I think this is a waste of a bit, because I cannot imagine
flows with negative values for these...

Also, the descriptions say the each of these fields "can be for
{bytes,packets} received (towards source) or {bytes,packets} sent
(towards destination) or both (bidirectional flow)."  Although I'm
personally not very interested in bi-directional flows, I definitely
think it would be an error to use a single field type for these three
attributes.

For bi-directional flows, the source/destination terminology seems
totally inappropriate.  Please consider talking about something like
"PortA", "AddressV6B".

The descriptions also say "The {packet,byte} count can be a delta
counter and is the count since the last report for this flow."

I don't think this is something that should be mentioned as the
semantics of specific fields; there should be a general requirement
that a flow record only refers to the part of the flow since the last
export.  This would be relevant for e.g. flowCreationTime as well!

I suggest to remove the text from the individual field descriptions.

Suggested text changes:

6.10 (packetCount), and
6.11 (byteCount), and
6.22 (droppedPacketCount) to be replaced with

    6.10 packetCount

    Description:

    Contains the number of packets in the flow, in the "downstream"
    (source-to-destination) direction.

    Type: The packetCount element is of type unsigned.

    Units: The unit of measure is packets.

    Field Id: 2

    6.11 inversePacketCount

    Description:

    Contains the number of packets against the flow, i.e. in the
    "upstream" (destination-to-source) direction.

    Type: The inversePacketCount element is of type unsigned.

    Units: The unit of measure is packets.

    6.12 totalPacketCount

    Field Id: TBD

    Description:

    Contains the number of packets in both directions of the flow,
    i.e. from source to destination and from destination to source.

    Type: The totalPacketCount element is of type unsigned.

    Units: The unit of measure is packets.

    Field Id: TBD

    6.13 byteCount

    Description:

    Contains the number of bytes in the flow, in the "downstream"
    (source-to-destination) direction.

    Type: The byteCount element is of type unsigned.

    Units: The unit of measure is bytes.

    Field Id: 1

    6.14 inverseByteCount

    Description:

    Contains the number of bytes against the flow, i.e. in the
    "upstream" (destination-to-source) direction.

    Type: The inverseByteCount element is of type unsigned.

    Units: The unit of measure is bytes.

    Field Id: TBD

    6.15 totalByteCount

    Description:

    Contains the number of bytes in both directions of the flow,
    i.e. from source to destination and from destination to source.

    Type: The totalByteCount element is of type unsigned.

    Units: The unit of measure is bytes.

    Field Id: TBD

    6.22 droppedPacketCount

    Description:

    Contains the number of dropped packets in the flow, in the
    "downstream" (source-to-destination) direction.

    Type: The droppedPacketCount element is of type unsigned.

    Units: The unit of measure is packets.

    Field Id: TBD

    6.23 inverseDroppedPacketCount

    Description:

    Contains the number of dropped packets against the flow, i.e. in
    the "upstream" (destination-to-source) direction.

    Type: The inverseDroppedPacketCount element is of type unsigned.

    Units: The unit of measure is packets.

    Field Id: TBD

    6.24 totalDroppedPacketCount

    Description:

    Contains the number of dropped packets in both directions of the
    flow, i.e. from source to destination and from destination to
    source.

    Type: The totalDroppedPacketCount element is of type unsigned.

    Units: The unit of measure is packets.

    Field Id: TBD
-- 
Simon.


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Wed Aug 27 17:06:17 2003
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 RAA08548
	for ; Wed, 27 Aug 2003 17:06:17 -0400 (EDT)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 19s7O0-00053c-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 27 Aug 2003 15:59:24 -0500
Received: from babar.switch.ch ([130.59.4.85])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 19s7Nz-00053X-00
	for ipfix-info@net.doit.wisc.edu; Wed, 27 Aug 2003 15:59:23 -0500
Received: from babar (localhost [IPv6:::1])
	by babar.switch.ch (8.12.9+Sun/8.12.2) with ESMTP id h7RKxLdg021011;
	Wed, 27 Aug 2003 22:59:21 +0200 (CEST)
From: Simon Leinen 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16205.7081.549250.774364@limmat.switch.ch>
Date: Wed, 27 Aug 2003 22:59:21 +0200
To: ipfix-info@net.doit.wisc.edu
Subject: [ipfix-info] draft-ietf-ipfix-info-01 issue: types for AS fields
X-Mailer: VM 7.17 under Emacs 21.3.1
X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7,F
 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z,@ttmwYVO7l`6OXXYR`
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit

The types for sourceAS, destinationAS, and nextHopAS should be
unsignedInt rather than int, analogous to InetAutonomousSystemNumber
in INET-ADDRESS-MIB.

Suggested text changes:

6.16 (sourceAS)
6.17 (destinationAS)
6.18 (nextHopAS)

replace the respective "Type" clauses with

    Type: The xxxAS element is of type unsignedInt.
-- 
Simon.


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/