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.
>
>
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
