Subject: [Rfced-future] **Program Last CALL: draft-iab-rfcefdp-rfc-model-05** Ends 5 Nov 2021

From: Eliot Lear <[email-masked]>
Date: Fri, 22 Oct 2021 10:13:34 +0200

Dear Colleagues,

This begins the two week last call on 
draft-iab-rfcedfp-rfced-model-05.[1]  This call will run through Friday, 
5 Nov 2021.  Please send your comments to this mailing list.  We will 
address any issues that are raised during our IETF time slot (and of 
course on list).

Brian and Eliot

[1] https://datatracker.ietf.org/doc/html/draft-iab-rfcefdp-rfced-model

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 25 Oct 2021 17:44:05 +1300

Hi,

I have re-read the whole document and I am very happy with it.

In case I forget later, many thanks to Eliot, Brian R, and Peter for driving this forward.

Regards
    Brian Carpenter
    Thinking of the IETF standards process: https://xkcd.com/2530/

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 25 Oct 2021 16:43:57 +1100

Hey everyone,

I've read this again fairly closely.  It is good, though I think we might want to adjust a few things.  I've opened two issues that could either be lack of clarity or a lack of a decision.  They are related:

https://github.com/intarchboard/program-rfced-future/issues/93
https://github.com/intarchboard/program-rfced-future/issues/94

There is text that limits appeals of RSWG decisions to just procedural matters.  (i.e., you can't appeal if you disagree)

There is no similar text for RSAB decisions, but the supporting language seems to assume that is the case (that's #93).  However, if you look at #94 (which asks if the RSAB bear the responsibility for timely decisions in the event of a dispute) the RSAB is responsible for interpreting existing policies.  That interpretation might be cause for appeal if someone disagrees with the interpretation from the RSAB.  Should this be in scope for appeal?

That is, when pressed for a timely answer in order to resolve a dispute...

* the RSAB might make a decision that they believe is necessary because the existing policies do not cover it, but someone might disagree and say that the outcome is covered by existing policies
* the RSAB might make a decision that everyone agrees is not covered by existing policies, the substance of which the (prospective) appellant disagrees with

I've also opened a few editorial issues and pull requests, but I think that this is good shape overall.

On Fri, Oct 22, 2021, at 19:13, Eliot Lear wrote:
> -- 
> Rfced-future mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/rfced-future
>
> Attachments:
> * OpenPGP_0x87B66B46D9D27A33.asc
> * OpenPGP_signature

---

From: Eliot Lear <[email-masked]>
Date: Mon, 25 Oct 2021 08:30:54 +0200

Hi Martin,

Thanks for taking the time, and for doing your LC check in a timely 
manner.  As you've indicated, it seems to me that these two issues have 
to be taken together.

On 25.10.21 07:43, Martin Thomson wrote:
> There is no similar text for RSAB decisions, but the supporting language seems to assume that is the case (that's #93).

In my opinion, the intent of this group was at least that appeals of the 
RSAB to the IAB  be limited to procedural matters.  I could be mistaken, 
but people should say so now if they believe I am.

>    However, if you look at #94 (which asks if the RSAB bear the responsibility for timely decisions in the event of a dispute) the RSAB is responsible for interpreting existing policies.  That interpretation might be cause for appeal if someone disagrees with the interpretation from the RSAB.  Should this be in scope for appeal?

What Issue 94 reads is as follows:

>     However, in the interest of time the disagreement may be resolved
>     as the parties best see fit while the RSWG formulates a more
>     general policy.
>
> "the parties" is not quite specific enough. I think that you want to 
> pin this responsibility on the RSAB. That suggests that an appeals 
> path that is not exclusively process-based might be needed (see #93 
> <https://github.com/intarchboard/program-rfced-future/issues/93>).
>
This is in Section 4.4, describing what happens at the time of 
publication of an RFC.  The "parties" here may refer to two or more 
stream owners, and indeed the previous bullet states the following:

>    *  If there is a conflict with a cross-stream policy, the RPC should
>       consult with the RSAB to achieve a resolution.

I interpret the previous intent of the group for these two bullets as 
having been that the RSAB should provide the RPC interim guidance so 
that publication can indeed proceed, the assumption being that the RSAB 
could move considerably faster than the RSWG.  Again, if I'm wrong, 
please say so.

This still leave's Martin's question about the IAB being able to address 
more than just process.

People should comment on how they want these two issues resolved.

Eliot

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 26 Oct 2021 13:59:23 +1100

I've read over the document and am generally very happy where we've ended up.

A few questions occurred to me:

1) Should we use this opportunity to nominate a set of existing RFCs to flip over to the Editorial stream? If we don't, it'll likely need to be done one-by-one as they need to be revised.

2) Section 4.2 seems to put the XML format under the exclusive control of the RPC. Is that really our intent? Likewise for the 'readability and presentation of RFCs'.

3) One of the things that concerned me about the previous model was the lack of any direct link between the amount of work requested of the RPC and what it ultimately cost us as an organisation. In other words, we keep on asking for more because the costs are hidden. I don't know if we can address that in *this* document, but it's something that continues to concern me. Any thoughts here?

Cheers,

> On 22 Oct 2021, at 7:13 pm, Eliot Lear <[email-masked]> wrote:
> 
> Dear Colleagues,
> 
> This begins the two week last call on draft-iab-rfcedfp-rfced-model-05.[1]  This call will run through Friday, 5 Nov 2021.  Please send your comments to this mailing list.  We will address any issues that are raised during our IETF time slot (and of course on list).
> 
> Brian and Eliot
> 
> <OpenPGP_0x87B66B46D9D27A33.asc>-- 

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

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 26 Oct 2021 14:16:12 +1100

On Tue, Oct 26, 2021, at 13:59, Mark Nottingham wrote:
> 1) Should we use this opportunity to nominate a set of existing RFCs to 
> flip over to the Editorial stream? If we don't, it'll likely need to be 
> done one-by-one as they need to be revised.

An ad hoc approach is fine.

> 2) Section 4.2 seems to put the XML format under the exclusive control 
> of the RPC. Is that really our intent? Likewise for the 'readability 
> and presentation of RFCs'.

I didn't read that text in that way, but in looking again, it could be clearer.

My interpretation is that there is a format specification owned by the RSWG, but the RPC will need to develop policies and practices that allow them to use that format specification effectively.  That is, the format specification is loose, but they have a need for tighter (operational) constraints on its interpretation.  For instance, an XML element might have semantics defined in an RFC, but the actual usage might benefit from some guidelines that ensure consistent use of that element.

(I have no opinion on your third question.)

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 26 Oct 2021 17:40:04 +1300

> 1) Should we use this opportunity to nominate a set of existing RFCs to flip over to the Editorial stream? If we don't, it'll likely need to be done one-by-one as they need to be revised.

I agree with Martin. Put it on the RSWG's initial action list. (There are other similar issues, such as reclassifying many of the early RFCs that are currently classified as Unknown.)

> 2) Section 4.2 seems to put the XML format under the exclusive control of the RPC. Is that really our intent? Likewise for the 'readability and presentation of RFCs'.

Section 4.2 starts thus:
"Under and consistent with the high-level policies defined for the RFC
  Series in general or particular streams,..."

I sincerely hope your reading is wrong. Maybe we need a text tweak to clarify. We've assumed all along that RSWG/RSAB will approve the style guide RFC, for example. It's clearly an RFC that would fit in the Editorial stream. Similarly the SVG mess (see rfc-interest passim) and any revision of the various RFCs about xml2rfcv3. But in both cases, clearly the RPC manages the details and the RPC and/or the LLC provide the tools.

We have carefully constructed the rules such that RPC staff can and should participate in RSWG discussions.
  
> 3) One of the things that concerned me about the previous model was the lack of any direct link between the amount of work requested of the RPC and what it ultimately cost us as an organisation. In…

Indeed, I don't think we should cover that here. One benefit of the new regime is that this really becomes the same question as we might ask about anything else funded through the LLC, so I think we should punt this to the LLC too.

Rgds
    Brian C

---

From: Lars Eggert <[email-masked]>
Date: Tue, 26 Oct 2021 13:07:14 +0300

Hi,

On 2021-10-22, at 11:13, Eliot Lear <[email-masked]> wrote:
> This begins the two week last call on draft-iab-rfcedfp-rfced-model-05

I read the document. It's generally in very good shape. I opened a few issues and suggest a few PRs:

Are contributions to the RSWG contributions to the IETF?
https://github.com/intarchboard/program-rfced-future/issues/100

Member of the community vs. delegate
https://github.com/intarchboard/program-rfced-future/issues/98

3-month timer restart?
https://github.com/intarchboard/program-rfced-future/issues/97

Require participants to publish I-Ds, not just generate them
https://github.com/intarchboard/program-rfced-future/pull/99

Wording clarifications related to appointing bodies and stream managers
https://github.com/intarchboard/program-rfced-future/pull/96

Suggestions to address some nits
https://github.com/intarchboard/program-rfced-future/pull/95

Thanks,
Lars

---

From: Eliot Lear <[email-masked]>
Date: Tue, 26 Oct 2021 12:43:00 +0200

Thanks, Lars.  Just one note below:

> https://github.com/intarchboard/program-rfced-future/issues/98

This issue should be taken as editorial, I think.

> https://github.com/intarchboard/program-rfced-future/issues/97

People should discuss.

> https://github.com/intarchboard/program-rfced-future/pull/99

Editorial.

> https://github.com/intarchboard/program-rfced-future/pull/96
Editorial.
> https://github.com/intarchboard/program-rfced-future/pull/95

Editorial.

My view.  Others can disagree of course.

Eliot

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 26 Oct 2021 15:34:54 +0100

Hiya,

I've stayed out of discussion for a while but have now read
the draft and agree it seems to reflect the list discussion.
I'm also ok with the content, though not thrilled by it, but
I don't object.

A few not-quite editorial comments below that I don't recall
being discussed on the list (apologies if they were):

- There is only brief mention that the RFC series has some
heritage. I think that'd be better expanded to include some
guidance for the RSWG that the preservation and propagation
of the positive parts of that heritage is a goal for the
RSWG. I don't think we ought try define that heritage (as
that'd likely be hard/controversial and very nitty) but a
total lack of guidance along those lines seems wrong to
me. That might take a bit of wordsmithing but the editor
may be best placed to start that.

- In various places, the LLC is described as the "ultimate"
authority for various things. AFAICS, each of those is ok
as they're all (I think) properly qualified, but I think
it'd be better if there were a statement somewhere that the
LLC only has that position because of the iasa2 process,
i.e., because that's what the (IETF/IRTF) community
currently want.

- Lastly, a question: has anyone asked people who've held
the role of RSE (or acting RSE), or significant folks from
the RPC, if there's anything falling between the cracks?
(I.e. not whether or not they like the draft just whether
something's being missed.) I think an explicit check like
that might be useful, and it could be those people might
otherwise be reticent to send a full review to the list.
I'd be fine if the chairs just did this off-list and brought
any interesting results to the list, so this is more a
request to the programme chairs really.

Cheers,
S.

---

From: Eliot Lear <[email-masked]>
Date: Tue, 26 Oct 2021 16:38:48 +0200

Hi Stephen,

Thank you.  I have two questions for you below:

> may be best placed to start that.

Do you have some proposed text to start with?

> i.e., because that's what the (IETF/IRTF) community

Again, could you take a stab at what sort of text you'd like to see?

Thanks,

Eliot

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 26 Oct 2021 15:53:56 +0100

Hiya,

> Thank you.  I have two questions for you below:

Fair questions. I didn't propose any though as
I've not been active in the discussion for a
few months, but since you ask...

(BTW, I'd be fine if someone else wanted to start
over proposing text rather than propose mods to
mine below.)

> Do you have some proposed text to start with?

Add to 1st para of intro, before last sentence,
just after "1969. ":

"The RFC series therefore has significant heritage
that seems to have overall been to the benefit of
the Internet. The RSWG should therefore also consider
the preservation and propagation of that heritage as
a goal as it considers process evolution."

> Again, could you take a stab at what sort of text you'd like to see?

Somewhere, don't care where:

"While the LLC is the 'ultimate' authority for various
administrative actions related to the RFC series and the
IETF more generally, the LLC holds that position thanks
to community consensus [ref]. So while the RSWG is not
scoped to consider changes to the LLC's authority, such
changes are within the gift of the IETF community, albeit
constituted differently from the RSWG (e.g. in some
iasa2-like WG [ref])."

I'm sure that last isn't good enough, but hopefully
you get the gist,

Cheers,
S.

---

From: Eliot Lear <[email-masked]>
Date: Tue, 26 Oct 2021 18:03:31 +0200

> I didn't read that text in that way, but in looking again, it could be clearer.

Again, my favorite question: do you have a preferred correction?

Eliot

---

From: Jay Daley <[email-masked]>
Date: Wed, 27 Oct 2021 07:39:26 +1300

Stephen

> request to the programme chairs really.

Yes, the RPC and Temporary RFC Series Manager have been carefully watching this list and the document edits and I've been checking in with them regularly to make sure that everything is covered and that they have made their views known.

Jay

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

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

---

From: Jay Daley <[email-masked]>
Date: Wed, 27 Oct 2021 07:39:32 +1300

> On 27/10/2021, at 3:53 AM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> 

You haven’t actually explained why this text is needed. 

This is certainly a general qualifier on the authority of the LLC, but as you've pointed out in your proposed text there isn’t anywhere in this new model where the RSWG/RSAB can override the LLC or set new rules for the LLC so adding this qualifier doesn’t have any practical purpose for this draft.   There are plenty of statements of fact from other RFCs that aren’t in this I-D and arbitrarily adding some is in my view bad policy writing and just creates problems further down when the source of the facts needs to change.

Jay

> 
> Cheers,
> S.
> 
> 
>> Thanks,
>> Eliot
> <OpenPGP_0x5AB2FAF17B172BEA.asc>

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

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 26 Oct 2021 20:18:43 +0100

On 26/10/2021 19:39, Jay Daley wrote:
>>>> authority for various things. AFAICS, each of those is ok as
>>>> they're all (I think) properly qualified, but I think it'd be
>>>> better if there were a statement somewhere that the LLC only
>>>> has that position because of the iasa2 process, i.e., because
>>>> that's what the (IETF/IRTF) community currently want.
>> administrative actions related to the RFC series and the IETF more
>> generally, the LLC holds that position thanks to community
>> consensus [ref]. So while the RSWG is not scoped to consider
>> changes to the LLC's authority, such changes are within the gift of
>> the IETF community, albeit constituted differently from the RSWG
>> (e.g. in some iasa2-like WG [ref])."
>> 
>> I'm sure that last isn't good enough, but hopefully you get the
>> gist,
> 
> This is certainly a general qualifier on the authority of the LLC,
> but as you've pointed out in your proposed text there isn’t anywhere
> in this new model where the RSWG/RSAB can override the LLC or set new
> rules for the LLC so adding this qualifier doesn’t have any practical
> purpose for this draft.   There are plenty of statements of fact from
> other RFCs that aren’t in this I-D and arbitrarily adding some is in
> my view bad policy writing and just creates problems further down
> when the source of the facts needs to change.

Sure, that's arguable, but if one accepts that then there'd
be no occurrences of the word "ultimate" in the draft, don't
you agree?

IMO the draft could give the wrong impression as to which is
the dog and which the tail, esp for readers unfamiliar with
the history (which'd be most of the few readers), so I think
in this case that kind of added text would be a worthwhile
addition.

Cheers,
S.

>> Cheers, S.
>>> Thanks, Eliot

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 26 Oct 2021 20:20:25 +0100

Hiya,

On 26/10/2021 19:39, Jay Daley wrote:
> Yes, the RPC and Temporary RFC Series Manager have been carefully
> watching this list and the document edits and I've been checking in
> with them regularly to make sure that everything is covered and that
> they have made their views known.
That's good thanks. Not quite the complete set, but good.

Cheers,
S.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 27 Oct 2021 09:06:37 +1300

> On 26.10.21 12:07, Lars Eggert wrote:

...
>> https://github.com/intarchboard/program-rfced-future/issues/97

    *  Voting on approval of policy documents produced by the RSWG shall
       be delayed until the vacancy or vacancies have been filled, up to
       a maximum of 3 months; this clause does not apply to a vacancy of
       the RSCE role, only of the stream representatives enumerated
       above.

I suggest s/3 months/3 months after the first vacancy/

Rationale: to exclude gaming the system by triggering a succession of vacancies.

    Brian

---

From: "StJohns, Michael" <[email-masked]>
Date: Tue, 26 Oct 2021 17:44:33 -0400

> I suggest s/3 months/3 months after the first vacancy/

S/3 months/3 months after the document is presented to the RSAB for
approval/

Same rationale and review incentive for the various organizations to get
their acts together.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 27 Oct 2021 10:12:57 +1100

How about:
  https://github.com/intarchboard/program-rfced-future/pull/101

Cheers,

> On 27 Oct 2021, at 3:03 am, Eliot Lear <[email-masked]> wrote:
> 
> 
> 
> <OpenPGP_0x87B66B46D9D27A33.asc>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 27 Oct 2021 00:22:58 +0100

Hi Mark,

> https://github.com/intarchboard/program-rfced-future/pull/101

Apologies if I'm getting the githubbery differy wrong but
your suggestion seems to add:

"In the absence of a high-level policy documented in an RFC,
or to specify the detail of its implementation, the RPC can
define working policies regarding the editorial preparation
and final publication and dissemination of RFCs."

My starting point is to be strongly opposed to that as it
puts the RPC in the position of initiating, and being the
proponent for, policy changes. That seems to me to be the
opposite of where we want to be, despite the inefficiency
of where we are:-)

Cheers,
S.

>>>> 2) Section 4.2 seems to put the XML format under the exclusive
>>>> control of the RPC. Is that really our intent? Likewise for the
>>>> 'readability and presentation of RFCs'.
>>>> 
> -- Mark Nottingham   https://www.mnot.net/
>

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 27 Oct 2021 10:30:58 +1100

Hi Stephen,

FWIW I think the current text encourages such things even more strongly. 

I agree that the RPC setting policies willy-nilly is concerning, but I also acknowledge that the reality is that they'll need to in some circumstances, else many RFCs will be delayed indefinitely while the RSWG and RSAB chew on an ever-increasing pile of problems.

A few things we can do to ameliorate that:

- Make it clear that RPC policies are temporary and subject to review by the RSWG
- Make it clear that RPC polices are not pre-emptive; although persuasive, they can be overridden by the RSWG
- Limit the scope of RPC policies

I think all three are implied by the current text and the proposal, but could be clarified.

Cheers,

> On 27 Oct 2021, at 10:22 am, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hi Mark,
> 
>> How about: https://github.com/intarchboard/program-rfced-future/pull/101
>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 27 Oct 2021 00:47:35 +0100

Hiya,

> FWIW I think the current text encourages such things even more

Hmm, maybe I need to re-read the draft as I didn't get that
intent from the text nor the previous list discussion.

Again, I'd be strongly opposed to the RPC setting policy in
almost all circumstances. My guess, from dealing with them,
as an author/WG chair/AD, has been that they'd also not want
to be put in that place. (If that's wrong, be great to know
that.)

> I agree that the RPC setting policies willy-nilly is concerning, but
> I also acknowledge that the reality is that they'll need to in some
> circumstances, else many RFCs will be delayed indefinitely while the
> RSWG and RSAB chew on an ever-increasing pile of problems.

Huh? If we're setting the streams up to be commonly waiting
on the RSWG/RSAB then we're doing it wrong. I don't see any
ever-increasing pile but maybe my pile-vision is limited;-)

> - Make it clear that RPC policies are temporary and subject to review
> by the RSWG - Make it clear that RPC polices are not pre-emptive;
> although persuasive, they can be overridden by the RSWG - Limit the
> scope of RPC policies

"RPC-initiated policy" should be a misnomer I think - isn't
the RPC intended to follow, and not set, policy ?If I'm wrong
there then the draft certainly confused me. (*)

Cheers,
S.

(*) To be clear: I think the RPC have done, and will keep
doing, a great job. And where they see difficulties, we
should have mechanisms in place for those to be raised and
dealt with efficiently.

>> Apologies if I'm getting the githubbery differy wrong but your
>> suggestion seems to add:
>> 
>> "In the absence of a high-level policy documented in an RFC, or to
>> specify the detail of its implementation, the RPC can define
>> working policies regarding the editorial preparation and final
>> publication and dissemination of RFCs."
>> 
>> My starting point is to be strongly opposed to that as it puts the
>> RPC in the position of initiating, and being the proponent for,
>> policy changes. That seems to me to be the opposite of where we
>> want to be, despite the inefficiency of where we are:-)
>> 
>> Cheers, S.
>> 
>>> Cheers,
>>>> On 27 Oct 2021, at 3:03 am, Eliot Lear <[email-masked]> wrote: On
>>>> 26.10.21 05:16, Martin Thomson wrote:
>>>>>> 2) Section 4.2 seems to put the XML format under the
>>>>>> exclusive control of the RPC. Is that really our intent?
>>>>>> Likewise for the 'readability and presentation of RFCs'.
>>>> Again, my favorite question: do you have a preferred
>>>> correction? Eliot <OpenPGP_0x87B66B46D9D27A33.asc>

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 26 Oct 2021 16:59:37 -0700

> heritage.

IMHO, this sounds like good appendix material.

-- 
Wes Hardaker
USC/ISI

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 27 Oct 2021 01:04:14 +0100

Hiya,

> IMHO, this sounds like good appendix material.

Perhaps. But the draft as-is seems to me to lack any
guidance from the programme on this aspect, and I for
one think it's important, so I'd argue that having it
as some up-front, at the top, text about one goal for
the RSWG, would be a better plan than it being one of
various appendages.

Cheers,
S.

---

From: Jay Daley <[email-masked]>
Date: Wed, 27 Oct 2021 13:28:06 +1300

> On 27/10/2021, at 8:18 AM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> 
>>>>> - In various places, the LLC is described as the "ultimate" authority for various things. AFAICS, each of those is ok as
>>> "While the LLC is the 'ultimate' authority for various administrative actions related to the RFC series and the IETF more

For me, the word "ultimate" is used within the context of this model and it’s use doesn’t imply anything beyond that.  However, I’m personally not stuck on that word and "ultimate authority" could be replaced with "authority" or "ultimate remit" or ...

> in this case that kind of added text would be a worthwhile

That’s a very long stretch and even if it were possible, the document already includes "The IETF LLC is ultimately responsible to the community via the mechanisms outlined in its charter" as a contraindication.

Jay

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

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 26 Oct 2021 17:43:00 -0700

> a goal as it considers process evolution."

I don't believe that we should add this text. We should do what's
good for the series and not treat tradition as a major consideration.
People of course are free to argue for heritage in any specific
case, but we shouldn't codify that in the document.

> I'm sure that last isn't good enough, but hopefully

This also seems unnecessary. Everything about this is
the result of consensus decisions

-Ekr

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 27 Oct 2021 01:47:28 +0100

Hiya,

On 27/10/2021 01:28, Jay Daley wrote:
> For me, the word "ultimate" is used within the context of this model

I do agree that that word is qualified when used in draft-05.
Nonetheless, I think it's not a great idea to cast things in
that way.

> and it’s use doesn’t imply anything beyond that. 

I'm less sure that the reader will grok that.

> However, I’m
> personally not stuck on that word and "ultimate authority" could be
> replaced with "authority" or "ultimate remit" or ...

"current authority" would be accurate (on a decadal timescale
I guess) but would, I guess, also be as wrong as "ultimate"?

>> IMO the draft could give the wrong impression as to which is the
>> dog and which the tail, esp for readers unfamiliar with the history
>> (which'd be most of the few readers), so I think in this case that
>> kind of added text would be a worthwhile addition.
 >
> That’s a very long stretch 

I'm one reader of the text who disagrees. This programme
isn't taking place in a vacuum.

> and even if it were possible, the document
> already includes "The IETF LLC is ultimately responsible to the
> community via the mechanisms outlined in its charter" as a
> contraindication.

"ultimate" again then:-)

FWIW, I don't think "responsible to the community" is quite
right - the LLC was established *by* the community and could
(and may, in time,) be replaced by the community. My point is
that it's the community that decides which entities are setup
for what, and it'd be better if we avoided any impressions of
something (other than the community, however ill-defined)
being "ultimately responsible."

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 27 Oct 2021 01:54:42 +0100

Hiya,

> good for the series and not treat tradition as a major consideration.

It's entirely fine to disagree. You don't provide any reason
why we ought discount heritage though - why should we? Do we
really want to ignore all the benefits of an RFC series that
has weathered a number of industry ups and downs and the vast
expansion of the Internet? I don't think we'd be wise to do
that myself.

(And btw, I'm not at all tied to "this text" precisely.)

> case, but we shouldn't codify that in the document.

See above:-)

> the result of consensus decisions

Not yet! We're in the process of attempting to establish
whether or not that's the case so it's not valid to claim
an existing consensus as far as I can see. (That said,
had these topics been discussed on the list already, I'd
of course defer, but I don't think they were - references
welcome.)

Cheers,
S.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 26 Oct 2021 18:17:31 -0700

On Tue, Oct 26, 2021 at 5:54 PM Stephen Farrell <[email-masked]>
wrote:

> why we ought discount heritage though - why should we?

Well, I think I did provide a reason. "We should do what's good for
the series". You may not happen to find that reason persuasive,
but then I don't find your argument persuasive.

Do we
> expansion of the Internet? I don't think we'd be wise to do

My view here is rather different: what's successful here is that
people want to read IETF standards and not due to any particular
heritage of the RFC series.

> of course defer, but I don't think they were - references

I think perhaps you misunderstand me. What I'm saying is that
all of our governing documents are the result of community
consensus (once published) and so reiterating that here
is unnecessary IMO.

-Ekr

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 27 Oct 2021 02:55:35 +0100

Hiya,

On 27/10/2021 02:17, Eric Rescorla wrote:
> the series". 

ISTM that "the series" in the above is way less meaningful
if one ignores the heritage. My own impression is that the
RFC series includes some crap (to which I've contributed;-)
but also many gems, and the series (plus list archives)
exposes the evolution of that history (e.g. if one considers
RFC822 and successors) in a significantly useful manner.

Ignoring that, and assuming that only the latest take on
some topic, or mode of expression, is all the RSWG ought
care about, seems to me very short-sighted. Especially
for the RSWG we're in the process of establishing.

But we seem to agree that the "good of the series" ought be
a goal for the RSWG, yet that isn't stated anywhere in the
draft we're discussing. I think fixing that would be a fine
thing for us to do. I'd welcome other offers of text that
try capture that part of the series' heritage as a goal for
the putative RSWG.

> You may not happen to find that reason persuasive,

Again, disagreeing is fine and we've done it before:-)

> heritage of the RFC series.

Yet you used the "good of the series" phrase. To me that
implicitly implies more than just "the latest set of IETF
standards."

That said, I totally agree we ought improve the ways in
which readers can implement from current standards (e.g.
via something better than errata) but alongside that, we
really shouldn't ignore decades of heritage while we try
improve things.

> consensus (once published) and so reiterating that here

Fair enough. The other thread about the use of "ultimate"
may result in a good outcome, but if we do agree that "the
series" is more than just the current IETF standards then
perhaps we ought also consider a readership that are not
really part of the development of those standards for whom
reading that the LLC having "ultimate" authority may just
add to confusion, rather than reduce confusion.

Cheers,
S.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 27 Oct 2021 13:01:46 +1100

I don't even know what this means -- does it boil down to 'keep the good things' without a definition of 'good'? 

> On 27 Oct 2021, at 1:34 am, Stephen Farrell <[email-masked]> wrote:
>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 27 Oct 2021 03:04:54 +0100

Hiya,

On 27/10/2021 03:01, Mark Nottingham wrote:
> I don't even know what this means -- does it boil down to 'keep the
> good things' without a definition of 'good'?

Eliot pinned me down already so you're late:-)

But yes - I think we should try find some words that
guide the RSWG towards preserving the best of the RFC
series without us trying to define that "best" (since
we'd fail if we tried;-).

Cheers,
S.

>> guidance for the RSWG that the preservation and propagation of the
>> positive parts of that heritage is a goal for the RSWG. I don't
>> think we ought try define that heritage (as that'd likely be
>> hard/controversial and very nitty) but a total lack of guidance
>> along those lines seems wrong to me. That might take a bit of
>> wordsmithing but the editor may be best placed to start that.
>

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 26 Oct 2021 19:05:54 -0700

On Tue, Oct 26, 2021 at 6:55 PM Stephen Farrell <[email-masked]>
wrote:

> if one ignores the heritage.

I only meant it in the sense of the "collection of documents we
will be publishing".

> try capture that part of the series' heritage as a goal for

As I said, I am not in favor of this.

> implicitly implies more than just "the latest set of IETF

Well, maybe, but I doubt much more. The existing documents are already
published and I think we should make decisions that will best serve the
documents we plan to publish in the foreseeable future. I'm not particularly
invested in the notion of the "RFC Series" as a separate thing.

> really shouldn't ignore decades of heritage while we try

Given the number of people who seem invested in that heritage,
I think the risk that we will underweight that heritage is minimal.
I think the risk is far greater that we will overweight it, and for that
reason I am opposed to any text of this form in the document

> add to confusion, rather than reduce confusion.

No, not really. Those people aren't going to read this doc, and even
if they were, if they don't understand the consensus structure, they're
going to have bigger problems than the word "ultimate".

-Ekr

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 27 Oct 2021 03:15:00 +0100

Hiya,

I'm sending too much mail on this so will take a break
now but just on this bit...

> reason I am opposed to any text of this form in the document

ISTM we have at least two sets of people in this respect.

One are those (incl. me ) who want to not disregard the
RFC series' heritage.

Another (also incl. me) who want to improve the current
production mechanisms and representation of IETF standards.

The nice thing about sets is that they don't have to be
disjoint. We can do both things, and (I think) we'd lose
if we only try for one of those.

The current draft IMO ignores the former aspect and ought
not.

Cheers,
S.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 26 Oct 2021 19:20:43 -0700

Just to avoid confusion, this does not change my mind, and I am not in
favor of changing the draft in this way.

-Ekr

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 27 Oct 2021 16:08:16 +1300

We're engineers. We all know that if it ain't broke, don't fix it.
Stephen wants to codify that. I think that words like "legacy" and
"heritage" carry a bit of an emotional overtone. Is there a more
formal way of saying this without that emotional overtone?

Regards
    Brian

On 27-Oct-21 15:20, Eric Rescorla wrote:
> Just to avoid confusion, this does not change my mind, and I am not in favor of changing the draft in this way.
> 
> -Ekr
> 
> 
> On Tue, Oct 26, 2021 at 7:15 PM Stephen Farrell <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>     Hiya,
>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 27 Oct 2021 16:10:52 +1300

> I think all three are implied by the current text and the proposal, but could be clarified.

If you s/working policies/working practices/ I think it will make the intent clear
without undercutting the RSWG/RSAB policy role.

    Brian

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 27 Oct 2021 14:12:36 +1100

I like it; done.

> On 27 Oct 2021, at 2:10 pm, Brian E Carpenter <[email-masked]> wrote:
>

---

From: Eliot Lear <[email-masked]>
Date: Wed, 27 Oct 2021 07:45:02 +0200

Hi Eric,

> reason I am opposed to any text of this form in the document

Perhaps there is a way to state the perceived tension, in which we talk 
about the need to consider the heritage of the series while at the same 
time taking steps to maintain the accessibility/health/??? of future 
contributions.

???

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Wed, 27 Oct 2021 12:00:33 +0200

Does anyone NOT like it?

Diff below.

Eliot

-## Implementation-Specific Policies
+## Working Practices

-Under and consistent with the high-level policies defined for the RFC
-Series in general or particular streams, the RPC shall define more
-particular policies regarding matters related to the editorial preparation
+In the absence of a high-level policy documented in an RFC, or to 
specify the
+detail of its implementation, the RPC can
+document working practices regarding the editorial preparation
  and final publication and dissemination of RFCs. Examples include:

  * Maintenance of a style guide that defines editorial standards to which
-  RFCs must adhere (see {{RFC7322}} and the
-  [style guide web page](https://www.rfc-editor.org/styleguide/)).
+  RFCs must adhere (see the
+  [style guide web page](https://www.rfc-editor.org/styleguide/), which
+  extends {{RFC7322}).

  * Policies regarding the file formats that are accepted as input to the
    editing and publication process.

  * Policies regarding the final structure and layout of published 
documents.
    In the context of the XML vocabulary ({{RFC7991}}), such policies could
-  include matters such as the exact XML elements and attributes used to
-  capture the semantic content of RFCs. More generally, such policies
-  could address the readability and presentation of information in RFCs.
+  include clarifications regarding XML elements and attributes used to
+  capture the semantic content of RFCs.

  ## RPC Responsibilities

Eliot

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 27 Oct 2021 10:13:31 -0700

> time taking steps to maintain the accessibility/health/??? of future

This doesn't work for me.

I think we ought to largely disregard the heritage of the series.

-Ekr

---

From: Ole Jacobsen <[email-masked]>
Date: Wed, 27 Oct 2021 10:18:38 -0700

<sarcasm>

Well, if we are to "largely disregard the heritage of the series," then surely
we ought to give it a more appropriate name, no?

<sarcasm\>

> On Oct 27, 2021, at 10:13, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> On Tue, Oct 26, 2021 at 10:45 PM Eliot Lear <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Eric,
> 

Ole J. Jacobsen
Editor and Publisher
The Internet Protocol Journal
Office: +1 415-550-9433
Cell:   +1 415-370-4628
Web: protocoljournal.org
E-mail: [email-masked]
E-mail: [email-masked]
Skype: organdemo

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 27 Oct 2021 10:50:56 -0700

> we ought to give it a more appropriate name, no?

That's a matter of branding, not heritage.

-Ekr

> E-mail: [email-masked] <[email-masked]>

---

From: Eliot Lear <[email-masked]>
Date: Wed, 27 Oct 2021 20:48:45 +0200

> That's a matter of branding, not heritage.

  When I think of heritage, I am thinking of archival aspects of the 
series, but perhaps the word "heritage" is just too loaded. But I think 
at this point, maybe we are better off leaving that discussion to the 
RSWG.  Nothing stops the RSWG from engaging in a "vibrant discussion" 
about how to address this issue.  I'm not sure it has to be decided in 
the this document.

Eliot

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 27 Oct 2021 11:51:34 -0700

On Wed, Oct 27, 2021 at 11:49 AM Eliot Lear <[email-masked]> wrote:

> series, but perhaps the word "heritage" is just too loaded.  But I think at
> this point, maybe we are better off leaving that discussion to the RSWG.
> Nothing stops the RSWG from engaging in a "vibrant discussion" about how to
> address this issue.  I'm not sure it has to be decided in the this document.
>

This matches my position.

-Ekr

Eliot

---

From: Michael StJohns <[email-masked]>
Date: Wed, 27 Oct 2021 16:10:06 -0400

On 10/27/2021 2:48 PM, Eliot Lear wrote:
> series, but perhaps the word "heritage" is just too loaded. But I 
> think at this point, maybe we are better off leaving that discussion 
> to the RSWG.  Nothing stops the RSWG from engaging in a "vibrant 
> discussion" about how to address this issue.  I'm not sure it has to 
> be decided in the this document.
>
> Eliot
>

Hi Eliot/EKR -

I disagree with the two of you and agree with Stephen and Ole. I don't 
have text as yet - I'm still reading over the current draft - but expect 
to provide some prior to the 5th of November. This is just a placeholder 
to ensure you don't consider the point closed.

The "good of the series" - to borrow EKRs term -  has to be informed by 
its history, accomplishments, impact on the Internet (in all the eras - 
and with all the motivators), as well as current and future needs.   
Wiping that slate clean by ignoring all of that and refusing to let it 
play in how we expect the RSWG to operate is both short sighted and  bit 
mean-spirited towards all of the people and communities that got us to 
this point and will tend to set us up for failure, or at least less than 
useful results.

I believe I get from EKRs posts that he wants an RSWG mostly unfettered 
by guard rails, or at least free to ignore history and long term needs 
in favor of what the current loudest voices on the RSWG want - I 
apologize if I misrepresent his position, but I submit there's some 
evidence for my belief.   I half expect there are some number of drafts 
already written that await only the creation of the RSWG that assume a 
clean slate.

I further believe that the RSAB will probably feel that it needs to 
provide those guard rails and will, at times,  reject documents that the 
RSWG proposes for the sole reason of "for the good of the series" 
probably leading to finger pointing and appeals.  I suggest that such 
conflict can be minimized by describing an overall philosophy in this 
meta document reflecting the heritage of the system that the RSWG has to 
color within and that the RSAB (on behalf of the broader community who 
lack the cycles to make loud noises within the RSWG) can live with.

Mike

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 27 Oct 2021 21:17:04 +0100

Hiya,

> This matches my position.

FWIW (and it may be I turn out to be in the rough), not
mine. I think it's important that this draft provide the
RSWG with guidance on that topic. And if you look at the
text I proposed it makes this consideration *a* goal, no
more, so I don't really agree that heritage here is either
an emotionally loaded term, nor that it doesn't apply.

Why do I think should this be mentioned in this draft?
Because ISTM we have quite a few genuine contributors
who, in all good faith, seem to think that heritage
doesn't really matter, and thus the probability that the
RSWG overemphasises only what are perceived as current
needs seems real. And I think it's also quite possible
that what seems currently quite sensible (in terms of
changes the RSWG might pursue) might be seen as a bad
move in another 5-10 years time.

Cheers,
S.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 27 Oct 2021 13:21:44 -0700

On Wed, Oct 27, 2021 at 1:10 PM Michael StJohns <[email-masked]>
wrote:

> I believe I get from EKRs posts that he wants an RSWG mostly unfettered by
> guard rails, or at least free to ignore history and long term needs in
> favor of what the current loudest voices on the RSWG want - I apologize if
> I misrepresent his position, but I submit there's some evidence for my
> belief.
>
This partly reflects my position and partly does not.

My position is that the community, as embodied in the RSWG, should have the
freedom to
make whatever changes to the RFC Series it deems necessary, provided that
the
streams, as embodied in the RSAB, do not believe it causes damage to the
series.

I do not believe that the RSWG should make its decisions on the basis of
what
the loudest voices are any more than WGs in general should.

I do not believe that this document should predecide questions about what
decisions
the RSWG can make outside of the above constraints.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 27 Oct 2021 13:24:56 -0700

On Wed, Oct 27, 2021 at 1:17 PM Stephen Farrell <[email-masked]>
wrote:

> needs seems real.

My concern is the dual of this: there are a number of people
who in all good faith, believe that we should not make changes
because they would not reflect the heritage of the series and
thus there is a probability that those concerns be overweighted.

For that reason, I believe it is best if we simply leave the document
silent on this matter and let the advocates for each position
make their case on indiv

-Ekr

---

From: Eliot Lear <[email-masked]>
Date: Wed, 27 Oct 2021 22:34:30 +0200

Mike:

On 27.10.21 22:10, Michael StJohns wrote:
> I suggest that such conflict can be minimized by describing an overall 
> philosophy in this meta document reflecting the heritage of the system 
> that the RSWG has to color within and that the RSAB (on behalf of the 
> broader community who lack the cycles to make loud noises within the 
> RSWG) can live with.

I am wondering, what does heritage mean in this case to you, and how 
might you describe how that might temper evolution of the series in 
tangible ways?  That is- if we are going to make a policy statement in 
this document, how would we know when it is being flouted?

Perhaps if we're a bit more concrete, we can seek some common ground.

And of course, people other than Mike should feel free to answer.

Eliot

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 27 Oct 2021 21:40:00 +0100

Hiya,

> thus there is a probability that those concerns be overweighted.

Understood. I dunno that there are people who want no change
at all tbh, but yes there are people who would like changes
that do get made to consider the good of the series, and not
*only* the current needs of current I-D authors and RFC
readers. And different people will weigh those pretty
differently, for sure.
> silent on this matter and let the advocates for each position

I think there's another reason why considering the good of
the series ought be documented in this draft: those who have
a fairly long view of the series' heritage may be less active
in future RSWG discussions for various reasons. Now, it so
happens that I'd myself often disagree with a lot of what
some such people might say, but that's not so relevant here -
the point is that by it's nature RSWG discussion will tend to
involve proponents advocating for the latest fashions in this
and that, and the good of the series is way more likely to
overlooked compared to a fashionable thing, and perhaps
even increasingly over time as the set of participants
change.

So I don't think "defer this argument to the RSWG" would
end up with a level playing field for this aspect of how
we deal with the series in future.

Cheers,
S.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 27 Oct 2021 13:44:44 -0700

Stephen,

Thanks for elaborating your position.

What you are advocating for is exactly what I am concerned about, namely
the weight of the past impairing the future's ability to make needed
changes.

-Ekr

P.S. I would like to note that "the good of the series" is a contested
term. I believe that the equities I am talking about represent the good of
the series.

---

From: Michael StJohns <[email-masked]>
Date: Wed, 27 Oct 2021 16:51:17 -0400

On 10/27/2021 4:34 PM, Eliot Lear wrote:
>> I suggest that such conflict can be minimized by describing an 
>> overall philosophy in this meta document reflecting the heritage of 
>> the system that the RSWG has to color within and that the RSAB (on 
>> behalf of the broader community who lack the cycles to make loud 
>> noises within the RSWG) can live with.
>

Did you miss " I don't have text as yet - I'm still reading over the 
current draft - but expect to provide some prior to the 5th of 
November." ?  :-)

Seriously - I think we need such text, and it needs to be concrete 
enough that the RSAB can point to it when it refuses to advance an RSWG 
document so that "abuse of discretion" doesn't become the usual version 
of the appeals process.

> And of course, people other than Mike should feel free to answer.

Of course.

BTW - I'd be interested in just what proposals EKR plans to make that he 
thinks might conflict with "heritage".  Perhaps if he's more concrete 
there, we can craft something that we all can get behind beside "no 
guardrails - no heritage considerations".

Later, Mike

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 27 Oct 2021 21:59:29 +0100

Hiya,

> the weight of the past impairing the future's ability to make needed

Yep. Different of us can see the same things as a negative and pressing 
weight of the past or as a positive heritage to
be cherished.

I'd be ok if we at least recognised that tension and told
the RSWG to not forget that there are good arguments on both
sides. But I'd be interested to see what others make of the
whole discussion.

> term. I believe that the equities I am talking about represent the good of

That's a fair point. I think "the series" as an identifiable
entity is still implicit in your phrase though, so I wonder
do we agree that a putative RFC100000 ought be recognisibly a
descendant of RFC1 (in some non-trivial sense), or else the
series should have died before then, likely being irrelevant?

If we did agree that, maybe just telling the RSWG to maintain
that characteristic without further detail might be enough? I'm not sure 
TBH. If we don't agree, that's fine, no harm
trying:-)

Cheers,
S.

---

From: Jay Daley <[email-masked]>
Date: Thu, 28 Oct 2021 11:29:33 +1300

> On 28/10/2021, at 9:24 AM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> On Wed, Oct 27, 2021 at 1:17 PM Stephen Farrell <[email-masked] <mailto:[email-masked]>> wrote:
> 

(no hat)

It seems to me as someone relatively new to the internal workings of the RFC series that "heritage" or any similar-meaning term is impossible to pin down as a general statement and is best addressed during a discussion on a specific proposal in the RSWG.  Unless the text is very carefully worded (e.g. with a corollary that change is necessary to avoid stagnation) then it would be such a blunt instrument that I would expect it to be regularly invoked inappropriately and to create friction because those invoking it would think they have policy on their side.

As to whether or not this will be forgotten about if not included, I’m not a gambler but I would happily take a bet that the chances of this not being raised during RSWG discussions, when it matters, are precisely zero even if it is not in the text.

Jay 

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

---

From: Christian Huitema <[email-masked]>
Date: Wed, 27 Oct 2021 16:58:14 -0700

> It seems to me as someone relatively new to the internal workings of the RFC series that "heritage" or any similar-meaning term is impossible to pin down as a general statement and is best addresse…

I don't think of that in terms of heritage so much as principles. I 
think we have broad agreement about most principles, such as making 
access to the discussion open and free. We also mostly have broad 
agreement on preserving continuity of the look and feel of the series, 
even if after tortuous debate we finally got  the format to evolve and 
allow such things as international characters or vector graphics. The 
only principle that I see regularly contested is the idea that once 
published, RFC cannot be changed.

I hear the arguments on both sides. On one side, RFC are archived 
documents, and we don't get to rewrite the past ever, so yes, once a 
document is stamped with a number, it is cast in stone. On the other 
side, network protocol specifications need to evolve frequently, and if 
they evolve developers ought to have a simple mean to access the latest 
version of protocol XXX. There is a big tension there, because if the 
protocol is known as RFC NNNN, then it cannot change. If it is known as 
protocol XXX it can change but then the RFC number becomes irrelevant. 
Arguably we have a tension between keeping the series relevant and 
maintaining a core principle.

Resolving such tensions is exactly what the RSWG should do. I don't 
think that we should try to preempt the debate by making statements 
about heritage. That leads me to agree with Eric and Elliot.

-- Christian Huitema

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 28 Oct 2021 15:13:45 +1300

On 28-Oct-21 12:58, Christian Huitema wrote:
>> It seems to me as someone relatively new to the internal workings of the RFC series that "heritage" or any similar-meaning term is impossible to pin down as a general statement and is best addressed during a discussion on a specific proposal in the RSWG.  Unless the text is very carefully 
worded (e.g. with a corollary that change is necessary to avoid stagnation) then it would be such a blunt instrument that I would expect it to be regularly invoked inappropriately and to create friction because those invoking it would think they have policy on their side.
> about heritage. That leads me to agree with Eric and Elliot.

We should probably wait until we see what Mike St J proposes,
but I feel that "heritage" as such is a bad choice of word, whereas
respecting long-established principles, and not fixing what isn't
broken, are reasonable guidelines.

     Brian

---

From: Eliot Lear <[email-masked]>
Date: Thu, 28 Oct 2021 09:16:47 +0200

Mike, everyone,

First, a point of clarification.  I don't have a strong position.  I may 
not have couched my words properly, but my only bias really is to fix 
the issues we can now, and not attempt to fix the issues we can't.

Christian has put things rather concretely by suggesting that 
fundamental parameters of the serious like whether RFCs are immutable 
might be changed.  There may be other aspects.  But I don't think we get 
through this without either dropping the word heritage or significantly 
elaborating it.  I think it may not be necessary to use the word.  See 
below.

Furthermore, there are enough concerns around this matter, that I don't 
see how we don't expose the tension at all.  But there is a difference 
between exposing that tension and trying to govern it. I don't think we 
do any harm to Eric's concerns if we do the former (EKR, you can and 
should correct me if you strongly disagree, but see below), and I have 
very little confidence that we will find any consensus on the latter.

With that in mind, we already have the following in Section 3.2.1:

>    Because policy issues can be difficult and contentious, RSWG
>    participants and RSAB members are strongly encouraged to work
>    together in a spirit of good faith and mutual understanding to
>    achieve rough consensus (see [RFC7282]).  In particular, RSWG members
>    are encouraged to take RSAB concerns seriously, and RSAB members are
>    encouraged to clearly express their concerns early in the process and
>    to be responsive to the community.  All parties are encouraged to
>    respect the value of each stream and the long-term health and
>    viability of the RFC Series.

Perhaps it is this last sentence that we might amend:

>  All parties are encouraged to, respect the value of each stream and 
> the long-term health and
>  viability of the RFC Series, and to give consideration for both the 
> factors that have led to the series'  wide acceptance, and those that 
> require it to evolve to see to its continued success.

Obviously those factors will be a matter of, perhaps intense, debate.  
Our rough consensus process is designed to allow for that tension to 
play out; but it requires a modicum of trust, that people will act in 
good faith toward one another.  You have all generally done an exemplary 
job of that here.  I hope that spirit would carry forward into the RSWG.

Eliot

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 28 Oct 2021 05:00:36 -0700

> > require it to evolve to see to its continued success.

I would be fine with this text.

-Ekr

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 28 Oct 2021 14:31:07 +0000

On 10/26/21, 11:08 PM, "Brian E Carpenter" <[email-masked]> wrote:

How about: The RFC Series has been very successful, and the RSAB should consider that success, and reasons for it, when making changes

---

From: John C Klensin <[email-masked]>
Date: Thu, 28 Oct 2021 14:50:13 -0400

Hi,

I have been trying to figure out how to respond to the Last Call
announcement without getting into nits, minutia, and even how to
give guidance to the RSA that I don't have much confidence they
will follow if input from the RSWG and Streams runs counter to
it (especially if people are making "look toward the future, not
the past" arguments).

That aside, I think there are three main clusters of issues:

(1) I continue to be worried about actual publications
expertise.  Replacing the RSE-based model with an RSCE is fine,
but there is no way to guarantee that the RSAB will pay any
attention to them, especially if the community (as represented
in the WG) and at least a few Streams want something else.
Maybe that is what we want, but I suggest it might be a mistake.

(2) We don't distinguish very well between important strategic
issues and, at the other extreme, subjects about which it may be
more important to make a decision among a set of reasonable
options than which option is chosen.  Instead, we seem to have a
community process for nearly everything.  That could result in
more community control (at least by the subset of the community
that feels passionately about the topics) and more transparency
but, as John Levine pointed out from a different perspective
[1], it could also lead to paralysis.

(3) The whole new system has many moving parts.  While I think
the draft does a good job of identifying roles and sorting
things out, I'm concerned that, should there be a big problem
--one on the scale of the one or two that brought us to this
point and effort-- enough different people will be responsible
for pieces of the puzzle that no one will be accountable.

best,
   john

[1]
https://mailarchive.ietf.org/arch/msg/rfced-future/Ly6kyS3h4Wo07RH0ydU7LHYQ5zA

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 28 Oct 2021 21:42:15 +0100

Hi,

I have comments about the update to RFC 8730.

There may be a more general issue about all of the updates, because the
document is sparse in its explanations of what the updates actually are.
With a protocol spec I think we would normally require some clarification of
what is being added to or changed in the updated document.

But I have a special interest in 8730 as the serving ISE.
I *think* that the intention here is to define additional responsibilities
of the ISE, and not to make any changes to the processes or responsibilities
defined in 8730 except the replacement of mentions of RSOC as described in
A.5
If so, it would be helpful if the Introduction said something like...
This document updates [RFC8730] by defining additional responsibilities for
the Independent Submissions Editor and by removing references to the RSOC.

By the way, A.5 says "this document dispenses with the RSOC" but there is no
prior mention of that change and only one mention of the RSOC (at the top of
Section 2).
I suspect A5 should also say, "...with oversight now provided as described
in Section X." But, I don't find the right section of the document to point
at for this.

Additionally, A.5 says "References to the RSOC in documents such as
[RFC8730] are obsolete". What does "documents such as" mean here. Is it that
we need to do a quick grep across the RFCs to get the full list?

Also, A.5 has "this document does away with the RSOC." That language may be
a bit extreme and open to interpretation. Maybe "there is no role for the
RSOC in the processes described in this document."

Cheers,
Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 28 Oct 2021 21:50:28 +0100

An issue in Section 3.1.2

   In the case that the IRTF chair or ISE is
   incapacitated or otherwise unable to appoint a delegate, the IAB (as
   the appointing body for the IRTF chair and ISE respectively) shall
   appoint a temporary member until the IRTF chair or ISE has been
   appointed by the IAB.

This sentence seems a bit mixed up.
The issue is that "the IRTF chair or ISE is incapacitated or otherwise
unable to appoint a delegate". But the resolution is qualified with "until
the IRTF chair or ISE has been appointed by the IAB".
Surely the qualification should be "until the IRTF chair or ISE is able to
resume their duties".

Cheers,
Adrian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 29 Oct 2021 10:18:51 +1300

On one point only:

On 29-Oct-21 09:42, Adrian Farrel wrote:
...

> RSOC in the processes described in this document."

RFC5622/8728 apparently intended to abolish the RSAG but failed to
do so. Personally, I prefer the current text to avoid any doubt.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 29 Oct 2021 10:19:54 +1300

On 29-Oct-21 01:00, Eric Rescorla wrote:
> 
> 
> On Thu, Oct 28, 2021 at 12:16 AM Eliot Lear <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Mike, everyone,
> 

Agreed
    Brian

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 28 Oct 2021 22:32:42 +0100

It's probably cultural, Brian.

"To do away with" commonly means "to put to death deliberately".

A

-----Original Message-----
From: Brian E Carpenter <[email-masked]> 
Sent: 28 October 2021 22:19
To: [email-masked]; [email-masked]
Subject: Re: [Rfced-future] **Program Last CALL: draft-iab-rfcefdp-rfc-model-05** Ends 5 Nov 2021

On one point only:

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 29 Oct 2021 10:57:49 +1300

> "To do away with" commonly means "to put to death deliberately".

Yes, there is that interpretation. Let's look at the sentence in context:

    To overcome some of these issues, this document
    dispenses with the RSOC.  References to the RSOC in documents such as
    [RFC8730] are obsolete because this document does away with the RSOC.

Is "dispenses with" widely understood by non-native English speakers? How about:

    To overcome some of these issues, this document
    abolishes the RSOC.  References to the RSOC in documents such as
    [RFC8730] are therefore obsolete.

     Brian

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 28 Oct 2021 15:27:14 -0700

Maybe "disbands"?

On Thu, Oct 28, 2021 at 2:58 PM Brian E Carpenter <
[email-masked]> wrote:

> > Subject: Re: [Rfced-future] **Program Last CALL:
> draft-iab-rfcefdp-rfc-model-05** Ends 5 Nov 2021
> >
> > On one point only:
> >

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 28 Oct 2021 18:04:14 -0600

> Maybe "disbands"?

+1

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 29 Oct 2021 13:48:44 +1300

> On 10/28/21 4:27 PM, Eric Rescorla wrote:

No objection
    Brian

---

From: Jay Daley <[email-masked]>
Date: Fri, 29 Oct 2021 13:53:16 +1300

> On 29/10/2021, at 1:04 PM, Peter Saint-Andre <[email-masked]> wrote:
> 

or "disestablishes" if we want to be very precise.

Jay

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

---

From: Mirja Kuehlewind <[email-masked]>
Date: Fri, 29 Oct 2021 12:43:01 +0200

Hi al,

Reviewing the draft now in detail, I would like to revive this discussion about ultimate authority.

First, I think we should just avoid the word “ultimate”. The LLC is responsible for certain decisions, especially when there are financial implications, however, the LLC itself is guided by the community. So I don’t find the word “ultimate” appropriately here.

Further the full sentence is this:

"Policy implementation is primarily the
   responsibility of the RFC Production Center (RPC), under the ultimate
   authority of the IETF Administration Limited Liability Company (IETF
   LLC).”

And I’m actually not sure anymore what we mean. This sounds a bit like the LLC has a yes/no role for each decision made by the RPC. Is that right? 

I would think that the RPC has a contract with the LLC and would take most decision on how to implement a policy without the LLC (except there is additional budget involved). 

So what do we mean here?

Mirja

> On 27. Oct 2021, at 02:28, Jay Daley <[email-masked]> wrote:
> 
> 
>

---

From: Eliot Lear <[email-masked]>
Date: Fri, 29 Oct 2021 13:46:57 +0200

> First, I think we should just avoid the word “ultimate”. The LLC is responsible for certain decisions, especially when there are financial implications, however, the LLC itself is guided by the com…

Does anyone object to the word "ultimate" being removed?

> And I’m actually not sure anymore what we mean. This sounds a bit like the LLC has a yes/no role for each decision made by the RPC. Is that right?

I don't interpret it as such.  The RPC has to have authority to make 
decisions, and the point of the text is to explain from where that 
authority emanates.

Eliot

---

From: Mirja Kuehlewind <[email-masked]>
Date: Fri, 29 Oct 2021 14:11:34 +0200

Below.

> On 29. Oct 2021, at 13:46, Eliot Lear <[email-masked]> wrote:
> 
> 
> I don't interpret it as such.  The RPC has to have authority to make decisions, and the point of the text is to explain from where that authority emanates.

That's also what I would assume but maybe we could actually further clarify this?

No, I don’t have a text proposal…

---

From: Mirja Kuehlewind <[email-masked]>
Date: Fri, 29 Oct 2021 14:16:13 +0200

I’m fine with the proposed addition below.

I also would like to note that we have this sentence in the intro:

"Under the auspices of this program, the community
   considered changes that would increase transparency and community
   input regarding the definition of policies for the RFC Series as a
   whole, while at the same time ensuring the continuity of the RFC
   Series, maintaining RFC quality, maintaining timely processing,
   ensuring document accessibility, and clarifying lines of authority
   and responsibility.”

I think this is a pretty good list. Maybe we should just add a sentence that the new RSWG is also expected to follow these goals or something?

> On 28. Oct 2021, at 14:00, Eric Rescorla <[email-masked]> wrote:
> 
> 
>

---

From: Mirja Kuehlewind <[email-masked]>
Date: Fri, 29 Oct 2021 16:50:34 +0200

As I know that Eliot would otherwise actually be disappointed, here is a proposal:

Later in the document we say "contractually overseen by the IETF LLC”. Maybe that is more clear?

However, while I think that makes the relationship between he RPC and LLC more clear, I think it still is not really clear what the responsibility of the LLC is.

We say the following

"The IETF LLC is responsible for the method of and management of the
   engagement of the RPC.  Therefore, the IETF LLC has authority over
   negotiating performance targets for the RPC and also has
   responsibility for ensuring that those targets are adhered to.
[…]
 The IETF LLC is
   ultimately responsible to the community via the mechanisms outlined
   in its charter.”

So the missing piece for me is how does the LLC set the performance targets? Does the later sentence mean that the Llc should consult about the performance targets with the community?

Should we add a sentence like this:

"Performance targets are set based on the current publication load as well as additional efforts as requested in policies by the RSWG and may be consulted with the community.”

Or is that too much detail?

Mirja

> On 29. Oct 2021, at 14:11, Mirja Kuehlewind <[email-masked]> wrote:
> 
> Below.
>

---

From: John C Klensin <[email-masked]>
Date: Fri, 29 Oct 2021 10:57:00 -0400

--On Friday, October 29, 2021 13:46 +0200 Eliot Lear
<[email-masked]> wrote:

>> Reviewing the draft now in detail, I would like to revive
>> this discussion about ultimate authority.
>> 
>> First, I think we should just avoid the word "ultimate".
>> The LLC is responsible for certain decisions, especially when
>> there are financial implications, however, the LLC itself is
>> guided by the community. So I don't find the word
>> "ultimate" appropriately here.
> 

While the optics are unfortunate and I think the odds of abuse
with the current LLC leadership are extremely low, the reality
is that:

(1) The LLC hires the RFCE according to whatever criteria they
work out (consultation with the community is advisory) and can
presumably get rid of them (either by firing or just by making
life miserable enough that they quit, decide not to renew
contracts, etc.)

(2) The LLC selects, manages the contracts of, etc., the RPC
including making decisions about performance reviews (and the
same comments about forcing an RPC contractor out apply).  

(3) Without LLC agreement to take, or not take, action and/or
supply funding many of the decisions the RSWG/RSAB might make...
well, there is a rude comment about actions performed into the
wind.

Now, as I suggested above, I think the odds of those turning
into real problems are very low.  I also note that any decisions
this group might make to, e.g., restrict the LLC's authority to
intervene in particular ways with its staff or contractors would
be out of this group's scope and probably that of the RSWG/RSAB,
almost certainly out of our competence to draft sufficiently
well, and probably irrelevant if the LLC concluded that those
interventions were necessary to good fiscal (at least)
management.  Remember that the community does not get to
second-guess such decisions and, because they would involve
contractual or personnel matters, doesn't even have an absolute
right to find out about them.

That sounds a whole lot like "ultimate authority" to me.
Dropping "ultimate" might make us feel better, but doesn't
change the reality.  We can, I think, rely on the integrity of
those running the LLC and the good connections between the LLC
and the community to prevent abuse of that authority, but,
unless I'm missing something significant, the authority is
definitely there and there is no plausible appeals mechanism
other than to the LLC itself.  

>> And I'm actually not sure anymore what we mean. This sounds
>> a bit like the LLC has a yes/no role for each decision made
>> by the RPC. Is that right?
> 
> I don't interpret it as such.  The RPC has to have authority
> to make decisions, and the point of the text is to explain
> from where that authority emanates.

Right.  That is certainly the intent.  If it were not true, we
would probably see paralysis beyond John Levine's worst
nightmares.  However (again noting that I don't expect this)
assume some future LLC hired a future Executive Director who had
serious, megalomaniac-level control issues.  Could they write an
RPC contract that insisted that every decision made be reviewed
by the LLC?  I don't see any possibility that we could prevent
that (other than being really careful about who gets onto the
LLC Board).

Like Mirja, I don't have any suggestions about text.  Although I
suppose we could put in some words encouraging the LLC to follow
the intent above, those words are presumably unnecessary with
the current administration and probably pointless with that
nightmare hypothetical future regime.

And that is what "ultimate authority" is all about, like it or
not.

     best,
   john

---

From: Mirja Kuehlewind <[email-masked]>
Date: Fri, 29 Oct 2021 17:56:58 +0200

Hi Eliot, hi Brian, hi all,

I just finished my review and would like to thank Peter for his good work. I agree with the other reviews that have been received so far that I’m pretty happy with the allover model.

I opened a couple of issues on Github but I think these are non-technical or at least minor such that we need to address them but they should not change any intention or content or the draft. Here is a list for reference:

#112 Minor: RPC Statement of Work
https://github.com/intarchboard/program-rfced-future/issues/112

#111 selection committees (again)
https://github.com/intarchboard/program-rfced-future/issues/111

#110 Where to put the RSCE role definition?
https://github.com/intarchboard/program-rfced-future/issues/110

#109 Do we want to write the existence of [email-masked] in stone?
https://github.com/intarchboard/program-rfced-future/issues/109

#108 Remove the word "ultimate"
https://github.com/intarchboard/program-rfced-future/issues/108

#107 What are the updates to other RFCs?
https://github.com/intarchboard/program-rfced-future/issues/107

#106 Editorial: Update first sentence of abstract?
https://github.com/intarchboard/program-rfced-future/issues/106

I have one more comment/question which is also related to issue #109 which I'll sent a separate mail for next. Of course feel free to also bring up any of the other issues separately on the mailing list if needed!

Mirja

> On 22. Oct 2021, at 10:13, Eliot Lear <[email-masked]> wrote:
> 
> Dear Colleagues,
>

---

From: Jay Daley <[email-masked]>
Date: Sat, 30 Oct 2021 09:08:02 +1300

I’ve added two issues:

1.  Allow for a temporary RSCE appointment while the permanent RSCE is still in post but temporarily unavailable. 
https://github.com/intarchboard/program-rfced-future/issues/104

This proposes adding the following text:

In the case that the RSCE is expected to be unavailable for an extended period then the IETF LLC may appoint a Temporary RSCE through whatever recruitment process it considers appropriate. A Temporary RSCE acts as the RSCE in all aspects during their term of appointment

2.  RPC responsibilities missing a couple of ex-(RFC Publisher) responsibilities 
https://github.com/intarchboard/program-rfced-future/issues/105

This proposes replacing 

Announcing and providing on-line access to RFCs.

With

Publishing RFCs by providing free and unrestricted online access both individually and in bulk, and by depositing copies in external archives.
Publishing catalogs and catalog entries, both individually and in bulk, for RFCs.
Announcing the publication of new RFCs to all interested parties.

(Sent from a device that doesn’t do plain text)

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

> On 22/10/2021, at 9:14 PM, Eliot Lear <[email-masked]> wrote:
> 
> Dear Colleagues,
>

---

From: Jay Daley <[email-masked]>
Date: Sat, 30 Oct 2021 09:42:22 +1300

> I would think that the RPC has a contract with the LLC and would take most decision on how to implement a policy without the LLC (except there is additional budget involved). 

My understanding is that the LLC is responsible for ensuring there is the resourcing necessary for policy to be implemented and has the necessary authority delegated to it by the community to do that. “policy” here means all administrative BCPs and all editorial RFCs and “resourcing” covers a spectrum of options including budget, staffing, contractors and more. In this draft, we are requiring the LLC to create a specific function to be responsible for implementing a subset of that policy, the editorial RFCs, but still within the responsibility and authority of the LLC, not independent of the LLC. 

Jay

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

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 30 Oct 2021 11:28:27 +1300

Good suggestions IMHO.

Regards
    Brian C

On 30-Oct-21 09:08, Jay Daley wrote:
> https://github.com/intarchboard/program-rfced-future/issues/104 <https://github.com/intarchboard/program-rfced-future/issues/104>
> 
> In the case that the RSCE is expected to be unavailable for an extended 
period then the IETF LLC may appoint a Temporary RSCE through whatever recruitment process it considers appropriate. A Temporary RSCE acts as the RSCE in all aspects during their term of appointment
> https://github.com/intarchboard/program-rfced-future/issues/105 <https://github.com/intarchboard/program-rfced-future/issues/105>
> 
> This proposes replacing
> 
>   * Announcing and providing on-line access to RFCs.
> 
> 
> With
> 
>   * Publishing RFCs by providing free and unrestricted online access both individually and in bulk, and by depositing copies in external archives.
>   * Publishing catalogs and catalog entries, both individually and in bulk, for RFCs.
>   * Announcing the publication of new RFCs to all interested parties.
> 
> 
> 
>> This begins the two week last call on draft-iab-rfcedfp-rfced-model-05.[1]  This call will run through Friday, 5 Nov 2021.  Please send your comments to this mailing list.  We will address any issues 
that are raised during our IETF time slot (and of course on list).

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 30 Oct 2021 11:33:57 +1300

> Does anyone object to the word "ultimate" being removed?

No objection, and I think that is necessary and sufficient. The LLC is already bound to consult with the community.

    Brian

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 29 Oct 2021 15:39:47 -0700

On Fri, Oct 29, 2021 at 1:08 PM Jay Daley <[email-masked]> wrote:

> I’ve added two issues:
>
> 1.  Allow for a temporary RSCE appointment while the permanent RSCE is
> still in post but temporarily unavailable.
> period then the IETF LLC may appoint a Temporary RSCE through whatever
> recruitment process it considers appropriate. A Temporary RSCE acts as the
> RSCE in all aspects during their term of appointment
>
>    - Announcing and providing on-line access to RFCs.
>
>
> With
>
>
>    - Publishing RFCs by providing free and unrestricted online access
>    both individually and in bulk, and by depositing copies in external
>    archives.
>
>
>    - Publishing catalogs and catalog entries, both individually and in
>    bulk, for RFCs.
>
>
I wonder if these are too concrete, actually. Right now the RPC is operated
by AMS who also operates the various IETF Web properties, but in the future
one might imagine that the IETF LLC would give the Web contract to someone
else, in which case one might imagine that they should also operated
rfc-editor.org and the RPC should just deliver the completed RFCs to them
to publish. After all, the skill of editing the documents is very different
from the skill of publishing them. It would be good to leave the LLC this
option, no?

-Ekr

>    - Announcing the publication of new RFCs to all interested parties.
>
>
>
> draft-iab-rfcedfp-rfced-model-05.[1]  This call will run through Friday, 5
> Nov 2021.  Please send your comments to this mailing list.  We will address
> any issues that are raised during our IETF time slot (and of course on
> list).
>
> Brian and Eliot
>

---

From: Jay Daley <[email-masked]>
Date: Sat, 30 Oct 2021 12:40:03 +1300

> On 30/10/2021, at 11:40 AM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> 
> I wonder if these are too concrete, actually. Right now the RPC is operated by AMS who also operates the various IETF Web properties, but in the future one might imagine that the IETF LLC would give the Web contract to someone else, in which case one might imagine that they should also operated rfc-editor.org and the RPC should just deliver the completed RFCs to them to publish. After all, the skill of editing the documents is very different from the skill of publishing them. It would be good to leave the LLC this option, no?

Yes.  I had intended it to refer to the act of putting files onto the server in various formats and arrangements, not the technical side but conflated the two. 

How about:

* Publishing RFCs, which includes:
 - depositing copies on the RFC Editor site both individually and in collections 
 - depositing copies with external archives 
 - creating catalogs and catalog entries
 - announcing the publication to all interested parties

Jay

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

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 29 Oct 2021 16:46:21 -0700

SGTM

On Fri, Oct 29, 2021 at 4:40 PM Jay Daley <[email-masked]> wrote:

> I wonder if these are too concrete, actually. Right now the RPC is
> operated by AMS who also operates the various IETF Web properties, but in
> the future one might imagine that the IETF LLC would give the Web contract
> to someone else, in which case one might imagine that they should also
> operated rfc-editor.org and the RPC should just deliver the completed
> RFCs to them to publish. After all, the skill of editing the documents is
> very different from the skill of publishing them. It would be good to leave
> the LLC this option, no?
>
>
> Yes.  I had intended it to refer to the act of putting files onto the
> server in various formats and arrangements, not the technical side but
> conflated the two.
>
> How about:
>

---

From: Eliot Lear <[email-masked]>
Date: Sat, 30 Oct 2021 09:35:13 +0200

On 29.10.21 22:08, Jay Daley wrote:
> In the case that the RSCE is expected to be unavailable for an 
> extended period then the IETF LLC may appoint a Temporary RSCE through 
> whatever recruitment process it considers appropriate. A Temporary 
> RSCE acts as the RSCE in all aspects during their term of appointment

I could envision example uses of this policy including 
maternity/paternity leave, extended sick leave, required military 
service leave.  And it is not permitted to permanently replace someone 
in many of these circumstances.  Really the only question for the group 
is whether the position should like vacant at such times.  The language 
here gives that latitude to the LLC, which allows for them to judge the 
current workload.

Eliot

---

From: Martin J. Dürst <[email-masked]>
Date: Sun, 31 Oct 2021 11:09:52 +0900

Hello Christian, others,

Thanks for mentioning the elephant in the room (changing the way RFCs 
get 'updated').

This is indeed a problem that may be discussed very actively in the 
future RSWG and RSAG. But please note that this cannot happen 
independently of the streams. It's the streams that have the authority 
on the content of their RFC.

Let's assume that the RSWG and RSAG came up with a way of integrating 
errata into published RFCs. If any stream refused, that stream's errata 
would just not participate in this feature.

The dependency is much clearer for more aggressive proposals. Let's 
assume that the RSWG and RSAG came up with a way of publishing RFCs as 
'living standards'. It's very clear that if any stream didn't want that, 
they just wouldn't use this feature.

I hope that also makes it clear that in particular for more aggressive 
proposals, the initiative really has to come from the streams, or more 
correctly, from the bodies behind these streams. Otherwise, any work is 
bound to be dead on arrival. Overall, it will probably take quite some 
time and a lot of coordination.

That leads me to the conclusion that whatever statement about heritage 
we make or do not make, we should be fine, because there isn't too much 
of a risk of some subgroup in the RSWG to dominate the direction.

Regards,   Martin.

On 2021-10-28 08:58, Christian Huitema wrote:
>> It seems to me as someone relatively new to the internal workings of 
>> the RFC series that "heritage" or any similar-meaning term is 
>> impossible to pin down as a general statement and is best addressed 
>> during a discussion on a specific proposal in the RSWG.  Unless the 
>> text is very carefully worded (e.g. with a corollary that change is 
>> necessary to avoid stagnation) then it would be such a blunt 
>> instrument that I would expect it to be regularly invoked 
>> inappropriately and to create friction because those invoking it would 
>> think they have policy on their side.
> 
>