Re: Evolving Documents (nee "Living Documents") side meeting at IETF105.)

[Brian E Carpenter <[e-mail]>]

On 19-Jul-19 16:56, Joel M. Halpern wrote:
> Responding here both to Job and to Chris Morrow.
> 
> There is indeed an argument that operational guidance has the dual 
> properties of
> 1) needing to be out promptly
> 2) changing over time as the operational environment changes.

How long does RIPE take to produce a BCOP?
See https://www.ripe.net/publications/docs/ripe-690#2--what-is-a-bcop-

   Brian

> 
> I do realize that Job's initial motivation for this was specifically 
> operational.  But most of the discussion has not seemed to be restricted 
> to that.  I do know that various people have asked for much more dynamic 
> protocol specs.  And some of the examples cited have been protocol 
> specs.  That is what makes me nervous.
> 
> If the focus is operational documents, there ought to be a way to do 
> something, and it ought to be worth a try.  Finding ways for the IETF to 
> be more useful to operators, and for operators to be able to participate 
> in a fashion taht is more eff3ective for what they need, does seem 
> valuable.  And with the restriction, many of my concerns do not apply. 
> (We do, for example, allow the contents of a BCP to change even though 
> the underlying individual RFCs are immutable.  While this is aimed to be 
> much faster, it seems related.)
> 
> Yours,
> Joel
> 
> On 7/19/2019 12:14 AM, Job Snijders wrote:
>> On Thu, Jul 18, 2019 at 11:58:06PM -0400, Joel M. Halpern wrote:
>>> (Supporting Keith on this.)
>>>
>>> One of the key benefits of IETF meetings is cross-area review.  One of
>>> the key reasons for having WG last call is the observed need for
>>> review outside the working group.  One of the observation from many
>>> such reviews is that it is amazing how much a working group can miss
>>> while getting its core stuff right.  Yes, this also means that
>>> periodically folks raise objections that are spurious, miss the point,
>>> or have been addressed already.  But the cost of not having the review
>>> is VErY high.
>>>
>>> Yes, folks have suggested that the review should be lightened or
>>> eliminated.  So far, the community has refused to do that.  And I for
>>> one am very glad that is so.  In spite of having had to deal with some
>>> frustrating objections in many cases.
>>
>> Joel,
>>
>> My take on it is that the context of this conversation is not protocol
>> specifications or extensions, but operational guidance. What some in
>> this thread are advocating for is a pathway to publish an equivalent of
>> BCPs in a shorter timeframe than 12 to 36 months.
>>
>> Kind regards,
>>
>> Job
>>
> 
>