Dear Amelia, Please see inline.
Cheers, Med > -----Message d'origine----- > De : Amelia Andersdotter [mailto:ame...@article19.org] > Envoyé : lundi 23 avril 2018 21:04 > À : BOUCADAIR Mohamed IMT/OLN; int-area@ietf.org > Cc : Stephen Farrell > Objet : Re: draft-andersdotter (was RE: [Int-area] WG adoption call: > Availability of Information in Criminal Investigations Involving Large-Scale > IP Address Sharing Technologies > > 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. [Med] It is a not a problem with the language of the reco, but its implementation. The IETF cannot dictate which information is required to provide a service and whether an IP address is needed. This is really implementation-specific. > > > 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. [Med] I don't have a problem with the general intent of your text, my concern is that you link those explicitly with RFC6302 which is misleading. RFC6302 has a very clear focus: address sharing. > > > 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. [Med] How those servers will react to DDoS attacks or other abuses? > > > 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. [Med] But there are laws out of there. I don't think that we need to interfere with those. 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. [Med] But how this is related to RFC6302 context? > > > 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. [Med] Rules to access regulatory data are well known. > > 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
