Subject: [Rfced-future] on principles, policies, and approvals

From: Eliot Lear <[email-masked]>
Date: Tue, 16 Nov 2021 10:21:22 +0100

All:

What I am seeing is the following:

  * By any reasonable measure, there is not rough consensus to include
    Mike's proposal.
  * We do not yet have rough consensus to move forward on the document
    without some changes.

Everyone agrees in principle (so to speak) that there may be some 
principles upon which we can find agreement, but that leaves a lot of 
deep-rooted disagreement on some principles and even more deep-rooted 
disagreement about attendant policies, and where and how to do the 
work.  Everyone must recognize that now with an eye towards solutions if 
this effort is to succeed.

There are three aspects to consider:

 1. The principles themselves
 2. The policies tied to principles
 3. The level of approval needed to change (1) and (2)

There is no consensus on each of these points, but they matter more or 
less depending on the interplay.  Let's look at them individually and 
then together:

1.  The Principles Themselves

Contrary to what has been repeatedly claimed, this community *has* 
previously debated these principles in one form or another (please 
review the Spring/Summer 2020 archives), and we stopped when it became 
clear that people had positions that were not going to move.   But there 
are some principles upon which we could possibly find agreement.  For 
instance, nobody has ever said that they said it would be ok to charge 
for RFCs, nor do I think we would find much opposition to the principle 
of accessibility, though there may be some disagreement on how to 
instantiate that principle into detailed policy.

2   The Policies Behind the Principles

Some insist that principles carry with them normative weight and others 
might suffer the principles being there if they were aspirational.  It 
is possible to split those into two groups. There are examples of how 
this as worked in the past.  RFC 2026 lays out goals, which themselves 
really are principles.  They are brief, high level, and non-normative.  
The policies are separate and not linked in any fashion.

3. The level of effort needed to change policies and principles

Some want to require higher levels of approval to change policies and 
priniciples and others see that as far too constraining. Proponents want 
to enshrine principles in order to establish trust in the process.  
Opponents find that if they cannot evolve the process, then the RSWG 
exercise is pointless.

The IAB and IESG have very rarely approved the same RFC.  I think the 
last one was in 2016, and I was the co-author.  Prior to that we have to 
go back to 2005 and RFC 4333.  In that time, the RFC Editor model itself 
was updated three times (2009, 2012, and 2020).  I will point out that 
the approval process for this draft itself is this group and then the 
IAB.  I know of no process that has required the approval of the IAB, 
the IESG, and the LLC.

The Interplay and Options

We have to be realistic.

First, those opposing addition of any principles or policies have to 
recognize that the consensus likely isn't there to move such a draft 
forward.

On the other hand, those supporting inclusion of principles and policies 
should recognize that very few minds have changed over several years.  
We have been debating these matters both here in 2020 and even before 
that point in RFC++.  If the approval bar for changes to principles and 
policies is higher than approval of this document, then the only ones 
one can reasonably expect to see in this document are the ones upon 
which there *already * exists rough consensus.  While that might not be 
particularly satisfying to anyone, it might allow things to proceed.  We 
can poll to determine where that rough consensus lies.

It is also possible to set the approval bar at the same level, agree on 
what we can agree, and then try to resolve differences over time in a 
way that doesn't block other work that likely wouldn't offend anyone's 
principles.  That would mean, practically, RSWG->IAB for such changes, 
and they would have to be documented in a different IAB track RFC.  
Personally I think RSWG->RSAB is a higher bar.  You be the judge.

It might also be possible to state something akin to what is in 2026.   
But that doesn't limit the scope of the RSWG or RSAB.  To some that is a 
benefit and to others a negative.  We could apply some mix of this list 
and some normative policies that have rough consensus.

Finally, the status quo is still possible: we can leave things as they 
are. *This* is the default (by definition).  That would mean that the 
RSOC continues, RFC 8728 remains in force, and the IAB's role would be 
unchanged.  I see this as greater than a 50/50 possibility at this point.

Others may see other possibilities, but those possibilities have to 
respect the reality that there are differences in how people see the 
future / "heritage" of the series.

Eliot