> It is clear from the list discussion that there is no broad, shared > understanding of how this policy statement will be applied. In other words, > we do not have rough consensus about what the document /means/. The problem with publishing as an informational is, as an information, it has no standing within the community. I think we might be mixing what something means with what action to take based on that meaning. I would agree there are no clear cut actions in the draft as it stands, but we're not really certain what those actions might be right now, at any rate. So the question becomes: Should it be a standard of some sort -- a draft with some standing other than "information" -- to find a way forward in building the questions, rules, and ideas around protecting the internet protocols designed here against pervasive monitoring? Should the IETF treat it as a standard that we should work towards this goal? If not, then don't bother writing it down at all, no matter the status. If so, then it's worth saying in a way that drives us forward into other work in this area. > As a rule, the IETF tends to avoid standardizing specifications that it knows it > does not understand. There is a difference between standardizing a specification in the technical sense, and saying, "this is a community goal we've agreed to work on." My concern, in the end, is that we publish an informational, and then say: "See, we've done something. Now we can get back to our regularly scheduled arguments over whether this should be a bit field or an integer." I don't think that's the right response. Pick the stronger vehicle, even if it's not "perfect." As with many other things in the IETF, the perfect is often the enemy of the good. Russ