Subject: RE: [ipfix] IPFIX requirements - final changes

From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <[email-masked]>
Date: Tue, 27 May 2003 14:25:03 -0400

Hi,

  I agree w/ Tal and Benoit on this one.

Regards,

  Jeff Meyer

> -----Original Message-----
> From: Tal Givoly [mailto:[email-masked]]
> Sent: Monday, May 26, 2003 9:43 AM
> To: Benoit Claise; Juergen Quittek
> Cc: [email-masked]
> Subject: RE: [ipfix] IPFIX requirements - final changes
> 
> 
> Juergen,
> 
> I agree with Benoit - it doesn't make sense to make 
> confidentiality and
> anonymization mandatory. In many deployments, there could be 
> physical and
> other security measures that addresses these issues.
> 
> Tal
> 
> -----Original Message-----
> From: majordomo listserver 
> [mailto:[email-masked]]On Behalf
> Of Benoit Claise
> Sent: Monday, May 26, 2003 8:02 AM
> To: Juergen Quittek
> Cc: [email-masked]
> Subject: Re: [ipfix] IPFIX requirements - final changes
> 
> 
> Juergen,
> 
> > 
> ==============================================================
> ==========
> > 12. Confidentiality from SHOULD to MUST
> > 
> ==============================================================
> ==========
> > Problem Description:
> > 
> --------------------------------------------------------------
> ----------
> > Requirements on the ipfix implementation - the document is 
> long and I
> > wonder if
> > the working group really meant the protocol's confidentiality and
> > anonymization
> > features to be so optional -  SHOULD confidentiality, MAY 
> anonymization.
> > Just for implementation.
> > 
> ==============================================================
> ==========
> > Suggested solution:
> > 
> --------------------------------------------------------------
> ----------
> >   change confidentiality requirement in section 6.3.3
> >   from SHOULD to MUST
> > 
> ==============================================================
> ==========
> > Status: solution to be agreed on
> > 
> ==============================================================
> ==========
> 
> I'm just wondering if a MUST is not a little bit extreme.
> The draft would become:
>    "Confidentiality of flow specific data transferred from an 
> exporting
>    process to a collecting process MUST be ensured."
> We all agree that over the Internet confidentiality is compulsory but
> this sentence would mean that even in a private LAN or environment, we
> must have confidentiality to be IPFIX compliant. And we know 
> that, with
> the software based encryption, the throughput would be 
> lowered. Ok, then
> we should have an crypto engine in hardware on the exporter to export
> the numerous flow export packets but there is a price to it.
> My point is that, as Confidentiality is not needed in all cases, why
> make it a MUST?
> 
> >
> >
> >
> > 
> ==============================================================
> ==========
> > 13. Anonymization from MAY to MUST
> > 
> ==============================================================
> ==========
> > Problem Description:
> > 
> --------------------------------------------------------------
> ----------
> > Requirements on the ipfix implementation - the document is 
> long and I
> > wonder if
> > the working group really meant the protocol's confidentiality and
> > anonymization
> > features to be so optional -  SHOULD confidentiality, MAY 
> anonymization.
> > Just for implementation.
> > 
> ==============================================================
> ==========
> > Suggested solution:
> > 
> --------------------------------------------------------------
> ----------
> >   change anonymization requirement in section 6.7 from MAY to MUST
> > 
> ==============================================================
> ==========
> > Status: solution to be agreed on
> > 
> ==============================================================
> ==========
> 
> Again, I have the same type of comments. Anonymization is not required
> in all cases. So why make it a MUST?
> 
> Regards, Benoit.
> 
> 
> 
> --
> 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/
> 

--
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: Wed, 28 May 2003 07:28:22 +1200

>   I agree w/ Tal and Benoit on this one.

The IESG comment was about confidentiality and anonymisation in IPFIX
being "so optional."  Maybe a better way to improve this would be to
write a few parargraphs referring to RFC 2975, making it clear that 
building an accounting system invloves much more than just selecting 
an export protocol (i.e. other techniques like using a separate network
may be sufficient in many cases), which is why the IPFIX requirements only
say SHOULD for these.  Of course, if a vendor implements them, users
can decide whether or not to actually use them!  If others agree with this,
I could write some text in a day or two ...

Juergen's other proposed changes to the draft look OK to me.

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/