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 >> > >
