Dear Mohamed, all, On 2018-04-23 10:38, mohamed.boucad...@orange.com wrote: > Dear Amelia, > > Some comments about the main recommendations in draft-andersdotter: > > SHOULD only store entire incoming IP addresses for as long as is > necessary to provide the specific service requested by the user. > > Med: This is implementation and deployment-specific. Not sure we can mandate > a server how to service users.
It's a recommendation. Cf. RFC2119 on the word SHOULD. That said, the draft is meant to encourage good (best!) practises that can assist with both privacy focus and regulatory compliance. The IETF cannot stop anyone from following a poor practise, and certainly I can't. > SHOULD keep only the first two octets (of an IPv4 address) or the > first three octets (of an IPv6 address) with remaining octets set > to zero, when logging. > > Med: A server can decide to follow this reco, but it will be difficult for > the owner of the server to claim an abuse and help identifying > responsibilities. The recommendation is partially inspired by web analytics recommendations for Piwik/Matomo installations by French DPA CNIL, but of course also enjoys support from the data minimization strategies advanced in RFC6973. > Please note that RFC6302 ** does not recommend to log IP addresses** :. > > "It is RECOMMENDED as best current practice that Internet-facing > servers logging incoming IP addresses from inbound IP traffic also > log " > > which means ** IF ** a server logs source IP address, then it has to log also > the source port. Indeed, my proposal is to recommend that servers do not log IP addresses other than to the extent recommended. If they don't log IP addresses at all, they would be following the recommendations. > SHOULD NOT store logs of incoming IP addresses from inbound > traffic for longer than three days. > > Med: It is out of the scope of the IETF to define the duration of logs. This > is country-specific. I'm proposing a recommendation for a best practise. Presumably if for legal reasons one finds oneself unable to follow best practise, one follows a worse practise instead. The fact that some people may have to follow a worse practise is not a reason to recommend a poor practise. > SHOULD NOT log unnecessary identifiers, such as source port > number, time stamps, transport protocol numbers or destination > port numbers. > > Med: Not sure to understand this one. "unnecessary identifiers" is not clear. > I prefer the current language in 6302 which identifies the minimum set of > information. The recommendation follows immediately from data minimization in RFC6973, which is consistently adhered to in IETF drafts with a privacy focus. > SHOULD ensure adequate log access control, with suitable > mechanisms for keeping track of which entity accesses logged > identifiers, for what reason and at what time. > > Med: I hear you, but this is out of scope of the IETF. Access rights to > retention data is well known and is not altered by the IETF specification. I don't understand the objection. The IETF discusses access control and authentication in various circumstances. If anything, the recommendation could be accused of being too inexact to qualify as a good recommendation. The scope of it is fine and well within IETFs mandate. best regards, Amelia > Cheers, > Med > >> -----Message d'origine----- >> De : Int-area [mailto:int-area-boun...@ietf.org] De la part de Amelia >> Andersdotter >> Envoyé : lundi 23 avril 2018 10:11 >> À : int-area@ietf.org >> Cc : Stephen Farrell >> Objet : Re: [Int-area] WG adoption call: Availability of Information in >> Criminal Investigations Involving Large-Scale IP Address Sharing Technologies >> >> I've tabled a similar draft but with a different scope. Happy to discuss >> with members on the list: >> >> https://datatracker.ietf.org/doc/draft-andersdotter-intarea-update-to- >> rfc6302/ >> >> -- >> >> Amelia Andersdotter >> Technical Consultant, Digital Programme >> >> ARTICLE19 >> www.article19.org >> >> PGP: 3D5D B6CA B852 B988 055A 6A6F FEF1 C294 B4E8 0B55 >> >> _______________________________________________ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area -- Amelia Andersdotter Technical Consultant, Digital Programme ARTICLE19 www.article19.org PGP: 3D5D B6CA B852 B988 055A 6A6F FEF1 C294 B4E8 0B55 _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
