[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-ietf-opsec-filter-caps-08.txt
Folks,
It appears that we have two issues on the table. These are:
1) should draft-ietf-opsec-filter-caps-08 be progressed as BCP or
INFORMATONAL?
2) should the IETF process be changed to support a PROPOSED BCP
I think that two questions are orthogonal to one another.
In the short term, we need to make a decision wrt the first question,
guided by RFC 2026, as it exists today. This discussion should continue
on the OPSEC mailing list.
In the longer term, we need to make a decision wrt the second question.
Because this decision impacts people outside of the OPSEC working group,
we should probably continue that thread under a new subject header on
the OPS-AREA mailing list.
thanks,
Ron
Barry Greene (bgreene) wrote:
>
> 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
>
>