On 1/19/2014 12:30 AM, Eliot Lear wrote:
It is fair to say that we should consider this threat at an architectural level. It's fair (albeit a truism) that finding design flaws earlier in the process rather than later is less costly (ENG-101). Justification language like the above, however, is likely to actively impede the IETF, as these sorts of things have in the past.
If I'm understanding this exchange, it hinges on the distinction between due consideration vs. appropriate design response.
Pressing to have work "consider" an issue early and thoughtfully makes sense for any topic that is as important as pervasive monitoring. Having IESG evaluation produce a blocking Discuss because an AD feels that the consideration was not sufficient or the resulting design flawed in terms of this issue is another matter.
The point I'm seeing Eliot make is that we don't have enough community understanding of the topic to be sure what constitutes appropriate design consideration. So, in the face of such minimal community understanding, an AD's blocking progress would be whimsical at best.
Based on how new this topic is -- we don't even yet have stable and shared terminology for the problem space nor the solution space -- Eliot's concern isn't just valid, it's important.
We /do/ have a long track record of well-intentioned ADs asserting Discusses that are reasonable in the abstract but impractical for work in the IETF, especially when the topic is frankly still vague.
While the formal status of this document is relevant to the concern, the more important issue I see is our community sense that work going forward needs serious effort, but also an understanding that the basis for blocking specification needs to be extremely cautiously applied.
By way of trying to be practical about being practical, I'll suggest that any IESG blocks based on a concern about pervasive monitoring needs to reflect a consensus view of the IESG, not just the concern of a single AD....
d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net