ietf
[Top] [All Lists]

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

2014-01-02 10:15:12
On 1/1/2014 2:08 PM, Ted Lemon wrote:
This argument boils down to "ADs can abuse process, so we ought not
to ever publish a document that might provide process for them to
abuse."

A normative document that requires action, but does not characterize the action, inherently encourages idiosyncratic interpretation. That's an invitation -- possibly even a demand -- for ADs to develop their personal preferences rather than to reflect a shared community sense of what is needed.


It will be used by working group chairs and document authors to
understand the IETF's expectations with respect to whether their work
needs to address the problem of pervasive surveillance on the
internet.

The problem here is your certitude about how it will be used.

The one thing that is certain about the document is that it does not specify that activity for those people.

And at this stage I don't think it should, because we don't know enough.


I expect that ADs will also have this in mind when
reviewing documents, and may ask questions about documents if the
documents appear not to have addressed the problem, and don't say
why.

A reasonable expectation. But since we have no community understanding of what the specific questions should be and even less community understanding of what the answers will be, making the current draft normative essentially requires a deadly embrace in the standards process, as each occurrence produces an ad hoc negotiation over an extended period of time. (This is exactly what happened for years with Security Considerations.)

All of this gets exacerbated by the likelihood of personal whim amongst ADs. (It's not a question of intent; everyone intends well. It's the lack of community guidance, at this stage.)



But the real goal of a document like this is to get working groups to
think about this, not to create more tail-end process.

Then don't make it normative, yet.


 ADs can
_already_ ask these questions, and can _already_ send documents back
to the working group if the answers aren't satisfactory.   What this
document does is to clearly state an IETF consensus (assuming one is
reached), which might result in more consistency both across the
process of developing a specific document, and also across time as
the makeup of working groups and the IESG changes.

On Jan 1, 2014, at 10:45 AM, Dave Crocker <dhc(_at_)dcrocker(_dot_)net> wrote:
There is a substantial community in the Internet wishing to have
its data and activities protected against pervasive monitoring.
The IETF needs to design specifications and practices (existing and
new) with the means to ensure such protection.

It sounds like you are saying that the IETF does not lead, but rather
follows the market.

Since I don't see anything in that statement of mine about the market, I can't guess what took you to that interpretation.


On Jan 1, 2014, at 3:29 PM, Melinda Shore 
<melinda(_dot_)shore(_at_)gmail(_dot_)com>
wrote:
I really don't think so, at least not in its current form.  I think
it's fine to publish it as-is as an opinion piece but it seems to
me that if it's going to be published as a "BCP" it really needs to
be clearer about specifically what is going to change in the
current document development and publication process.

This document is advice, not code.

"Advice" is not normative.


  It is indeed "best practice" in
the sense that, if the IETF gains consensus on it, it is saying that
we should make a habit of thinking about pervasive monitoring when
writing our documents.

Ted, a recurring problem in many folks' posting on this topic is that they seem to be applying invoking themselves as the model of what will happen with the document, rather than considering the community's history, including how different ADs have operated over the years.

And then there is the well-demonstrated variability already showing up in the current discussion. It makes clear that we don't yet have shared community understanding of what we should be doing in terms of technical specifics.

The document really has nothing to do with best current practices because it is not about practices at all. It is about concerns. We don't make statements about concerns normative. Especially when we do not have any history of working on a topic.

d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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