Subject: [Rfced-future] Principles / policies proposal

From: Eliot Lear <[email-masked]>
Date: Mon, 15 Nov 2021 17:58:34 +0100

Dear Colleagues,

The chairs have been following the vibrant discussion regarding the 
proposal that Mike put forth on principles of the RFC series.  We see, 
roughly speaking, two groups of individuals: those who want governing 
policies in the draft now, and those who would rather see this 
discussion moved to the RSWG.

All of us in this group are veterans.  We have all chaired working 
groups and been in other leadership positions, and by and large we know 
one another.  With this in mind, we have a question:

Do you believe that we will reach consensus to include Mike’s proposal 
or similar?

If you answer yes to this question, are you willing to move off of your 
views to find common ground with those who hold different perspectives?

Brian and Eliot

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 15 Nov 2021 17:01:22 +0000

FWIW, I do not know if we will achieve consensus, but I am backing out of this conversation since I do not have any new points to make, and I will not object to any consensus calls that are made.

---

From: Michael StJohns <[email-masked]>
Date: Mon, 15 Nov 2021 13:08:09 -0500

On 11/15/2021 11:58 AM, Eliot Lear wrote:
> groups and been in other leadership positions, and by and large we 
> know one another.  With this in mind, we have a question:
>
>
As I pointed out in another email, and a point this email skips over, 
there is also the question: Do you believe that we will reach consensus 
to exclude Mike's proposal or similar?

Which if the process is fair needs to be an absolute dual to the first 
question.

So let me answer the neutral question not the one you asked:  I believe 
we will achieve rough consensus (but not consensus - rough consensus 
being lesser of consensus and with the possibility of remaining 
opposition) on how to proceed.  I doubt that it will be an easy 
discussion. I don't know what that decision will be, nor am I willing to 
constrain the time period for achieving the decision, nor to treat one 
position as superior to the other at the beginning of the discussion.

>
> If you answer yes to this question, are you willing to move off of 
> your views to find common ground with those who hold different 
> perspectives?
>
This question really makes little sense in conjunction with your first 
one.  If I say, yes we'll achieve consensus to include principles text, 
I would expect the next discussion is on the views and where they 
differ.    If you say no, then we don't even ask if you're willing to 
attempt to make common ground?

You have emails that you've received that have fairly hardened positions 
on both sides.  I would submit a willingness to move from views has not 
necessarily been a common strategy for most members of this group.

---

From: John C Klensin <[email-masked]>
Date: Mon, 15 Nov 2021 15:07:20 -0500

--On Monday, November 15, 2021 17:58 +0100 Eliot Lear
<[email-masked]> wrote:

> Dear Colleagues,
> 
> 
> The chairs have been following the vibrant discussion
> regarding the proposal that Mike put forth on principles of
> the RFC series.  We see, roughly speaking, two groups of
> individuals: those who want governing policies in the draft
> now, and those who would rather see this discussion moved to
> the RSWG.
> 
> 
> All of us in this group are veterans.  We have all chaired
> working groups and been in other leadership positions, and by
> and large we know one another.  With this in mind, we have a
> question:
> 
> 
> Do you believe that we will reach consensus to include
> Mike's proposal or similar?
> 
> 
> If you answer yes to this question, are you willing to move
> off of your views to find common ground with those who hold
> different perspectives?

Eliot,

First, yes, but only if the requirement is for no more than
rough consensus and only if the chairs do not take the position
that not addressing this topic is somehow a default that somehow
has to be overcome by strong positions and agreement.  There
cannot be a default for any decision this group reaches unless
that default is to preserve the status quo ante, discard all of
the new ideas and mechanisms, and stick, more or less, to RFC
Editor Model version 2 (oral tradition and all)... and I believe
there is more than rough consensus to not do that.

I also think there is a further distinction to be made than the
one you cite above: I see two sets of positions among those who
do not want some set of principles in the draft.  One is opposed
because they think it is the wrong thing to do and would be the
wrong thing to do even if we could magically agree on the
principles and the text well before the end of the week.  The
others think it would be just too hard and not worth the delay.
I have also seen several statements that appear to me to be
strawmen or close to it, e.g., that any such text in the draft
would prevent the RSWG/RSAB and the process specified in the
draft from making changes, ever.  Let's not confuse those
positions and let's not try to get an answer by creating
unreasonable procedural barriers to one of the outcomes.

    john

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 16 Nov 2021 09:24:22 +1300

On 16-Nov-21 05:58, Eliot Lear wrote:
> Dear Colleagues,
> 
> 
> The chairs have been following the vibrant discussion regarding the proposal that Mike put forth on principles of the RFC series.  We see, roughly speaking, two groups of individuals: those who want governing policies in the draft now, and those who would rather see this discussion moved to the RSWG.
> 
> 
groups and been in other leadership positions, and by and large we know one another.  With this in mind, we have a question:
> 
> 
> Do you believe that we will reach consensus to include Mike’s proposal or similar?

Assuming you mean rough consensus, probably yes, but on what timescale?

As long as it's clear that the text is subject to later change by the RSWG/RSAB process, I'd be OK with being in the rough.

   Brian C

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 15 Nov 2021 21:14:12 +0000

Hiya,

As others noted the questions below seem fairly biased
towards not working on text on this topic. I'm sure as
chairs you were trying to figure a fair way to cut a
Gordian knot but I don't think the result is nearly as
good as I guess you hoped.

But nonetheless...

> Do you believe that we will reach consensus to include Mike’s proposal 

Yes. Mostly because I do think almost all of us actually have
a pretty closely aligned set of views of the heritage of the
RFC series, and/or of basic principles.

If people are in argumentative mode, or very fearful of
ceding ground, establishing rough consensus on text may be
tricky though. But I do think such text is needed, as already
stated, and the discussion may even lance some boils if we
approach it with open minds.

> views to find common ground with those who hold different perspectives?

Yes. (I'll be quite surprised if any answer to this question
is illuminating;-)

S.

---

From: Jay Daley <[email-masked]>
Date: Tue, 16 Nov 2021 10:31:32 +1300

Eliot

> On 16/11/2021, at 5:58 AM, Eliot Lear <[email-masked]> wrote:
> 
> Dear Colleagues,
> 
> All of us in this group are veterans.  We have all chaired working groups and been in other leadership positions, and by and large we know one another.  With this in mind, we have a question:
> 

As a reminder, Mike’s proposal contained both principles and policy about how those principles could be changed.  Tackling those two parts separately might increase the chances of consensus being reached on at least one of the two.

Jay

> 
> If you answer yes to this question, are you willing to move off of your views to find common ground with those who hold different perspectives?
> 
> Brian and Eliot
> 
> <OpenPGP_0x87B66B46D9D27A33.asc>-- 
> Rfced-future mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/rfced-future

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: Michael StJohns <[email-masked]>
Date: Mon, 15 Nov 2021 16:43:38 -0500

On 11/15/2021 3:24 PM, Brian E Carpenter wrote:
>
> As long as it's clear that the text is subject to later change by the 
> RSWG/RSAB process, I'd be OK with being in the rough. 

Hi Brian -

Can I ask you to clarify here?  The text I wrote allows for changes via 
the RSWG/RSAB process, but requires additional approvals from the 
IAB/IESG/LLC and community support (e.g. the same level of approval that 
this first document will require). Did you mean that, or did you mean 
the process we're defining in this document.  If the latter, what's to 
keep the RSWG/RSAB from wiping out this section with its first 
publication except good will or loud voices?  Especially since we seem 
to still be arguing about the conditions in which the RSAB may say no.

Thanks - Mike

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 15 Nov 2021 14:54:43 -0700

> to still be arguing about the conditions in which the RSAB may say no.

Section 6 of our document states:

    The Editorial Stream will be used only to specify and update
    policies, procedures, guidelies, rules, and related information
    regarding the RFC Series as a whole; no other use of the Editorial
    Stream is authorized by this memo and no other streams are so
    authorized.  This policy may be changed only by agreement of the IAB,
    IESG, and IETF LLC.

It seems that you would suggest adding something like this:

    Changes to the RFC Editor Model itself (either updating or obsoleting
    this document) can be made only by agreement of the IAB, IESG, and
    IETF LLC.

Is that correct?

Peter

---

From: Michael StJohns <[email-masked]>
Date: Mon, 15 Nov 2021 17:03:46 -0500

On 11/15/2021 4:54 PM, Peter Saint-Andre wrote:
>>> As long as it's clear that the text is subject to later change by 
>>> the RSWG/RSAB process, I'd be OK with being in the rough. 
>>
>> Hi Brian -
>>
>> Can I ask you to clarify here?  The text I wrote allows for changes 
>> via the RSWG/RSAB process, but requires additional approvals from the 
>> IAB/IESG/LLC and community support (e.g. the same level of approval 
>> that this first document will require). Did you mean that, or did you 
>> mean the process we're defining in this document.  If the latter, 
>> what's to keep the RSWG/RSAB from wiping out this section with its 
>> first publication except good will or loud voices?  Especially since 
>> we seem to still be arguing about the conditions in which the RSAB 
>> may say no.
>

I know discussion (or at least one email) has been going on for 
inclusion of similar text (and I support the text you've crafted above) 
and if we get consensus on that text, then the *set* of principles 
doesn't need similar approval text (e.g. in the header).   Some of the 
items within the set may need some tagging as to which are tangible 
things that can't be changed absent model change approval (maybe related 
to Jays Principles vs Policies).

I included similar language in the principles text as I wasn't sure what 
the final result would be on that discussion, and figured it was either 
critical or just editorial depending on where we came down on the Model 
modification process.

In any event, clarification from Brian on what he meant by "subject to 
later change by the RSWG/RSAB process" would be helpful as a checkpoint.

Thanks, Mike

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 16 Nov 2021 11:10:08 +1300

> to still be arguing about the conditions in which the RSAB may say no.

I believe that the RSWG/RSAB model does require community support and
rough consensus for changes, so personally I do not see a need for
additional checks and balances.

(From a broader perspective, I'm also anxious to see fewer extraneous
responsibilities piled on the IESG and IAB, since they detract from
their ability to perform their main roles.)

     Brian

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 15 Nov 2021 15:30:06 -0700

> critical or just editorial depending on where we came down on the Model 

As I see it, the document as we have it right now (modulo editorial 
fixes and leaving aside for the moment the question of adding text about 
principles) defines version 3 of the RFC Editor Model - that is, the 
operational framework for moving forward with management of the Series 
and for publishing policy documents in the Editorial Stream (but not for 
publishing documents that redefine the Model itself). Therefore, text 
along the foregoing lines seems appropriate to me.

Peter

---

From: Eliot Lear <[email-masked]>
Date: Tue, 16 Nov 2021 00:14:40 +0100

On 15.11.21 23:30, Peter Saint-Andre wrote:
>> inclusion of similar text (and I support the text you've crafted 
>> above) and if we get consensus on that text, then the *set* of 
>> principles doesn't need similar approval text (e.g. in the header).   
>> Some of the items within the set may need some tagging as to which 
>> are tangible things that can't be changed absent model change 
>> approval (maybe related to Jays Principles vs Policies).
>>
>> I included similar language in the principles text as I wasn't sure 
>> what the final result would be on that discussion, and figured it was 
>> either critical or just editorial depending on where we came down on 
>> the Model modification process.
>
> fixes and leaving aside for the moment the question of adding text 
> about principles) defines version 3 of the RFC Editor Model - that is, 
> the operational framework for moving forward with management of the 
> Series and for publishing policy documents in the Editorial Stream 
> (but not for publishing documents that redefine the Model itself). 
> Therefore, text along the foregoing lines seems appropriate to me.
>
That text has become central to the dispute at hand.

Eliot

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 15 Nov 2021 23:33:57 +0000

Hi Eliot,

> That text has become central to the dispute at hand.

IMO: yes and no.

Yes: I do agree Peter's suggested addition is good and needed
and, as I think Mike said, could make his proposed text a lot
shorter. So yeah "central" is fair in that respect.

No: documenting what's required for a model-change is not the
same as providing principles to help guide the RSWG operating
within what'll be the new model. So no, "central" isn't quite
right in that respect.

The "yes" part of the above does seem like a thing this group
could "bank" which'd be a good thing. My guess though is that
neither that nor any other purely bureaucratic move will take
the "no" part above off the table really.

Cheers,
S.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 16 Nov 2021 10:34:41 +1100

These are somewhat odd questions, but...

> On 16 Nov 2021, at 3:58 am, Eliot Lear <[email-masked]> wrote:
> 

I suspect not, for a few reasons:

* Scope: Defining principles is more rightly in-scope for the RSWG, not this group. We were chartered to delivery a process for creating policy, not the policies themselves. I'd argue that principles informing policy are more closely associated with the RSWG.

* Oversight/accountability: The RSWG has a well-defined appeal and oversight chain; this body does not, given that the IAB is in an extremely delicate situation regarding this group's operation. Given that this is obviously contentious, holding the discussion in a more robust forum seems prudent.

* Delivery timelines: Embarking upon this further prolongs our period without a consultant and without a strategy function. It's uncertain how long it will take to both establish consensus on Mike's proposals, and to assure ourselves that there aren't any other principles worth documenting. 

I've seen a few people argue that it's imperative that these principles be documented as part of the model. Given that the RFC Series has survived for so long without such documentation, I don't find those arguments convincing. I also fail to see why folks think it's so important to include these in the model, given that presumably they'll be participating in the RSWG as well.

We *might* be able to reach consensus to define principles in a separate document (without the higher bar to changes), and perhaps refer to that informatively; that would allow us to ship the model. However, I don't really see the merit in doing that over just taking it to the RSWG.

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 15 Nov 2021 16:08:05 -0800

I roughly agree with mnot here.

I would add in addition that it should not be a surprise that we have
differences of opinion about the best way for the series to evolve. I had
understood the purpose of the work we have been doing to create a venue in
which (1) we could make progress despite those differences on areas where
there was agreement and (2)  some of those differences could be discussed
and hopefully via resolved (via rough consensus). Attempting instead to
resolve those issues prior to that structure being created seems like the
wrong order of operations.

-Ekr

On Mon, Nov 15, 2021 at 3:34 PM Mark Nottingham <[email-masked]> wrote:

> * Scope: Defining principles is more rightly in-scope for the RSWG, not
> this group. We were chartered to delivery a process for creating policy,
> not the policies themselves. I'd argue that principles informing policy are
> more closely associated with the RSWG.
>
> * Oversight/accountability: The RSWG has a well-defined appeal and
> oversight chain; this body does not, given that the IAB is in an extremely
> delicate situation regarding this group's operation. Given that this is
> obviously contentious, holding the discussion in a more robust forum seems
> prudent.
>
> * Delivery timelines: Embarking upon this further prolongs our period
> without a consultant and without a strategy function. It's uncertain how
> long it will take to both establish consensus on Mike's proposals, and to
> assure ourselves that there aren't any other principles worth documenting.
>
> I've seen a few people argue that it's imperative that these principles be
> documented as part of the model. Given that the RFC Series has survived for
> so long without such documentation, I don't find those arguments
> convincing. I also fail to see why folks think it's so important to include
> these in the model, given that presumably they'll be participating in the
> RSWG as well.
>
> We *might* be able to reach consensus to define principles in a separate
> document (without the higher bar to changes), and perhaps refer to that
> informatively; that would allow us to ship the model. However, I don't
> really see the merit in doing that over just taking it to the RSWG.
>
> Cheers,
>
> --

---

From: Eliot Lear <[email-masked]>
Date: Tue, 16 Nov 2021 01:26:20 +0100

Stephen,

I'm struggling to understand your point.  Please see below.

> within what'll be the new model. So no, "central" isn't quite

It's this "no" part about which I have some confusion.  Can you expand 
on what you have in mind?

Eliot

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 16 Nov 2021 00:55:10 +0000

Hiya,

> on what you have in mind?

Sure, I can try:-)

ISTM that Peter's sensible text about approval for changes to
the new model is ok. But only having that text won't help the
RSWG so much.

To the extent that differences in opinion on the principles
underlying the series exist(*) we're going to have to thrash
those out sometime to really understand the well-intended,
well-informed, but sometimes conflicting opinions that exist
and here and now seems to me like maybe the best time to do
that, so that the RSWG can then make progress under the new
model without having to re-litigate the model itself over
and over.

Cheers,
S.

(*) Again, I think when we do get into that debate, I bet
we'll find we're more in agreement than may seem to be the
case.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 16 Nov 2021 14:21:48 +1300

Note the narrowed subject header.

>>> On 11/15/21 2:43 PM, Michael StJohns wrote:
...
> along the foregoing lines seems appropriate to me.

Fair enough, but then:
(a) Why are the Editorial, IRTF and Independent streams not required to agree?
(b) The LLC needs a right to "[No] Objection", but as a servant of the
community, I don't think they are called upon to "agree".

    Brian

---

From: John C Klensin <[email-masked]>
Date: Mon, 15 Nov 2021 20:26:37 -0500

--On Tuesday, November 16, 2021 11:10 +1300 Brian E Carpenter
<[email-masked]> wrote:

>> Can I ask you to clarify here?  The text I wrote allows for
>> changes via the RSWG/RSAB process, but requires additional
>> approvals from the IAB/IESG/LLC and community support (e.g.
>> the same level of approval that this first document will
>> require). Did you mean that, or did you mean the process
>> we're defining in this document.  If the latter, what's to
>> publication except good will or loud voices?  Especially
>> since we seem to still be arguing about the conditions in
>> which the RSAB may say no.
 
> I believe that the RSWG/RSAB model does require community
> support and rough consensus for changes, so personally I do
> not see a need for additional checks and balances.
 
> (From a broader perspective, I'm also anxious to see fewer
> extraneous responsibilities piled on the IESG and IAB, since
> they detract from their ability to perform their main roles.)

Brian,
(definitely not speaking for anyone else here)

Because I agree with much of what you say above as principles,
let me explain my perspective to try to understand what we
disagree about.  In reverse order:

* I strongly agree about not piling extraneous, or any avoidable
extra, responsibilities on the IESG.  For the IAB, "extraneous"
is a bit complicated because, while the IESG's primary
responsibilities are toward the IETF, the IAB has always [1] had
responsibilities for and to the broader Internet community.
That makes the boundary for "extraneous", at best, a little bit
fuzzy.  I hope your charter draft reflects that broader
responsibility.  If it does not, we should have a discussion in
that context.

* We (both in the work of this Program and more generally) have
often used the term "community" and followed it with a good deal
of handwaving.  I even recall that we had a lengthy discussion
about how to reach out to, and reflect the needs and opinions
of, a community that included direct and indirect users of the
RFC Series, not just the extended IETF community.    That
discussion seems to have fizzled out and been dropped: as I read
draft-iab-rfcefdp-rfced-model-05, I can see no uses of that term
that imply reaching well beyond the types of people
participating in this effort.

Now, against that backdrop, I have a prediction about the RSWG,
one that is extrapolated from IETF WGs (especially long-lived
ones): once things settle down, the active participants will be
those who have strong opinions about the RFC Series, special
commitments to it, or have particular axes to grind: not only
not representative of "the community" but even less
representative than this group.   Most likely still ok for
routine work with the RSAB as sanity-checker.  But I am
concerned about identifying the non-routine, the things for
which we'd want at least as broad representation as this Program
effort.  My goal for that part of the process may be different
from Mike's but I want to identify proposals that would
represent significant changes of direction and require an extra
(and broader) level of scrutiny.  As long as the triggering
mechanism is clear, I care less about whether we do it by
dragging in more organizations, making special announcements and
extra-intense calls for community review and input, or doing a
special, attention-getting, ritual dance during plenaries.  Or
something else.

Does that make any sense?

    john

[1] As I understand it, going back to "Dave Clark, IAB Chair and
Internet Architect" and definitely an issue POISED did not
address in rearranging responsibilities.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 16 Nov 2021 15:18:36 +1300

Front posting: I agree. Maybe I have too much faith that the
Last Calls for the Editorial stream will be effective. Logic:
RFC issues are ones that anybody can have an opinion about,
unlike narrow technical issues where the "community" is
intrinsically subdivided and Last Calls are often no-ops.

For the record, I'll go with whatever our co-chairs deem to
be rough consensus.

One inserted comment below.

Regards
    Brian

> responsibility.  If it does not, we should have a discussion in

The new sentence in draft-carpenter-rfced-iab-charter-02 is
"The RFC Editor function is defined under the authority of the
  IAB by <xref target="I-D.iab-rfcefdp-rfced-model"/>"

---

From: "StJohns, Michael" <[email-masked]>
Date: Mon, 15 Nov 2021 21:18:52 -0500

Below

> community, I don't think they are called upon to "agree".

I thought this would be obvious, but the IESG, IAB, and LLC board (and I
mostly mean board where I say LLC) have community proposed and confirmed
memberships.   Neither ISE or the IRTF share that characteristic, and this
is not about the streams, but about the model.

The IAB, IESG, and the LLC (board) are all servants of the community, or at
least are expected to act in the best interest of the community.  With
respect to that characteristic, I see little difference between the three
groups.  The LLC also has fiscal reality it needs to measure against what
this new model or tweaks to it might inflict making it useful for the LLC
board to weigh in, even if it’s a this looks good, we trust you.

Later, Mike

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 16 Nov 2021 18:07:41 +1100

On Tue, Nov 16, 2021, at 12:26, John C Klensin wrote in a thread entitled "Re: [Rfced-future] Principles / policies proposal":
> [...] I want to identify proposals that would
> (and broader) level of scrutiny.

This gets to the crux of my opposition to this proposal.

Mike proposed an elevated process for changes that crossed certain lines.  

Maybe it seems reasonable to invoke some extraordinary process if someone wanted to: 
* eliminate the IAB stream
* abolish April 1 RFCs
* stop publishing YANG in RFCs (back to MIBs folks)
* outlaw Security Considerations sections
* stop publishing affiliations for authors
* publish in Maori rather than English (or even as well as)
* some other controversial thing

But I don't know if there is much, if anything, left for the RSWG to do if we proscribe its remit so precisely.  What subjects are both worth the time and effort required to run the RSWG/RSAB process and RFC publication, but do not directly address these principles?  

There are a few things perhaps, but even those are guided by principles and might require amending them. Our choice to allow Unicode under certain constraints required that we address a bunch of things here: software, fonts, language, accessibility. It was perhaps consistent with what Mike wrote, but would that be true for a proposal written prior to RFC 799x work?

I'm not sure that I agree with all of the principles Mike proposed, but I certainly don't agree that we need a bigger process if we want to revise them.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 16 Nov 2021 10:10:19 -0500

If there was not a lot more to do, we would not have had an RSE with 
enough authority that other folks became uncomfortable with that.  And 
she did not do anything to cross any of the lines Mike laid out.

I try hard not to read into other people's statements.  But I am left 
with the impression that there must be some set of principles in Mike's 
list that a number of folks here really want the ability to change.  If 
so, would people please state them?

Yours,
Joel

---

From: Martin J. Dürst <[email-masked]>
Date: Wed, 17 Nov 2021 19:08:19 +0900

Hello everybody,

[inline, various places]

> so, would people please state them?

It would indeed be good to have this.

>> On Tue, Nov 16, 2021, at 12:26, John C Klensin wrote in a thread 
>> entitled "Re: [Rfced-future] Principles / policies proposal":

These are all good examples, even if they are (on purpose, I know) a bit 
extreme.

[The mention of April fool's RFCs also leads to the question of what 
stream they will be published in. Maybe worth an issue, maybe not.]

What I'm not sure is why terms such as "extraordinary process" or 
"extremely hard to change" are used. If the changes are indeed what the 
community wants, then it should be not too difficult to get the IESG, 
the IAB, and the LLC Board (in the texts we have, we should make it 
clear it's the Board, not just write LLC) to sign off on them. (I'm not 
married to the specifics, it could be just two of these, or some other 
combination

>> But I don't know if there is much, if anything, left for the RSWG to 
>> do if we proscribe its remit so precisely.  What subjects are both 
>> worth the time and effort required to run the RSWG/RSAB process and 
>> RFC publication, but do not directly address these principles?

Well, the RSWG is still the place where the actual work gets done. 
I think nobody is saying that the principles cannot be changed at all. 
But if they need to be changed, there are some details to be worked out. 
The example of non-ASCII text is a good one, see more below.

My favorite example for something that doesn't touch the principles (if 
done right), but definitely needs some work (to do it right) would be 
"provide a way to integrate errata into RFCs".

>> There are a few things perhaps, but even those are guided by 
>> principles and might require amending them. Our choice to allow 
>> Unicode under certain constraints required that we address a bunch of 
>> things here: software, fonts, language, accessibility. It was perhaps 
>> consistent with what Mike wrote, but would that be true for a proposal 
>> written prior to RFC 799x work?

Very good question. I think this example is a very good test for our new 
process. I can very well imagine that before that work, the principles 
might have included something like "RFCs are written in US-ASCII with 
lines no longer than 72 characters,... for readability on the widest 
range of devices.".

Now, would it make sense in that case to have had a somewhat more 
extensive approval process to change this? I guess yes. The RSWG would 
have to do most of the work of deciding under which conditions and in 
which places what non-ASCII characters would be allowed, at least to the 
extent that it could convince the community that the resulting RFCs 
would be an improvement over the status quo (e.g. because they brought 
us close to publication standards e.g. in the IEEE or the ACM, and 
allowed to use actual characters in examples where these characters were 
used).

Ideally, this wouldn't come as a complete surprise for the IESG/IAB/LLC 
Board. If their representatives on the RSAB reported "back home" often 
enough, it could be more like a slam dunk.

>> I'm not sure that I agree with all of the principles Mike proposed, 
>> but I certainly don't agree that we need a bigger process if we want 
>> to revise them.

Even if we end up not having a process with somewhat higher procedural 
hurdles, it should be very clear that changing e.g. the name of an XML 
element (if that every rises to the level of policy and an RFC) would 
need much less scrutiny than e.g. the change from RFCs to "living 
standards". For the later, without very significant buy-in from the 
wider community, including their representatives in the IAB and the 
IESG,..., it would be a very bad idea. If that buy-in exists, the 
process shouldn't be the problem.

Regards,    Martin.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 17 Nov 2021 05:30:05 -0800

> married to the specifics, it could be just two of these, or some other

Be that as it may, Mike's document proposes a different process than
for the RSWG documents in general. If it's not intended to be more
difficult, then why not just have the regular process?

-Ekr

---

From: "StJohns, Michael" <[email-masked]>
Date: Wed, 17 Nov 2021 11:27:36 -0500

Hi EKR - maybe before we get to your question, an answer to Joel’s might be
in order first?

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 17 Nov 2021 08:50:20 -0800

> On Nov 16, 2021, at 7:10 AM, Joel M. Halpern <[email-masked]> wrote:
> 
> If there was not a lot more to do, we would not have had an RSE with enough authority that other folks became uncomfortable with that.  And she did not do anything to cross any of the lines Mike laid out.
> 
> I try hard not to read into other people's statements.  But I am left with the impression that there must be some set of principles in Mike's list that a number of folks here really want the ability to change.  If so, would people please state them?

I’m not sure that there’s as much a desire to change particular items, but rather confusion about why there needs to be “special” principles that require an elevated process beyond the RSWG process.

Perhaps it would be helpful to ask the question the other way: what on the enumerated list are people concerned about changing, so much that even if the RSWG process decided to change it, it should have some higher bar? If there is some time, in 20 years, in which the community (via the RSWG) decides that for some reason it is indeed appropriate to change something that falls into this list of principles, what is insufficient about the process that has been defined already?

I would suggest that if there are things people are very concerned about changing, there is both the RSAB approval and an appeals process built into the new model. If that is good enough for the concerns we can’t anticipate now, then why do some of the concerns that people have today in this group need to have a different process?

Best,
Tommy

---

From: Joel Halpern Direct <[email-masked]>
Date: Wed, 17 Nov 2021 12:06:19 -0500

First, as I read what we have agreed to:
We have very tightly constrained both the RSAB refusal limits and the 
appeals process.   Thus, as far as I can tell, those are almost 
irrelevant for keeping the RSWG from changing its core principles.  For 
example, if the RSWG suddenly decided the series was not archival, that 
would do not short term harm to any stream.  The harm would be to a much 
larger picture.  But the RSAB would not have grounds to object.

Then, my take on why we need a higher bar.  I don't know if the other 
proponents see other (maybe stronger) reasons:

Basically, as we have structured things, the presumption is that the 
RSWG is doing the right thing, and it would take significantly community 
objection to block something.  That is what we seem to want, and for 
most things, I can live with that.

For changing the basic principles, the bar it seems to me needs to be on 
the other side.  The RSWG needs to make the case to the IAB and IESG 
that there is a good reason for making the change.  And, I hope, the 
community has to agree.

Otherwise, any time the RSWG gets to discussing any interesting change 
(and I presume it will) we will immediately regress to arguing about the 
unresolved issue of principles.  And it will get resolved based on who 
has more staying power in the RSWG.  Really?

Yours,
Joel

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 17 Nov 2021 09:27:25 -0800

> larger picture.  But the RSAB would not have grounds to object.

I'm surprised to hear you say that. S 3.2.2. lists two reasons why an RSAB
member can file a concern:

   o  The proposal represents a serious problem for the group a
      particular member represents.

   o  The member believes that the proposal would cause serious harm to
      the overall series, including harm to the long term health and
      viability of the series.

https://intarchboard.github.io/program-rfced-future/draft-iab-rfcefdp-rfced-model.html#section-3.2.2

I would generally think this would give the RSAB plenty of room to object to
a change in this area.

With that said, I don't find the term "archival" particularly informative
here, as it seems to
mean different things to different people. It might be useful for people
who think there
is an important principle here to try map out in more detail what the
operational implications
of "archival" are.

-Ekr

---

From: John C Klensin <[email-masked]>
Date: Wed, 17 Nov 2021 15:15:34 -0500

--On Wednesday, November 17, 2021 12:06 -0500 Joel Halpern
Direct <[email-masked]> wrote:

> We have very tightly constrained both the RSAB refusal limits
> and the appeals process.   Thus, as far as I can tell, those
> are almost irrelevant for keeping the RSWG from changing its
> core principles.  For example, if the RSWG suddenly decided
> the series was not archival, that would do not short term harm
> to any stream.  The harm would be to a much larger picture.
> But the RSAB would not have grounds to object.
> 
> Then, my take on why we need a higher bar.  I don't know if
> the other proponents see other (maybe stronger) reasons:
> 
> Basically, as we have structured things, the presumption is
> that the RSWG is doing the right thing, and it would take
> significantly community objection to block something.  That is
> what we seem to want, and for most things, I can live with
> that.
> 
> For changing the basic principles, the bar it seems to me
> needs to be on the other side.  The RSWG needs to make the
> case to the IAB and IESG that there is a good reason for
> making the change.  And, I hope, the community has to agree.
> 
> Otherwise, any time the RSWG gets to discussing any
> interesting change (and I presume it will) we will immediately
> regress to arguing about the unresolved issue of principles.
> And it will get resolved based on who has more staying power
> in the RSWG.  Really?

Slightly different take on this...   While I agree with Joel, I
look at this as some potential changes ought to have a higher
approval bar than others because their impact is likely to be
much broader, to have greater impact, and/or to harder to
reverse [1].  For me at least, Martin Dürst's examples were
helpful in defining way to think about the boundary.  Analogies
to someone driving but making adjustments to the route versus
making a change to a completely different destination come to
mind as well.  If we can agree that some possible decisions are
different from other (not sure we are there yet), then there is
an almost-separate question of how that higher approval bar
should be handled.  

To me, that is also one of the reasons to make the distinction.
As we discussed early in the life of the Program (and before it
was created), the users and audience for the RFC Series include
groups who will never be very well represented on the RSWG or
RSAB.  A circular way of defining what is really a principle is
that it is something for which a change would have a significant
impact on some of those groups rather than just being something
we can work with (or around) in the IETF community.   Ideally,
the approval process for changes that type of principle ought to
include those groups, but we have never been able to define a
good way to reach them and determine consensus.  Would pulling
in the full IAB, IESG, and LLC Board --all of whom have greater
or lesser degrees of responsibility to the broader Internet
community-- be a good surrogate for involving those other
groups?   IMO, not very, but maybe good enough.  Would creating
a mailing list that we promise to not use except for prospective
changes in principles and then trying to get some significant
libraries, organizations with liaisons with the IETF, academics
who have interest in our work but don't participate, and maybe
industry groups who are dependent on RFCs be enough?  Maybe.  

For me, the issue is now whether, e.g., the RSAG has enough
levers with which to object or ways of doing so (separate
question) but whether, if we are going to make an extraordinary
change, there is an opportunity for input by the widest possible
community.

That said, let me make a suggestion.   If we can agree that
there are such things as principles for the Series, changes to
which are to be treated as extraordinary, perhaps we can leave
the question of the procedure for reviewing and approving such
changes to the RSWG.  That would need to be subject to three
constraints: (1) That whatever they agree on has to be have
reasonable odds of getting wider review, (2) that it be a
superset of the "normal" procedure, and (3) that they not be
able to change the extraordinary review process while they are
considering or about to consider a change to a principle (or
principle-level policy).

    john

[1] Turning that into an argument about what to call those topic
and where the boundary lies between principles and policies does
not seem productive to me, YMMD.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 18 Nov 2021 11:08:19 +1300

Eric,

On 18-Nov-21 06:27, Eric Rescorla wrote:

<snip>

> With that said, I don't find the term "archival" particularly informative here, as it seems to
> mean different things to different people. It might be useful for people who think there
> is an important principle here to try map out in more detail what the operational implications
> of "archival" are.

Exactly. As a principle, it's a buzzword. To make it meaningful needs expertise that is largely going to come from the RSCE and the experienced members of the RPC.

Let's take the thought experiment a bit further. Let's assume that [miracle needed here] the IETF decides to remove one of the major bugs in its standards process in such a way, for example, that the IPv6 standard defined in RFC1883.0 would have been updated as RFC1883.1 and RFC1883.2 (instead of RFC2460 and RFC8200), and therefore requests the RSWG to define a policy allowing such renumbering to be applied.

Does that breach the principle that the RFC series is "archival"?

Is it seriously likely that the RSWG will say "no, that's fine" without a discussion that involves the IESG and IAB anyway?

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 18 Nov 2021 11:20:20 +1300

Martin,

On 17-Nov-21 23:08, Martin J. Dürst wrote:
...

> stream they will be published in. Maybe worth an issue, maybe not.]

They are part of the Independent Stream, so it's a matter of stream policy,
not an RSWG matter.

     Brian

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 17 Nov 2021 15:00:24 -0800

On Wed, Nov 17, 2021 at 2:08 PM Brian E Carpenter <
[email-masked]> wrote:

> Exactly. As a principle, it's a buzzword.
>

Right. And this is why my concern about having a principle that says that
they are archival, because I would expect it to be invoked to oppose
change, even though we never actually had any consensus one what it meant.

> Let's take the thought experiment a bit further. Let's assume that
> [miracle needed here] the IETF decides to remove one of the major bugs in
> its standards process in such a way, for example, that the IPv6 standard
> defined in RFC1883.0 would have been updated as RFC1883.1 and RFC1883.2
> (instead of RFC2460 and RFC8200), and therefore requests the RSWG to define
> a policy allowing such renumbering to be applied.
>
> Is it seriously likely that the RSWG will say "no, that's fine" without a
> discussion that involves the IESG and IAB anyway?
>

This  seems like a great example, but I also think it's hard to determine
what direction it cuts in.

I agree that RSWG would be very foolish to make such a change without
consulting the IESG and IAB (and if they didn't, I would expect some kind
of unsolicited input). On the other hand, doesn't that render a requirement
to consult them superfluous? Moreover, as I indicated, the IESG and IAB
collectively control 3 votes on the RSAB, so it seems unlikely that any
such change would pass without their support.

-Ekr

---

From: John C Klensin <[email-masked]>
Date: Wed, 17 Nov 2021 18:01:19 -0500

--On Thursday, November 18, 2021 11:08 +1300 Brian E Carpenter
<[email-masked]> wrote:

>> With that said, I don't find the term "archival" particularly
>> informative here, as it seems to mean different things to
>> different people. It might be useful for people who think
>> there is an important principle here to try map out in more
>> detail what the operational implications of "archival" are.
> 
> Exactly. As a principle, it's a buzzword. To make it
> meaningful needs expertise that is largely going to come from
> the RSCE and the experienced members of the RPC.
> 
> Let's take the thought experiment a bit further. Let's assume
> that [miracle needed here] the IETF decides to remove one of
> the major bugs in its standards process in such a way, for
> example, that the IPv6 standard defined in RFC1883.0 would
> have been updated as RFC1883.1 and RFC1883.2 (instead of
> RFC2460 and RFC8200), and therefore requests the RSWG to
> define a policy allowing such renumbering to be applied.
> 

Not really.  It does, however, breaches the principle (not
listed by Mike) that RFCs are numbered more or less sequentially
in order of publication.  It would also cause problems for
external bodies who have established collections of RFCs and
organized their indices on the basis that they are numbered as a
sequence of digits with no delimiters.  If a paper in a
professional publication contained a reference to RFC 1883 and
we suddenly decided that number referred to a series of
documents rather than a single one or they referenced RFC 2460
and we decided that was really RFC 1883.2, that would be a
problem too.  Finally (for now at least), it would risk
violating the Law of Least Astonishment for bodies used to the
convention used by ISO and many bodies related to or inspired by
them that having a document numbered 1234.2 or 1235-2 implies
component parts of document 1234 rather than sequential updates
to it.

And for the particular example of 1893 and its successors, it
would be solving a non-existent problem because we already have
the notation of STD 86 (more on that below).

I don't think any of those factors should cause an absolute
prohibition on the hypothetical change you suggest.  However... 
 
> Is it seriously likely that the RSWG will say "no, that's
> fine" without a discussion that involves the IESG and IAB
> anyway?

I would like to be as sure as we can that the RSWG (and the
RSAB) are aware of the issues outlined above and not just about
an IETF decision that it would improve the standards process.
If, fully aware of and having considered those issues, they
decided that the costs were worth it, had thought through other
adjustments that would need to be made to preserve stability,
and went ahead anyway, so be it.  But, if the decision were made
only on the basis of "bug in the standards process", I think
that would be bad trouble for the stability and reputation of
the series.

And, fwiw, that "bug" is exactly the reason overlay numbering
(e.g., BCP, STD, and FYI for a while) was introduced into the
series and why there have been repeated proposals along the
lines of the NEWTRK work and to assign STD numbers at Proposed
Standard.   Another principle, one that I hope does not need
writing down but that is a component of "Archival", is that
making changes that have the potential to be disruptive to
things that have worked for years requires careful consideration
including examination of possibly less-disruptive alternatives.

    john

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 17 Nov 2021 23:11:20 +0000

Hiya,

(I do wish some of the people who don't want to talk about
principles in the draft would provide some concrete examples
of what they really would like to change that might run afoul
of such text. ISTM, that's been asked for and not answered a
number of times now which makes this discussion feel a bit
like being asked to bring a rock.)

On 17/11/2021 17:27, Eric Rescorla wrote:
> mean different things to different people. 

Yet you don't say what meaning you attach to that? It would
be helpful if you would.

> It might be useful for people
> who think there

For me, archival includes (but is not solely defined by) the
ability to read the RFC decades after it was written. We have
a series that has demonstrably achieved that. I would think
any change that puts that at serious risk should have to pass
some higher level of approval than a change that does not.
One consequence of that is (I think, but am willing to be
educated further) that we probably need to keep some at least
output format for RFCs that requires minimal tooling. At this
point, I could see that changing from text to PDF perhaps
without that being a "breach" of this principle, but a change
to HTML plus CSS & JS & whatever else (for a supposedly
archival friendly output format) ought require passing a
higher bar as I think that would threaten the archival aspect
of the series.

Cheers,
S.

PS: I'm not so fussed as to the detail of the higher bar. My
main point is that we should mention these principles in the
draft so that the RSWG really has to deal with the (good bits
of the) heritage and/or some agreed principles.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 17 Nov 2021 15:16:49 -0800

> like being asked to bring a rock.)

As I said at the beginning of this discussion, my objection is to having the
text there at all, so it doesn't much matter what the principles are;
I'm certainly not asking anyone to bring a rock.

However at this point I've now provided three separate examples of
principles I don't think should go there, one of which is in this very
message ("archival"), and the other two being "RFCs are in English"
and "world class document series".

> Yet you don't say what meaning you attach to that? It would

My point, as Brian says, is that it's a buzzword, and that therefore we
shouldn't use it.

-Ekr

---

From: John C Klensin <[email-masked]>
Date: Wed, 17 Nov 2021 18:29:42 -0500

--On Wednesday, November 17, 2021 23:11 +0000 Stephen Farrell
<[email-masked]> wrote:

>...
>> It might be useful for people > who think there > is an
>> important principle here to try map out in more detail > what
>> the operational implications > of "archival" are.

> higher bar as I think that would threaten the archival aspect

Rather good explanation, IMO.  I would add that "Archival
Series" goes beyond just "Archival Document" as described above
and into issues of whether ways to access those documents are
stable.  See my recent response to Brian Carpenter about NNNN.1
for a better explanation and examples, but, if someone is going
to reference an RFC from a publication that has high standards
for the long-term availability and accessibility for things that
are referenced, another part of "Archival" is that we should
have a clear standard for those references (not doing as well
about that as we were a decade or two IMO) and that they should
be stable.  That does not mean "never make a change".  It does
means being extra-aware of potential risks and consequences and,
in almost all cases, including mitigation of damage in the
evaluation of, and decisions about, that change.

> of the) heritage and/or some agreed principles.

I'm not fussed about those details either.  I just want to be as
sure as possible, not only that the RSWG deals with things as
suggested above but that we go further than we might reasonably
go for less consequential changes to be sure that we get input
as broad as possible and that the RSWG does its evaluation on
the basis of that broader set of perspectives.  Dragging in
other bodies who presumably have broader perspectives and more
responsibility to people and groups outside the IETF than the
RSWG is likely to have is just a way to try to accomplish that
and not necessarily the only one.

best,
   john

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 17 Nov 2021 23:30:17 +0000

Hiya,

> text there at all, so it doesn't much matter what the principles are;

I don't agree that that helps. You (and others arguing
similarly) are not providing realistic examples of what
you would like to change, that could be put at risk if
such text were included. It really would help me at least
understand your objections (because I do not so far) if
some such examples were described.

> I'm certainly not asking anyone to bring a rock.

It feels to this someone as if you are.

> and "world class document series".

Yes, but that still does not answer my "ask" above and
to be frank part of the reason I'm  unconvinced by your
argument is because of that lack of positive concrete
information. (As opposed to "negative" argument that
such text ought not go in for some, I guess, "principled"
reason:-)

> My point, as Brian says, is that it's a buzzword, and that therefore we

I don't consider archival a buzzword (*) nor one that really
needs any definition in a draft such as we're considering.

S.

(*) Personally I think archival (as in archival series) is
much less likely to be misinterpreted than buzzword:-)

---

From: John C Klensin <[email-masked]>
Date: Wed, 17 Nov 2021 18:38:33 -0500

--On Wednesday, November 17, 2021 15:16 -0800 Eric Rescorla
<[email-masked]> wrote:

> My point, as Brian says, is that it's a buzzword, and that
> therefore we shouldn't use it.

"buzzword" is a way of casting aspersions on some terminology
without trying engage with intentions and underlying meaning.
In the communities who deal with what is not called Information
Science and with document repositories where both the
repositories and the documents are expected to be available for
a long time (e.g., many times the current age of the Internet),
the term is rather well understood even though people may
quibble about details.   And Stephen's description is rather
good, plus or minus my additions, is rather good.

But, if you find "archival" offensive, I suggest we try to agree
on Stephen's explanation (or something else to it) and then, if
necessary, assign another word or set of words.

best,
   john

---

From: "StJohns, Michael" <[email-masked]>
Date: Wed, 17 Nov 2021 18:45:48 -0500

Nope.  The assignment of this to the ISE vs the RSE was not a stream issue
exactly.  And I can see it being moved about or even snuffed out being
within the proposed  purview of the RSWG.  Or do you have text that says
otherwise?

Later, Mike

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 18 Nov 2021 14:18:39 +1300

> without trying engage with intentions and underlying meaning.

To be fair, I asserted that it was a buzzword when used unqualified
as a statement of principle. I've served on several library committees
and at least one archive committee, and am a card-carrying user of
the NZ National Archive, so I certainly appreciate the value of
a traditional library-style archive.

> necessary, assign another word or set of words.

Here's the thing. We are indeed lacking a definition of what "archive"
means for the RFC Series. How can we make a statement of principle
*before* doing the work to agree on such a definition?

I think this illustrates my main concern. It seems to me that reaching
a solid consensus on Mike's proposed set of principles would take
work and time, and would leave the RFC Editor Function in a state of
administrative uncertainty for several more months. I would much
prefer to avoid this, even though I largely support those principles
as written.

     Brian

---

From: Christian Huitema <[email-masked]>
Date: Wed, 17 Nov 2021 17:21:23 -0800

> component parts of document 1234 rather than sequential updates

That's a pretty good point, John, and it makes me think about what we 
should do.

I don't like the way Mike wrote his set of principles. I feel the text 
is too long, and that several of the bullet points in his list overlap. 
I also feel that some of the text is situational, such as the quip about 
"more recently, Internet standards", which negates the fact that for the 
last 25 years or so the vast majority of RFC published were in fact the 
work of the IETF, and also negates the fact that researchers have long 
used other venues than the RFC series to publish idea -- IFIP, SIGCOM or 
USENIX being great examples. I would much prefer that for now we stick 
to the short formulation in RFC 8729:

    The RFC Series is the archival series dedicated to documenting
    Internet technical specifications, including general contributions
    from the Internet research and engineering community as well as
    standards documents.

    RFCs are available free of charge to anyone via the Internet.

I think that these short sentences carry the essence of what we want, 
i.e., centered on the Internet, open to both standards and diverse 
voices, widely available at any time, and archived so that texts can be 
retrieved at any time. The problems start when we want to elaborate. 
Your example of unintended consequences of simple changes is a great 
example of possible elaborations. But I am not sure that we want that 
level of details in the current draft. In fact, when I see this kind of 
arguments, I become more convinced that we should keep a simple text in 
the draft, and ask the WG to write down the full details.

-- Christian Huitema

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 17 Nov 2021 19:49:36 -0700

>     from the Internet research and engineering community as well as

Lo and behold, that's the first sentence here:

https://datatracker.ietf.org/doc/html/draft-iab-rfcefdp-rfced-model-05#section-1

Peter

---

From: John C Klensin <[email-masked]>
Date: Thu, 18 Nov 2021 00:20:31 -0500

> To be fair, I asserted that it was a buzzword when used
> unqualified as a statement of principle. I've served on
> several library committees and at least one archive committee,
> and am a card-carrying user of the NZ National Archive, so I
> certainly appreciate the value of a traditional library-style
> archive.

And, to be clear, I was not responding to your use of that term
as much as to another message that seems to assert that, because
it was a buzzword. there was no value in using the term.  I
assumed, perhaps incorrectly, but in line with earlier notes,
that meant that, because a buzzword had been used, there was
little point in discussing the topic further.

>> In the communities who deal with what is not called
>> Information Science and with document repositories where both
>> the repositories and the documents are expected to be
>> available for a long time (e.g., many times the current age
>> of the Internet), the term is rather well understood even
>> though people may quibble about details.   And Stephen's
>> description is rather good, plus or minus my additions, is
>> rather good.
>> 
>> But, if you find "archival" offensive, I suggest we try to
>> agree on Stephen's explanation (or something else to it) and
>> then, if necessary, assign another word or set of words.

> Here's the thing. We are indeed lacking a definition of what
> "archive" means for the RFC Series. How can we make a
> statement of principle *before* doing the work to agree on
> such a definition?

And that is precisely why I suggested putting the term aside (at
least temporarily) and focus on Stephen's description and mine,
which operationalizes the key elements of the concept for which
we have been using that term.

And, of course, it is only one of the principles/policies on
Mike's list.

> I think this illustrates my main concern. It seems to me that
> reaching a solid consensus on Mike's proposed set of
> principles would take work and time, and would leave the RFC
> Editor Function in a state of administrative uncertainty for
> several more months. I would much prefer to avoid this, even
> though I largely support those principles as written.

The opposing concern, at least from my perspective (which
clearly differs from elements of Mike's) is that, while I share
your concern about having this process drag out further and am
upset that it has dragged out this long, I am even more
concerned about the possibility that, because we have swept too
much under the rug, kicked too many issues down the road, or
failed to be sufficiently clear about issues that require
special attention, something goes seriously awry and we find
ourselves back here in a couple of years.   While I think the
odds of things going that seriously bad are low, the risks and
consequences could be sufficiently bad if they occurred that I
think it is worth some extra time and effort to leave more of us
confident that we have reached the right balance between "right"
and "sooner".

best,
   john

---

From: John C Klensin <[email-masked]>
Date: Thu, 18 Nov 2021 00:27:09 -0500

--On Wednesday, November 17, 2021 19:49 -0700 Peter Saint-Andre
<[email-masked]> wrote:

>>     The RFC Series is the archival series dedicated to
>>  documenting    Internet technical specifications,
>>  including general contributions    from the Internet
>>  research and engineering community as well as    standards
>>  documents.
> 

Indeed.  And the combination of Christian's comments and that
text strengthens my belief that we are getting close and that
the current debate is, or should be, as much about defining
things that require exceptional review and those review
mechanisms than real disagreements about about principles.
However, if we really have no idea what "archival" means or if
it means enough different things to different people --as I
think has been suggested but maybe I misunderstood-- then that
sentence is handwaving rather than definitive.

Also, at the risk of nit-picking, note that "technical
specification" has a very specific meaning defined in RFC 2026
and that a very significant fraction of the documents in the
series do not meet that definition.

best,
   john

---

From: Eliot Lear <[email-masked]>
Date: Thu, 18 Nov 2021 07:25:25 +0100

John:

On 18.11.21 06:20, John C Klensin wrote:
>   I am even more
> ourselves back here in a couple of years.

Let's not again talk about ignoring issues or sweeping anything under 
the rug, because  that hasn't happened.  Everyone here must accept that 
there are some issues upon which we will not find agreement.  The 
question is no more nor less than how to accommodate those differences.

Joel's text leads me to hope in that department, perhaps coupled with 
Christian's note, as you say.

Eliot

---

From: John C Klensin <[email-masked]>
Date: Thu, 18 Nov 2021 02:04:22 -0500

--On Thursday, November 18, 2021 07:25 +0100 Eliot Lear
<[email-masked]> wrote:

>> concerned about the possibility that, because we have swept
>> too much under the rug, kicked too many issues down the road,
>> or failed to be sufficiently clear about issues that require
> Let's not again talk about ignoring issues or sweeping
> anything under the rug, because  that hasn't happened. 
> Everyone here must accept that there are some issues upon
> which we will not find agreement.  The question is no more
> nor less than how to accommodate those differences.

Eliot, I would like to agree but I have heard several comments
in the last couple of weeks that sound, to me, remarkably like
"we can't reach agreement on that now, so let's just dump the
issue on the RSWG".  Especially when there is no suggestion of
figuring out a way to actually require the RSWG to engage on the
issue [either], that is better than "... so let's pretend it
does not exist" but it is also not, IMO, figuring out how to
accommodate differences.  I want to stress that there may be
entirely reasonable arguments for pushing some
issues/discussions off onto the RSWG (and that I've heard some
of them for some issues) but they are different from treating it
as a handy default when we cannot reach agreement (or reach
agreement quickly).

> Joel's text leads me to hope in that department, perhaps
> coupled with Christian's note, as you say.

Agreed.

thanks,
    john

---

From: Mirja Kuehlewind <[email-masked]>
Date: Thu, 18 Nov 2021 09:15:01 +0100

Please see below.

> On 18. Nov 2021, at 03:49, Peter Saint-Andre <[email-masked]> wrote:
> 
>> That's a pretty good point, John, and it makes me think about what we should do.
>> I don't like the way Mike wrote his set of principles. I feel the text is too long, and that several of the bullet points in his list overlap. I also feel that some of the text is situational, such as the quip about "more recently, Internet standards", which negates the fact that for the last 25 years or so the vast majority of RFC published were in fact the work of the IETF, and also negates the fact that researchers have long used other venues than the RFC series to publish idea -- IFIP, SIGCOM or USENIX being great examples. I would much prefer that for now we stick to the short formulation in RFC 8729:

The second sentence proposed by Christian ("RFCs are available free of charge to anyone via the Internet.”) is written down as part of the IETF mission statement (RFC3935):

"Open process - any interested person can participate in the work,
      know what is being decided, and make his or her voice heard on the
      issue.  Part of this principle is our commitment to making our
      documents, our WG mailing lists, our attendance lists, and our
      meeting minutes publicly available on the Internet.”

I think this is also were it belongs. Having open access is important for the IETF stream, however, the more I think about it, the less I’m convinced we should write this down as a general principle for all future streams. I mean, yes, I hope and believe that having free access to all RFCs is a good value, however, I also won’t rule out that that there are never any future use cases where publishing something with some kind of limited access would not be of any value.

Similarly this is also true for most of the text Mike proposed. When reading it first I was mostly agreeing to many points but when thinking about it in detail I actually found most things too restrictive when applied to al streams and all potential future streams. I even started yesterday an email to comment of each point and see if there is something I could find useful to write down. However, while these points are applicable to the IETF stream today, it wasn’t clear to me that all principles should be applied to all streams and also if there are good enough reason to say that any of these principles should be “hard” to change or are in any way more important than other considerations in the RSWG. So I ended up not sending an email, and think we really should specify the model now (which already sneaks for the largest possible community feedback for all the work the RSWG publishes) and get more experience with the process to understand if any such principles can, should, or need to be written down. 

I recommend everybody (also those in favour) to go carefully go through Mike's text by themselves and see if they really agree or not agree to those things for all streams in future, and if there are any high level principles that people think should be written down now, to ask yourself why such a principle should have more weight than any other arguments that might come up in the RSWG discussion for all stream.

If you have identified such principle, I think it would be useful to discuss that on list (rather than the whole text as propose by Mike) including the reason why you think that specific principle is important. I didn’t identify anything at the end that raised the bar for me.

Mirja

P.S.: I’ve been thinking for a while about the principle of high quality documents. Quality is also mentioned in the IETF mission statement. Again I think high quality is more important for the IETF stream than others, however, I’m not even sure if we are reaching the bar on any stream today… also note that we are explicitly not asking the RPC to check the content. This is the responsibility of the streams itself. I guess the RPC does a great job of lifting the quality quite a bit but really not sure if I would consider all published RFC as high quality. At minimum I have to say that there are large differences in quality (given the process, topics, and level of review).

---

From: Mirja Kuehlewind <[email-masked]>
Date: Thu, 18 Nov 2021 10:38:13 +0100

Actually, let me add a concrete and hopefully constructive proposal here. Inline with Christian’s proposal and the text we already have, which is this:

“The Request for Comments (RFC) Series is the archival series
   dedicated to documenting Internet technical specifications, including
   general contributions from the Internet research and engineering
   community as well as standards documents.  As described in [RFC8700],
   RFCs have been published continually since 1969.  The overall
   framework for the RFC Series and the RFC Editor function are
   described in [RFC8729] and updated here.”

I think we could maybe add another paragraph that defines a bit more what the RFC series currently is, e.g.:

“The RFC Series is currently the publication venue for four streams - the IETF stream, the IAB stream, the IRTF stream, and the Independent Submission Editor (ISE) stream. This document establishes a fifth stream, the Editorial stream. Documents of these streams are intentionally published in the same publication series in order to foster exchange among these communities and support diversity in expression. The streams are responsible for the content of the published document and, respectively, also to organise a review process that ensures document quality as well as community consensus if desired. The RFC Production Center (RPC) is responsible for the publication and accessibility of RFCs, including technical challenges for the long-term archival of digital publications.”

I think such text is sufficient and more correct than trying to establish principles that need to apply to all streams equally and in “all” times because I think the scope of the RFC series if mainly defined by the scope of its streams and I believe we have designed the new system very explicitly to consider the needs and requirements of all streams.

Mirja

> On 18. Nov 2021, at 09:15, Mirja Kuehlewind <[email-masked]> wrote:
> 
> Please see below.
>

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 18 Nov 2021 14:17:48 +0000

I don't think that's a valid criticism.  You can say "these shouldn't be here" and "well, what does it break and what do you want changed" isn't really responding to the first issue.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 18 Nov 2021 14:51:00 +0000

Hiya,

On 18/11/2021 14:17, Salz, Rich wrote:
>> similarly) are not providing realistic examples of what you would
>> like to change, that could be put at risk if such text were included.
>> It really would help me at least understand your objections (because
>> I do not so far) if some such examples were described.
> 
> I don't think that's a valid criticism.  You can say "these shouldn't
> be here" and "well, what does it break and what do you want changed"
> isn't really responding to the first issue.

Sorry for not being clear. I do get that Ekr and some others
don't want the text there. I do not really understand why,
and some example of how such text might cause a problem for
some realistic thing the RSWG might want do might help me at
least understand that better.

I do think that's a valid question and answers would also I
think help the discussion.

To be fair, Mirja did propose one such - saying that some
RFCs from some putative stream might have "limited access"
but I'd actually turn that around and argue that we ought
never have any secret RFCs. ("Limited access" might I guess
apply to some other outputs of some RGs, but a) we've not
done that for ages, which I think is good, and b) I don't
think that ever applied to IRTF RFCs.)

Cheers,
S.

---

From: Mirja Kuehlewind <[email-masked]>
Date: Thu, 18 Nov 2021 16:06:38 +0100

Just to add one minor comment/correctly below.

> On 18. Nov 2021, at 15:51, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
> 

My point was rather that I think it’s a per-stream decision and I don’t really see a point in restricting us this way on a per-series basis (even though I'm personally supportive of the goal to always try to have open access to all RFCs).

> 
> Cheers,
> S.
> <OpenPGP_0x5AB2FAF17B172BEA.asc>--

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 18 Nov 2021 15:15:43 +0000

Hiya,

On 18/11/2021 15:06, Mirja Kuehlewind wrote:
>> To be fair, Mirja did propose one such - saying that some RFCs from
>> some putative stream might have "limited access" but I'd actually
>> turn that around and argue that we ought never have any secret
>> RFCs. ("Limited access" might I guess apply to some other outputs
>> of some RGs, but a) we've not done that for ages, which I think is
>> good, and b) I don't think that ever applied to IRTF RFCs.)

> My point was rather that I think it’s a per-stream decision and I
> don’t really see a point in restricting us this way on a per-series
> basis (even though I'm personally supportive of the goal to always
> try to have open access to all RFCs).

Sure, that's what I understood you meant. I just disagree
with it:-)

I do think that "no secret RFCs" is an excellent principle
for the entire series, regardless of stream. Going further
I'd also argue that all RFCs ought continue to be freely
available at no cost for as long as the series is alive.

Cheers,
S.

---

From: Joel Halpern Direct <[email-masked]>
Date: Thu, 18 Nov 2021 10:19:52 -0500

Mirja, I think that free access to RFCs is an RFC series decision and 
not a stream decision.

Yours,
Joel

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 19 Nov 2021 13:27:35 +1300

> Mirja, I think that free access to RFCs is an RFC series decision and

Where should that principle be debated, if not in the RSWG?

It seems clear to me by now that we will not reach consensus to add a set 
of principles to the RFC Editor Model (Version 3). Whether we have rough consensus to proceed without it is for our chairs to decide.

    Brian

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 18 Nov 2021 20:25:53 -0500

Frankly, it had occurred to me that the principle of open access to RFCs 
should be debated.

Since folks don't seem to get it, it seems to me it needs to be written 
down.
And then, if the RSWG wants to change it, it needs extra review.

This has been a cornerstone of the RFC series since before the IETF existed.

Yours,
Joel

On 11/18/2021 7:27 PM, Brian E Carpenter wrote:
> It seems clear to me by now that we will not reach consensus to add a 
> set of principles to the RFC Editor Model (Version 3). Whether we have 
> rough consensus to proceed without it is for our chairs to decide.
> 
>     Brian
> 
>>
>> Yours,
>> Joel
>>

---

From: Christian Huitema <[email-masked]>
Date: Thu, 18 Nov 2021 17:33:38 -0800

The basic principles of the series are listed in the first paragraph of 
the draft's introduction. These principles have been followed for 50 
years. Nothing is immutable, but changes to these basic principles may 
well have unintended consequences, and should not be considered lightly.

I would support adding the previous two lines somewhere in the draft, 
maybe in the introduction. I will also support an RSWG effort 
delineating the principles, the past experience, and possible unintended 
consequences. I will not support trying to do that definition work in 
the draft itself.

-- Christian Huitema

On 11/18/2021 5:25 PM, Joel M. Halpern wrote:
> Frankly, it had occurred to me that the principle of open access to 
> RFCs should be debated.
>
> Since folks don't seem to get it, it seems to me it needs to be 
> written down.
>> set of principles to the RFC Editor Model (Version 3). Whether we 
>> have rough consensus to proceed without it is for our chairs to decide.
>>
>>     Brian
>>
>>>
>>> Yours,
>>> Joel
>>>

---

From: Jay Daley <[email-masked]>
Date: Fri, 19 Nov 2021 16:29:25 +1300

> On 19/11/2021, at 2:26 PM, Joel M. Halpern <[email-masked]> wrote:
> 
> Frankly, it had occurred to me that the principle of open access to RFCs should be debated.
> 
> Since folks don't seem to get it, it seems to me it needs to be written down.

There’s a key point here that I don’t understand and that I’m hoping someone can explain. Why do people think that the RSWG is more likely to reach consensus on changing something like ‘open access to RFCs’ than this group?  I’m obviously much less familiar with how these groups work than many of you, but naively perhaps, I don’t see how such a radical divergence could reach consensus. Are some worried that without these principles, policies will be introduced that go against them without explicitly acknowledging or considering that?

Jay

-- 
Jay Daley
IETF Executive Director 
[email-masked]
>> It seems clear to me by now that we will not reach consensus to add a set of principles to the RFC Editor Model (Version 3). Whether we have rough consensus to proceed without it is for our chairs to decide.
>>    Brian
>>> 
>>> Yours,
>>> Joel
>>>

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 19 Nov 2021 14:02:15 +0000

> These principles have been followed for 50 
    years. Nothing is immutable

Words are.  Hacker.  Crypto.  Open access often used to mean you could find it in the library.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 22 Nov 2021 17:00:11 -0700

> The second sentence proposed by Christian ("RFCs are available free of charge to anyone via the Internet.”) is written down as part of the IETF mission statement (RFC3935):

It's also part of RFC 8729 and in -06 of our Internet-Draft I 
incorporated that sentence into the first paragraph of the Introduction:

https://datatracker.ietf.org/doc/html/draft-iab-rfcefdp-rfced-model-06#section-1

>        meeting minutes publicly available on the Internet.”

I do wonder whether it's a good idea to incorporate IETF-specific text 
into our Internet-Draft.

Peter

---

From: John C Klensin <[email-masked]>
Date: Mon, 22 Nov 2021 19:57:50 -0500

--On Monday, November 22, 2021 17:00 -0700 Peter Saint-Andre
<[email-masked]> wrote:

> I do wonder whether it's a good idea to incorporate
> IETF-specific text into our Internet-Draft.

FWIW, I think it is not.  And see my earlier note about
"technical specification" and the very specific meaning of that
term in RFC 2026.

   john

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 23 Nov 2021 14:42:39 +1300

On 23-Nov-21 13:57, John C Klensin wrote:
> FWIW, I think it is not.  

I agree.
     Brian

> And see my earlier note about

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 23 Nov 2021 19:04:01 +0100

See below.

> On 23. Nov 2021, at 01:00, Peter Saint-Andre <[email-masked]> wrote:
> 
> It's also part of RFC 8729 and in -06 of our Internet-Draft I incorporated that sentence into the first paragraph of the Introduction:
> 
> I do wonder whether it's a good idea to incorporate IETF-specific text into our Internet-Draft.

We should not have IETF specific text or principles in this draft. However, I think the sentence is fine as it’s a statement of fact describing the current situation (for all RFCs) and not phrased as a principle.

Mirja

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 24 Nov 2021 14:06:50 +1300

On 24-Nov-21 07:04, Mirja Kuehlewind wrote:
...

> We should not have IETF specific text or principles in this draft. However, I think the sentence is fine as it’s a statement of fact describing the current situation (for all RFCs) and not phrased…

Mirja is onto something here. Stating historical facts without describing 
them as fixed principles might get us out of this debate.

    Brian

---

From: Adam Roach <[email-masked]>
Date: Mon, 29 Nov 2021 15:36:35 -0600

On 11/18/2021 9:29 PM, Jay Daley wrote:
> There’s a key point here that I don’t understand and that I’m hoping someone can explain. Why do people think that the RSWG is more likely to reach consensus on changing something like ‘open access to RFCs’ than this group?

Jay --

I see two factors that are likely to drive people's perspectives about 
whether these principles should be defined in the rfced-future program 
or in the RSWG, and I don't think "likeliness of reaching consensus on 
principles" is one of them.

The first factor is a practical consideration that this program was 
established to quickly put in place a structure that could ensure 
stewardship of the RFC series. Until it does so, we have the equivalent 
of a "provisional government" for the series, left in something of a 
holding pattern, and specifically constrained from making any strategic 
decisions. It is now 20 months into this process, and we have a document 
that arguably, after much work, meets the fundamental goal that the 
program had at its outset.

Into this, we add a demonstrably controversial proposal to add 
principles to the document; and, to complicate matters, the proposed 
principles themselves are controversial. It is difficult to imagine 
either of these issues resolved quickly, and each day we spend 
attempting to resolve them results in another day delay in moving out of 
our provisional holding pattern into a new model of governance. Reaching 
consensus in the RSWG will not be faster or more likely to succeed, 
because it will presumably have exactly the same personnel makeup as 
this program; but neither will the conversation in the RSWG gate the 
creation of the new governance structure.

The second factor is one of effect: some people are implying (or 
outright stating) that by placing these principles into the document 
that defines the new model itself, they become in some way sacrosanct, 
and outside the purview of the RSWG to change. By contrast, principles 
defined by the RSWG itself can't logically be beyond the RSWG's remit to 
revise later.

This is a principle you sometimes see in lawmaking, where certain 
provisions are put in place that require some extraordinary (and 
frequently unattainable) preconditions to be met in order to ever be 
revised. There was, for example, a recent constitutional amendment 
passed in Texas -- which has never had a state income tax -- requiring a 
2/3rds majority of the legislature to *ever* enact an income tax, rather 
than the simple majority that any other lawmaking generally requires.

This kind of action can be seen either as a benevolent attempt to lock 
in some fundamental properties that we believe will protect the 
community from harmful future changes, or as a paternalistic attempt to 
protect future versions of the community from itself by exerting the 
will of the (by that future point in time) minority of people who 
happened to have a majority position at some potentially long-past point 
in time. I suspect the core of the tussle we're seeing right now has to 
do with which of these two perspectives various program participants have.

/a

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 29 Nov 2021 21:43:27 +0000

Hi Adam

On 29/11/2021 21:36, Adam Roach wrote:
> and outside the purview of the RSWG to change.

Where was that stated? I don't recall such. AFAIK everyone
who wants this kind of text included understands that things
can change later. "Sacrosanct" seems like a pretty inaccurate
way to describe that.

Cheers,
S.

---

From: Adam Roach <[email-masked]>
Date: Mon, 29 Nov 2021 15:47:53 -0600

On 11/29/2021 3:43 PM, Stephen Farrell wrote:
>> that defines the new model itself, they become in some way 
>> sacrosanct, and outside the purview of the RSWG to change.
>

Stephen: among others that I can't find as quickly, there's this message:

On 11/22/2021 12:02 PM, Michael StJohns wrote:
> One of the key items in my formulation (and I think hidden a bit in 
> Joel's) is that principles are meta laws that are not generally 
> subject to change within this process.  To use a fairly weak analogy, 
> this document we're working on is a constitution, while the RSWG/RSAB 
> will be writing laws subject to that constitution.

/a

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 29 Nov 2021 21:54:38 +0000

> Stephen: among others that I can't find as quickly, there's this message:

Thanks. But wasn't that accompanied by discussion a) that it
wasn't a great analogy and b) as to how constitutions change.

A claim that the text below means everyone who wants e.g.
Brian's text, considers that sacrosanct is not IMO at all
a reasonable description of recent list traffic.

>> will be writing laws subject to that constitution. 

FWIW, I don't agree that changes to the text proposed are
not subject to change via the RSWG, it's just, as I think
has been stated often, that additional care is needed.

Cheers,
S.

---

From: Jay Daley <[email-masked]>
Date: Tue, 30 Nov 2021 10:56:21 +1300

> On 30/11/2021, at 10:36 AM, Adam Roach <[email-masked]> wrote:
> 
> I see two factors that are likely to drive people's perspectives about whether these principles should be defined in the rfced-future program or in the RSWG, and I don't think "likeliness of reaching consensus on principles" is one of them.
> 
> The first factor is a practical consideration that this program was established to quickly put in place a structure that could ensure stewardship of the RFC series. Until it does so, we have the equivalent of a "provisional government" for the series, left in something of a holding pattern, and specifically constrained from making any strategic decisions. It is now 20 months into this process, and we have a document that arguably, after much work, meets the fundamental goal that the program had at its outset.
> 
> Into this, we add a demonstrably controversial proposal to add principles to the document; and, to complicate matters, the proposed principles themselves are controversial. It is difficult to imagine either of these issues resolved quickly, and each day we spend attempting to resolve them results in another day delay in moving out of our provisional holding pattern into a new model of governance. Reaching consensus in the RSWG will not be faster or more likely to succeed, because it will presumably have exactly the same personnel makeup as this program; but neither will the conversation in the RSWG gate the creation of the new governance structure.
> 
> The second factor is one of effect: some people are implying (or outright stating) that by placing these principles into the document that defines the new model itself, they become in some way sacrosanct, and outside the purview of the RSWG to change. By contrast, principles defined by the RSWG itself can't logically be beyond the RSWG's remit to revise later.
> 
> This is a principle you sometimes see in lawmaking, where certain provisions are put in place that require some extraordinary (and frequently unattainable) preconditions to be met in order to ever be revised. There was, for example, a recent constitutional amendment passed in Texas -- which has never had a state income tax -- requiring a 2/3rds majority of the legislature to *ever* enact an income tax, rather than the simple majority that any other lawmaking generally requires.
> 
> This kind of action can be seen either as a benevolent attempt to lock in some fundamental properties that we believe will protect the community from harmful future changes, or as a paternalistic attempt to protect future versions of the community from itself by exerting the will of the (by that future point in time) minority of people who happened to have a majority position at some potentially long-past point in time. I suspect the core of the tussle we're seeing right now has to do with which of these two perspectives various program participants have.

Thanks Adam, that’s a well articulated summary.

My question though was slightly different so let me try expressing it better - there are some who are concerned that the RSWG will go ahead and agree changes that break some fundamental principles that this group would never agree to, and so seek to protect those fundamental principles now to limit that.  My question was, how could it be apparently so much easier for the RSWG to reach consensus on something that breaks these principles when there are people in this group who are strongly supportive of those principles? Or to put it more bluntly and borrowing a phrase from Rich Salz - if we didn’t have this bar fight in this group then wouldn’t we just have it in the RSWG, what’s different?

The two answers I’ve had offlist are that a) such change could happen by stealth/accident if the principles are not pre-defined; and b) the dynamics of the RSWG will be very different from the dynamics of this group potentially leading to some strongly supported positions here being declared as in the rough in the RSWG.  

Jay

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 29 Nov 2021 14:58:14 -0700

> a reasonable description of recent list traffic.

Adam did say: "some people are implying (or outright stating)..." (not 
*all* people).

At this point I don't think we can say all people in these threads agree 
on anything. ;-)

Peter

---

From: Jay Daley <[email-masked]>
Date: Tue, 30 Nov 2021 10:59:43 +1300

> On 30/11/2021, at 10:56 AM, Jay Daley <[email-masked]> wrote:
> 
> 
> 
> My question though was slightly different so let me try expressing it better - there are some who are concerned that the RSWG will go ahead and agree changes that break some fundamental principles that this group would never agree to,

Sorry that’s still not clear - I mean "the RSWG will go ahead and agree changes that this group would never agree to, because they break what some consider to be fundamental principles".

Jay

> and so seek to protect those fundamental principles now to limit that.  My question was, how could it be apparently so much easier for the RSWG to reach consensus on something that breaks these principles when there are people in this group who are strongly supportive of those principles? Or to put it more bluntly and borrowing a phrase from Rich Salz - if we didn’t have this bar fight in this group then wouldn’t we just have it in the RSWG, what’s different?
> 
> [email-masked] <mailto:[email-masked]>
> 
> -- 
> [email-masked] <mailto:[email-masked]>
> https://www.iab.org/mailman/listinfo/rfced-future <https://www.iab.org/mailman/listinfo/rfced-future>
-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 29 Nov 2021 17:00:10 -0500

If I did not think the principles could be changed or itnerpretted, I 
would not have proposed text describing what I would like to see happen 
when such changes are introduced.  And while my text introduces a higher 
bar, it does not introduce an insuperable bar, particularly if there is 
actual community support for the change.

The words you chose for your description seem to misrepr3esent the 
opinions of the folks with whom you disagree.

Yours,
Joel

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 29 Nov 2021 22:02:39 +0000

> At this point I don't think we can say all people in these threads agree 

Which is kinda odd, isn't it? Given the amount of time
and effort all those involved have put into work that
feeds into the RFC series over time.

S.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 30 Nov 2021 11:02:56 +1300

This appears paradoxical, but it seems to me that writing things down rather than leaving them as folklore makes them *easier* for our successors to change, not harder, whatever form of words we adopt.

Regards
    Brian

On 30-Nov-21 10:56, Jay Daley wrote:
>>> There’s a key point here that I don’t understand and that I’m hoping someone can explain. Why do people think that the 
RSWG is more likely to reach consensus on changing something like ‘open access to RFCs’ than this group?
>> I see two factors that are likely to drive people's perspectives about 
whether these principles should be defined in the rfced-future program or 
in the RSWG, and I don't think "likeliness of reaching consensus on principles" is one of them.
>> Into this, we add a demonstrably controversial proposal to add principles to the document; and, to complicate matters, the proposed principles themselves are controversial. It is difficult to imagine either of these issues resolved quickly, and each day we spend attempting to resolve them 
results in another day delay in moving out of our provisional holding pattern into a new model of governance. Reaching consensus in the RSWG will not be faster or more likely to succeed, because it will presumably have exactly the same personnel makeup as this program; but neither will the conversation in the RSWG gate the creation of the new governance structure.
>>
>> The second factor is one of effect: some people are implying (or outright stating) that by placing these principles into the document that defines the new model itself, they become in some way sacrosanct, and outside 
the purview of the RSWG to change. By contrast, principles defined by the 
RSWG itself can't logically be beyond the RSWG's remit to revise later.
>>
>> This is a principle you sometimes see in lawmaking, where certain provisions are put in place that require some extraordinary (and frequently unattainable) preconditions to be met in order to ever be revised. There was, for example, a recent constitutional amendment passed in Texas -- which has never had a state income tax -- requiring a 2/3rds majority of the 
legislature to *ever* enact an income tax, rather than the simple majority that any other lawmaking generally requires.
>> This kind of action can be seen either as a benevolent attempt to lock 
in some fundamental properties that we believe will protect the community 
from harmful future changes, or as a paternalistic attempt to protect future versions of the community from itself by exerting the will of the (by 
that future point in time) minority of people who happened to have a majority position at some potentially long-past point in time. I suspect the core of the tussle we're seeing right now has to do with which of these two perspectives various program participants have.
> My question though was slightly different so let me try expressing it better - there are some who are concerned that the RSWG will go ahead and agree changes that break some fundamental principles that this group would never agree to, and so seek to protect those fundamental principles now 
to limit that.  My question was, how could it be apparently so much easier for the RSWG to reach consensus on something that breaks these principles when there are people in this group who are strongly supportive of those principles? Or to put it more bluntly and borrowing a phrase from Rich 
Salz - if we didn’t have this bar fight in this group then wouldn’t we just have it in the RSWG, what’s different?
> 
> The two answers I’ve had offlist are that a) such change could happen by stealth/accident if the principles are not pre-defined; and b) the dynamics of the RSWG will be very different from the dynamics of this 
group potentially leading to some strongly supported positions here being 
declared as in the rough in the RSWG.

---

From: Adam Roach <[email-masked]>
Date: Mon, 29 Nov 2021 16:04:19 -0600

> The two answers I’ve had offlist are that a) such change could happen by stealth/accident if the principles are not pre-defined; and b) the dynamics of the RSWG will be very different from the dyna…

I think that's a very short-term perspective on the matter, and I don't 
find either answer to have much explanatory power, unless those who 
supposedly feel strongly about the principles they currently advocate 
for now plan to disengage once the RSWG is formed.

The longer-term view that at least I have is that constituencies evolve, 
and there's value in letting governance structures evolve with them 
rather than being constrained by the needs of what the community looked 
like 50 years ago. Setting higher bars for this evolution is simply one 
way to favor the needs of a legacy community over the contemporaneous 
community.

/a

---

From: Adam Roach <[email-masked]>
Date: Mon, 29 Nov 2021 16:08:37 -0600

On 11/29/2021 4:00 PM, Joel M. Halpern wrote:
> would not have proposed text describing what I would like to see 
> happen when such changes are introduced.  And while my text introduces 
> a higher bar, it does not introduce an insuperable bar, particularly 
> if there is actual community support for the change.
>

I'm sorry if my summary didn't capture some of the nuance of "meta laws 
that are not generally subject to change within this process," and feel 
free to mentally replace "sacrosanct" with that phrase in my email.

Regarding the difference between forbidding changes and making them 
difficult, I'll repeat what I said to Jay: constituencies evolve, and 
there's value in letting governance structures evolve with them rather 
than being constrained by the needs of what the community looked like 50 
years ago. Even if not technically insurmountable, setting higher bars 
for this evolution is simply one way to favor the needs of a legacy 
community over the contemporaneous community.

/a

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 29 Nov 2021 22:20:38 +0000

Hiya,

On 29/11/2021 22:08, Adam Roach wrote:
> there's value in letting governance structures evolve with them 

Agreed. I don't think we disagree about that.

> rather 
> than being constrained 

I'd say guided, not constrained but that's just a rhetorical
difference.

> by the needs of what the community looked like 50 
> years ago. 

We're talking about now, not 50 years ago.

> Even if not technically insurmountable, setting higher bars 
> community

I don't agree that adding principles as discussed "favors
the needs" of anyone today. (I mean, who exactly is making
a profit from all this debate? Right... nobody is:-)

> over the contemporaneous community.

FWIW, my believe, which differs from yours, is that stating
these principles will be useful to the future community.

Cheers,
S.

---

From: Adam Roach <[email-masked]>
Date: Mon, 29 Nov 2021 16:20:55 -0600

On 11/29/2021 4:02 PM, Brian E Carpenter wrote:
> This appears paradoxical, but it seems to me that writing things down 
> rather than leaving them as folklore makes them *easier* for our 
> successors to change, not harder, whatever form of words we adopt. 

I see the general point you're making, and suspect it's even more true 
if these principles are written down by the RSWG.

To be crystal clear: I'm not objecting to writing down basic principles 
for the series; I just don't think it's the role of this program to do so.

/a

---

From: Adam Roach <[email-masked]>
Date: Mon, 29 Nov 2021 16:21:47 -0600

> We're talking about now, not 50 years ago. 

I'm talking about 50 years in the future.

/a

---

From: Michael StJohns <[email-masked]>
Date: Mon, 29 Nov 2021 17:23:49 -0500

On 11/29/2021 4:54 PM, Stephen Farrell wrote:
>>> subject to change within this process.  To use a fairly weak 
>>> analogy, this document we're working on is a constitution, while the 
>>> RSWG/RSAB will be writing laws subject to that constitution. 
>

To put it slightly differently, changes to "the text proposed" can 
originate in the RSWG and be approved by the RSAB, but that might not be 
sufficient in all cases to permit their publication and adoption.   
I.e., "additional care is needed".

Mike

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 29 Nov 2021 15:33:23 -0700

>> On 29/11/2021 21:47, Adam Roach wrote:

<snip/>

> sufficient in all cases to permit their publication and adoption. I.e., 
> "additional care is needed".

What I hear Adam saying is that there's a difference between "please 
take care about this" and "you need a super-majority to change this".

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 29 Nov 2021 15:38:13 -0700

> for the series; I just don't think it's the role of this program to do so.

This is my feeling as well.

In particular, I'm concerned about blowing up this Program and our 
progress (dare I even say consensus) on the governance process.

Peter

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 29 Nov 2021 22:46:04 +0000

Hiya,

On 29/11/2021 22:20, Adam Roach wrote:
> for the series; 

A question: I don't understand how that's consistent with
your other points about not favouring today's opinions over
those of future people who'll be involved in the RSWG? Do
you really think it'd be any easier to change these kinds
of thing if done later by the RWSG and not now?

> I just don't think it's the role of this program to do so.

I do, but that's probably obvious:-)

S.

---

From: Adam Roach <[email-masked]>
Date: Mon, 29 Nov 2021 16:57:17 -0600

On 11/29/2021 4:46 PM, Stephen Farrell wrote:
>> To be crystal clear: I'm not objecting to writing down basic 
>> principles for the series; 
>

Yes.

I do.

I covered this exact point in detail in my initial message today -- in 
fact, it comprises about half of the text in that message -- and you 
actually quoted the primary sentence that explains this in your response 
to that message. As per Joel's objection, I request that upon re-reading 
that sentence, you replace "sacrosanct" with the phrase "meta laws that 
are not generally subject to change within this process."

/a

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 29 Nov 2021 18:45:04 -0500

I do not think that any of us fall into either the camp "this is what we 
do, and therefore must be kept" or "this is new and therefore must be 
better."

However, I do have a bias against changing things that serve important 
purposes without careful examination and consultation.  I presume 
(although I do not know) that you do not share this bias.  So I am not 
asking that the bias itself be recorded in the document.  But I do want 
something that effects that bias with regard to those things we can 
agree serve important purposes.

And yes, I do think that it is our job to agree on those.  Because that 
is tied to the structuring we create.

Yours,
Joel

---

From: Adam Roach <[email-masked]>
Date: Mon, 29 Nov 2021 17:59:22 -0600

On 11/29/2021 5:45 PM, Joel M. Halpern wrote:
> (although I do not know) that you do not share this bias.

That's not quite right, but I think it's safe to say that I'm likely to 
believe the process should be more nimble than it currently is. For 
example: work on the the RFC format change began in late 2012, and 
appears to be mostly (although not completely) concluded today, nearly 9 
years later. I am solidly of the opinion that this is not the right 
balance of agility versus stability.

> So I am not asking that the bias itself be recorded in the document. 
> But I do want something that effects that bias with regard to those 
> things we can agree serve important purposes. 

What's your take on Jay's most recent proposal?

/a

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 29 Nov 2021 19:04:59 -0500

I must have misread an email.  I did not see a proposal on this issue 
from Jay.  can you point me at it?

Thank you,
Joel

---

From: Adam Roach <[email-masked]>
Date: Mon, 29 Nov 2021 18:07:05 -0600

> from Jay.  can you point me at it?

https://mailarchive.ietf.org/arch/msg/rfced-future/CPKDxkV1DxvV6hlXsLrVf5sHF0Q/

/a

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 30 Nov 2021 00:10:38 +0000

On 29/11/2021 23:59, Adam Roach wrote:
> For example: work on the the RFC format change began in late 2012, and 

That's a fair point. Way more nimble that that seems totally
sensible. That said, I'm not sure any of the principles I'd
argue to include that caused that delay.

S.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 29 Nov 2021 19:19:32 -0500

The proposal I see is:
I wonder if all sides could agree to a compromise on the question of 
principles whereby the document sets the bar by which any principles can 
be added/changed/removed/reinterpreted but not the principles themselves?

For me, that is not effective.  It defines a process for some set of 
principles which may some day exist.  But does not make that process 
apply to anything.  Hence, I do not see what putting that in this 
document would accomplish.

Yours,
Joel

---

From: Adam Roach <[email-masked]>
Date: Mon, 29 Nov 2021 18:25:50 -0600

On 11/29/2021 6:10 PM, Stephen Farrell wrote:
>> For example: work on the the RFC format change began in late 2012, 
>> and appears to be mostly (although not completely) concluded today, 
>> nearly 9 years later. I am solidly of the opinion that this is not 
>> the right balance of agility versus stability.
>

It is, however, trivially easy to imagine, had we attempted to define 
such principles some while back, that they would contain language that 
says roughly "RFCs are copied by the interested people and printed or 
displayed at their site on their equipment. This means that the format 
of the online files must meet the constraints of a wide variety of 
printing and display equipment. To this end, the character codes used in 
RFCs are ASCII; each page must be limited to 58 lines followed by a 
form-feed on a line by itself; and each line must be limited to 72 
characters followed by a carriage return and line feed. No overstriking 
or underlining is allowed."

That was an incredibly sensible thing to say when RFC 825 was published, 
and people probably would have agreed to it as a bedrock principle.

/a

---

From: Adam Roach <[email-masked]>
Date: Mon, 29 Nov 2021 18:33:58 -0600

The primary thing that it does -- which is why I asked in this context 
-- is provide the kind of ballast "against changing things that serve 
important purposes without careful examination and consultation."

To be clear, I'm not 100% sold, in large part because I'm concerned 
we're likely not to agree on exactly what that ballast should look like 
(I'm willing to give it a go if others are). However, if it's a 
compromise that we could all move forward with, then I could probably 
live with it for the primary reason that it gets us out of the temporary 
holding pattern for RFC governance more quickly; and for the secondary 
reason that it at least establishes a consistent baseline for changing 
principles rather than having ad-hoc per-principle guidelines about what 
it might take to change something.

But if you don't see value in that, I guess we're back where we were.

/a

On 11/29/2021 6:19 PM, Joel M. Halpern wrote:
> principles whereby the document sets the bar by which any principles 
> can be added/changed/removed/reinterpreted but not the principles 
> themselves?
>
>>> I must have misread an email.  I did not see a proposal on this 
>>> issue from Jay.  can you point me at it?
>>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 30 Nov 2021 00:34:27 +0000

> and people probably would have agreed to it as a bedrock principle.

Again, that's fair. But it seems equally fair to me to
imagine that someone today, or shortly, might argue that
the latest rendering technology for phones or tablets or
for viewing in an IDE or the latest githubbery is clearly
better and for that to be equally wrong.

The principles that I think we want to document relate
to longevity and archival forms as goals and not the
specific recipes for producing those. (Such recipes are
fine things for the RSWG to consider, as they are
proposed.)

I think the text suggested (as in Joel/Brian text) is a
great start for text at right level of abstraction.

Cheers,
S.

---

From: Jay Daley <[email-masked]>
Date: Tue, 30 Nov 2021 13:35:00 +1300

Joel

> On 30/11/2021, at 1:19 PM, Joel M. Halpern <[email-masked]> wrote:
> 
> The proposal I see is:
> I wonder if all sides could agree to a compromise on the question of principles whereby the document sets the bar by which any principles can be added/changed/removed/reinterpreted but not the principles themselves?
> 
> For me, that is not effective.  It defines a process for some set of principles which may some day exist.  But does not make that process apply to anything.  Hence, I do not see what putting that in this document would accomplish.

A thought experiment - imagine there are two principles X and Y that you want included in this document but we can only reach consensus that X is included now not Y and we all agree that the document can move forward.  That then leaves the situation that principle X has the extra level of protection that you would like to see, but not Y making it easier to create policy that contradicts it.  It’s also questionable whether any process would exists by which Y could achieve that same level of protection.

Would that be a better outcome than my proposal?

Jay

>>> I must have misread an email.  I did not see a proposal on this issue from Jay.  can you point me at it?
>> https://mailarchive.ietf.org/arch/msg/rfced-future/CPKDxkV1DxvV6hlXsLrVf5sHF0Q/ /a
> 
> -- 

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 29 Nov 2021 20:06:32 -0500

Fair question.

Getting clarify on what principles we can agree on would help me.
Having some degree of protection (not permanence) for those principles 
would help.

I well understand that neither perfection nor everything I want are 
reasonable goals.

On the other hand, if there really are no principles we can agree on, 
then I am very concerned that this process is on a road to hell paved 
with good intention.

Yours,
Joel

---

From: Adam Roach <[email-masked]>
Date: Mon, 29 Nov 2021 19:11:36 -0600

> then I am very concerned that this process is on a road to hell paved 

Hard agree.

I don't think we're anywhere near that situation. What I *do* think is 
that it's going to take a fair bit of discussion to tease out the set of 
base principles we do all agree on, and even longer to hammer out all 
the nuance that people are going to want to attach to each of them. And 
I don't think it's reasonable to delay creation of a non-temporary 
governance structure for as long as that's going to take.

/a

---

From: Martin J. Dürst <[email-masked]>
Date: Tue, 30 Nov 2021 10:36:49 +0900

>>> the right balance of agility versus stability.

As with all standards-related things (and many other things, too), they 
always take longer than predicted or desired. The speed for upcoming 
changes will meet the same fate, whether we like it or not.

> printing and display equipment.

Up to that point, with some tweaks, that might have been a reasonable 
principle, and may be a reasonable principle even now. And something 
akin to this principle actually was considered very carefully when 
working on the RFC format change.

The ultimate conclusion was that technology had advanced enough that 
wherever needed, a system understanding HTML/CSS and the necessary fonts 
covering Unicode should be widely available, or else a way to print PDF/A.

> To this end, the character codes used in 

That's details, and I think nobody (possibly with the exception of those 
who say "I don't know what archival means") has seriously proposed to 
include such details.

> and people probably would have agreed to it as a bedrock principle.

The principle, yes. The details, at the time yes, but as details, not as 
principle. And having had such a principle would not, in my view, have 
seriously affected the effective timeline for the RFC format change. 
Because indeed the general perception in the discussion was that such a 
principle existed and was important.

What took time was a) to convince some people that technology indeed had 
moved ahead (when you never print out anything else than ASCII, you 
don't realize how much you can print out on your system), b) to convince 
people that there would be an advantage in having non-ASCII characters 
included in a controlled way, for example for names and for examples 
(and actually not much else), c) to work out the details.

Regards,   Martin.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 29 Nov 2021 18:38:07 -0700

Hard agree.

Further, I'm concerned about violating the principle of least user 
surprise when (or, at this stage, if?) we take the results of this 
program back to the broader community. "You know that program that was 
going to define an open governance process for making future changes to 
policies related to the RFC Series? Well, they also defined a base set 
of perpetual principles for the RFC Series." Even if *we* think we have 
carte blanche from the IAB (note: I'm not convinced we do), I don't know 
if that's how folks who aren't paying close attention to this program 
see it. At the very least, if we're going to go down this path, maybe we 
need to issue a wider call for community participation so folks are 
aware that they might want to get involved.

Peter

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 30 Nov 2021 02:01:40 +0000

Hiya,

> aware that they might want to get involved.

Wider call: good.

Expectation of useful feedback: not so much;-( But has to
be done anyway.

"perpetual", "bedrock", "sacrosanct": not useful. Mind you,
I'm as guilty as many of us of sometimes flowery language
so this is just commentary, not condemnation:-)

Cheers,
S.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 29 Nov 2021 19:28:22 -0700

On 11/29/21 7:01 PM, Stephen Farrell wrote:
>> going to define an open governance process for making future changes 
>> to policies related to the RFC Series? Well, they also defined a base 
>> set of perpetual principles for the RFC Series." Even if *we* think we 
>> have carte blanche from the IAB (note: I'm not convinced we do), I 
>> don't know if that's how folks who aren't paying close attention to 
>> this program see it. At the very least, if we're going to go down this 
>> path, maybe we need to issue a wider call for community participation 
>> so folks are aware that they might want to get involved.
> 
> Wider call: good.
> 

Fair enough. Adam suggested a less flowery expansion of "sacrosanct", so 
I'll suggest a less flowery expansion of "perpetual principles": 
fundamental propositions that we expect to guide the evolution of the 
RFC Series as a whole for the next 20-50 years.

Peter

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 30 Nov 2021 02:42:12 +0000

> Fair enough. Adam suggested a less flowery expansion of "sacrosanct", so

Thanks both. (And again, I'm as guilty;-)

> RFC Series as a whole for the next 20-50 years.

That last sounds like a good thing to me (without being
fixated on specific integers).

Perhaps part of the divergence in opinion here is that the
RFC series has contributed to at least a couple of not-
equally recognised things: documenting some of the recent
past and the evolution of the Internet (as an archival
series) but also documenting the present and future (via new
RFCs, some of which are rubbish, but a non-negligible
proportion of which have been associated with significant
changes to the Internet, and hence, the world).

I'm not sure if that helps much, but maybe different sets
of us are putting more or less emphasis on those different
aspects leading us to different conclusions.

S.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 30 Nov 2021 16:00:33 +1300

> aware that they might want to get involved.

+N, where N is a large integer. I think with "principles" in the text,
the community last call will definitely demonstrate what Dorothy Parker
meant by "What fresh hell is this?". We might get away with "Historical
Properties", but not with "Principles".

    Brian

---

From: Adam Roach <[email-masked]>
Date: Mon, 29 Nov 2021 23:51:21 -0600

On 11/29/2021 7:36 PM, Martin J. Dürst wrote:
> And something akin to this principle actually was considered very 
> carefully when working on the RFC format change. 

...but then later wrote...

> And having had such a principle would not, in my view, have seriously 
> affected the effective timeline for the RFC format change.

It -- or as you astutely point out, something akin to it -- manifestly 
did impact the RFC format change timeline. Substantial cycles in that 
effort were burned on arguing over presentation formats, with potential 
outputs including HTML, PDF, Paginated Text, Unpaginated Text, and 
various ebook formats. "Printability" was repeatedly surfaced as an 
argument to boost support for certain formats (e.g., paginated text), as 
was "meeting the constraints of a wide variety of... display equipment" 
(e.g., ebook formats).

It should be lost on no one that both of the aforementioned example 
formats were ultimately rejected by that effort.

/a

---

From: Eliot Lear <[email-masked]>
Date: Tue, 30 Nov 2021 07:17:53 +0100

On 30.11.21 02:11, Adam Roach wrote:
> that it's going to take a fair bit of discussion to tease out the set 
> of base principles we do all agree on, and even longer to hammer out 
> all the nuance that people are going to want to attach to each of 
> them. And I don't think it's reasonable to delay creation of a 
> non-temporary governance structure for as long as that's going to take.

As I've mentioned before, we can poll to see where we are even close on 
some principles.   That would at least permit us to agree on that which 
we can agree.  We can discuss this option on the call.

Eliot

---

From: Martin J. Dürst <[email-masked]>
Date: Tue, 30 Nov 2021 15:18:35 +0900

>> affected the effective timeline for the RFC format change.

Well, sorry, let me be more precise.

What I meant was that whether the principle had been *written down* or 
not did not affect the timeline. What affected the timeline was that the 
principle was accepted widely, but that there were differences in 
opinion about how well the proposed solutions would work out for that 
principle.

> formats were ultimately rejected by that effort.

As far as I count, you mention five formats (1) HTML, 2) PDF, 
3) Paginated text, 4) Unpaginated text, 5) ebook formats). 
Which two do you mean were rejected?

And the ultimate outcome was okay because both HTML and in particular 
PDF are indeed quite printable, and displayable on a wide range of devices.

Regards,    Martin.

---

From: Adam Roach <[email-masked]>
Date: Tue, 30 Nov 2021 00:21:44 -0600

> Which two do you mean were rejected? 

"(e.g., paginated text)"

"(e.g., ebook formats)"

/a

---

From: Eliot Lear <[email-masked]>
Date: Tue, 30 Nov 2021 13:13:04 +0100

Hi

On 30.11.21 03:28, Peter Saint-Andre wrote:
> Fair enough. Adam suggested a less flowery expansion of "sacrosanct", 
> so I'll suggest a less flowery expansion of "perpetual principles": 

Just a reminder- the governance structure of the series and personnel 
have changed a bit more frequently than that, even if the document 
format has held relatively constant.  What that says to me is that we 
should be cautious about looking TOO far out to the future.

Eliot