Hi Med, On 06/06/14 12:41, mohamed.boucad...@orange.com wrote: > [Med] I'm not sure about this Ted. There are other initiatives that > try to solve the issue for particular use cases, see for instance > this effort for HTTP: > http://tools.ietf.org/html/draft-ietf-appsawg-http-forwarded-10. The > rationale of the "host identifier scenarios" document is to group all > use cases suffering from the same problem instead of focusing on one > single case. This allows having a big picture view of the problem > space.
I think XFF is actually a good example of why we ought not adopt this work. XFF is widely deployed already but somewhat flakey in terms of interop so the authors of the above draft aimed to produce a spec that just addressed interop. (*) That was adopted by an area WG without (IMO) ever really considering the privacy implications, and definitely without any effort having been made to develop a more privacy-friendly mechanism (which could have been done, again IMO) to solve what were the claimed use-cases. By the time it got to the IESG that was in practice unfixable and after some fairly painful discussions it ended up with 4 abstain ballots, including mine. [1] (For those who quite reasonably don't need to care about IESG balloting, an abstain means approximately "yuk.":-) Of course that all also pre-dated BCP188 and the last year's shenanigans so I'd hope we have learned to not keep doing that. I'd be delighted if those who could get a better solution implemented/deployed were to attempt to try to address the privacy issues with XFF but it seems that at least in that case relevant folks don't care (sufficiently;-) deeply about our privacy to go do that. S. [1] https://datatracker.ietf.org/doc/draft-ietf-appsawg-http-forwarded/ballot/ (*) To be clear: I think the authors were genuinely just trying to fix what they saw as an interop problem. _______________________________________________ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
