RE: draft-ietf-opsec-filter-caps-08.txt

["Barry Greene \(bgreene\)" <bgreene@cisco.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

My confidence in the IETF's BCP system went out the door with BCP84. 

RFC 3704  was Pekka's expression of operation experience. What worked
for him. What did not. What he would recommend. Fred and I had long
E-mails dialogs as that expression and the "operational
recommendations" where word crafted. The idea was to get the word out
- - Information RFC. Next thing you know, it is a BCP. Why? What was
the logic?

What it demonstrated was that we have a broken "IETF BCP" system. The
consequence is that it devalues the objectives and impact of the
"BCP" status.

As we continue to strive to pull in more operators in the IETF
process, we need a way to dialog with the vast majority of hardware
engineers who do not attend IETF. We need a way for operators to say
"it would be really awesome if this would work for us - here is a
proposed BCP." Then, just like the standards process - the dialectic
of the industry takes use down a path of draft BCP and BCP. That
dialectic will be played out in the marketplace (i.e. RFPs) and
engineering reality (to the physics and engineering allow for the
desired operational behavior to be built).

So yes, I think the industry needs proposed BCP, draft BCP, and BCP -
parallel to the standards track.


But .... Right now I seem to be a lone voice pointing the IESG's
trend of BCP devaluation. Go flip through the BCPs over the last few
years. "Commentaries" and individual engineering design preferences
are blessed as _the_ "best way."


> -----Original Message-----
> From: Ross Callon [mailto:rcallon@juniper.net] 
> Sent: Thursday, June 28, 2007 8:28 AM
> To: Barry Greene (bgreene); gmj@pobox.com; Chris Morrow; Ronald
> Bonica Cc: opsec@ops.ietf.org
> Subject: RE: draft-ietf-opsec-filter-caps-08.txt
> 
> 
> >  Since this is in the working group, work the problem. 
> >  
> >  Submit the document as a "Proposed BCP" status. That is 
> equivalent  
> > to "Proposed Standard."
> 
> Right now the IETF process does not have a status of 
> "proposed BCP". It is not up to the OPSEC working group to 
> decide to change the process and create another status for 
> documents. Of course, if there is consensus that the process 
> *should* have a possible status of "proposed BCP", then this 
> is something that we could propose to the general area of the IETF.
> My understanding is that the IETF Chair (currently Russ 
> Housley) is the "AD" overseeing IETF process issues. 
> 
> I am a bit sympathetic that the BCP series is not really 
> equivalent to the standards track series since we don't have 
> the same three steps for documents. However, I haven't heard 
> a lot of arguments that we need to add more steps to the 
> general process of getting RFCs out (even BCP RFCs), and 
> slowing down the IETF process is not something that I strive for. 
> 
> Barry: Are you seriously proposing that we *should* have a 
> status of "Proposed BCP"? If so, then are two steps 
> sufficient (proposed BCP and BCP), or would you want to have 
> the process completely parallel to the standards track 
> process (Proposed BCP, Draft BCP, and BCP)? 
> 
> Ross

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.1

iQA/AwUBRoPYa7/UEA/xivvmEQKG0wCffnkKK4xdcV8q/M07TDvY1Nacn3UAoO+d
XgHTkiczUfcmLoGNYZvGSkDk
=kkUN
-----END PGP SIGNATURE-----