Hiya, We could trade references to existing BCPs and RFCs but I don't think we need to - I did not claim that the IETF had never done work in this space, nor that we ought not - my point was that such work being done at this point in time needs to take a broader perspective than the document concerned. (If for some reason it is helpful to trade references to existing BCPs and RFCs that argue for different approaches to privacy, I'm fine with doing that, but I hope it's not needed;-)
Below you say: > The I-D inherits the same privacy implications of existing RFCs. That would be a significant reason to not adopt the current document! I hope that we've learned that we need to do more thorough analyses of the privacy implications of our work. Cheers, S. On 23/04/18 06:32, [email protected] wrote: > Hi Stephen, > > The scope of this document is aligned with what the IETF has published in the > past in this field. A list is provided below: > > 1. Identify logging as an issue in address sharing: RFC 6269 > > 2. Require address sharing to enable a logging function: RFC 6269 > and RFC 6888 > > 3. Identify a minimal set of information to be logged: RFC 6269, > RFC 6888, and RFC 6908 > > 4. Identify and discuss trade-offs of solutions to achieve logging: > RFC 6269, RFC 6908 > > 5. Specify means to optimize logging (port range allocation, > deterministic NAT): draft-ietf-softwire-stateless- > 4v6-motivation, RFC 7596, RFC 7597, RFC 7599, RFC 7753, and > RFC7422 > > 6. Recommend servers to log source port: RFC 6302 > > 7. An initial survey of servers supporting source port logging: RFC > 7768 (ISE) > > 8. Retrieve NAT session loggings: draft-ietf-behave-syslog-nat- > logging, RFC 8158 > > 9. CPU and memory issues: RFC 6908 > > As such, this I-D: > - **DOES NOT** define a new behavior: it relies on existing IETF RFCs. > - **DOES NOT** require logging another yet information: again, it relies on > the various schemes discussed in existing RFCs. > > The I-D inherits the same privacy implications of existing RFCs. > > Cheers, > Med > >> -----Message d'origine----- >> De : Int-area [mailto:[email protected]] De la part de Stephen >> Farrell >> Envoyé : samedi 21 avril 2018 18:24 >> À : [email protected] >> Objet : [Int-area] WG adoption call: Availability of Information in Criminal >> Investigations Involving Large-Scale IP Address Sharing Technologies >> >> >> Hiya, >> >> I've read this draft and do not support adoption of a >> draft with this scope. >> >> I do support consideration of how law enforcement >> investigations can be carried out, but not without a >> similar level of consideration of the real trade-offs >> between assisting law enforcement and commercial or >> other surveillance. At present, the draft is nowhere >> near sufficient in this respect. (Despite saying that >> "Clearly a balance needs to be struck between individual >> right to privacy and law enforcement access to data >> during criminal investigations" the draft is anything >> but balanced in that respect.) >> >> I don't think that this problem is a thing that'd be >> reasonable to try fix after WG adoption, but needs to be >> handled beforehand as it's a fundamental scope issue. >> >> In other words, I believe this draft just has the wrong >> scope, and if adopted would be likely quite controversial >> before publication. In contrast, a draft that really does >> consider the trade-offs related to logging could be quite >> valuable and if it provided a balanced approach might even >> not be controversial. >> >> (FWIW, I might be willing to try help out a bit on a draft >> that did have what I think is an appropriate scope, as I do >> think more appropriate logging is a reasonable goal. But >> before accepting that offer be aware that IMO sometimes >> "more appropriate" ought mean only logging minimal data for >> a very short period and then thoroughly scrubbing all of >> that:-) >> >> Separately, if a document on this topic is to be adopted >> by any IETF WG, I think the adoption call ought be widely >> circulated (esp to saag, and art-area lists) as this is a >> topic that is likely to attract interest from various folks >> in other areas, and it'd be much better to figure out early >> and not late if others also see problems with this draft. >> >> Cheers, >> S. >> >> PS: I'm not subscribed to the int-area list so please do >> cc' me on any follow ups. >> >> >
0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
