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

[Brian Trammell <[e-mail]>]

Hi, Dan,

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

Best regards,

Brian

On Oct 18, 2010, at 11:08 AM, Romascanu, Dan (Dan) wrote:

> Thanks, Brian. Please submit. 
> 
> Regards,
> 
> Dan
> 
> 
>> -----Original Message-----
>> From: Brian Trammell [mailto:[e-mail]] 
>> 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.
>> 
>> On Oct 14, 2010, at 8:45 PM, Romascanu, Dan (Dan) wrote:
>> 
>>> 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/
>> 
>> Good point, thanks.
>> 
>>> 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.
>> 
>> 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
>>> 
>>>  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.
>> 
>> 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.
>> 
>>> 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. 
>> 
>> Points on rephrasing and 2119 lanugage are taken; edited.
>> 
>>> 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/
>> 
>> 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
>>