On 2018-04-26 06:29, Brian E Carpenter wrote: > On 26/04/2018 04:07, Amelia Andersdotter wrote: >> On 2018-04-25 14:42, [email protected] wrote: >>> You could have two different objections to the draft: >>> >>> 1. The IETF does not, in general, recommend grace periods or time >>> periods for logging, caching, etc. That's just wrong - I find loads of >>> examples in old and new RFCs of recommended time-periods for data >>> storage by googling. >>> [Med] AFAIK, there is no such IETF reco for address sharing specifications. >> The IETF has made recommendations against a backdrop of highlighted >> regulatory requirements mandating storage of data (for 6-12 months), cf >> RFC7768, RFC6269. So the time-limits are there, just not decided on >> technical merits, but by reference to legal merits. > We can recommend what we like, but the fact of life is that products will > be designed to support the most stringent regulatory requirement in the > world market, and if there are conflicting requirements in different > jurisdictions there will be corresponding configuration options in the > products. So even if we put privacy-protecting SHOULDs in our RFCs, > the regulators decide what actually happens. I'm not against putting > those SHOULDs but I try to be realistic about their impact. >
I think Povl already touched upon the interactions between RFCs and regulators. It's a question of taste whether one wants to legal system to hash out what is reasonable or have a technical recommendation. To me, it seems preferable to have a technically motivated/scrutinized recommendation. The worst thing that could happen is that we'd have to revise RFC6302 again. > > IMHO we should say nothing that appears to be a recommendation > about the duration of logging. We can say as a factual matter that > logging is useful for operational purposes (fault diagnosis, abuse > detection, and statistical analysis) and may be legally required. > We can say that the logs SHOULD be stored securely, and SHOULD NOT > be retained any longer than is needed for these purposes. The risk is then that it's not practically useful for people in organisations that lack large legal teams. A typical difficult case in Sweden is municipalities, municipality-owned corporations, civil-society organisations (I know my affiliation is an CSO for IETF purposes, but plenty of CSOs don't work in tech standards groups at all) or similar: they may have a lot of staff, but the vast majority don't have more than one or two IT staff, and they may have access to lawyers only as needed. It's a consultant field-day where reliable recommendations are hard to come by, but they still all have internet-facing servers in one way or the other. For that kind of use-case, saying "it depends" is not really helpful. Also the current RFC6302 is not helpful for this group, since it provides recommendations that prima facie are shaky against a background analysis that is also shaky. best regards, Amelia > Brian > >> But the examples I mentioned are for other types of identifiers that are >> logged, cached or stored. RFC2308 Section 7.1 and 7.2, for example. >> RFC5988 section 6.3. In general, the IETF could decide to recommend data >> minimization in terms of storage duration, was what I meant, and it >> wouldn't be a complete break from tradition. >> >>>> 2. The time-period as suggested is wrong. For instance, as Povl >>>> proposed, 3 days is reasonable if it's just about shifting the log from >>>> the internet-facing server as such to somewhere else, and for storing >>>> logs at end-destination a longer period of time is necessary. >>>> >>>> I think you're aiming for objection 1). I don't see the historical >>>> precedent for this assertion, and it seems to be rather about what the >>>> IETF would feel like. I'm open for discussion on objection 2). >>> [Med] Hmm. Please check >>> https://mailarchive.ietf.org/arch/msg/behave/GzY46_zyxVDeKv10nGzGWM8FA34 >>> >> Not sure I see the relevance? Neither RFC6269 nor RFC7768 should have >> been adopted by workgroups or become RFCs if that 2011 e-mail had >> established an IETF praxis. >> >> best regards, >> >> Amelia >> >>>> best, >>>> >>>> A >>>> >>>>> Cheers, >>>>> >>>>> Med >>>>> >>>>> >>>>> >>>>> *De :*Povl H. Pedersen [mailto:[email protected]] >>>>> *Envoyé :* mercredi 25 avril 2018 13:16 >>>>> *À :* BOUCADAIR Mohamed IMT/OLN >>>>> *Cc :* [email protected] >>>>> *Objet :* Re: [Int-area] WG adoption call: Availability of Information >>>>> in Criminal Investigations Involving Large-Scale IP Address Sharing >>>>> Technologies >>>>> >>>>> >>>>> >>>>> I would keep full IP address + port info in my firewall log. Separate >>>>> from the webserver log. This to help the webguys not abusing collected >>>>> data. >>>>> >>>>> Having talked to the webguys, they use the logfiles in daily >>>>> operations, and they see them as necesary to provide continous >>>>> delivery of the services to the end user.That is another obligation we >>>>> have. >>>>> Our legal department actually suggested we keep logs for 5 years, as >>>>> some data must be kept that long. >>>>> >>>>> The big privacy issue here is more about abuse and losing the data >>>>> (move them away from the internet facing server within 3 days would be >>>>> a good recommendation). This must be controlled by internal company >>>>> rules. Not this RFC that says we must cripple data after 3 days. And 3 >>>>> days is a stupid limit if there is a longer weekened/holidays etc. >>>>> Easter is an example, Thursday to monday are non-working days. That is >>>>> 5 days + the extra. So the 3 days should be 6 days without even >>>>> accounting for holidays. >>>>> >>>>> >>>>> >>>> -- >>>> 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 >>>> [email protected] >>>> 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 [email protected] https://www.ietf.org/mailman/listinfo/int-area
