Dear all, I hope it’s not inappropriate for me to step into this discussion, but I would like to respond to a few of the points that have been raised so far. For brevity I will incorporate my responses to the various emails into a single email.
The main point people are making: ——————————————————————— There are several objections to the document scope (by Stephen Farrell, Brian E Carpenter and Ted Lemon - quotations are not necessary, I trust). In response I only point out that the intarea working group has already adopted a document making recommendations that logging of source port should be done (RFC6302/BCP162). The point I’m making in this document is that: 1. source port logging is not routine, despite publication of RFC6302 in 2011 - in other words the document has not had the hoped for impact 2. what are the reasons for this 3. what additional recommendations can be made to move this along Therefore I’m a little surprised by this response to a relatively minor movement in an already published intarea position. However, if people are irreconcilably opposed to the scope of the current document, then I propose as follows: a. Reject the call for adoption by the working group and move the document back to the independent submission stream. I believe the conflict review comments have already been adequately addressed in draft -04 and publication will hopefully be possible there. b. Begin a discussion here (or in whatever forum might be more appropriate) on what would be an appropriate scope for a separate document to consider the broader issues that are being raised by the various commenters and see what sort of consensus can be reached. I offer to contribute my opinion to that discussion. Other additional points: ——————————————— From Stephen Farrell: > 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.) The document is not supposed to be an analysis of the privacy implications of law enforcement access to data in general and, by the way, nobody is talking about “assisting law enforcement and commercial or other surveillance” - that’s a straw man. I do address in section 9 the privacy implications of the specific proposal (source port logging) as a solution to a specific problem (carrier grade NAT and similar technologies) - a proposal that has already been accepted by the intarea group in RFC6302/BCP162. However, I agree with you that a broader discussion within the IETF of the balance between privacy and the societal need for law enforcement access to data is certainly required. From what I can see in my research so far, the philosophy within the IETF appears to heavily favour privacy over other issues (such as societal rights or rights of victims of crime - represented in this case by law enforcement access to data). I cite as just two examples of this (and believe me I can provide many more): - RFC4941 (Privacy extensions for stateless address auto configuration in IPv6) - “by design” obfuscation of the source of network traffic with no consideration of the crime attribution implications - RFC6742 (Default address selection for Internet Protocol version 6 (IPv6)) - recommending selection of temporary addresses generated using RFC4941 over other options I think a discussion of the broader issue requires robust and vocal representation of both sides and I am willing to adopt for the purposes of such a discussion the, apparently unpopular, position that while the right to privacy is very important it is not the only right and a more nuanced consideration of the situation might be worthwhile. From Brian E Carpenter: > I do have another comment about adoption. This is an IPv4 technology. Do we > really want to spent IETF cycles on it? I'd prefer that we adopt > https://tools.ietf.org/html/draft-george-ipv6-support-03 . I agree with you that this is an IPv4 problem. I mention in the document (last paragraph of section 1) that migration to IPv6 would make this problem go away but also I would like to emphasise that this is a real problem being faced right now and it is something that can’t be put off until IPv6 migration is complete. Whether or not the IETF is the correct forum is not for me to say - all I’m trying to do is make sure that at least the conversation takes place. Regards, daveor _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
