ietf
[Top] [All Lists]

Re: Last Call: <draft-farrell-perpass-attack-02.txt> (Pervasive Monitoring is an Attack) to Best Current Practice

2013-12-13 08:08:23
On 12/12/13 7:54 PM, Brian E Carpenter wrote:

Like RFC 1984 and RFC 2804, this one is intended to be jointly
issued by the IAB and IESG.

No. 1984 and 2804 were Informational. This is targeted as a BCP. It will be a product of the IETF, not the IAB or IESG. It will be a consensus document of the IETF. As 2026 says:

   While it is recognized that entities such as the IAB and IESG are
   composed of individuals who may participate, as individuals, in the
   technical work of the IETF, it is also recognized that the entities
   themselves have an existence as leaders in the community.  As leaders
   in the Internet technical community, these entities should have an
   outlet to propose ideas to stimulate work in a particular area, to
   raise the community's sensitivity to a certain issue, to make a
   statement of architectural principle, or to communicate their
   thoughts on other matters.  The BCP subseries creates a smoothly
   structured way for these management entities to insert proposals into
   the consensus-building machinery of the IETF while gauging the
   community's view of that issue.

Obviously (given the document editors), IESG and IAB members were interested in "inserting this proposal into the consensus-building machinery of the IETF". But it is, in the end, going to be a product of the IETF.

As Jari said, the IAB may explicitly endorse this document, and I think it would be wonderful if they would.

I don't see any difference (except for
the artefact that it has to be assigned to one of the streams,
which didn't exist when the two previous RFCs were issued).

Which is part of the reason for doing this as a BCP. The IAB gets to issue its statements as Informational documents in its own stream. The IESG manages the IETF stream and publishes consensus documents of the IETF. That's nicely clarified in 5741, so doing this as a BCP is the most appropriate. And being the consensus of the IETF will (hopefully) be a stronger statement than "statements from on high."

The discussion of the principle *was* over in Vancouver.
Workshops, and IETF WGs, have to apply the principle to actual
technology.

See other messages. This is just rubbish. The discussion in Vancouver (especially when one contrasts the IAB plenary from what was said in the perpass BOF) made it clear that there was still some work to do clarifying the bounds of the principle.

That said, I do agree that this document is about the general principle, not the details of how it applies to particular technology. We should get the document clear that we (the IETF) intend to take seriously the security threat of pervasive monitoring of data, a threat that we didn't take as seriously before, and that we will attempt to mitigate that threat in our protocols, where it is possible *and* sensible. I think the current rev of the document is darn close (if not already there) on the general principle, though I'm fine with finding the words to make the "possible and sensible" part agreeable to folks. But we don't want to mush the document up so much that it becomes "whenever we feel like it". The principle has limits, and we should make sure we express that fact clearly, but (I think) we absolutely do want to say that we have a general hole to plug in many protocols, one that we didn't think was as likely to be exploited as it turns out to be. And I think we want to say that as concisely and generally as we are able to.

I hope the workshop will be discussing specific technology, or at
least specific technical guidelines, not wordsmithing the general
principle.

Yep.

On 13/12/2013 01:37, Stewart Bryant wrote:

I should add to this response that Dave Crocker
proposed that we pull back on this BCP and
explicitly consider its impact in each of our
working groups.
I strongly disagree. That detailed consideration should
follow *after* the general principle has been committed
to the RFC repository. Otherwise we will simply enter a
maze of looping discussions.

Brian said it better than I could. I completely agree.

pr

--
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

<Prev in Thread] Current Thread [Next in Thread>