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/