I agree entirely that defining host identification as a problem
indicates that the authors believe a solution is called for. I also
agree that the privacy impact of solution candidates must be discussed,
including making a concerted effort to mitigate the possibility of those
solution candidates being used for pervasive monitoring purposes. My
point is simply that this draft is not intended to propose solutions or
discuss solution candidates.
RFC6967, which as you note is repeatedly cited, discusses solution
candidates and lays out a framework for privacy discussion related to
solution proposals. Future RFCs that actually propose solutions are
already expected to follow the guidance from RFC6967, and the references
to that RFC in this draft are meant to point to RFC6967 as the
authoritative guidance.
Is there some reason why you do not consider it adequate for this "use
cases" draft to reference the existing and already published "potential
solutions analysis" rfc? What specific content related to privacy and/or
pervasive monitoring belongs in this draft that is not already present
in RFC6967?
Thanks,
--Brandon
On 06/09/2014 01:16 PM, joel jaeggli wrote:
On 6/9/14, 7:01 AM, Stephen Farrell wrote:
On 09/06/14 14:46, Brandon Williams wrote:
Would you please indicate where the draft proposes a new identifier? If
you are seeing a proposal for protocol changes somewhere in the draft,
editing work is required in order to either clarify or excise the
associated text.
There are 6 citations of
http://tools.ietf.org/html/rfc6967
the document doesn't exist in a vacuum where somehow how to do it has
fallen off the table.
given the repeated asertion that this work is useful because of external
requests (etsi) and that request is in fact tied closely to a particular
method it is relatively strait forward to conflate the discussion of
scenarios and methods.
Fair enough that its an assumption of mine that adding some kind of
identifier is required to meet the (no-longer mis-stated:-)
requirements for these use-cases. But I think that is logically
required, and its valid to draw obvious conclusions and its also
invalid to ignore obvious conclusions.
S.
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
--
Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
