On Dec 31, 2013, at 3:48 PM, John C Klensin <john-ietf@xxxxxxx> 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.shore@xxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxxxxx> 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.shore@xxxxxxxxx> 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.