Subject: Re: [Rfced-future] iRSE comments on the new RFC editor structure

From: Eliot Lear <[email-masked]>
Date: Mon, 1 Nov 2021 08:08:25 +0100

Hi Mark,

You and John are saying two slightly different things:

  * You desire a process by which members of the community can some
    changes through some light weight approval process.
  * John is saying that the RSCE needs to be able to address issues as
    they perceive them arising.

Both of these issues come together in the end under the auspices of the 
LLC (RPC).

Under our current system, the LLC has the authority to create light 
weight approaches to address the sorts of changes you have envisioned.  
It does not require any action on the part of the RSWG or the RSAB, and 
it barely requires oversight by either.

Let's go to our text.  I am assuming that your PR#101 is going to be 
accepted because I've heard no objections to it and some support (this 
doesn't yet incorporate Jay's proposed changes, that I've also heard no 
objection to):

> 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 the style guide web page
>     <https://www.rfc-editor.org/styleguide/>, which extends {{RFC7322}).
>
>  *
>
>     Instructions regarding the file formats that are accepted as input
>     to the editing and publication process.
>
>  *
>
>     Guidelines regarding the final structure and layout of published
>     documents. In the context of the XML vocabulary ({{RFC7991}}),
>     such guidelines could include clarifications regarding XML
>     elements and attributes used to capture the semantic content of RFCs.
>
We are relying on their discretion to properly oversee changes, or at 
the very least to refer controversial matters to the community.

This is my view as to how the draft stands today.

We could add text that requests that LLC initiate and oversee a process 
to consider and accept tooling and site changes from the community.  
Does the group want such a change?

However, to address John's concern, we should make slight changes to the 
RSCE text, so that we don't prohibit the RSCE from doing that which you 
would like other community members to engage in. That was the substance 
of the change I proposed.  Does the group want such a change?

Eliot

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 1 Nov 2021 08:58:34 -0400

As I understand it, the RSWG owns policy and strategic direction.
It seems to me that it follows that the RSWG does not own the 
maintenance of the RFC Editor web page.  The RPC does.
So it is not at all clear that the question below is in the remit of 
this group.

Yours,
Joel

On 10/31/2021 8:54 PM, Mark Nottingham wrote:
> Let's say that I, as a member of the community and a participant in the RSWG, had an idea about how to improve the RFC Editor web site. Maybe it's a change to the CSS, maybe it's an RSS feed, maybe it's something much more substantial.
> 
> I'm willing to do the work (both in terms of convincing people it's a good idea, and actually performing the task). Let's assume that there is no financial cost beyond what we currently pay to host a web site, etc., and the ongoing administrative, maintenance and operational burden is non-existent to slight-but-eminantly-manageable.
> 
> In my mind, the barriers to this kind of community contribution should be as low as is possible *while* still assuring adequate review, consensus, and oversight.
> 
> The first question is whether making that happen demands that an RFC be published. If it does, I think we've failed.
> 
> If it doesn't require an RFC being published, the next question is how that kind of thing is authorised.
> 
> One answer would be for me to petition the RSCE to use their position to enact this. I think that's inappropriate, and against the spirit of what we're doing here.
> 
> Another answer would be for me to go talk to the RPC and convince them to do it. Again, to me there isn't adequate oversight or visibility.
> 
> Another answer is 'some level of discussion + consensus in the RSWG, with buy-in from the RSAB'. Personally, I think that's reasonable.
> 
> Is there another way to do this? Do people disagree with this goal (and if so, why)?
> 
> Cheers,
> 
> 
>> On 29 Oct 2021, at 6:44 pm, Eliot Lear <[email-masked]> wrote:
>>
>> We say that the RSCE has the responsibility inter alia to:
>>
>>
>>
>>
>>>     *  If requested, provide expert advice to the RPC and IETF LLC
>>
>> And then we say:
>>
>>>
>>>     Matters on which the RSCE might be consulted could include the
>>>     following (see also Section 4 of [RFC8729]):
>>>
>>>     *  Editing, processing, and publication of RFCs
>>>
>>>     *  Publication formats for the RFC Series
>>>
>>>     *  Changes to the RFC style guide
>>>
>>>     *  Series-wide guidelines regarding document content and quality
>>>
>>>     *  Web presence for the RFC Series
>>>
>>>     *  Copyright matters related to the RFC Series
>>>
>>>     *  Archiving, indexing, and accessibility of RFCs
>>
>> So here we have an example of indexing.  The only issue is when a commitment is needed.  In that case, either the RPC has the authority, the ED has the authority, or the ED and RPC must seek the authority.  And then the question turns to whom.
>>
>> Am I missing something?
>>
>> Eliot
>>
>> On 29.10.21 06:13, Mark Nottingham wrote:
>>> This area has been a concern in the back of my mind too.
>>>
>>> What might be really interesting is if the RSWG were to have a lightweight way* to bless a particular goal or effort -- whether it be by the RPC, the RSCE, or a community member (or group of them). It would still retain change control over the output, of course, but it would enable things like this to make progress.
>>>
>>> Does that makes sense?
>>>
>>> Cheers,
>>>
>>>
>>> * I.e., without publishing an RFC.
>>>
>>>
>>>
>>>
>>>> On 29 Oct 2021, at 11:32 am, Jay Daley <[email-masked]>
>>>>   wrote:
>>>>
>>>>
>>>>
>>>>
>>>>> On 29/10/2021, at 1:14 PM, John R Levine <[email-masked]>
>>>>>   wrote:
>>>>>
>>>>> On Fri, 29 Oct 2021, Brian E Carpenter wrote:
>>>>>
>>>>>>> As a concrete example, we have a longstanding issue that Google Scholar does not index RFCs. I think I know what the problem is, various coding and indexing issues on the rfc-editor web site, and I hope I can get them fixed before my term runs out. But if I don't or I do but then it breaks again, who has the authority to talk to Google and if need be, to make the changes to fix it? ...
>>>>>>>
>>>>>> The language in sections 4.2 "Implementation-Specific Policies",
>>>>>> (proposed to become "Working Practices") and 4.3 "RPC Responsibilities",
>>>>>> isn't exclusive. So my answer is that if the problem flagged by the
>>>>>> community is "get RFCs into Google Scholar", solving it is then the
>>>>>> RPC's job (and how they tackle will probably involve consulting the
>>>>>> RSCE). Maybe we need a sentence or two making this clear.
>>>>>>
>>>>> We have known about the Google Scholar problem for many years.  The RPC is as aware of it as anyone, but hasn't been able to fix it because, unsurprisingly, their deep expertise in editorial issues doesn't happen to extend to the details of web indexing.  (I happen to know about it because I used to do expert witness work for Google.)
>>>>>
>>>>> If the RSWG has to rediscover that this is an issue, then tell the RPC to fix it, then hear back that the RPC needs outside help, then consult the RSCE, etc etc. oh never mind.
>>>>>
>>>>> We need to have people with the authority to solve small problems on their own and assign those problems directly to people who can address them.  Running everything through two committees is truly a recipe for paralysis.
>>>>>
>>>> As I understand it, the new model allows for this because the new model focuses solely on policy, leaving the implementation to the RPC (with support from … and oversight from … and …)  As the Google Scholar issue is solely one of distribution, then it is solely an implementation issue.
>>>>
>>>> We need to remember that only a subset of the role/responsibilities of the RSE are transferring to the RSWG and implementation matters are not part of that.
>>>>
>>>> Jay
>>>>
>>>>
>>>>
>>>>> Regards,
>>>>> John Levine,
>>>>> [email-masked]
>>>>> , Taughannock Networks, Trumansburg NY
>>>>> Please consider the environment before reading this e-mail.
>>>>> https://jl.ly
>>>>>
>>>>>
>>>>> -- 
>>>>> Rfced-future mailing list
>>>>>
>>>>> [email-masked]
>>>>> https://www.iab.org/mailman/listinfo/rfced-future
>>>>>
>>>>>
>>>>>
>>>> -- 
>>>> Jay Daley
>>>> IETF Executive Director
>>>>
>>>> [email-masked]
>>>>
>>>>
>>>> -- 
>>>> Rfced-future mailing list
>>>>
>>>> [email-masked]
>>>> https://www.iab.org/mailman/listinfo/rfced-future
>>> --
>>> Mark Nottingham
>>> https://www.mnot.net/
>>>
>>>
>>>
>> <OpenPGP_0x87B66B46D9D27A33.asc>
> 
> --
> Mark Nottingham   https://www.mnot.net/
>

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 1 Nov 2021 07:49:22 -0700

> So it is not at all clear that the question below is in the remit of

A bit of framing to potentially help (and hopefully not hinder):

A. RFCs contain content in English (currently) with some structure around
how they're composed (RFC7322) and encoded (RFC7991)
B. the RFC Editor page, html versions, text versions, pdf versions, etc are
about the presentation of that content (insert datatracker and tools team
too)

It seems to me that this work has been concentrating on A, and that's its
perceived remit.  And it's up to the RSCE and the RPC to deal with B.  The
community should likely be able to contribute to both efforts.  Mark's good
question is about whether B has oversight or not.

It will come down to a level of micro-management vs autonomy vs required
paperwork for changes (again).
-- 
Wes Hardaker
USC/ISI

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 1 Nov 2021 10:57:49 -0400

That framing below is reasonable.

However, I still say that B, that is performing oversight over the 
details of things like the RFC Editor web pages, is outside the scope of 
the RSWG.
Having said that, assigning where the responsibility lies may be within 
the scope of this body.

Historically, it was indeed part of the RSE's job.  often in 
consultation with the RSOC and RSAG.
We have, as far as I can tell, not assigned that responsibility to the 
RSCE.  I had assumed therefore that the oversight fell to the LLC / IETF 
Executive Director.

As a minor note, I have no idea if the current setup of the rools and 
process used to create and maintain the RFC Editor web pages would lend 
itself to the kind of community input that we use for the datatracker, 
or if some different interaction would be needed.  I would hate to 
commit as part of this work to a complete rebuild of that system just to 
make input a little easier.

Yours,
Joel

On 11/1/2021 10:49 AM, Wes Hardaker wrote:
> A. RFCs contain content in English (currently) with some structure 
> around how they're composed (RFC7322) and encoded (RFC7991)
> B. the RFC Editor page, html versions, text versions, pdf versions, etc 
> are about the presentation of that content (insert datatracker and tools 
> team too)
> 
> It seems to me that this work has been concentrating on A, and that's 
> its perceived remit.  And it's up to the RSCE and the RPC to deal with 
> B.  The community should likely be able to contribute to both efforts.  
> Mark's good question is about whether B has oversight or not.
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 2 Nov 2021 09:45:10 +1300

> We could add text that requests that LLC initiate and oversee a process 
to consider and accept tooling and site changes from the community.  Does 
the group want such a change?

Harmless, but IMHO already covered by RFC8711.

Regards
    Brian

On 01-Nov-21 20:08, Eliot Lear wrote:
>   * You desire a process by which members of the community can some changes through some light weight approval process.
>   * John is saying that the RSCE needs to be able to address issues as they perceive them arising.
> 
LLC (RPC).
> 
> Under our current system, the LLC has the authority to create light weight approaches to address the sorts of changes you have envisioned.  
It does not require any action on the part of the RSWG or the RSAB, and it barely requires oversight by either.
> 
> Let's go to our text.  I am assuming that your PR#101 is going to be accepted because I've heard no objections to it and some support (this 
doesn't yet incorporate Jay's proposed changes, that I've also heard no objection to):
> 
>> 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 the style guide web page <https://www.rfc-editor.org/styleguide/>, which extends {{RFC7322}).
>>
>>  *
>>
>>
>>  *
>>
>>     Guidelines regarding the final structure and layout of published documents. In the context of the XML vocabulary ({{RFC7991}}), such guidelines could include clarifications regarding XML elements and attributes used to capture the semantic content of RFCs.
>>
> We are relying on their discretion to properly oversee changes, or at the very least to refer controversial matters to the community.
> 
> 
> However, to address John's concern, we should make slight changes to the RSCE text, so that we don't prohibit the RSCE from doing that which you 
would like other community members to engage in. That was the substance of the change I proposed.  Does the group want such a change?

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 2 Nov 2021 13:29:01 +1100

> On 2 Nov 2021, at 1:57 am, Joel M. Halpern <[email-masked]> wrote:
> 
> However, I still say that B, that is performing oversight over the details of things like the RFC Editor web pages, is outside the scope of the RSWG.
> Having said that, assigning where the responsibility lies may be within the scope of this body.

I agree that the RPC + LLC have _responsibility_ for keeping the pages available and functional (you used 'ownership' earlier, which is a bit fuzzy). I also agree that they can act proactively on B ('presentation').

However, I think it's important that the community has some level of input. I also think that it's important that it not be ad hoc or private -- it needs to see some level of daylight.

The RSWG seems well suited as a venue for that kind of discussion. People are saying that it's 'outside the scope of RSWG' as if RSWG were already operating -- we're here to determine what the scope *is*. So if there's a reasoned argument as to why RSWG should consider such things out of scope instead of just assertions that it isn't in scope, it'd be good to hear.

> Historically, it was indeed part of the RSE's job.  often in consultation with the RSOC and RSAG.
> We have, as far as I can tell, not assigned that responsibility to the RSCE.  I had assumed therefore that the oversight fell to the LLC / IETF Executive Director.
> 
> As a minor note, I have no idea if the current setup of the rools and process used to create and maintain the RFC Editor web pages would lend itself to the kind of community input that we use for the datatracker, or if some different interaction would be needed.  I would hate to commit as part of this work to a complete rebuild of that system just to make input a little easier.

That doesn't seem relevant to this discussion.

---

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

Mark,

> The RSWG seems well suited as a venue for that kind of discussion. People are saying that it's 'outside the scope of RSWG' as if RSWG were already operating -- we're here to determine what the scop…

I'm not especially happy about this, but I'm asserting it's out of scope because RFC8711 *makes* it out of scope. When the IETF community reached rough consensus on that document, they handed the problem over to the implementation of the LLC and in particular of the para I pointed to yesterday:
https://www.rfc-editor.org/rfc/rfc8711.html#section-5.1-5

We could add some text saying that the RSWG may document its expectations for tools, for the benefit of the LLC and its contractor(s), according to that paragraph. Even that is a bit strange, because RFC8711 refers exclusively to "the IETF community", but I'd be happy to see such text. However, if we don't like RFC8711, that is not in our remit. That's all I'm trying to say.

    Brian

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 1 Nov 2021 23:24:59 -0400

Giving the RSWG purview to work on adjustments to the UI of the RFC 
Editor web site is a significant change to the scoping that I understood 
we agreed to, which was policy and strategy.

I strongly object to such a change in scope.

Yours,
Joel

---

From: Michael StJohns <[email-masked]>
Date: Mon, 1 Nov 2021 23:37:26 -0400

On 11/1/2021 10:29 PM, Mark Nottingham wrote:

> On 2 Nov 2021, at 1:57 am, Joel M. Halpern<[email-masked]>  wrote:
>
>     I agree that the RPC + LLC have_responsibility_  for keeping the pages available and functional (you used 'ownership' earlier, which is a bit fuzzy). I also agree that they can act proactively on B ('presentation').
>

> The RSWG seems well suited as a venue for that kind of discussion. People are saying that it's 'outside the scope of RSWG' as if RSWG were already operating -- we're here to determine what the scope*is*. So if there's a reasoned argument as to why RSWG should consider such things out of scope instead of just assertions that it isn't in scope, it'd be good to hear.

AIRC we spent a *lot* of time on delineating and agreeing to the 
boundaries of the RSWG and the current draft describes those limits.  
Strategic policy as described in RSWG authored and RSAB approved 
documents is how the RSWG affects the RFC series.  It might be OK to 
have the discussion in the RSWG with the understanding that the tactical 
decisions are not made there.  But given the general mission creep of 
most working groups, and the lack of established (in terms of precedent 
and common agreement) fences between the strategic and tactical, I would 
object to any discussion in the RSWG that's not targeted at creating 
policy documents for the editorial series and any attempts at 
management-like input to either the RPC or the RSCE from the RSWG.

So if the RSWG wants input, it gets people to write documents, follows 
its process to get community consensus (including outside non-RSWG 
commentary and adjustments), and gets the RSAB to approve it, and the 
LLC to scope the work for the RPC and RSCE contracts that are driven by 
such documents.   I think that's satisfies Mark's "community has some 
level of input".  That said, that process is by design and definition 
not quick, and we need a process for things that the IAB had previously 
delegated to the RSE that require quicker turn around.   The RSWG/RSAB 
can always write a document to override those decisions.

To Joel's point - the RSWG *might* be able to direct where the 
responsibility lies, but I actually think that's a meta issue that this 
group needs to clarify and that it probably should not be subject to 
later RSAB/RSWG twiddling.

Think of it this way:  We as a group are proposing a structure for the 
delegation of a number of authorities and responsibilities  to the 
RSWG/RSAB/RSCE  from the IAB, IESG and LLC which structure those groups 
will have to approve as part of this document publication.  How RFC 
series responsibilities have been split up and specified by the 
to-be-published first document should probably not be subject to change 
by the internal processes of the RSWG/RSAB without the further approval 
of those groups.  We may want to make that a bit clearer to avoid having 
the possibility of the RSWG throwing out most of the discussion and hard 
work we've done within a few years of formation.  Or at least provide 
some minimum number of years where certain things are fixed so we can 
get some experience to inform any future changes. If there's a need to 
do the changes sooner, we re-involve the delegating organizations and 
get their approval.

As an aside, I really miss the old interface to the mailing list 
archives.  Maybe I'm missing something, but trying to move back and look 
at the early threads without having a specific subject or phrase is 
painful and time consuming.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 2 Nov 2021 14:44:08 +1100

Hi Brian,

> On 2 Nov 2021, at 2:00 pm, Brian E Carpenter <[email-masked]> wrote:

> https://www.rfc-editor.org/rfc/rfc8711.html#section-5.1-5

Paragraph four mentions the RFC Editor as an example of historical benefit seen due to the IETF's use of contractors, and then paragraph five then talks about the IETF's history of community involvement, documenting an expectation that the LLC will respect the IETF community's wishes -- possibly requiring documentation of consensus.

I read this as imprecise use of 'IETF community' in 8711 -- especially since a distinction with the greater RFC Series Community had yet to be strenuously and successfully argued for.

Regardless of that, this text does not prohibit the LLC from considering other factors. 

Nor does it give the LLC authority over such decisions -- section 5.1 is couched in terms of *responsibilities*, not authorities, and all other mentions of the RFC Editor in 8711 merely characterise the LLC as a source of 'financial support for the operation of the RFC Editor.' 

For example, when the IESG wants a change to www.ietf.org, they make that known to the LLC, and the LLC has the responsibility to carry that out. Of course, the LLC can and does adjust and improve the site based upon their expertise and observations, but ultimate authority resides in the IESG. In our current model, there is no clear role or body that has authority over the content of rfc-editor.org.

So I think it's too strong to say that 8711 puts out of scope any involvement of the RSWG in defining requirements for or even offering improvements to e.g., the RFC Editor web site. And, it would be exceedingly odd for us to effectively convene the RFC Series Community in the RSWG but then say that it had no input into or authority over how the RFC Series is presented. 

> We could add some text saying that the RSWG may document its expectations for tools, for the benefit of the LLC and its contractor(s), according to that paragraph. Even that is a bit strange, becau…

Understood, but see above.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 2 Nov 2021 14:44:21 +1100

That may have been your understanding, but it was not mine.

> On 2 Nov 2021, at 2:24 pm, Joel M. Halpern <[email-masked]> wrote:
> 
> Giving the RSWG purview to work on adjustments to the UI of the RFC Editor web site is a significant change to the scoping that I understood we agreed to, which was policy and strategy.
>

---

From: Eliot Lear <[email-masked]>
Date: Tue, 2 Nov 2021 08:27:11 +0100

Mark,

Let's at least for the moment accept your goal that you would like to 
have a means by which community members can directly contribute to 
improve the RFC Editor service.  Let's also accept that the RPC is going 
to need to be involved in seeing to the above goal.  Let's posit at 
least a modest mechanism to implement that goal in the form of a review 
process to accept changes, and a transparency report to indicate what 
those changes were.

In an earlier email, I had proposed some text, which I gather people 
didn't prefer.  What would be the policy language you would want in This 
document to enable/require such a thing?  We can argue over the words 
"MUST" or "is requested" but let's get into the right ballpark, if we 
can.  That way at least there is some proposal that people can consider.

Eliot

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 2 Nov 2021 09:54:17 -0400

From the front of the current Internet Draft, which I thought we had 
all agreed on:

    The RFC Series Working Group (RSWG) shall formulate proposals
    regarding policies that govern the RFC Series.

Adjustments to the RFC Editor web page are not policy.

Yours,
Joel

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 2 Nov 2021 14:26:11 +0000

>    Adjustments to the RFC Editor web page are not policy.

Makes sense to me.

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 2 Nov 2021 15:52:17 +0100

I agree with Mark that the _authority_ of the _content_ of the RFC editor page should not be with the LLC.

I could actually see the RSAB to have this authority, as the RSCE is as members and the stream representatives are the (only) customers. I think I would trust the RSAB to decide if a change touches on policy and would need to be discussed in the RSWG or not.

However, for me Marks originally proposal was more about tooling (which might be the confusing part here). For RFC-tooling-related question, so far we used rfc-interest@ for discussion and I think that works well, so I don’t think we should changes it. And it also seems that LLC actually has the authority about tooling (that support the needs of the various bodies we have).

Not sure if others agree to this view but I at least think this discussion has shown that we need to clarify this in the draft as we seem to have different ideas in this group.

> On 2. Nov 2021, at 04:44, Mark Nottingham <[email-masked]> wrote:
> 
> Hi Brian,
>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 3 Nov 2021 09:20:34 +1300

> I agree with Mark that the _authority_ of the _content_ of the RFC editor page should not be with the LLC.

Huh? The content (the text etc.) is not going to be debated in detail by a committee, I hope. The policy is not the content, and the RSWG/RSAB only determine policy. I agree with Joel that we have unambiguously limited the RSWG/RSAB in that way. If the web site content does not follow the policy, of course, that's a problem, but it's an operational problem.

> I could actually see the RSAB to have this authority, as the RSCE is as 
members and the stream representatives are the (only) customers. I think I would trust the RSAB to decide if a change touches on policy and would need to be discussed in the RSWG or not.

The RSAB isn't an authority. It's an approval body. Its power of decision 
is actually very limited.

> However, for me Marks originally proposal was more about tooling (which 
might be the confusing part here). For RFC-tooling-related question, so far we used rfc-interest@ for discussion and I think that works well, so I 
don’t think we should changes it. And it also seems that LLC actually has the authority about tooling (that support the needs of the various bodies we have).

Yes. Again, RFC8711 settled this issue almost 2 years ago.

    Brian

>>> I'm not especially happy about this, but I'm asserting it's out of scope because RFC8711 *makes* it out of scope. When the IETF community reached rough consensus on that document, they handed the problem over to the 
implementation of the LLC and in particular of the para I pointed to yesterday:
>> I read this as imprecise use of 'IETF community' in 8711 -- especially 
since a distinction with the greater RFC Series Community had yet to be strenuously and successfully argued for.
>> Nor does it give the LLC authority over such decisions -- section 5.1 is couched in terms of *responsibilities*, not authorities, and all other 
mentions of the RFC Editor in 8711 merely characterise the LLC as a source of 'financial support for the operation of the RFC Editor.'
>>
>> For example, when the IESG wants a change to www.ietf.org, they make that known to the LLC, and the LLC has the responsibility to carry that out. Of course, the LLC can and does adjust and improve the site based upon 
their expertise and observations, but ultimate authority resides in the IESG. In our current model, there is no clear role or body that has authority over the content of rfc-editor.org.
>>>>> As a minor note, I have no idea if the current setup of the rools and process used to create and maintain the RFC Editor web pages would lend itself to the kind of community input that we use for the datatracker, or if some different interaction would be needed.  I would hate to commit 
as part of this work to a complete rebuild of that system just to make input a little easier.
> .

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 2 Nov 2021 21:35:32 +0100

The authority over the content on the IETF webpage lies with the IESG, which is a committee of people that is selected by the community to act based on community consensus.

The RPC is not that. I was not proposing to maintain the content of the RFC editor webpage in the RSWG but there needs to be authority over the content by a body that is guided by the community.

The RSAB is an approval body but we talk about “activities related to implementation of policies” and the RSAB as an advisory body for the RPC, so I think we already defined more than “just” approval of documents as their role.

In think we have a gap here.

> On 2. Nov 2021, at 21:20, Brian E Carpenter <[email-masked]> wrote:
> 
> The RSAB isn't an authority. It's an approval body. Its power of decision is actually very limited.
> 
> might be the confusing part here). For RFC-tooling-related question, so far we used rfc-interest@ for discussion and I think that works well, so I don’t think we should changes it. And it also seems that LLC actually has the authority about tooling (that support the needs of the various bodies we have).
>

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 3 Nov 2021 13:29:09 +1100

> On 3 Nov 2021, at 1:52 am, Mirja Kuehlewind <[email-masked]> wrote:
> 

I think there are two issues mingling here:

1) Who determines how the RFC Series is presented to and interacts with the world. E.g., the web site. This is the 'authority' issue discussed before.

2) How the tradition of 'community involvement in the execution of certain administrative functions' (as per RFC8711) is reflected in #1. 

It's a bit weird to me to characterise #2 as a tooling issue, since in many cases it will be making suggestions for content on the web site. It might be creating new tools too.  That *doesn't* mean that I want the ability for the RSWG to create requirements for the tools team -- rather, that if a good tool emerges in the community, and it would be beneficial to list it / use it on the site, we should have a process for that.

> Not sure if others agree to this view but I at least think this discussion has shown that we need to clarify this in the draft as we seem to have different ideas in this group.

Oh, my yes.

Cheers,

---

From: "John Levine" <[email-masked]>
Date: 3 Nov 2021 14:16:37 -0400

>1) Who determines how the RFC Series is presented to and interacts with the world. E.g., the web site. This is the 'authority' issue discussed before.

Historically it has been the RSE and RPC, or in practice AMS.

If we are claiming the IETF gets to manage that site, we have severe mission creep.

R's,
John

PS: Insert the long "the RFC series isn't just the IETF" string here.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 4 Nov 2021 10:56:38 +1300

> If we are claiming the IETF gets to manage that site, we have severe mission creep.

Agreed. But where does the draft suggest or imply that?

     Brian

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 9 Nov 2021 16:49:59 -0700

Coming to these threads late, I see a few things...

> process to accept changes, and a transparency report to indicate what 

1. As Alice and Jay both pointed out, the RPC will formulate work plans 
in concert with the LLC and communicate those plans to the community 
within the RSWG. This is an opportunity to provide input regarding these 
more implementation-specific priorities and identify any policy-related 
issues that such priorities might raise (say, that the RFC Editor 
website could provide improved accessibility to visually impaired users).

2. People have bright ideas about things that are more implementation 
specific (e.g., regarding CSS or layout for the RFC Editor website) and 
they should have a way to suggest those ideas in a relatively 
transparent way, which I *think* is rfc-interest. From the perspective 
of the RSWG, I think the main reason for this transparency is to ensure 
that if such a suggestion raises a policy issue, we can identify that 
issue more clearly and bring it to the RSWG.

It seems to me that these things will happen naturally via the existing 
or envisioned mechanisms described above.

Do we need to specify these matters in greater detail in the document 
before us? I see no reason not to, at least for the avoidance of doubt.

> can.  That way at least there is some proposal that people can consider.

Eliot, as I understood it your proposal was:

OLD

NEW

    * Provide expert guidance to the RPC and IETF LLC

    Matters on which the RSCE might provide guidance could include the
    following (see also Section 4 of [RFC8729]):

(Note: in the bullet point I prefer "guidance" to "advice" so that it 
ties in with the very next paragraph.)

This seems fine to me, but it doesn't fully address the topic at hand. 
I'm happy to formulate more precise text to address (1) and (2) if we 
think that's needed.

Peter