Subject: RE: [ipfix-req] list of issues - Reinaldo-6

From: "Reinaldo Penno" <[email-masked]>
Date: Wed, 23 Oct 2002 12:50:27 -0700

This is Sebastian proposal based on our thread. The only issue I have is
that there is no such thing as partial anonymization. There only is
anonymization and partial disclosure of information. Just a little change of
words but I think it makes a significant difference.

Besides that I think Sebastian text should be included on the requirements
draft. 

> -----Original Message-----
> From: Sebastian Zander [mailto:[email-masked]]
> Sent: Thursday, October 10, 2002 1:38 AM
> To: Penno, Reinaldo [BL60:0430:EXCH]
> Cc: Tanja Zseby; Benoit Claise; Jürgen Quittek
> Subject: Re: [ipfix-req] IPFIX Requirement draft status - section 6.6
> 
> 
> Reinaldo,
> 
> I completly agree with you that using a bigger prefix does not provide
> complete anonymization. Actually what your proposing is adding a
> statement like "It MUST NOT be possible for someone besides the entity
> which anonymizes the data to derive information from the anonymized
> attribute(s) which can be used for partial or complete 
> identification."
> Would be fine with me to add something like this. But somebody might
> pop up demanding something like partial anonymization... As 
> an alternative
> we could define anonymization in the terminology.
> 
> But an advocacy draft can always claim to comply to req X by 
> doing Y and
> if you think Y is not a proper solution for X please post it 
> to the eval
> team and the list.
> 
> Cheers,
> 
> Sebastian

> -----Original Message-----
> From: Juergen Quittek [mailto:[email-masked]]
> Sent: Tuesday, October 22, 2002 2:25 AM
> To: [email-masked]
> Subject: [ipfix-req] list of issues
> 
> 
> Dear all,
> 
> Since the posting of the last requirements I-D, I took some
> 'vacation' from the ipfix list. Now I find that I missed
> participating in some very interesting discussions.
> 
> Below I try to summarize raised requriements issues.
> It might be incomplete. Please add issues I missed.
> 
> My intention is to check all issues and identify an already
> existing consensus, or to trigger completion of the discussion
> on these issues in order to get consesus soon.
> 
> If you want to contribute to the further discussion of these
> issues, please use separate emails per issues and please state
> the issue in the subject field. ("Re: list of issues" is not
> really helpful for continuing the MPLS label discussion).
> 
>     Juergen
> 
> 
> Reinaldo-1a: adding a VPN-ID attribute in section 6.1
> 
>     I think this is a good point. Still I have three questions:
>     - Would it be a MUST, a SHOULD, or a MAY?
>     - Shall we ask it to be required only where applicable (on devices
>       supporting VPN-IDs?
>     - Is it required too much for an IP meter? (see MPLS 
> label discussion)
> 
> Reinaldo-1b: export NATed flows (before and after)
> 
>     We already discussed this issue earlier this year and 
> decided to not
>     stating a requirement. However, it is already considered by the
>     information model I-D.
> 
> Reinaldo-2a: Add failover requirements, for example on the ability
>              to detect loss of connectivity with the collector and
>              trigger the appropriate action (eg. a switch over to
>              an alternate collector.)
> 
>     I haven't seen many responses on that. Is this a nice-to-have
>     or a MUST?
>     What would be appropriate actions?
>     Is the requirement just "do something senseful in case of
>     loosing a connection (or something like this) to the collector?
> 
> Reinaldo-2b: Add optional export of flow records to multiple 
> collectors
> 
>     This is already covered.
> 
> Reinaldo-2c: Add optional re-transmission of lost flow records.
> 
>     This should be part of the requirements discussion (see 
> Reinaldo-3).
> 
> Reinaldo-2d: Add: Exchange control information from the 
> collector, monitor
>              export process and detect any overload in the process of
>              exporting.
> 
>     I do not think, an exchange of control information from 
> the collector
>     is required.
> 
>     Monitoring the exporter and detecting overload is not explicitly
>     discussed, but implied in the reliability requirement ("indicate
>     missing reliability"). Is a clarification needed that for 
> indicating
>     missing reliability a detection of overload is required?
> 
> Reinaldo-3: Rephrase or modify Section 6.3.2. "Reliability"
> 
>     There was an extended discussion on this. Can one of the 
> participants
>     tell me what he considers to be the consensus concerning the new
>     phrasing.
> 
> Reinaldo-4: Add MUST requirement for exporting ICMP codes in 
> Section 6.1
> 
>     There were not many responses on this suggestion. Personally, I do
>     not consider it a MUST, but a nice-to-have.
> 
> Reinaldo-5: Remove Section 5.8. "Ignore Port Copy"?
> 
>     This is not a strong requirement. It's a nice-to-have.
>     Is there a consesus on either keeping or removing it?
> 
> Reinaldo-6: Section 6.6. "Anonymization"
> 
>     As far as I understood the discussion, there was a request to more
>     clearly state what kind/level of anonymization is required. I find
>     this hard to decide. Therefore, I suggest keeping the more vague
>     current version.
> 
> Simon-1: Drop MPLS label
> 
>    This covers two sections:
>        - Requiring the metering process to be able to 
> separate flows by the MPLS label
>        - requiring the ability to export the MPLS label or FEC
> 
>    It has been discussed controversially for a long time. I 
> still do not see
>    a clear consensus on this issue. Fortunaltely, I do not 
> see a considerable
>    impact on the protocol evaluation.
> 
> 
> 
> --
> 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/
>