Subject: RE: [ipfix] Requirements: reaching consensus

From: "Carter Bullard" <[email-masked]>
Date: Fri, 1 Aug 2003 15:08:36 -0400

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:[email-masked]] On Behalf Of Nevil Brownlee
> Sent: Friday, August 01, 2003 12:15 PM
> To: [email-masked]
> 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:[email-masked] and say "help"
> in message body
> Unsubscribe mailto:[email-masked] and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
>

--
Help        mailto:[email-masked] and say "help" in message body
Unsubscribe mailto:[email-masked] and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/

---

From: Nevil Brownlee <[email-masked]>
Date: Sat, 2 Aug 2003 07:40:25 +1200

> 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

---

From: Alex Audu <[email-masked]>
Date: Fri, 01 Aug 2003 15:45:55 -0500

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

Regards,
Alex.

---

From: Rik Wade <[email-masked]>
Date: Mon, 4 Aug 2003 08:53:23 +0000

On Fri, 01 Aug 2003, Carter Bullard wrote:

> 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