Hi Dave, On 01/02/2014 12:33 PM, Dave Crocker wrote: > On 1/2/2014 4:23 AM, Stephen Farrell wrote: >> This BCP will not change the potential for any AD to abuse the >> IETF. Not a whit. And it really doesn't matter what happened >> 10 years ago or whenever you care to pick. > > > Stephen, > > I think this assessment is incorrect, based on the earlier history with > Security Considerations. We disagree about the assessment, though not the history. > For years, we were faced with a requirement to do these Considerations, > but had no guidance about what would satisfy it and what wouldn't. As a > consequence, working groups had to play a guessing game -- sometimes for > months -- as to what would satisfy the blocking AD. > > Of course, that potential is always present, and not just for Security > Considerations. But it is exacerbated by a document with formal status > that makes broad requirements but affords working groups no guidance > about how to satisfy those requirements. > > Again, this is why I think your document should be issued with > non-normative status. I do get the concern. > It's good to have the statements it makes. It's bad to give them > normative force until we have experience trying to apply it. I think someone else pointed out yesterday that the normative force here is only to the effect that pervasive monitoring needs to be considered, but nothing normative is stated here about how that is to be done. That latter is being worked on but will take quite a while before we can really claim its based on reality. I also think waiting until we have that experience will be damaging. - It would take years. - The result would likely be this statement plus some details that will be relatively quickly be out of date. - In this space, it will be hard to know which mitigations have really been effective. So waiting would not be a good approach. As to status: 2026 section 5 says: The BCP subseries of the RFC series is designed to be a way to standardize practices and the results of community deliberations. A BCP document is subject to the same basic set of procedures as standards track documents and thus is a vehicle by which the IETF community can define and ratify the community's best current thinking on a statement of principle or on what is believed to be the best way to perform some operations or IETF process function. This draft is precisely a statement of principle and hence ideally suited to be a BCP. I just don't think it'd be sane to require every statement of principle to be accompanied by all the assembly instructions. And it'd be wrong to never state principles. Cheers, S. > > d/