Re: Last Call: draft-ietf-opsec-filter-caps (Filtering and Rate Limiting Capabilities for IP Network Infrastructure) to BCP

[Danny McPherson <danny@tcb.net>]

[apologies for the lengthy response]

On Jun 28, 2007, at 9:54 AM, Barry Greene (bgreene) wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> There is no confusion on my part. I've been in and out of IETF work
> since 1990. So I've very clear about my concerns and issues.

Now I'm confused..  Let me recap in hopes that you'll
help clarify my confusion on where you are on the issue.

I'll leave the charter bits out of this I've already addressed
with George in a previous email.

draft-ietf-opsec-filter-caps completes WG Last Called with
intent to publish as BCP, is passed on to IESG.

IESG reviews and sends IETF Last Call.

You object because "I don't understand "BCP." Information
RFC yes. Something that can be use for requirements yes.
But Best Common Practice? How is an operator's "I wish my
equipment can do this in my network" become a BCP?" and
appeal to the IESG that the BCP process is being abused
providing a fragment of text from RFC 2026 you cited here
earlier about how BCP's follow the same process as Standards
Track document - but without the rest of the text, and in
particular, section 6.1, is in and of itself confusing and
incomplete.

Then Ron/AD says OK, let's publish as Informational and I
disagreed.  Strictly speaking, the current IETF process and
RFC 2026 in particular explicitly states that requirements
should not be contained in Informational documents, yet
this is commonly ignored in application.

So, I object and state that it should be BCP, and you reply
with concerns of "unilateral imposition" and "no rough
consensus".  You go on to detail some of the content of
the draft as implausible.  Then you state "Informational RFC
allows it to go into RFPs ASAP. _THE_ most powerful driver
on the vendor community are RFPs."  Then on from there to
"My issue is not with the document. My issue is with the jump
to BCP status."  - I'm not sure where the RFP thing comes
from as it'd seem equally applicable to BCPs, but let's
continue anyway.

Your last email states that you have no confidence with the
IETF BCP system and outline BCP 84 as an example and talk
about the devaluation of the IETF BCP process.

However, you continue with the concern that we're trying to
pull more operators into the IETF process and "we need a
way for operators to say it would really be awesome if this
would work for us, here is a proposed BCP".

So, to address the more immediate matter first, how do
you go this to a position that opsec-filer-caps should be an
Informational document and not a BCP?  There are operators
here, in OPSEC, saying we think these things are a good
ideas.  The draft has been through 8 iterations and has been
Last Called in both OPSEC and IETF-wide, the process the
IETF employs as a best effort to gauge community consensus.

BCPs are the current avenue by which this should be
accomplished in the IETF.  Simply because you're unhappy
about BCP 84 doesn't mean the IETF process should no
longer be utilized.  I certainly doubt that vendors would prefer
we capture these requirements in a Standards Track AS/PS
document?

Regarding the process in general and your comments about
the IESG devaluing the BCP process with "commentaries" and
the like, I'm certain that over your many years of involvement
you're well aware that the BCP series is not only the IETF's way
of documenting community consensus and recommendations, it
is also the place IETF process and deliberations themselves
are documented.

If you're not happy with the process I suggest you work to
change it.  I know Brian Carpenter currently has a draft published
discussing some updates to RFC 2026, I've provided him some
comments, so to should you.

If we're going "to get operators to participate" here their output
has to be meaningful, which you well know.

-danny