Donald Eastlake <d3e3e3@xxxxxxxxx> wrote: > On Fri, Jan 3, 2014 at 11:34 AM, Eric Rosen <erosen@xxxxxxxxx> wrote: > > > > Stewart> The -03 text is a significant improvement, but I still fear the > > Stewart> impact of single issue technical politics on the output of our > > Stewart> document stream. > > > > Let's face it, the draft is nothing but a political manifesto, and the IETF > > has no business even considering it. It is also clear from this discussion > > that there is no consensus, even rough consensus, in favor. All this quibbling over whether or not the document is political, a manifesto, or whatever, seems pretty pointless to me. All I care about is what the document says and given that, what the likely effects of having this document as a BCP are going to be. > Anyone who has been around in the IETF long enough has seen this > before. Rabid opposition to real consideration of strong security. I > have seen yelling at plenaries. I've heard people say how the IETF > will be destroyed or become irrelevant if we don't bow to the US > Government rules. Etc. The fact that there has been opposition to previous statements about security does not mean that the opposition to the document at hand has the same character. The burden of proof for that would be on you and others making this claim, and thus far I don't see any evidence being presented to support this underlying claim. In my own case, I fully supported the publication of RFCs 1984 (weak keys) and 2804 (wiretapping) - the two previous statements of this sort this document cites. I also argued for the imposition of mandatory to implement ciphersuites in TLS. And so on - I don't think I've exactly been an opponent of strong security. And yet I strongly oppose publication of this document as a BCP. I think it should be published as an informational document instead. (I should note that I find the idea of publishing this as experimental to be intriguing, but given the confusion that has surrounded previous experiments I think this course is too risky for something this important.) I find this document to be too vague to function properly as a BCP, and I don't think we have a sufficient understanding of the tradeoffs involved in making pervasive monitoring more difficult to write a proper BCP at the present time. And if anything, hasty and ill-considered changes may make monitoring easier, not harder. I think the course advocated by Dave Crocker is the correct one: Publish this as an informational policy statement, and then work through the policy on subsequent specifications. Then, once we believe we have a sufficient grasp of how this actually plays out, write a BCP. (Dave, I think this summarizes your position, but if not, apologies for getting it wrong.) I also note that RFCs 1984 and 2804 were both published as informational. Maybe I missed it, but I find nothing in the document itself that explains why this time is different and publication as BCP is warranted. > If you want to distort the word "political" to try to characterize > this, I don't care that much. This draft is completely in line with > the previous admirable IETF engineering positions on security. Which would argue for handling this one the same way, would it not? > > Note the tone taken by proponents of the draft. ... one cannot determine > > from the draft what the actual impact on IETF process is ... claim the support > > of a "silent majority" ... (This is really off topic, but since you raised the issue, I'll make one comment about it. I have no intention of discussing this further.) The tone taken by both sides in this argument has been quite poor. That said, my impression has been that there has been more impugning of motives from supporters than from opponents. > Note the tone taken by opponents of the draft. Gross distortions and > mischaracterization of the draft. I hope people reading the IETF > discussion list, if they care about this issue, will actually read the > draft and see what it actually says, which is pretty reasonable. What the draft says is reasonable IMO, but that's really beside the point. The problem is what the draft does not say. It says we're going to take action to mitigate attacks but doesn't say how this is going to be done. That vagueness is fine for an architectural policy statement but leaves far too much leeway for a BCP. > The intended effect on IETF process is clear enough to me from the > document, at least in version -03. I have no doubt the intentions here are good. But all too often intended and actual results diverge. Ned