ietf
[Top] [All Lists]

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

2014-01-01 16:09:43
On Dec 31, 2013, at 3:48 PM, John C Klensin <john-ietf(_at_)jck(_dot_)com> 
wrote:
No matter what
assurances are made to the contrary, we've seen example after
example, general guideline after general guideline, turned into
rigid rules during or after Last Call on particular documents
because some AD decides that a document that doesn't match his
(usually -- I think we've yet to have a really abusive,
testosterone-poisoned, woman AD) ideas of how things should work
and should therefore be blocked until the authors or WG either
conform to whatever "requirement" supports his conclusion or
produce an overwhelming proof that should not be necessary.

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."   Forgive me, 
but this is just bad logic: if ADs are abusing process, the problem is the ADs, 
and the solution has to be addressed through the AD nomination and/or recall 
process.   There are already plenty of processes to abuse—if I really want to 
scuttle a document, I don't need another BCP with which to do it.

On Jan 1, 2014, at 12:38 AM, Melinda Shore 
<melinda(_dot_)shore(_at_)gmail(_dot_)com> wrote:
I've mostly been baffled by the IETF response to
revelations about internet eavesdropping, to be honest,
and it's struck me that work on some of the problems that
need to be solved to provide better privacy guarantees (for
example, fixing PKI and providing better keying) have been
pushed to a back burner in a scramble to make grandiose
pronouncements.

Fixing PKI doesn't address the pervasive surveillance problem at all.

It's not that draft-farrell is a bad
document on its own merits, it's just that I cannot for
the life of me understand what it specifically means for
work moving through the IETF process.

It means that, if the IETF winds up having consensus to say so, we agree that 
document authors and working groups ought to consider the problem of pervasive 
surveillance: that considering these issues is documented best practice in the 
IETF.

On Jan 1, 2014, at 9:37 AM, Abdussalam Baryun 
<abdussalambaryun(_at_)gmail(_dot_)com> wrote:
So if you support, could you just state directly how this document
will be used?

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.   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.   In some cases, further consideration in the working group will be 
called for.   In other cases, adding some explanatory text may suffice.   In 
still other cases, explaining the situation to the AD will be enough.

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.   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.

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.   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.   I 
think it would be harmful to be more specific than that.   One the one hand, 
formal process may be applied when good judgment would have argued otherwise, 
because "that's the process."   On the other hand, formal process may well 
accidentally exempt documents where a more general "you ought to think about 
this" would have clearly applied.


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