Re: [Rfcplusplus] IRTF stream considerations

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

On 12/07/2018 17:09, Adam Roach wrote:
> On 7/11/18 10:54 PM, Brian E Carpenter wrote:
>> On 12/07/2018 15:37, Adam Roach wrote:
>> ...
>>> The RFC format work was an IETF BOF too [1] (three, actually), and those
>>> specific BOFs resulted in input that went well beyond impacts on the
>>> IETF stream. I believe your original statement about the scope of
>>> discussions that can take place in such a venue is more refuted than
>>> supported by the precedent you cite.
>> There's a real difference, in my opinion, in that the definition of
>> the streams was a codification of existing practice, and the format
>> update was something people have been requesting for many years.
>> Neither of them showed any signs of being fundamentally contentious.
> 
> Your understanding of the potential, in the IETF 83 timeframe, for 
> controversy around the RFC format change is completely different than 
> mine. I recall the issue coming up repeatedly at plenaries and in 
> hallways with well more than a hint of contention surrounding it.
> 
> We are free to disagree on our recollections here, of course, but if you 
> check the minutes for the administrative plenary at IETF 79 -- a scant 
> four meetings before the RFCFORM BOF -- Stewart Bryant used the phrase 
> "this is a controversial subject" to describe this exact topic. The 
> benefit of time between now and then may make it seem far less so in 
> 2018, but that has little bearing on the fact that it *was* expected to 
> be controversial by many at the time.

The details, for sure, and I am 100% certain that when the new format and
its tools are released there will be much noise too. But I really see this
as a fundamentally different type of controversy and proposed change. If
you don't agree, we'd better agree to differ.

>> This time, we've seen a much more radical proposal which, if carried
>> forward, would fundamentally change the series. In that case you can't
>> duck the question of authority and who calls consensus.
> 
> It feels like you're trying to move the goalposts. Your original 
> statement was that this is "an IETF BOF and that limits its direct input 
> to IESG decision making." If I carefully parse what you've written 
> above, it seems that you want to amend that to only apply when some 
> (potentially small) subset of the IETF population thinks it won't be 
> contentious, but that doesn't seem quantifiable enough to be a rule.

No, I'm not trying to move goalposts (although where they are is still
unclear to me). I'm trying to say that the IETF, and its leadership,
if they reach a consensus that changes *non-IETF* usage of the RFC series,
simply can't impose that. What the IETF could do, if such was the consensus,
is take that consensus to the rest of the RFC-producing community and ask
whether they agree, or have modifications to propose, or disagree totally.

It seems to me that the goal posts for reaching consensus in the IETF
are fairly well known, and some of us will end up in the rough as always.
But for the RFC-producing community as whole, I currently have no idea
where the goal posts are. To quote my draft "How to reach out to this
community is in itself a big question."

Regards
    Brian