Subject: Re: [Rfced-future] I-D Action: draft-thomson-rfced-model-01.txt

From: Martin J. Dürst <[email-masked]>
Date: Fri, 4 Sep 2020 16:08:43 +0900

Hello Martin, Brian, others,

Sorry to be very late with a reply on a thread.

On 17/08/2020 10:27, Martin Thomson wrote:
> Hi Brian,
> 
> I'm glad to see that we only disagree on relatively minor points.
> 
> I think that your main points are:

> 2. You are concerned about style guide (and similar) maintenance.  I had imagined that this would follow the usual model for things that are ostensibly developed in working groups.  Those most invested in its maintenance would supply the work, but the product would be discussed and approved by the working group.

I can easily imagine that this could be made to work for an overall 
style guide that is updated once a year or so. But it doesn't work for 
for more day-to-day issues, which I understand come up quite regularly.

Regards,   Martin.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 4 Sep 2020 12:47:17 -0400

From my perspective there is one aspect that makes Martin Thomsom's 
suggestion for using a WG to do the style guide almost workable, and 
several aspects that do not.

The good thing is that we do not update the style guide annually.

The first bad thing is that I have not seen a working group that can 
update a document even bi-annually.

The next problem that occurs to me is that a style guide is often a 
judgement call.  There is not a technical right answer.  But an answer 
is generally needed.  The IETF WG process is consistently very bad at 
that sort of decision.  Witness the mess for almost every process 
decision in the IETF.  And the WG process does not allow the chairs to 
simply declare a conclusion when there is not rough consensus.

Yes, in general we want the RFC series decisions to be responsive to the 
broad community rough consensus.  But we also need a mechanism that 
actually makes informed decisions to drive the publication process.

Yours,
Joel

On 9/4/2020 3:08 AM, Martin J. Dürst wrote:
>> 2. You are concerned about style guide (and similar) maintenance.  I 
>> had imagined that this would follow the usual model for things that 
>> are ostensibly developed in working groups.  Those most invested in 
>> its maintenance would supply the work, but the product would be 
>> discussed and approved by the working group.
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 5 Sep 2020 10:26:26 +1200

Hi Joel,
> update a document even bi-annually.

That's where I believe that a nominated RFC Series Advisor comes in. See
https://tools.ietf.org/html/draft-carpenter-rfced-model-00#section-8
and in particular (emphasis added):

   Further, the RSA is expected to ensure that RSAWG consensus is well
   documented and communicated to the community, the LLC, and the REP.
   *This may include document authorship.*

   The RSA is expected to be a thought leader for improvements to the
   RFC Series, for developing vision and policy documents, and for
   *establishing community consensus for them.*

I would indeed expect the style guide to remain a living document,
as it is today. Given that style guide issues have often been
discussed on [email-masked] (an open list) I don't
even see much of a change in practice here.

> simply declare a conclusion when there is not rough consensus.

On the other hand, they are supposed to facilitate the process.

> actually makes informed decisions to drive the publication process.

Agreed. But on the other hand, we say we don't want monarchs and presidents.

   Brian

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 07 Sep 2020 10:49:56 +1000

> simply declare a conclusion when there is not rough consensus.

Aside from this point about not attaining consensus, I don't see a problem with working groups making decisions.  We routinely make a large number of decisions every week in some working groups.  Most of them might require some debate, but they don't end up in paralysis.  Even for judgment calls.  Paralysis only exists where there are hard constraints or no shared interest in reaching a conclusion (leaving aside for the moment the severe vulnerability of this process to trolling).

But I think that you raise a different point about the relation of style guide to the purpose of the system that we are designing here.  If the goal is to provide strategy, and maintaining a style guide is not entirely strategic decisions, then we need to ensure that the group only provides strategic input.  That is, the process of editing and publication does not depend on the "working group" providing timely decisions.

I had envisaged an ownership model that is less direct.  That is, the RPC (or whatever they are called) would be empowered to exercise judgment in tactical matters, such as in the example Jay raised.  They would own the style guide in the same way that a document editor might own a working group document.  They then effectively are proposing changes to the group, based on their own "running code": the practices they actively follow.

If the group wants to debate the strategic merit of RPC decisions, that is fine, but the RPC needs to keep the lights on, so once a strategic direction is agreed, I would expect them to eventually move to follow that.  Any inconsistencies between practice and direction might then need to be resolved.  My expectation is that the RPC will make sensible decisions and any eventual strategic decision will rarely be incompatible with practice.  True conflicts between direction and practice can be negotiated as part of contracts, by the LLC.  (That isn't always a failure of strategic direction, as some elements of strategic direction might affect contract terms in material ways, such as those that affect the cost of providing the service.)

This general split between tactical needs and strategic direction is something that I've observed to cause problems with xml2rfc development as well.  The goal there was to run design decisions through a "working group".  But that turned out to be unworkable, slow, and fraught with conflict.  What we have now is the code (or practice) leading the standardization (or formalization) effort.  That's now at the point where I'm uncomfortable with the openness of that process and the extent to which it is responsive to the community.  But we have a chance to learn from that process here.

---

From: "John Levine" <[email-masked]>
Date: 6 Sep 2020 21:13:07 -0400

In article <[email-masked]> you write:
>Aside from this point about not attaining consensus, I don't see a problem with working groups making decisions.

FYi, the RPC asks me to make small style decisions all the time. These
are on the order of whether some chunk of text looks more like artwork
or a snippet of source code, or what's the best way to handle nested
quoted text in some context. The answers to these are mostly
arbitrary, and it is more important that they be answered consistently
than that any individual decision be made one way or the other.

If this sort of stuff were pushed up to WGs it would not be a good use
of WG time, and if different questions were pushed to different WGs,
we'd get different answers which would make the series look worse.
It's not a bad idea to have one person whose job is to think about
this stuff in the context of the whole RFC series, not individual
documents.

R's,
John