Subject: [IPFIX] AD review on draft-ietf-ipfix-anon-04.txt

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 14 Oct 2010 20:45:11 +0200

Please find below the AD review of draft-ietf-ipfix-anon-04.txt. The
document is in quite good shape, however, there are a number of issued
that I suggest should be resolved by a revised ID before proceeding to
IETF Last Call. 

Comments are marked T for Technical and E for Editorial. 

T1. Section 4.2 - MAC Address Anonymisation

   Beyond
   this, the address is unstructured, and there is no particular
   relationship among the OUIs assigned to a given vendor.

This is not completely true. Actually some vendors keep a structure of
the OUIs (per family of products for example) or the relative values of
the OUIs may indicate a time relation. I suggest s/particular/standard/

T2. Same section.

It is not clear for me why the Truncation was not included as a scheme
for Anonymisation of MAC addresses. I actually believe that it can be
quite significant as the first 24 bits of an EUI-48 address provides
vendor information. 

T3. Section 4.2.1 

   Also note that the utility or removing
   manufacturer information is dubious, and not particularly well-
   covered by the literature.

I would argue against the 'dubious' characterization. Actually the
information may be important and need to be anonymized. 

T4. In sections 5.3, 5.4, 5.5 the last phrase in each paragraph  that
makes recommendations about limiting exported information of various
sorts should be rephrased using 2119 capitalized SHOULD or SHOULD NOT

T5. Section 7.2.3 - 

   Anonymisation of timestamps and the Export Time header field should
   take care to avoid times too far in the past or future

Please rephrase - header fields do not 'take care' of anything :-). Also
usage of 2119 capitalized keywords seems in place here. 

T6. Section 7.2.4 

   care should be taken while using
   them with anonymised data export and storage.

What does this exactly mean? Please rephrase, possibly using 2119
capitalized keywords. 

T7. Same section

   care
   must be taken to ensure that Options described by this template are
   written using the anonymised timestamps instead of the original ones.

Please rephrase, possibly using 2119 capitalized keywords. 

T8. Section 7.2.5

   When anonymising data for transport or storage using IPFIX containing
   anonymised IP addresses, and the analysis purpose permits doing so,
   it is recommended to filter out or leave unanonymised data containing

Using 2119 RECOMMENDED seems appropriate. 

T9. Section 7.2.6

   The general ground rule is that information of similar type
   to that anonymised should not be made available to the receiver by
   any means, whether in the Data Records, in IPFIX protocol structures
   such as Message Headers, or out-of-band.

Using 2119 RECOMMENDED seems appropriate. 

E1. Section 4.3.2 - please expand QoS and SLA at first occurrence

E2. Section 5.2.1 - in the first phrase that defines stability s/a
single given/the same given/

E3. Figure 3 - please expand FR, FW, EP, etc. 

Thanks and Regards,

Dan

---

From: Brian Trammell <[email-masked]>
Date: Mon, 18 Oct 2010 08:40:26 +0200

Hi, Dan,

Thanks for your review. We've prepared a -05, ready for submission after a final editorial pass. Comments on comments inline.

> the OUIs may indicate a time relation. I suggest s/particular/standard/

Good point, thanks.

> quite significant as the first 24 bits of an EUI-48 address provides

Removing vendor information would be served by reverse truncation. Normal truncation would remove information about the individual nodes (which may be preserved through IP addresses, for example) while preserving vendor information (which may have specific utility when researching vendor-specific phenomena). More discussion of these issues in the document wouldn't hurt in any event. Done.

> information may be important and need to be anonymized. 

Point taken. I would actually (on review) argue against calling it dubious in an RFC, even if it were. But it's certainly not well-covered by the literature. :) Fixed.

> Using 2119 RECOMMENDED seems appropriate. 

Points on rephrasing and 2119 lanugage are taken; edited.

> single given/the same given/

The suggested correction reads to me as if there's no anonymisation at all. However, the present phrasing is also a little confusing. How about s/a single given/a given/ here?

> E3. Figure 3 - please expand FR, FW, EP, etc. 

Done, in the introductory text.

Thanks again, best regards,

Brian

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 18 Oct 2010 11:08:33 +0200

Thanks, Brian. Please submit. 

Regards,

Dan

> -----Original Message-----
> From: Brian Trammell [mailto:[email-masked]] 
> Sent: Monday, October 18, 2010 8:40 AM
> To: Romascanu, Dan (Dan)
> Cc: IPFIX Working Group
> Subject: Re: [IPFIX] AD review on draft-ietf-ipfix-anon-04.txt
> 
> Hi, Dan,
> 
> Thanks for your review. We've prepared a -05, ready for 
> submission after a final editorial pass. Comments on comments inline.
> 
> > the OUIs (per family of products for example) or the 
> relative values 
> > of the OUIs may indicate a time relation. I suggest 
> > s/particular/standard/
> 
> Good point, thanks.
> 
> > T2. Same section.
> > 
> Removing vendor information would be served by reverse 
> truncation. Normal truncation would remove information about 
> the individual nodes (which may be preserved through IP 
> addresses, for example) while preserving vendor information 
> (which may have specific utility when researching 
> vendor-specific phenomena). More discussion of these issues 
> in the document wouldn't hurt in any event. Done.
> 
> > T3. Section 4.2.1
> > 
> Point taken. I would actually (on review) argue against 
> calling it dubious in an RFC, even if it were. But it's 
> certainly not well-covered by the literature. :) Fixed.
> 
> > Please rephrase - header fields do not 'take care' of anything :-). 
> > Also usage of 2119 capitalized keywords seems in place here.
> > 
> > T6. Section 7.2.4
> > 
> The suggested correction reads to me as if there's no 
> anonymisation at all. However, the present phrasing is also a 
> little confusing. How about s/a single given/a given/ here?
>

---

From: Brian Trammell <[email-masked]>
Date: Wed, 20 Oct 2010 09:14:43 +0200

Hi, Dan,

Done; draft-ietf-ipfix-anon-05 is now available.

Best regards,

Brian