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

From: Jay Daley <[email-masked]>
Date: Tue, 2 Nov 2021 21:36:15 +1300

Mark

So that I’m clear, is your concern specifically about improving the RFC Editor web presence or is it more broadly about improving the RFC Editor service as Eliot describes it?

Jay

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

> On 2/11/2021, at 4:44 PM, Mark Nottingham <[email-masked]> wrote:
> Hi Brian,
> 
>> On 2 Nov 2021, at 2:00 pm, Brian E Carpenter <[email-masked]> wrote:
> 
>> 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
> 
> 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, 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.
> 
> Understood, but see above.
> 
> 
>> 
>>  Brian
>> 
>> 
>> 
>>>> 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.
>>> --
>>> Mark Nottingham   https://www.mnot.net/
> 
> --
> Mark Nottingham   https://www.mnot.net/
> 
> -- 
> Rfced-future mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/rfced-future

---

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

> On 2 Nov 2021, at 7:36 pm, Jay Daley <[email-masked]> wrote:
> 

The web presence is the most obvious and important aspect. If it simplifies the discussion, I'm happy to limit it to the web presence, since that's 99% of non-IETF folks' experience with the RFC Series.

Cheers,

---

From: Jay Daley <[email-masked]>
Date: Thu, 4 Nov 2021 13:50:44 +1300

> On 3/11/2021, at 3:22 PM, Mark Nottingham <[email-masked]> wrote:
> 
> 

Great. So what I want to do now is break that down into pieces and examine each one. The tl;dr of what follows is that there are two gaps but neither need to be tackled in this proposed new model.

Piece 1 - strategic.  Examples of what I mean here are:
- how does the rfc-editor site balance its three purposes of publishing RFCs, being the home of the RFC editor function and being the source of info for the AUTH48 process, or should they be split into multiple sites
- what’s the expected user experience for non-IETF consumers of RFCs

For me this piece sits clearly in the proposed RSWG/RSAB process. However, and this is a big however, I don’t think that there has so far been any attempt to discuss and agree a community consensus on the strategy for the site and so this would mean quite a new direction for those discussions.  If an RFC were published that contained an overall strategic plan then that would ease much of the friction below. 

Piece 2 - functional design.  Examples of what I mean here are:
- should this site offer full text search of RFCs
- what should be the default page/format presented to those finding an RFC

These decisions were previously made by the RSE and as I understand it, this is where you see the need for a lighter weight consensus process than a new RFC. While that’s preferable to another sole decision maker, it still means that these decisions are being made without an overall strategy and will be patchy as a result.  (That assumes that it is possible to reach a lightweight consensus on these matters which I doubt). 

We are better off considering this as a new type of implementation task - implementation of the strategy from piece 1 above - that should be delegated to a focused team that reports back to the community but doesn’t require community consensus. Currently I don’t see any suitable team that brings together all the right groups (Community, RPC, Tools) and so there is a gap.   

Piece 3 - content. Examples of what I mean here are:
- the overall plan for what content appears on the site and what doesn’t 
- how to integrate content from different sources (staff, RFCs, volunteers, external sites) into a seamless content experience. 

Again this was under the sole purview of the RSE but it’s obvious to me that the absence of an overall content strategy for all our web presences meant that the end result was bound to be messy.  The overlaps between rfc-editor.org, Datatracker, www.Ietf.org and tools.Ietf.org are strong evidence for that. 

For now this sits with the RPC/LLC but there is still a gap though one much larger than just this site - we need ways to improve community involvement in all content for all of our web presences.  

Piece 4 - infrastructure. Examples of what I mean here are:
- ensuring that we don’t go another five years between server upgrades
- optimising content delivery to various parts of the internet

Again this was previously managed by the RSE and I believe this is now for the LLC to manage through setting contractual expectations and SLAs with our outsourced IT team based on ongoing community consultation. 

Sorry for the long post, but how does that analysis match with others’ understanding?

Jay

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

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 4 Nov 2021 13:32:50 +1100

Hi Jay,

Thanks, that's very helpful. Responses below.

> On 4 Nov 2021, at 11:50 am, Jay Daley <[email-masked]> wrote:
> 

Yes.

> We are better off considering this as a new type of implementation task - implementation of the strategy from piece 1 above - that should be delegated to a focused team that reports back to the com…

Yes, but am wary of forming yet more isolated teams that are supposed to represent the community but are really just an exclusive group with little accountability or communication. 

> - the overall plan for what content appears on the site and what doesn’t 

Is this what we've been talking about as 'authority'? It's more than a plan, I think -- it can also be reactive.

> For now this sits with the RPC/LLC but there is still a gap though one much larger than just this site - we need ways to improve community involvement in all content for all of our web presences.  

I think the authority needs to sit in the community, not the LLC. It might be delegated for small things, but if there's a decision to be made about what content appears on the site (e.g., because there's a dispute about what should be said), that shouldn't be made by the LLC or RPC. The execution of content (writing, editing, HTML, etc.) might often come from the LLC or a contractor, of course.

> Again this was previously managed by the RSE and I believe this is now for the LLC to manage through setting contractual expectations and SLAs with our outsourced IT team based on ongoing community…

Yes.

Cheers,

---

From: Jay Daley <[email-masked]>
Date: Thu, 4 Nov 2021 16:13:11 +1300

> On 4/11/2021, at 3:32 PM, Mark Nottingham <[email-masked]> wrote:
> 
> Hi Jay,
> 

I agree, such a group would need clear terms of reference / operating procedures to prevent it becoming that.  That’s still preferable than attempting to reach consensus on this level of detail as I think that would be unworkable.

> Is this what we've been talking about as 'authority'? It's more than a plan, I think -- it can also be reactive.

No idea - I find this focus on static ’authority’ rather than the dynamic process of change to be a distorted lens.  Yes I agree it can be and should be reactive too. 

>> Again this was under the sole purview of the RSE but it’s obvious to me that the absence of an overall content strategy for all our web presences meant that the end result was bound to be messy.  The overlaps between rfc-editor.org <http://rfc-editor.org/>, Datatracker, www.Ietf.org <http://www.ietf.org/> and tools.Ietf.org <http://tools.ietf.org/> are strong evidence for that. 
>> 

Yes I fully agree this needs to be community-led.  My point is that content changes and content planning is needed every day and until a community-led structure emerges, the LLC is by default picking this up, taking whatever lead it can from the IESG, EMODIR, tools users, individual community members, etc.  My personal goals, which were publicly consulted on, cover some parts of this.

Jay

> Mark Nottingham   https://www.mnot.net/ <https://www.mnot.net/>
-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: Mirja Kuehlewind <[email-masked]>
Date: Thu, 4 Nov 2021 13:57:43 +0100

Hi Jay, hi Mark,

Jay thanks for spitting this up. I mostly agree just one more comment below.

> On 4. Nov 2021, at 03:32, Mark Nottingham <[email-masked]> wrote:
> 
> Hi Jay,
> 
> I think the authority needs to sit in the community, not the LLC.It might be delegated for small things, but if there's a decision to be made about what content appears on the site (e.g., because there's a dispute about what should be said), that shouldn't be made by the LLC or RPC. The execution of content (writing, editing, HTML, etc.) might often come from the LLC or a contractor, of course.

I agree authority about the content of any page should not sit with the the LLC. For the ietf.org page and the datatracker the authority is with the IESG which a board of community members selected by community member. This is not the case for the RPC, so I think the authority over the content of the rfc-editor.org page should also not sit with the RPC. While there is work to improve community involvement for all pages, the is an actual gap in authority for the rfc-editor.org page.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 4 Nov 2021 13:59:50 +0100

On 04.11.21 13:57, Mirja Kuehlewind wrote:
> I agree authority about the content of any page should not sit with the the LLC. For the ietf.org page and the datatracker the authority is with the IESG which a board of community members selected by community member.

Precisely where does it say that?  Maybe we can model that language.

Eliot

---

From: Mirja Kuehlewind <[email-masked]>
Date: Thu, 4 Nov 2021 14:10:07 +0100

Actually, that's a bit overly simplified I guess. RFC3710 say “[The IESG] also
   administers IETF logistics, including operation of the Internet-Draft
   document series and the IETF meeting event.”

However, if you further read on, the RFC says "The IESG has web pages as part of the IETF web (www.ietf.org)”.

This RFC was written before the datatracker was widely used and when the old ietf.org page was still up. From the RFC it seems, however, quite cleat that all matters related to the datatracker are clearly in scope for the IESG, however, there are probably parts of the ietf.org side where authority is not fully clear or lies with some other entities (e.g. information about the LLC or the IAB…).

Mirja

> On 4. Nov 2021, at 13:59, Eliot Lear <[email-masked]> wrote:
> 
> 
> <OpenPGP_0x87B66B46D9D27A33.asc>

---

From: Eliot Lear <[email-masked]>
Date: Thu, 4 Nov 2021 17:27:53 +0100

Hi Jay and Mark,

Here is what the  Section 3 chapeau currently reads:

> Policies governing the RFC Series as a whole are defined in the open 
> through proposals that are generated by and discussed within the RFC 
> Series Working Group (RSWG) and then approved by the RFC Series 
> Approval Board (RSAB).

> Policies under the purview of the RSWG and RSAB might include but are 
> not necessarily limited to document formats, processes for publication 
> and dissemination of RFCs, and overall management of the RFC Series.

As I read it, this permits the RSWG and RSAB to publish the sort of RFC 
you are suggesting to be written.  Such an RFC could state both 
transparency and coordination requirements, as well as operational 
expectations.  As you wrote, such an RFC would cover all much of what 
you described.

Mark, again as I read the above text, it does not specifically address 
your concerns, but provides you an avenue to get your concerns addressed 
once the RSWG is created.  Do you read it the same way, and do you (and 
others) believe that is sufficient for us to proceed with this document?

Eliot

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 5 Nov 2021 09:02:31 +1300

On 05-Nov-21 02:10, Mirja Kuehlewind wrote:
> This RFC was written before the datatracker was widely used and when the old ietf.org page was still up. From the RFC it seems, however, quite cleat that all matters related to the datatracker are clearly in scope for 
the IESG, however, there are probably parts of the ietf.org side where authority is not fully clear or lies with some other entities (e.g. information about the LLC or the IAB…).

Well yes. It isn't actually said very clearly in RFC 8711, but the implication is that the LLC provides tools and the IETF web site, and controls the RFC Editor contract, which implies the RFC tools and web site. But as 
I have quoted to the point of boredom, it also says that the LLC "is expected to respect the IETF community's wishes". As far as rules go, I believe that's all we've got. It's enough, but it does seem that our draft should empower the RSWG/RSAB to *express* those wishes. We can't change RFC 8711, because we're not the IETF.

    Brian

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 5 Nov 2021 13:49:02 +1100

Hi Eliot,

> On 5 Nov 2021, at 3:27 am, Eliot Lear <[email-masked]> wrote:
> 
> Hi Jay and Mark,
> 
>> Policies governing the RFC Series as a whole are defined in the open through proposals that are generated by and discussed within the RFC Series Working Group (RSWG) and then approved by the RFC Series Approval Board (RSAB).
> 
>> Policies under the purview of the RSWG and RSAB might include but are not necessarily limited to document formats, processes for publication and dissemination of RFCs, and overall management of the RFC Series.
> 
> As I read it, this permits the RSWG and RSAB to publish the sort of RFC you are suggesting to be written.  Such an RFC could state both transparency and coordination requirements, as well as operational expectations.  As you wrote, such an RFC would cover all much of what you described.
> 
> Mark, again as I read the above text, it does not specifically address your concerns, but provides you an avenue to get your concerns addressed once the RSWG is created.  Do you read it the same way, and do you (and others) believe that is sufficient for us to proceed with this document?

I have two concerns at this point:

1) While that's a reasonable reading of the above, some have strongly pushed back on this area as 'out of scope.' If they were pushing back on including some of the detailed work that Jay so helpfully categorised as being homed in the RPC and LLC, that's understandable. However, if there's pushback on any discussion of this area *at all* in the RSWG, I'd be concerned that the scope of the WG was being used to limit community oversight and input. 

2) The path you outline could result in the RSWG considering publishing an RFC that creates new bodies or new communication channels to pursue these topics. Execution of those functions could involve the RSWG in some capacity -- whether in an oversight role or in direct consultation or decision making -- without the publication of an RFC for each decision. Therefore, I'd expect that the RSWG would be able to modify its operation (subject to RSAB oversight) to accommodate that, and any argument that doing so were out of scope would be toothless. Is that the clearly case?

Cheers,

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 4 Nov 2021 23:19:11 -0400

To address your quesitons directly...
No, I do not think the RSWG / RSAB are free, once established to simply 
expand their scope as they see fit.  Having that right would undermine 
most of the point of this process, and many of the assumptions that 
enabled compromise.

I do think that that policies about "document formats, processes for 
publication and dissemination of RFCS" fall within the policy remit we 
have agreed to assign to the RSWG.  I do not think that includes 
management of the layout, tools, or content structure for the RFC Editor 
web site.

Yours,
Joel

---

From: Michael StJohns <[email-masked]>
Date: Thu, 4 Nov 2021 23:28:33 -0400

On 11/4/2021 11:19 PM, Joel M. Halpern wrote:
> No, I do not think the RSWG / RSAB are free, once established to 
> simply expand their scope as they see fit.  Having that right would 
> undermine most of the point of this process, and many of the 
> assumptions that enabled compromise.
>
> management of the layout, tools, or content structure for the RFC 
> Editor web site.
>
> Yours,
> Joel

> and dissemination of RFCs, and overall management of the RFC Series. 
becomes:

Policies described within the Editorial series might include, but are 
not necessarily limited to document formats, processes for publication 
and dissemination of RFCs, and a general model for overall management of 
the RFC series.

For avoidance of doubt, the RSWG shall have no role in the day to day 
operation of the RFC series, and the RSAB shall have only the roles 
described within this document with respect to operation of the series.  
Such roles or lack of roles may not be expanded without the concurrence 
of the IAB and the IESG or absent a general expression of consensus by 
the community for the change.

>>>> Policies governing the RFC Series as a whole are defined in the 
>>>> open through proposals that are generated by and discussed within 
>>>> the RFC Series Working Group (RSWG) and then approved by the RFC 
>>>> Series Approval Board (RSAB).
>>>
>>>> Policies under the purview of the RSWG and RSAB might include but 
>>>> are not necessarily limited to document formats, processes for 
>>>> publication and dissemination of RFCs, and overall management of 
>>>> the RFC Series.
>>>
>>> As I read it, this permits the RSWG and RSAB to publish the sort of 
>>> RFC you are suggesting to be written.  Such an RFC could state both 
>>> expectations.  As you wrote, such an RFC would cover all much of 
>>> what you described.
>>>
>>> Mark, again as I read the above text, it does not specifically 
>>> address your concerns, but provides you an avenue to get your 
>>> concerns addressed once the RSWG is created.  Do you read it the 
>>> same way, and do you (and others) believe that is sufficient for us 
>>> to proceed with this document?
>>
>> 1) While that's a reasonable reading of the above, some have strongly 
>> pushed back on this area as 'out of scope.' If they were pushing back 
>> on including some of the detailed work that Jay so helpfully 
>> categorised as being homed in the RPC and LLC, that's understandable. 
>> However, if there's pushback on any discussion of this area *at all* 
>> in the RSWG, I'd be concerned that the scope of the WG was being used 
>> to limit community oversight and input.
>>
>> 2) The path you outline could result in the RSWG considering 
>> publishing an RFC that creates new bodies or new communication 
>> channels to pursue these topics. Execution of those functions could 
>> involve the RSWG in some capacity -- whether in an oversight role or 
>> in direct consultation or decision making -- without the publication 
>> of an RFC for each decision. Therefore, I'd expect that the RSWG 
>> would be able to modify its operation (subject to RSAB oversight) to 
>> accommodate that, and any argument that doing so were out of scope 
>> would be toothless. Is that the clearly case?
>>
>> Cheers,
>>
>> --

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 5 Nov 2021 15:18:12 +1100

> On 5 Nov 2021, at 2:19 pm, Joel M. Halpern <[email-masked]> wrote:
> 
> No, I do not think the RSWG / RSAB are free, once established to simply expand their scope as they see fit.  Having that right would undermine most of the point of this process, and many of the assumptions that enabled compromise.

What about introducing new processes within its scope? E.g., the ability to gain consensus on a question and communicate that to the RPC/RSCE/LLC without publishing an RFC?

> I do think that that policies about "document formats, processes for publication and dissemination of RFCS" fall within the policy remit we have agreed to assign to the RSWG.  I do not think that includes management of the layout, tools, or content structure for the RFC Editor web site.

'Tools' is a word that's used imprecisely in the IETF. Would you consider the following in scope?

- Whether there should be an RSS feed with particular kinds of content available
- What specific information should be available on the site
- What *requirements* the layout, tools, or content structure should honour

Cheers,

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 5 Nov 2021 00:36:49 -0400

In line.  Although the real answer to most of the second set of 
questions is "it depends".

Yours,
Joel

> What about introducing new processes within its scope? E.g., the ability to gain consensus on a question and communicate that to the RPC/RSCE/LLC without publishing an RFC?

Since the structure in terms of the powers of the chairs, and the 
oversight by the RSAB, is keyed to the production of an RFC, introducing 
an alternative agreement form would seem at best to risk undermining the 
compromises of the structure.

Also, it seems to me that as long as the goal is policy, the cost of 
producing an RFC seems an acceptable cost for getting the work done well.

> - Whether there should be an RSS feed with particular kinds of content available
If asked as "whether the RFC Editor web site should support a 
subscription form of access to some set of data (e.g. newly publish 
RFCs), I can see that as policy.  Saying it is RSS is implementation.

> - What specific information should be available on the site
This gets marginal, but certainly can be policy.  For example, the 
question of whether the RFC Editor makes available versions of RFCs with 
the accepted errata inlined does seem to be policy.  That such be 
clearly identified is probably policy.  How it is to be presented is 
clearly NOT policy.

> - What *requirements* the layout, tools, or content structure should honour
Clearly, come of those requirements (e.g. ADA access) are policy.  And 
some things people describe as "requirements on layout (though shalt use 
style sheet "foo") are not policy.

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 5 Nov 2021 16:22:38 +1100

Hi Joel,

Inline as well. I think we're making progress, at least in terms of isolating the specific issues.

> On 5 Nov 2021, at 3:36 pm, Joel M. Halpern <[email-masked]> wrote:
> 
> In line.  Although the real answer to most of the second set of questions is "it depends".
> 
> Yours,
> Joel
> 
> Since the structure in terms of the powers of the chairs, and the oversight by the RSAB, is keyed to the production of an RFC, introducing an alternative agreement form would seem at best to risk undermining the compromises of the structure.

I anticipated that might be the answer, and I don't disagree with it -- but Eliot's proposal seemed to imply such flexibility.

> Also, it seems to me that as long as the goal is policy, the cost of producing an RFC seems an acceptable cost for getting the work done well.

Publishing an RFC is *extremely* onerous these days. I note that both the IESG and IAB document policy-like things on the Web as a result. 
  https://www.ietf.org/about/groups/iesg/statements/
  https://www.ietf.org/about/groups/iesg/iesg-coi-policy/
  https://www.iab.org/documents/correspondence-reports-documents/
  https://www.iab.org/internet-architecture-board-conflict-of-interest-policy/

Requiring an RFC for any statement from the RSWG is going to hobble its ability to do even simple things like answer a question from the Executive Director or RPC. If someone sees an obvious improvement that can quickly gain consensus, they'll need to either publish an RFC or (more likely, if they know the right people) make a quiet suggestion on the side.

We seem to agree that RSWG/RSAB are authoritative for the content on the RFC Editor site, in the sense that when there's disagreement about it, it will be resolved there. Is it really practical to wait for an RFC to be published if a problem comes up that requires that authority to be exercised?

> If asked as "whether the RFC Editor web site should support a subscription form of access to some set of data (e.g. newly publish RFCs), I can see that as policy.  Saying it is RSS is implementation.

Implementation is 'write a Perl script to produce the feed.' Specifying RSS (or more likely in our case, Atom, since it has an RFC) is a functional requirement -- i.e., we are requiring the site to interoperate with feed readers. Just as 'publish a Web site' implies use of HTML, not PDF.

If we can't agree to allow the RSWG to say such things, fine -- but it seems like an absurd limitation to force the RSWG to state everything in abstract weasel words for the LLC and RPC to interpret, and let's be clear: we're placing all of our faith in the LLC coming up with the appropriate way to deal with these 'implementation details', outside of the community as constituted. That's less transparent and open than I'd expect.

> This gets marginal, but certainly can be policy.  For example, the question of whether the RFC Editor makes available versions of RFCs with the accepted errata inlined does seem to be policy.  That such be clearly identified is probably policy.  How it is to be presented is clearly NOT policy.

Agreed.

> Clearly, come of those requirements (e.g. ADA access) are policy.  And some things people describe as "requirements on layout (though shalt use style sheet "foo") are not policy.

Agreed (it does indeed depend).

Cheers,

---

From: Eliot Lear <[email-masked]>
Date: Fri, 5 Nov 2021 08:56:48 +0100

Hi Mark, Mike, and Joel,

Very productive discussion.  TL;DR - scope of document probably ok, 
maybe tweak Section 3 chapeau to match Section 6 change of scope rules.  
Now please see below.

On 05.11.21 06:22, Mark Nottingham wrote:
>>>> On 5 Nov 2021, at 2:19 pm, Joel M. Halpern<[email-masked]>  wrote:
>>>>

My reading of the text agrees that the RSWG is really geared toward 
establishing policies and producing RFCs.*  For them to play an active 
role in managing content would require an entirely different decision 
process that is, as of yet, undocumented. Would that be a good idea?  Up 
to the community to decide, but it would, I think, be an impractical 
place to start, in order to achieve what I understand to be your goals.

I think the closest analog we have is the committer model in some OSS 
projects, where by agreement different people keep track of different 
parts of the code, and those committers get selected through various 
political processes – perhaps that's where you are aiming.  I could 
easily envision something akin to that here, and maybe that is a good 
hypothetical to discuss.

The question at hand is what policy would the RSWG state to cause that 
model to come to be.

Could an RFC state something along these lines (just an example):

 1. The LLC is requested to establish an OSS committer model that covers
    the following components: the RFC Editor web site, production, input
    processing, etc.
 2. The LLC is requested to provide a public log of all changes.
 3. Committers shall be selected by a committee {elected by the RSWG
    members OR appointed by the LLC OR appointed by the RSAB OR ....}
 4. Committer responsibilities include ensuring proper CI/CD for each
    change, validating, reviewing.
 5. The LLC may back out changes that it finds conflict with established
    policies or might otherwise unduly impact contractual
    responsibilities such as SLAs.
 6. Committers may be removed by {rough consensus of the RSWG OR vote of
    RSAB OR by whim of  Brian Rosen OR...}

There is some heavy lifting in the each of these bullets.  Again, my 
reading of this document allows for these sorts of negotiations to take 
place in the RSWG, under the current scope of authority. Could there be 
a conflict in with LLC model as negotiations take place?  Sure.  I would 
expect reason to prevail.  The LLC is simply not going to implement 
something that they can't implement.

And this is just one hypothetical example.  There may indeed be others, 
such as overlapping decision processes within the RSWG.  I don't know 
how those would look, but it sounds... messy.  And those might require a 
change of scope.  We are already saying that editorial series scope 
changes require additional layers of approval.  We could very much 
borrow some text from Section 6, along the lines that Mike has 
mentioned.**  The implication would be that we should try to use the LLC 
relationship we have before doing major surgery.

If people agree, we will need to wordsmith the Section 3 chapeau 
slightly, but not in a way that I think changes the overall intent in 
our work.

Eliot

*Entertainment/bar moment: Mark Twain once said, “There is no such thing 
as a new idea...”  The model we have is somewhat analogous to the 
separation of powers in the US, where the legislature (RSWG as lower 
house/RSAB as upper house) proposes and the executive (LLC) disposes.  
And so the LLC would have to establish community involvement and 
transparency mechanisms that are guided by the legislation created by 
the RSWG/RSAB.

**Mike, I take it you took your proposed chapeau text directly from 
Section 6?

Eliot

---

From: Mirja Kuehlewind <[email-masked]>
Date: Fri, 5 Nov 2021 10:31:52 +0100

Hi Brian,

> On 4. Nov 2021, at 21:02, Brian E Carpenter <[email-masked]> wrote:
> 
> Well yes. It isn't actually said very clearly in RFC 8711, but the implication is that the LLC provides tools and the IETF web site, and controls the RFC Editor contract, which implies the RFC tools and web site.

I have to slightly disagree here. Jay nicely separated 4 different angles about the website strategy, function design, content, and infrastructure. While the LLC or RPC is responsible for the infrastructure of running and maintaining the website, there is a gap in who owns the content and functions design decisions. And based on my own interactions with the RPC I believe they also don’t want to be responsible for the content, beyond just reflect what’s written down in RFCs, as that would require more community responsibility.

While the IESG has authority about (at least most parts of) the IESG website content, I don’t think it should be the RPC or LLC that has authority about the RFC editor website content and I don’t think that’s what RFC8711 says because otherwise this would also be true for IETF website.

So I think we have a gap here. I don’t think the RSWG has the right structure to fill that gap (as these things don’t require policy, aka Jay’s point about strategy for the webpage) but decisions. For me the only available option is the RSAP (or something entirely new but I really hope we won’t end up adding more bureaucracy and positions to the model)...

Mirja

> But as I have quoted to the point of boredom, it also says that the LLC "is expected to respect the IETF community's wishes". As far as rules go, I believe that's all we've got. It's enough, but it does seem that our draft should empower the RSWG/RSAB to *express* those wishes. We can't change RFC 8711, because we're not the IETF.
> 
>   Brian
> 
>> Mirja

---

From: John C Klensin <[email-masked]>
Date: Fri, 05 Nov 2021 09:01:15 -0400

--On Friday, November 5, 2021 08:56 +0100 Eliot Lear
<[email-masked]> wrote:

>...
> *Entertainment/bar moment: Mark Twain once said, "There is
> no such thing as a new idea..."  The model we have is
> somewhat analogous to the separation of powers in the US,
> where the legislature (RSWG as lower house/RSAB as upper
> house) proposes and the executive (LLC) disposes.  And so the
> LLC would have to establish community involvement and
> transparency mechanisms that are guided by the legislation
> created by the RSWG/RSAB.

Eliot,

Poor analogy.    More specifically, the analogy more or less
works as long as everything goes smoothly.  If they don't, the
US system is supposed to include a third branch which can
interpret those decisions and actions and enforce consistency
with more general and lasting principles (we seem to be in the
middle of a test as to whether that will continue to work).
More important, that legislative body has the power to remove an
executive who does not implement the policies it sets.  Neither
the RSWG/RSAG combination nor the "IETF community" (whatever
that means) have the authority to remove the LLC or override its
decisions.

     john

---

From: Michael StJohns <[email-masked]>
Date: Fri, 5 Nov 2021 14:52:49 -0400

On 11/5/2021 3:56 AM, Eliot Lear wrote:
> maybe tweak Section 3 chapeau to match Section 6 change of scope 
> rules.  Now please see below.
>
> process that is, as of yet, undocumented.  Would that be a good idea?  
> Up to the community to decide, but it would, I think, be an 
> impractical place to start, in order to achieve what I understand to 
> be your goals.
>
I'm not quite sure why we're here yet again.   We set up a division of 
labor way early.  If you really think we need to reopen that division of 
labor, I've got a whole lot of other things we can reopen at the same 
time that were based on the understanding of that division of labor.

Basically, the RSWG writes documents - period.  It does not in any way 
shape or form run anything operational, nor give operational guidance, 
nor produce opinions except in the form of documents which have the 
consensus of the RSWG.  It has no mechanism for it, and there is no 
similar mechanism in the IETF that can be borrowed that would not end up 
turning the RSWG into something closer to the RSOC than most of us feel 
comfortable doing - and even the RSOC members were not self-selected.

>  1. The LLC is requested to establish an OSS committer model that
>     covers the following components: the RFC Editor web site,
>     production, input processing, etc.
>  5. The LLC may back out changes that it finds conflict with
>     established policies or might otherwise unduly impact contractual
>  6. Committers may be removed by {rough consensus of the RSWG OR vote
>     of RSAB OR by whim of  Brian Rosen OR...}
>
Seriously, this reads like something out of an open source software 
program (which apparently it is), not a policy shop for the RFC 
series.   I can't see any way in which a consistent and sane RFC series 
could continue under a model like the above.  In particular, "elected by 
the RSWG members" is particularly offensive - like every other WG, there 
are no members, only participants - we don't do voting.  Something like 
that could provide the beginnings of an oligarchy who might feel free to 
ignore community input.

I will note that the above eliminates the IESG, IAB, IRTF chair and the 
RPC as places where sanity might occur in the publication of documents.

If you want to throw out hypotheticals, maybe there's one that isn't 
quite this bad?  (And don't say Wiki....)

> And this is just one hypothetical example.  There may indeed be 
> others, such as overlapping decision processes within the RSWG. I 
> don't know how those would look, but it sounds... messy.  And those 
> might require a change of scope.  We are already saying that editorial 
> series scope changes require additional layers of approval.  We could 
> very much borrow some text from Section 6, along the lines that Mike 
> has mentioned.**  The implication would be that we should try to use 
> the LLC relationship we have before doing major surgery.
>
I didn't actually borrow from section 6.  Section 6 talks about the 
Editorial stream and the use of the BCP and STD tags.   I'm more 
concerned with making sure that the division of labor we've agreed upon 
doesn't get overthrown with the first document out of the RSWG.
> *Entertainment/bar moment: Mark Twain once said, “There is no such 
> thing as a new idea...”  The model we have is somewhat analogous to 
> the separation of powers in the US, where the legislature (RSWG as 
> lower house/RSAB as upper house) proposes and the executive (LLC) 
> disposes.  And so the LLC would have to establish community 
> involvement and transparency mechanisms that are guided by the 
> legislation created by the RSWG/RSAB.
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 6 Nov 2021 11:58:10 +1300

Hi Mirja,

On 05-Nov-21 22:31, Mirja Kuehlewind wrote:
>>> This RFC was written before the datatracker was widely used and when the old ietf.org page was still up. From the RFC it seems, however, quite 
cleat that all matters related to the datatracker are clearly in scope for
>> the IESG, however, there are probably parts of the ietf.org side where 
authority is not fully clear or lies with some other entities (e.g. information about the LLC or the IAB…).
> I have to slightly disagree here. Jay nicely separated 4 different angles about the website strategy, function design, content, and infrastructure. While the LLC or RPC is responsible for the infrastructure of running 
and maintaining the website, there is a gap in who owns the content and functions design decisions. And based on my own interactions with the RPC I believe they also don’t want to be responsible for the content, 
beyond just reflect what’s written down in RFCs, as that would require more community responsibility.
> 
> While the IESG has authority about (at least most parts of) the IESG website content, I don’t think it should be the RPC or LLC that has 
authority about the RFC editor website content and I don’t think that’s what RFC8711 says because otherwise this would also be true for IETF website.

I agree with that. As others have made clear, the boundary between policy 
and implementation is somewhat subjective, but except in emergencies, the 
RPC and LLC are not supposed to make policy.
  
> So I think we have a gap here. I don’t think the RSWG has the right structure to fill that gap (as these things don’t require policy, aka Jay’s point about strategy for the webpage) but decisions.…

Agreed, sort of. But I observe that when needed, the IESG sets policy by issuing an IESG Statement. I see no reason why the RSWG/RSAB can't issue a formal statement when the topic is not suitable for an RFC. If there are words in the draft that forbid that, we should remove those words.

So, someone proposes in the RSWG that the RFC Editor web site should be unavailable on the day of the full moon. There is rough consensus for this, the RSAB agrees, and puts out a formal Statement saying so. The RPC implements this.

    Brian

> 
> Mirja
> 
>   
> 
>> But as I have quoted to the point of boredom, it also says that the LLC "is expected to respect the IETF community's wishes". As far as rules go, I believe that's all we've got. It's enough, but it does seem that our 
draft should empower the RSWG/RSAB to *express* those wishes. We can't change RFC 8711, because we're not the IETF.
>>>>> I agree authority about the content of any page should not sit with 
the the LLC. For the ietf.org page and the datatracker the authority is with the IESG which a board of community members selected by community member.
> .

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 5 Nov 2021 16:25:59 -0700

On Fri, Nov 5, 2021 at 3:58 PM Brian E Carpenter <
[email-masked]> wrote:

> >>> This RFC was written before the datatracker was widely used and when
> the old ietf.org page was still up. From the RFC it seems, however, quite
> >> Well yes. It isn't actually said very clearly in RFC 8711, but the
> implication is that the LLC provides tools and the IETF web site, and
> controls the RFC Editor contract, which implies the RFC tools and web site.
> >
> > I have to slightly disagree here. Jay nicely separated 4 different
> angles about the website strategy, function design, content, and
> infrastructure. While the LLC or RPC is responsible for the infrastructure
> of running
> and maintaining the website, there is a gap in who owns the content and
> functions design decisions. And based on my own interactions with the RPC I
> believe they also don’t want to be responsible for the content,
> > While the IESG has authority about (at least most parts of) the IESG
> website content, I don’t think it should be the RPC or LLC that has
> authority about the RFC editor website content and I don’t think that’s
> what RFC8711 says because otherwise this would also be true for IETF
> website.
>
> > So I think we have a gap here. I don’t think the RSWG has the right
> structure to fill that gap (as these things don’t require policy, aka Jay’s
> point about strategy for the webpage) but decisions. For me the only
> available option is the RSAP (or something entirely new but I really hope
> we won’t end up adding more bureaucracy and positions to the model)...
>
> Agreed, sort of. But I observe that when needed, the IESG sets policy by
> issuing an IESG Statement. I see no reason why the RSWG/RSAB can't issue a
> formal statement when the topic is not suitable for an RFC. If there are
> words in the draft that forbid that, we should remove those words.
>
> So, someone proposes in the RSWG that the RFC Editor web site should be
> unavailable on the day of the full moon. There is rough consensus for this,
> the RSAB agrees, and puts out a formal Statement saying so. The RPC
> implements this.
>

I agree with this. This is consistent, I think with our practice of having
non-RFC IESG statements that still have substantive force.

-Ekr

    Brian
>
> >
> > Mirja
> >
> >
> >
> >> But as I have quoted to the point of boredom, it also says that the LLC
> "is expected to respect the IETF community's wishes". As far as rules go, I
> believe that's all we've got. It's enough, but it does seem that our
> draft should empower the RSWG/RSAB to *express* those wishes. We can't
> change RFC 8711, because we're not the IETF.
> >>
> >>    Brian
> >>
> >>> Mirja
> the the LLC. For the ietf.org page and the datatracker the authority is
> with the IESG which a board of community members selected by community
> member.
> >>>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 5 Nov 2021 19:34:18 -0400

I think there is a basic problem with this approach (at the bottom) of 
RSWG statements.
IESG statements are made by people appointed by and responsible to the 
community.  We permit them to make statements that do not necessarily 
have rough community consensus when decisions need to be made.  because 
they are our seleccted leaders.

Allowing the RSWG to issue statements does not match that pattern at 
all.  These statements are not, by the rules we have written so far, 
even subject to review by the RSAB.  They do not require community 
review and acceptance.

People keep saying that RFCs are a lot of work.  What the numbers that 
others have produceed show is that the work is in the working group and 
community rough consensus process.  Either we retain that part of the 
process, and thus the work, or we ditch that and have an unaccountable 
body able to exercise authority of the workings of the RPC.

For me, I would rather retain the work.  if the thing being done does 
not have a long enough impact to be published, then it is clearly not 
Policy.  Its tactics.

Yours,
Joel

On 11/5/2021 7:25 PM, Eric Rescorla wrote:
> 
> 
> On Fri, Nov 5, 2021 at 3:58 PM Brian E Carpenter 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi Mirja,
> 
>      >> On 4. Nov 2021, at 21:02, Brian E Carpenter
>     <[email-masked] <mailto:[email-masked]>>
>     wrote:
>      >>
>      >>> However, if you further read on, the RFC says "The IESG has web
>     pages
>     as part of the IETF web (www.ietf.org <http://www.ietf.org>)”.
>      >>> This RFC was written before the datatracker was widely used and
>     when the old ietf.org <http://ietf.org> page was still up. From the
>     RFC it seems, however, quite
>      >> the IESG, however, there are probably parts of the ietf.org
>     <http://ietf.org> side where
>      >> Well yes. It isn't actually said very clearly in RFC 8711, but
>     the implication is that the LLC provides tools and the IETF web
>     site, and controls the RFC Editor contract, which implies the RFC
>     tools and web site.
>      >
>      > I have to slightly disagree here. Jay nicely separated 4
>     different angles about the website strategy, function design,
>     content, and infrastructure. While the LLC or RPC is responsible for
>     the infrastructure of running
>     and maintaining the website, there is a gap in who owns the content
>     and functions design decisions. And based on my own interactions
>     with the RPC I believe they also don’t want to be responsible for
>     the content,
>      > While the IESG has authority about (at least most parts of) the
>     IESG website content, I don’t think it should be the RPC or LLC that
>     has
>     authority about the RFC editor website content and I don’t think
>     that’s what RFC8711 says because otherwise this would also be true
>     for IETF website.
> 
>      > So I think we have a gap here. I don’t think the RSWG has the
>     right structure to fill that gap (as these things don’t require
>     policy, aka Jay’s point about strategy for the webpage) but
>     decisions. For me the only available option is the RSAP (or
>     something entirely new but I really hope we won’t end up adding more
>     bureaucracy and positions to the model)...
> 
>     Agreed, sort of. But I observe that when needed, the IESG sets
>     policy by issuing an IESG Statement. I see no reason why the
>     RSWG/RSAB can't issue a formal statement when the topic is not
>     suitable for an RFC. If there are words in the draft that forbid
>     that, we should remove those words.
> 
>     So, someone proposes in the RSWG that the RFC Editor web site should
>     be unavailable on the day of the full moon. There is rough consensus
>     for this, the RSAB agrees, and puts out a formal Statement saying
>     so. The RPC implements this.
> 
> 
> I agree with this. This is consistent, I think with our practice of 
> having non-RFC IESG statements that still have substantive force.
> 
> -Ekr
> 
>          Brian
> 
>      >
>      > Mirja
>      >
>      >
>      >
>      >> But as I have quoted to the point of boredom, it also says that
>     the LLC "is expected to respect the IETF community's wishes". As far
>     as rules go, I believe that's all we've got. It's enough, but it
>     does seem that our
>     draft should empower the RSWG/RSAB to *express* those wishes. We
>     can't change RFC 8711, because we're not the IETF.
>      >>
>      >>    Brian
>      >>
>      >>> Mirja
>      >>>> On 4. Nov 2021, at 13:59, Eliot Lear <[email-masked]
>     <mailto:[email-masked]>> wrote:
>      >>>>
>      >>>>
>     the the LLC. For the ietf.org <http://ietf.org> page and the
>     datatracker the authority is with the IESG which a board of
>     community members selected by community member.
>      >>>>
>      >> [email-masked] <mailto:[email-masked]>
>     <https://www.iab.org/mailman/listinfo/rfced-future>
>      >
>      > .
>      >
> 
>     -- 
>     [email-masked] <mailto:[email-masked]>
>     <https://www.iab.org/mailman/listinfo/rfced-future>
>

---

From: Michael StJohns <[email-masked]>
Date: Fri, 5 Nov 2021 19:37:22 -0400

On 11/5/2021 7:34 PM, Joel M. Halpern wrote:
> have rough community consensus when decisions need to be made.  
> because they are our seleccted leaders.
>
> others have produceed show is that the work is in the working group 
> and community rough consensus process.  Either we retain that part of 
> the process, and thus the work, or we ditch that and have an 
> unaccountable body able to exercise authority of the workings of the RPC.
>

Joel said it much better than I could have and I agree with this 
unconditionally. Mike

>>      > Hi Brian,
>>      >
>>      >> On 4. Nov 2021, at 21:02, Brian E Carpenter
>>      >>
>>      >> On 05-Nov-21 02:10, Mirja Kuehlewind wrote:
>>      >>> Actually, that's a bit overly simplified I guess. RFC3710 say
>>     “[The IESG] also
>>      >>>     administers IETF logistics, including operation of the
>>     Internet-Draft
>>      >>>     document series and the IETF meeting event.”
>>      >>> However, if you further read on, the RFC says "The IESG has web
>>     pages
>>      >>> This RFC was written before the datatracker was widely used and
>>      >> the IESG, however, there are probably parts of the ietf.org
>>      >>
>>      >> Well yes. It isn't actually said very clearly in RFC 8711, but
>>      >
>>      > I have to slightly disagree here. Jay nicely separated 4
>>      >
>>      > While the IESG has authority about (at least most parts of) the
>>      > So I think we have a gap here. I don’t think the RSWG has the
>>      >
>>      > Mirja
>>      >
>>      >
>>      >
>>      >> But as I have quoted to the point of boredom, it also says that
>>      >>
>>      >>    Brian
>>      >>
>>      >>> Mirja
>>      >>>> On 4. Nov 2021, at 13:59, Eliot Lear <[email-masked]
>>      >>>>
>>      >>>>
>>      >>>> On 04.11.21 13:57, Mirja Kuehlewind wrote:
>>      >>>>> I agree authority about the content of any page should not
>>     sit with
>>      >>>>
>>      >>>> Precisely where does it say that?  Maybe we can model that
>>     language.
>>      >>>>
>>      >>>> Eliot
>>      >>>>
>>      >>>> <OpenPGP_0x87B66B46D9D27A33.asc>
>>      >>
>>      >> --
>>      >> Rfced-future mailing list
>>      >> [email-masked] <mailto:[email-masked]>
>>      >> https://www.iab.org/mailman/listinfo/rfced-future
>>      >
>>      > .
>>      >
>>     --     Rfced-future mailing list

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 5 Nov 2021 18:13:24 -0700

FWIW, I was anticipating that these statements would go through the same
process as RFCs, they just wouldn't be published in the series.

With that said, if we can agree that RFCs published by the RSWG/RSAB
venue either have immediate effect upon RSAB approval or expedited
publication in the RFC series, I don't object to them being published as
RFCs.

-Ekr

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 5 Nov 2021 22:39:15 -0400

I could live with declaring that policy determined by the RSWG / RSAB 
takes effect when the RFC is approved for publication.
Yours,
Joel

On 11/5/2021 9:13 PM, Eric Rescorla wrote:
> On Fri, Nov 5, 2021 at 4:34 PM Joel M. Halpern <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>      > <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>      >
>      >     Hi Mirja,
>      >
>      >     <[email-masked]
>     <mailto:[email-masked]>
>     <mailto:[email-masked]
>     <mailto:[email-masked]>>>
>      >     wrote:
>      >      >>
>      >     as part of the IETF web (www.ietf.org <http://www.ietf.org>
>     <http://www.ietf.org <http://www.ietf.org>>)”.
>      >     when the old ietf.org <http://ietf.org> <http://ietf.org
>     <http://ietf.org>> page was still up. From the
>      >      >> the IESG, however, there are probably parts of the
>     ietf.org <http://ietf.org>
>      >     <http://ietf.org <http://ietf.org>> side where
>      >     authority is not fully clear or lies with some other entities
>     (e.g.
>      >     information about the LLC or the IAB…).
>      >      >>
>      >     I agree with that. As others have made clear, the boundary
>     between
>      >     policy
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >      >>>>
>      >      >>>>
>      >     the the LLC. For the ietf.org <http://ietf.org>
>     <http://ietf.org <http://ietf.org>> page and the
>     <mailto:[email-masked] <mailto:[email-masked]>>
>      >     <https://www.iab.org/mailman/listinfo/rfced-future
>     <https://www.iab.org/mailman/listinfo/rfced-future>>
>      >      >
>      >      > .
>      >      >
>      >
>      >     --
>     <mailto:[email-masked] <mailto:[email-masked]>>
>      >     <https://www.iab.org/mailman/listinfo/rfced-future
>     <https://www.iab.org/mailman/listinfo/rfced-future>>
>      >
>

---

From: "StJohns, Michael" <[email-masked]>
Date: Fri, 5 Nov 2021 23:07:11 -0400

I’m mostly ok with the LLC beginning it’s actions once the document is
approved for publication.  We do need to manage expectations, as simple
things might incur out of proportion costs and may require LLC to twiddle
its budget.  Or may just not be possible immediately. To be clear, the
authors may not use AUTH48 to expand upon what was approved.

EKR - I think it’s in your corner to propose text?

Mike

On Fri, Nov 5, 2021 at 22:39 Joel M. Halpern <[email-masked]> wrote:

> and
> >      >      >>> Actually, that's a bit overly simplified I guess.
> >     RFC3710 say
> >      >     “[The IESG] also
> >      >      >>>     administers IETF logistics, including operation of
> the
> >      >     Internet-Draft
> >      >     cleat that all matters related to the datatracker are clearly
> in
> >      >     scope for
> >      >      >> the IESG, however, there are probably parts of the
> >      >      >>>>> I agree authority about the content of any page should
> not
> >      >     sit with
> >      >      >>>> Precisely where does it say that?  Maybe we can model
> that
> >      >     language.
> >      >      >>>>
> >      >      >>>> Eliot
> >      >      >>>>

---

From: "StJohns, Michael" <[email-masked]>
Date: Fri, 5 Nov 2021 23:16:23 -0400

As I wrote the stuff below, I realized that we hadn’t considered the AUTH48
and author/editor centric stuff in the publication process.  Unlike IETF WG
documents, or for that matter most other stream documents, editorial stream
documents will always (mostly?) be the product of the whole RSWG not a
specific author or set of authors.  That suggests that AUTH48 queries may
need to be sent to the entire WG, with anything more complex than phrasing
and comment placement needing WG input.

Consider the above a partially formed thought.

Mike

On Fri, Nov 5, 2021 at 23:07 StJohns, Michael <[email-masked]>
wrote:

>> >      > <[email-masked] <mailto:[email-masked]
>> >
>> >      >     cleat that all matters related to the datatracker are
>> clearly in
>> >      >     scope for
>> >      >     beyond just reflect what’s written down in RFCs, as that
>> would
>> >      >     require more community responsibility.
>> >      >      >
>> >      >      >>>>> I agree authority about the content of any page
>> should not
>> >      >     sit with

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 6 Nov 2021 16:54:04 +1300

Hi Mike,

I think that's wrong. At least for the IETF stream, any WG document that gets to AUTH48 is the work of the WG, and the authors are really editors on behalf of the WG. The AUTH48 goes to the authors, and iirc to the WG chairs, the shepherd, and the sponsoring AD. Correct behaviour is that if (and only if) there is an issue that is not editorial, the proposed change is taken briefly to the WG list. (Briefly, that is, if it is non-controversial. If it proves to be controversial, AUTH48 can take 48 weeks...)

Why would the RSWG be different?

Regards
    Brian

On 06-Nov-21 16:16, StJohns, Michael wrote:
> As I wrote the stuff below, I realized that we hadn’t considered the AUTH48 and author/editor centric stuff in the publication process.  Unlike IETF WG documents, or for that matter most other stream documents, editorial stream documents will always (mostly?) be the product of the whole RSWG not a specific author or set of authors.  That suggests that AUTH48 queries may need to be sent to the entire WG, with anything 
more complex than phrasing and comment placement needing WG input.
> On Fri, Nov 5, 2021 at 23:07 StJohns, Michael <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     I’m mostly ok with the LLC beginning it’s actions once the document is approved for publication.  We do need to manage expectations, as simple things might incur out of proportion costs and may require LLC to twiddle its budget.  Or may just not be possible immediately. To be clear, the authors may not use AUTH48 to expand upon what was approved.
> 
> 
> 
>     On Fri, Nov 5, 2021 at 22:39 Joel M. Halpern <[email-masked] <mailto:[email-masked]>> wrote:
> 
>          > On Fri, Nov 5, 2021 at 4:34 PM Joel M. Halpern <[email-masked] <mailto:[email-masked]>
>          > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>          >
>          >      > On Fri, Nov 5, 2021 at 3:58 PM Brian E 
Carpenter
>          >      > <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>          >     <mailto:[email-masked] <mailto:[email-masked]>
>          >     <mailto:[email-masked] <mailto:[email-masked]>>>> wrote:
>          >      >
>          >      >     Hi Mirja,
>          >      >
>          >      >     On 05-Nov-21 22:31, 
Mirja Kuehlewind wrote:
>          >      >      > Hi Brian,
>          >      >      >
>          >      >      >> On 4. Nov 2021, 
at 21:02, Brian E Carpenter
>          >      >     <[email-masked] <mailto:[email-masked]>
>          >     <mailto:[email-masked] <mailto:[email-masked]>>
>          >     <mailto:[email-masked] <mailto:[email-masked]>
>          >     <mailto:[email-masked] <mailto:[email-masked]>>>>
>          >      >     wrote:
>          >      >      >>
>          >      >      >> On 05-Nov-21 02:10, Mirja Kuehlewind wrote:
>          >      >      >>> Actually, that's a bit overly simplified I guess.
>          >     RFC3710 say
>          >      >     “[The IESG] 
also
>          >      >      >>>     administers IETF logistics, including operation of the
>          >      >     Internet-Draft
>          >      >      >>>     document series and the IETF meeting event.”
>          >      >      >>> However, if you further read on, the RFC says "The IESG
>          >     has web
>          >      >     pages
>          >      >     as part of the IETF 
web (www.ietf.org <http://www.ietf.org> <http://www.ietf.org <http://www.ietf.org>>
>          >     <http://www.ietf.org <http://www.ietf.org> <http://www.ietf.org <http://www.ietf.org>>>)”.
>          >      >      >>> This RFC was written before the datatracker was widely
>          >     used and
>          >      >     when the old ietf.org <http://ietf.org> <http://ietf.org <http://ietf.org>> <http://ietf.org 
<http://ietf.org>
>          >     <http://ietf.org <http://ietf.org>>> page 
was still up. From the
>          >      >     RFC it seems, however, quite
>          >      >     cleat that all matters related to the datatracker are clearly in
>          >      >     scope for
>          >      >      >> the IESG, however, there are probably parts of the
>          > ietf.org <http://ietf.org> <http://ietf.org <http://ietf.org>>
>          >      >     <http://ietf.org <http://ietf.org> <http://ietf.org <http://ietf.org>>> side where
>          >      >     authority is not fully clear or lies with some other entities
>          >     (e.g.
>          >      >     information about the LLC or the IAB…).
>          >      >      >>
>          >      >      >> Well yes. It isn't actually said very clearly in RFC
>          >     8711, but
>          >      >     the implication is that the LLC provides tools and the IETF web
>          >      >     site, and controls the RFC Editor contract, which implies the RFC
>          >      >     tools and web site.
>          >      >      >
>          >      >      > I have to slightly disagree here. Jay nicely separated 4
>          >      >     different angles about the website strategy, function design,
>          >      >     content, and infrastructure. While the LLC or RPC is
>          >     responsible for
>          >      >     the infrastructure of running
>          >      >     and maintaining the 
website, there is a gap in who owns the
>          >     content
>          >      >     and functions design decisions. And based on my own interactions
>          >      >     with the RPC I believe they also don’t want to be responsible for
>          >      >     the content,
>          >      >     beyond just reflect 
what’s written down in RFCs, as that would
>          >      >     require more community responsibility.
>          >      >      >
>          >      >      > While the IESG has authority about (at least most parts
>          >     of) the
>          >      >     IESG website content, I don’t think it should be the RPC or
>          >     LLC that
>          >      >     has
>          >      >     authority about the 
RFC editor website content and I don’t think
>          >      >     that’s what 
RFC8711 says because otherwise this would also be
>          >     true
>          >      >     for IETF website.
>          >      >
>          >      >     I agree with that. As others have made clear, the boundary
>          >     between
>          >      >     policy
>          >      >     and implementation is somewhat subjective, but except in
>          >      >     emergencies, the
>          >      >     RPC and LLC are not 
supposed to make policy.
>          >      >
>          >      >      > So I think we have a gap here. I don’t think the RSWG has the
>          >      >     right structure to fill that gap (as these things don’t require
>          >      >     policy, aka Jay’s point about strategy for the webpage) but
>          >      >     decisions. For me the only available option is the RSAP (or
>          >      >     something entirely new but I really hope we won’t end up
>          >     adding more
>          >      >     bureaucracy and positions to the model)...
>          >      >
>          >      >     Agreed, sort of. But I observe that when needed, the IESG sets
>          >      >     policy by issuing an IESG Statement. I see no reason why the
>          >      >     RSWG/RSAB can't issue a formal statement when the topic is not
>          >      >     suitable for an RFC. If there are words in the draft that forbid
>          >      >     that, we should remove those words.
>          >      >
>          >      >     So, someone proposes in the RSWG that the RFC Editor web site
>          >     should
>          >      >     be unavailable on the day of the full moon. There is rough
>          >     consensus
>          >      >     for this, the RSAB agrees, and puts out a formal Statement saying
>          >      >     so. The RPC implements this.
>          >      >
>          >      >
>          >      > I agree with this. This is consistent, 
I think with our practice of
>          >      > having non-RFC IESG statements that still have substantive force.
>          >      >
>          >      > -Ekr
>          >      >
>          >      >          Brian
>          >      >
>          >      >      >
>          >      >      > Mirja
>          >      >      >
>          >      >      >
>          >      >      >
>          >      >      >> But as I have quoted to the point of boredom, it also
>          >     says that
>          >      >     the LLC "is expected to respect the IETF community's wishes".
>          >     As far
>          >      >     as rules go, I believe that's all we've got. It's enough, but it
>          >      >     does seem that our
>          >      >     draft should empower the RSWG/RSAB to *express* those wishes. We
>          >      >     can't change RFC 8711, because we're not the IETF.
>          >      >      >>
>          >      >      >>    Brian
>          >      >      >>
>          >      >      >>> Mirja
>          >      >      >>>> On 4. Nov 2021, at 13:59, Eliot Lear <[email-masked] <mailto:[email-masked]>
>          >     <mailto:[email-masked] <mailto:[email-masked]>>
>          >      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>> wrote:
>          >      >      >>>>
>          >      >      >>>>
>          >      >      >>>> On 04.11.21 13:57, Mirja Kuehlewind wrote:
>          >      >      >>>>> I agree authority about the content of any page should not
>          >      >     sit with
>          >      >     the the LLC. For the ietf.org <http://ietf.org> <http://ietf.org <http://ietf.org>>
>          >     <http://ietf.org <http://ietf.org> <http://ietf.org <http://ietf.org>>> page and the
>          >      >     datatracker the authority is with the IESG which a board of
>          >      >     community members selected by community member.
>          >      >      >>>>
>          >      >      >>>> Precisely where does it say that?  Maybe we can model that
>          >      >     language.
>          >      >      >>>>
>          >      >      >>>> Eliot
>          >      >      >>>>
>          >      >      >>>> <OpenPGP_0x87B66B46D9D27A33.asc>
>          >      >      >>
>          >      >      >> --
>          >      >      >> Rfced-future mailing list
>          >      >      >> [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>          >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
>          >      >      >> https://www.iab.org/mailman/listinfo/rfced-future <https://www.iab.org/mailman/listinfo/rfced-future>
>          >     <https://www.iab.org/mailman/listinfo/rfced-future <https://www.iab.org/mailman/listinfo/rfced-future>>
>          >      >     <https://www.iab.org/mailman/listinfo/rfced-future <https://www.iab.org/mailman/listinfo/rfced-future>
>          >     <https://www.iab.org/mailman/listinfo/rfced-future <https://www.iab.org/mailman/listinfo/rfced-future>>>
>          >      >      >
>          >      >      > .
>          >      >      >
>          >      >
>          >      >     --
>          >      >     Rfced-future mailing list
>          >      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>          >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
>          >      > https://www.iab.org/mailman/listinfo/rfced-future <https://www.iab.org/mailman/listinfo/rfced-future>
>          >     <https://www.iab.org/mailman/listinfo/rfced-future <https://www.iab.org/mailman/listinfo/rfced-future>>
>          >      >     <https://www.iab.org/mailman/listinfo/rfced-future <https://www.iab.org/mailman/listinfo/rfced-future>
>          >     <https://www.iab.org/mailman/listinfo/rfced-future <https://www.iab.org/mailman/listinfo/rfced-future>>>
>          >      >
>          >
> 
>         -- 
>         https://www.iab.org/mailman/listinfo/rfced-future <https://www.iab.org/mailman/listinfo/rfced-future>
> 
>

---

From: Eliot Lear <[email-masked]>
Date: Sat, 6 Nov 2021 09:00:16 +0100

Ok.

What I am hearing is that we should add a sentence saying that policies 
take upon approval by the RSAB, regardless of the timing of publication 
of an RFC.

Eliot

On 06.11.21 04:54, Brian E Carpenter wrote:
> Hi Mike,
>
> I think that's wrong. At least for the IETF stream, any WG document 
> that gets to AUTH48 is the work of the WG, and the authors are really 
> editors on behalf of the WG. The AUTH48 goes to the authors, and iirc 
> to the WG chairs, the shepherd, and the sponsoring AD. Correct 
> behaviour is that if (and only if) there is an issue that is not 
> editorial, the proposed change is taken briefly to the WG list. 
> (Briefly, that is, if it is non-controversial. If it proves to be 
> controversial, AUTH48 can take 48 weeks...)
>
>> As I wrote the stuff below, I realized that we hadn’t considered the 
>> AUTH48 and author/editor centric stuff in the publication process.  
>> Unlike IETF WG documents, or for that matter most other stream 
>> documents, editorial stream documents will always (mostly?) be the 
>> product of the whole RSWG not a specific author or set of authors.  
>> That suggests that AUTH48 queries may need to be sent to the entire 
>> WG, with anything 
>>     I’m mostly ok with the LLC beginning it’s actions once the 
>> document is approved for publication.  We do need to manage 
>> expectations, as simple things might incur out of proportion costs 
>> and may require LLC to twiddle its budget.  Or may just not be 
>> possible immediately. To be clear, the authors may not use AUTH48 to 
>> expand upon what was approved.
>>
>>
>>
>>          > FWIW, I was anticipating that these statements would go 
>> through the same
>>          > process as RFCs, they just wouldn't be published in the 
>> series.
>>          >
>>          > With that said, if we can agree that RFCs published by the 
>> RSWG/RSAB
>>          > venue either have immediate effect upon RSAB approval or 
>> expedited
>>          > publication in the RFC series, I don't object to them 
>> being published as
>>          > RFCs.
>>          >
>>          > -Ekr
>>          >
>>          >
>>          >
>>          > On Fri, Nov 5, 2021 at 4:34 PM Joel M. Halpern 
>> <[email-masked] <mailto:[email-masked]>
>>          > <mailto:[email-masked] <mailto:[email-masked]>>> 
>> wrote:
>>          >
>>          >     I think there is a basic problem with this approach 
>> (at the bottom) of
>>          >     RSWG statements.
>>          >     IESG statements are made by people appointed by and 
>> responsible to the
>>          >     community.  We permit them to make statements that do 
>> not necessarily
>>          >     have rough community consensus when decisions need to 
>> be made.  because
>>          >     they are our seleccted leaders.
>>          >
>>          >     Allowing the RSWG to issue statements does not match 
>> that pattern at
>>          >     all.  These statements are not, by the rules we have 
>> written so far,
>>          >     even subject to review by the RSAB. 
> They do not require community
>>          >     review and acceptance.
>>          >
>>          >     People keep saying that RFCs are a lot of 
> work.  What the numbers that
>>          >     others have produceed show is that the work is in the 
>> working group and
>>          >     community rough consensus process.  Either we retain 
>> that part of the
>>          >     process, and thus the work, or we ditch that and have 
>> an unaccountable
>>          >     body able to exercise authority of the workings of the 
>> RPC.
>>          >
>>          >     For me, I would rather retain the work.  if the thing 
>> being done does
>>          >     not have a long enough impact to be published, then it 
>> is clearly not
>>          >     Policy.  Its tactics.
>>          >
>>          >     Yours,
>>          >     Joel
>>          >
>>          >     On 11/5/2021 7:25 PM, Eric Rescorla wrote:
>>          >      >
>>          >      >
>>          >      > On Fri, Nov 5, 2021 at 3:58 PM Brian E 
> Carpenter
>>          >      > <[email-masked] 
>> <mailto:[email-masked]>>
>>          >     <mailto:[email-masked] 
>>          >     <mailto:[email-masked] 
>> <mailto:[email-masked]>>>> wrote:
>>          >      >
>>          >      >     Hi Mirja,
>>          >      >
>>          >      >     On 05-Nov-21 22:31, 
> Mirja Kuehlewind wrote:
>>          >      >      > Hi Brian,
>>          >      >      >
>>          >      >      >> On 4. Nov 2021, 
>>          >      >  <[email-masked] 
>>          >     <mailto:[email-masked] 
>> <mailto:[email-masked]>>
>>          >     <mailto:[email-masked] 
>>          >     <mailto:[email-masked] 
>> <mailto:[email-masked]>>>>
>>          >      >     wrote:
>>          >      >      >>
>>          >      >      >> On 05-Nov-21 02:10, Mirja Kuehlewind wrote:
>>          >      >      >>> Actually, that's a bit overly simplified I 
>> guess.
>>          >     RFC3710 say
>>          >      >     “[The IESG] 
> also
>>          >      >      >>>    administers IETF logistics, including 
>> operation of the
>>          >      >     Internet-Draft
>>          >      >      >>>     document series and the IETF meeting 
>> event.”
>>          >      >      >>> However, if you further read on, the RFC 
>> says "The IESG
>>          >     has web
>>          >      >     pages
>>          >      >     as part of the IETF 
>>          >     <http://www.ietf.org <http://www.ietf.org> 
>> <http://www.ietf.org <http://www.ietf.org>>>)”.
>>          >      >      >>> This RFC was written before the 
>> datatracker was widely
>>          >     used and
>>          >      >     when the old ietf.org <http://ietf.org> 
>> <http://ietf.org <http://ietf.org>> <http://ietf.org 
> <http://ietf.org>
>>          >     <http://ietf.org <http://ietf.org>>> page 
> was still up. From the
>>          >      >     RFC it seems, however, quite
>>          >      >     cleat that all matters related to the 
>> datatracker are clearly in
>>          >      >     scope for
>>          >      >      >> the IESG, however, there are probably parts 
>> of the
>>          > ietf.org <http://ietf.org> <http://ietf.org 
>> <http://ietf.org>>
>>          >      >     <http://ietf.org <http://ietf.org> 
>> <http://ietf.org <http://ietf.org>>> side where
>>          >      >     authority is not fully clear or lies with some 
>> other entities
>>          >     (e.g.
>>          >      >     information about the LLC or the IAB…).
>>          >      >      >>
>>          >      >      >> Well yes. It isn't actually said very 
>> clearly in RFC
>>          >     8711, but
>>          >      >     the implication is that the LLC provides tools 
>> and the IETF web
>>          >      >     site, and controls the RFC Editor contract, 
>> which implies the RFC
>>          >      >     tools and web site.
>>          >      >      >
>>          >      >      > I have to slightly disagree here. Jay nicely 
>> separated 4
>>          >      >     different angles about the website strategy, 
>> function design,
>>          >      >     content, and infrastructure. While the LLC or 
>> RPC is
>>          >     responsible for
>>          >      >     the infrastructure of running
>>          >      >     and maintaining the 
>>          >     content
>>          >      >     and functions design decisions. And based on my 
>> own interactions
>>          >      >     with the RPC I believe they also don’t want to 
>> be responsible for
>>          >      >     the content,
>>          >      >     beyond just reflect 
>>          >      >     require more community responsibility.
>>          >      >      >
>>          >      >      > While the IESG has authority about (at least 
>> most parts
>>          >     of) the
>>          >      >     IESG website content, I don’t think it should 
>> be the RPC or
>>          >     LLC that
>>          >      >     has
>>          >      >     authority about the 
>>          >      >     that’s what 
>>          >     true
>>          >      >     for IETF website.
>>          >      >     I agree with that. As others have made clear, 
>> the boundary
>>          >     between
>>          >      >     policy
>>          >      >     and implementation is somewhat subjective, but 
>> except in
>>          >      >     emergencies, the
>>          >      >     RPC and LLC are not 
> supposed to make policy.
>>          >      >
>>          >      >      > So I think we have a gap here. I don’t think 
>> the RSWG has the
>>          >      >     right structure to fill that gap (as these 
>> things don’t require
>>          >      >     policy, aka Jay’s point about strategy for the 
>> webpage) but
>>          >      >     decisions. For me the only available option is 
>> the RSAP (or
>>          >      >     something entirely new but I really hope we 
>> won’t end up
>>          >     adding more
>>          >      >     bureaucracy and positions to the model)...
>>          >      >
>>          >      >     Agreed, sort of. But I observe that when 
>> needed, the IESG sets
>>          >      >     policy by issuing an IESG Statement. I see no 
>> reason why the
>>          >      >     RSWG/RSAB can't issue a formal statement when 
>> the topic is not
>>          >      >     suitable for an RFC. If there are words in the 
>> draft that forbid
>>          >      >     that, we should remove those words.
>>          >      >
>>          >      >     So, someone proposes in the RSWG that the RFC 
>> Editor web site
>>          >     should
>>          >      >     be unavailable on the day of the full moon. 
>> There is rough
>>          >     consensus
>>          >      >     for this, the RSAB agrees, and puts out a 
>> formal Statement saying
>>          >      >     so. The RPC implements this.
>>          >      >
>>          >      >
>>          >      > I agree with this. This is consistent, 
>>          >      > having non-RFC IESG statements that still have 
>> substantive force.
>>          >      >
>>          >      > -Ekr
>>          >      >
>>          >      >          Brian
>>          >      >
>>          >      >      >
>>          >      >      > Mirja
>>          >      >      >
>>          >      >      >
>>          >      >      >
>>          >      >      >> But as I have quoted to the point of 
>> boredom, it also
>>          >     says that
>>          >      >     the LLC "is expected to respect the IETF 
>> community's wishes".
>>          >     As far
>>          >      >     as rules go, I believe that's all we've got. 
>> It's enough, but it
>>          >      >     does seem that our
>>          >      >     draft should empower the RSWG/RSAB to *express* 
>> those wishes. We
>>          >      >     can't change RFC 8711, because we're not the IETF.
>>          >      >      >>
>>          >      >      >>    Brian
>>          >      >      >>
>>          >      >      >>> Mirja
>>          >      >      >>>> On 4. Nov 2021, at 13:59, Eliot Lear 
>> <[email-masked] <mailto:[email-masked]>
>>          >     <mailto:[email-masked] <mailto:[email-masked]>>
>>          >      >     <mailto:[email-masked] <mailto:[email-masked]> 
>> <mailto:[email-masked] <mailto:[email-masked]>>>> wrote:
>>          >      >      >>>>
>>          >      >      >>>>
>>          >      >      >>>> On 04.11.21 13:57, Mirja Kuehlewind wrote:
>>          >      >      >>>>> I agree authority about the content of 
>> any page should not
>>          >      >     sit with
>>          >      >     the the LLC. For the ietf.org <http://ietf.org> 
>> <http://ietf.org <http://ietf.org>>
>>          >     <http://ietf.org <http://ietf.org> <http://ietf.org 
>> <http://ietf.org>>> page and the
>>          >      >     datatracker the authority is with the IESG 
>> which a board of
>>          >      >     community members selected by community member.
>>          >      >      >>>>
>>          >      >      >>>> Precisely where does it say that?  Maybe 
>> we can model that
>>          >      >     language.
>>          >      >      >>>>
>>          >      >      >>>> Eliot
>>          >      >      >>>>
>>          >      >      >>>> <OpenPGP_0x87B66B46D9D27A33.asc>
>>          >      >      >>
>>          >      >      >> --
>>          >      >      >> Rfced-future mailing list
>>          >      >      >> [email-masked] 
>> <mailto:[email-masked]> <mailto:[email-masked] 
>> <mailto:[email-masked]>>
>>          >     <mailto:[email-masked] 
>> <mailto:[email-masked]> <mailto:[email-masked] 
>> <mailto:[email-masked]>>>
>>          >      >      >> 
>>          >  <https://www.iab.org/mailman/listinfo/rfced-future 
>>          >      >  <https://www.iab.org/mailman/listinfo/rfced-future 
>>          >  <https://www.iab.org/mailman/listinfo/rfced-future 
>> <https://www.iab.org/mailman/listinfo/rfced-future>>>
>>          >      >      >
>>          >      >      > .
>>          >      >      >
>>          >      >
>>          >      >     --
>>          >      >     Rfced-future mailing list
>>          >      > [email-masked] <mailto:[email-masked]> 
>>          >     <mailto:[email-masked] 
>> <mailto:[email-masked]> <mailto:[email-masked] 
>> <mailto:[email-masked]>>>
>>          >      > https://www.iab.org/mailman/listinfo/rfced-future 
>>          >  <https://www.iab.org/mailman/listinfo/rfced-future 
>>          >      >  <https://www.iab.org/mailman/listinfo/rfced-future 
>>          >  <https://www.iab.org/mailman/listinfo/rfced-future 
>> <https://www.iab.org/mailman/listinfo/rfced-future>>>
>>          >      >
>>          >
>>

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 6 Nov 2021 05:55:57 -0700

On Fri, Nov 5, 2021 at 8:54 PM Brian E Carpenter <
[email-masked]> wrote:

> Hi Mike,
>
> I think that's wrong. At least for the IETF stream, any WG document that
> gets to AUTH48 is the work of the WG, and the authors are really editors on
> behalf of the WG. The AUTH48 goes to the authors, and iirc to the WG
> chairs, the shepherd, and the sponsoring AD. Correct behaviour is that if
> (and only if) there is an issue that is not editorial, the proposed change
> is taken briefly to the WG list. (Briefly, that is, if it is
> non-controversial. If it proves to be controversial, AUTH48 can take 48
> weeks...)
>

This was my expectation as well. Of course, in AUTH48, the eponsoring AD
has some latitude to determine whether a given change is de minimis. I
agree with Mike that in this case, there just shouldn't be discretion.

-Ekr

> AUTH48 and author/editor centric stuff in the publication process.  Unlike
> IETF WG documents, or for that matter most other stream documents,
> editorial stream documents will always (mostly?) be the product of the
> whole RSWG not a specific author or set of authors.  That suggests that
> AUTH48 queries may need to be sent to the entire WG, with anything
> >     I’m mostly ok with the LLC beginning it’s actions once the document
> is approved for publication.  We do need to manage expectations, as simple
> >          > On Fri, Nov 5, 2021 at 4:34 PM Joel M. Halpern <
> [email-masked] <mailto:[email-masked]>
> >          >      > <[email-masked] <mailto:
> [email-masked]> <mailto:[email-masked] <mailto:
> [email-masked]>>
> >          >      >     “[The IESG]
> >          >      >      >>>     administers IETF logistics, including
> operation of the
> >          >      >     Internet-Draft
> >          >      >      >>> However, if you further read on, the RFC says
> "The IESG
> >          >     has web
> >          >      >     pages
> >          >      >     as part of the IETF
> >          >     <http://www.ietf.org <http://www.ietf.org> <
> http://www.ietf.org <http://www.ietf.org>>>)”.
> >          >      >      >>> This RFC was written before the datatracker
> was widely
> >          >     used and
> >          >      >     when the old ietf.org <http://ietf.org> <
> http://ietf.org <http://ietf.org>> <http://ietf.org
> <http://ietf.org>
> >          >      >     cleat that all matters related to the datatracker
> are clearly in
> >          >      >     scope for
> >          > ietf.org <http://ietf.org> <http://ietf.org <http://ietf.org
> >>
> >          >      >     <http://ietf.org <http://ietf.org> <
> http://ietf.org <http://ietf.org>>> side where
> >          >      >      >> Well yes. It isn't actually said very clearly
> in RFC
> >          >     8711, but
> >          >      >     content, and infrastructure. While the LLC or RPC
> is
> >          >     responsible for
> >          >      >     and maintaining the
> >          >      >     beyond just reflect
> >          >      >      > While the IESG has authority about (at least
> most parts
> >          >     of) the
> >          >      >     IESG website content, I don’t think it should be
> the RPC or
> >          >     LLC that
> >          >      >     has
> >          >      >     authority about the
> >          >      >     that’s what
> >          >      >     and implementation is somewhat subjective, but
> except in
> >          >      >     emergencies, the
> >          >      >     RPC and LLC are not
> supposed to make policy.
> >          >      >
> >          >      >     something entirely new but I really hope we won’t
> end up
> >          >     adding more
> >          >      >     So, someone proposes in the RSWG that the RFC
> Editor web site
> >          >     should
> >          >      >     be unavailable on the day of the full moon. There
> is rough
> >          >     consensus
> >          >      >      >> But as I have quoted to the point of boredom,
> it also
> >          >     says that
> >          >      >     the LLC "is expected to respect the IETF
> community's wishes".
> >          >     As far
> >          >      >      >>>> On 4. Nov 2021, at 13:59, Eliot Lear <
> [email-masked] <mailto:[email-masked]>
> >          >      >     <mailto:[email-masked] <mailto:[email-masked]>
> >          >      >      >>>>> I agree authority about the content of any
> page should not
> >          >      >     sit with
> >          >      >     the the LLC. For the ietf.org <http://ietf.org> <
> http://ietf.org <http://ietf.org>>
> >          >      >      >>>> Precisely where does it say that?  Maybe we
> can model that
> >          >      >     language.
> >          >      >      >>>>
> >          >      >      >>>> Eliot
> >          >      >      >>>>
> >          >      >      >> [email-masked] <mailto:
> [email-masked]> <mailto:[email-masked] <mailto:
> [email-masked]>>
> >          >     <mailto:[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]>>>
> >          >      >      >>
> https://www.iab.org/mailman/listinfo/rfced-future <
> https://www.iab.org/mailman/listinfo/rfced-future>
> >          >     <https://www.iab.org/mailman/listinfo/rfced-future <
> https://www.iab.org/mailman/listinfo/rfced-future>>
> >          >     <https://www.iab.org/mailman/listinfo/rfced-future <
> https://www.iab.org/mailman/listinfo/rfced-future>>>
> >          >      >      >
> >          >      >      > .
> >          >      >      >
> >          >      >
> >          >      >     --
> >          >     <mailto:[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]>>>
> >          >      > https://www.iab.org/mailman/listinfo/rfced-future <
> https://www.iab.org/mailman/listinfo/rfced-future>
> >          >     <https://www.iab.org/mailman/listinfo/rfced-future <
> https://www.iab.org/mailman/listinfo/rfced-future>>
> >          >     <https://www.iab.org/mailman/listinfo/rfced-future <
> https://www.iab.org/mailman/listinfo/rfced-future>>>
> >          >      >
> >          >
> >
> >         --
> >         https://www.iab.org/mailman/listinfo/rfced-future <
> https://www.iab.org/mailman/listinfo/rfced-future>
> >
> >
>
>

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 6 Nov 2021 13:59:46 +0100

On 2021-11-06, at 04:16, StJohns, Michael <[email-masked]> wrote:
> 
> with anything more complex than phrasing and comment placement needing WG input.  

… and RSAB approval (standing in for the AD in the IETF stream).

Grüße, Carsten

---

From: Martin J. Dürst <[email-masked]>
Date: Sun, 7 Nov 2021 19:04:09 +0900

Hello everybody,

I agree with what Mark says below, and have some additional comments.

>    https://www.iab.org/internet-architecture-board-conflict-of-interest-policy/

One way to see these documents is that they are there for as long as 
nobody sees the need to document their content in an actual RFC. That 
view might work for our case, too.

Let's say somebody in the RSWG　has actually figured out how to make 
sure RFCs appear in Google Scholar. Let's say they write it up as an 
email first, and after the RSWG quickly agrees that doing this would be 
a good thing, it ends up as a 'statement'. The RSAB could then simply 
ask the LLC and the RPC "do you need this as an RFC, or are you fine 
with what we have". The RPC could come back and say "that's a one line 
change, we'll ask our programmer to work on it next week, where they 
have some cycles available", or (not in this case I'd guess, but in 
another) "sorry, we need more money if you want us to do this". The LLC 
could then say "sorry, that's too much money for us to just wrap that in 
somewhere, can you please give us an RFC".

> Requiring an RFC for any statement from the RSWG is going to hobble its ability to do even simple things like answer a question from the Executive Director or RPC. If someone sees an obvious improv…

Yes. In this discussion, I think some people are afraid that an active 
minority of RSWG participants rides their hobby horses. That's clearly 
not what we want to be happening.

On the other hand, we don't want to block obvious progress that has wide 
agreement, and we want to make the effort needed for such progress 
commensurate with the issues involved, and want to make sure we can take 
advantage of the expertise available.

>>>> I do think that that policies about "document formats, processes for publication and dissemination of RFCS" fall within the policy remit we have agreed to assign to the RSWG.  I do not think tha…

Well, just as a very simple example, what about the RSWG/RSAB saying 
that STDs are more important than RFCs, and should therefore come first?

> If we can't agree to allow the RSWG to say such things, fine -- but it seems like an absurd limitation to force the RSWG to state everything in abstract weasel words for the LLC and RPC to interpre…

I very much agree with Mark here. Please also consider the following points:

Most people in the IETF are technically oriented. It will be very 
difficult for many of them to not think about and discuss some of the 
main implementation 'details'. I can't imagine the chairs telling 
everybody to shut up talking about technical details. (I can imagine and 
hope that they will tell people to concentrate on policy and discuss 
details only to the extent relevant, but that's a separate thing.)

There may be wide community consensus on some of the bigger 'details' 
(e.g. Atom as in the example above), and it would be a pity if these 
wouldn't be documented and would result in money spent uselessly away 
from community interest and needs.

And many of the people involved will have valuable expertise in some of 
the areas affected. Do we want to give these people the impression that 
their expertise isn't of interest? And then let the LLC and the RPC 
figure out things on their own, and pay additional consultancies?

It's fairly clear that the RSWG/RSAB shouldn't tell the LCC/RPC whether 
a button should be green or blue, or have sharp or round corners. But 
there's an awful lot between what Mark has very nicely termed "abstract 
weasel words" and low level details. We have to make sure that the 
RSWG/RSAB (which, after all, after integrating wide review comments,... 
should reflect community consensus) can express the needs of the 
community at a level the community is comfortable with, and at a level 
that makes the job of the LCC/RPC easier, not more difficult.

Also, do we want to have strictly separated groups, e.g. a policy group 
and a tools group, with extremely clear but very thin lines separating 
their responsibilities? A few mails ago, in 
https://mailarchive.ietf.org/arch/msg/rfced-future/wwo239eievM6y6C-7J5DENo3wGc, 
Mark said he's happy to limit the discussion to Web presence. I think 
that's a good example, but another example is the RFC XML format. If 
some changes to that format are needed, does the RSWG/RSAB discuss them 
to result in something purely abstract, and then much of the same 
discussion is rehashed in some tools group or list? Or is there a better 
way to organize this?

Regards,   Martin.

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 9 Nov 2021 17:03:18 -0700

> publication in the RFC series, I don't object to them being published as 

IMHO it would be best for such pronouncements to go through the process 
we've outlined in our document (RSWG I-D, approved by RSAB, published as 
RFC) so as to trim the decision tree and forestall confusion about 
what's a "statement" (non-RFC) and what's a "policy" (RFC).

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 9 Nov 2021 17:04:00 -0700

> take upon approval by the RSAB, regardless of the timing of publication 

WFM.

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 9 Nov 2021 17:12:44 -0700

On 11/5/21 12:52 PM, Michael StJohns wrote:
> consensus of the RSWG. 

Big +1.

(Modulo that the RSWG is also the/a place where the LLC and RPC inform 
the community about their work plans and priorities in the realm of 
implementation.)

Peter

---

From: Michael StJohns <[email-masked]>
Date: Tue, 9 Nov 2021 19:20:35 -0500

On 11/9/2021 7:04 PM, Peter Saint-Andre wrote:
>> What I am hearing is that we should add a sentence saying that 
>> policies take upon approval by the RSAB, regardless of the timing of 
>> publication of an RFC.
>
> WFM.
>
> Peter
>
I originally agreed with this, but I'm rethinking it given other emails 
that have occurred since this thread started.

Basically, approval by the RSAB for publication of the document, does 
not necessarily mean that the LLC/RPC/RSCE has either the funding or the 
tasking in place to make such things happen.  The period of time between 
the RSAB approval, and the RPC getting the final document through the 
process provides some breathing room for the LLC et al to figure out how 
to do what the document is requesting/directing.

At the very least, I'd suggest that the RSAB approval be followed by a 
request for a no-objection ruling on the early implementation from the 
LLC before any work begins just because neither the RSAB nor the RSWG 
can obligate funding or even tasking. Think of it as being somewhat 
similar to the conflict review the IESG does for independent submissions.

Also, there are documents that won't require/can't be done with early 
implementation - how are those differentiated during the evaluation process?

Mike

---

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

> implementation - how are those differentiated during the evaluation 

I see your points. We can change "policies take effect upon approval by 
the RSAB" to "policies *can* take effect upon approval by the RSAB". 
Clearly some policies won't actually take effect until processes, 
practices, and tools have been adjust to make it so.

Peter

---

From: Michael StJohns <[email-masked]>
Date: Tue, 9 Nov 2021 19:36:26 -0500

On 11/9/2021 7:27 PM, Peter Saint-Andre wrote:
>>>> policies take upon approval by the RSAB, regardless of the timing 
>>>> of publication of an RFC.
>>>
>>> WFM.
>>>
>>> Peter
>>>
>> I originally agreed with this, but I'm rethinking it given other 
>> emails that have occurred since this thread started.
>>
>> not necessarily mean that the LLC/RPC/RSCE has either the funding or 
>> the tasking in place to make such things happen.  The period of time 
>> between the RSAB approval, and the RPC getting the final document 
>> through the process provides some breathing room for the LLC et al to 
>> figure out how to do what the document is requesting/directing.
>>
>> At the very least, I'd suggest that the RSAB approval be followed by 
>> a request for a no-objection ruling on the early implementation from 
>> the LLC before any work begins just because neither the RSAB nor the 
>> RSWG can obligate funding or even tasking. Think of it as being 
>> somewhat similar to the conflict review the IESG does for independent 
>> submissions.
>>
> I see your points. We can change "policies take effect upon approval 
> by the RSAB" to "policies *can* take effect upon approval by the 
> RSAB". Clearly some policies won't actually take effect until 
> processes, practices, and tools have been adjust to make it so.
>
"may" not "can"  I believe, and add "unless the LLC makes an objection 
due to the need to resolve resource or contract issues"

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 9 Nov 2021 17:38:20 -0700

> due to the need to resolve resource or contract issues"

Seems reasonable, thanks.

Peter

---

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

> what's a "statement" (non-RFC) and what's a "policy" (RFC).

The issue I see there is that it might lead to a fair number of RFCs whose
effective content is one line of text. If the RSWG has something very
simple to say, it should just say it. One way is for the RSWG to follow
the rule in RFC 2418 and post minutes of its meetings, for example. We
surely don't need to legislate for that.

    Brian

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 9 Nov 2021 20:36:01 -0500

Brian, I do nto follow your logic.

The only thing the RSWG is supposed to opin about is policy.
For policy, it is suppodsed to determine the rough consensus of the 
larger community.  THere are a series of hoops we have selcted to try to 
achieve that.

Minutes of a session of a meeting do not match that in any fashion.

If once or twice we actually need 1 content line RFCs, so be it.  The 
bits are cheap.  If we need it more than that, something very strange is 
going on.

Yours,
Joel

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 9 Nov 2021 19:10:41 -0700

On 11/9/21 6:14 PM, Brian E Carpenter wrote:
> effective content is one line of text. 

Like draft-carpenter-rfced-iab-charter? ;-)

> If the RSWG has something very
> simple to say, it should just say it. 

As I understand it, folks are suggesting that we have a separate class 
of RFC Series "statements", proposed within the RSWG and approved by the 
RSAB, yet published not as RFCs but as pages on a website somewhere. 
This strikes me as a recipe for confusion (where does one find the 
policies if they're in two different places?). If the process we've 
specified results in a policy, let's publish that policy as an RFC in 
the Editorial Stream, end of story.

Peter

---

From: John C Klensin <[email-masked]>
Date: Tue, 09 Nov 2021 21:28:53 -0500

--On Tuesday, November 9, 2021 20:36 -0500 "Joel M. Halpern"
<[email-masked]> wrote:

> For policy, it is suppodsed to determine the rough consensus
> of the larger community.  THere are a series of hoops we have
> selcted to try to achieve that.
> 
> If once or twice we actually need 1 content line RFCs, so be
> it.  The bits are cheap.  If we need it more than that,
> something very strange is going on.

Brian,

I largely agree with Joel.  The bits associated with an RFC,
even a short one, are cheap (a comment I first heard from Jon
Postel in the 1980s.  If we find ourselves needing to publish
more than one or two of those in a six month period, I'd see
that as not merely strange but a sign of either bad management,
overspecification, or attempted micromanagement on the part of
the RSWG/RSAB process.  If we need multiple trivial-length RFCs
to cause the community to be aware of such things, that might
actually be a benefit.    I'd also think that the RSAB ought to
have the authority and good sense to combine multiple
trivial-length I-Ds getting approved within the same general
time period into single RFC if that made sense... and that the
RPC ought to feel enabled to encourage that if they found
themselves working on more than RFC process documents at the
same time.

And especially because I think we are talking about cases --
ones that ought to be rare or non-existent -- of many very short
documents within a short period, if any of the above needs to be
explicit in the document rather than assuming the relevant
actors would have and apply good sense, I think we and the
document, have serious problems.

best,
  john

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 10 Nov 2021 15:42:08 +1300

Peter,

(Also trying to reply to Joel's point.)

> the Editorial Stream, end of story.

If there's a page of substantive content, sure. I had in mind
something more like:

"RSWG members agreed that the definition of acceptable SVG in RFCs
requires a major update."

It seems clear to me that this is a matter where the RSWG community
might have a strong opinion, which they might construe as policy.
However, doing anything about it, such as revising the relevant
RFC, is not RSWG business. (I assume that nobody thinks RFC 7996
is policy.)

How do you think the RSWG should convey this opinion?

Alternatively, do you think that RFC 7996 is policy?

    Brian

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 9 Nov 2021 19:57:57 -0700

> might have a strong opinion, which they might construe as policy.

As I understand it, general agreement that we need to fix our use of SVG 
in RFCs could lead in several different directions, such as:

- creating a design team to report back to the RSWG with recommendations

- suggesting the addition of related tasks to the RPC's work plan (e.g., 
survey RFC authors regarding the tools they use to generate SVG)

- conferring with the RSCE about best practices for SVG generation in 
technical publishing

It's not clear to me how either an RFC or a "statement" is needed in 
order to do those things.

> How do you think the RSWG should convey this opinion?

By communicating with the RSCE, LLC executive director, RPC folks, 
interested RSWG participants, etc. And, of course, all of these 
individuals should already be part of the discussions happening in the 
RSWG, so this kind of communication ought to happen quite naturally. 
Nothing special required as far as I can see.

Peter

---

From: John C Klensin <[email-masked]>
Date: Tue, 09 Nov 2021 23:11:56 -0500

--On Wednesday, November 10, 2021 15:42 +1300 Brian E Carpenter
<[email-masked]> wrote:

>>>>> FWIW, I was anticipating that these statements would go
>>>>> through the same process as RFCs, they just wouldn't be
>>>>> published in the series.
>>>>> 
>>>>> With that said, if we can agree that RFCs published by the
>>>>> RSWG/RSAB venue either have immediate effect upon RSAB
>>>>> approval or expedited publication in the RFC series, I
>>>>> don't object to them being published as RFCs.
>>>> 
>>>> IMHO it would be best for such pronouncements to go through
>>>> the process we've outlined in our document (RSWG I-D,
>>>> approved by RSAB, published as RFC) so as to trim the
>>>> decision tree and forestall confusion about what's a
>>>> "statement" (non-RFC) and what's a "policy" (RFC).
>>> 
>>> The issue I see there is that it might lead to a fair number
>>> of RFCs whose effective content is one line of text.
>> 
>> As I understand it, folks are suggesting that we have a
>> separate class of RFC Series "statements", proposed within
>> the RSWG and approved by the RSAB, yet published not as RFCs
>> but as pages on a website somewhere. This strikes me as a
>> recipe for confusion (where does one find the policies if
>> they're in two different places?). If the process we've
>> specified results in a policy, let's publish that policy as
>> an RFC in the Editorial Stream, end of story.
> 

While I'm not either Peter or Joel, I would have no problems
with either

(1) Putting that information into an I-D even if the only thing
that will eventually turn into an RFC is that major update.

(2) Making an announcement to some appropriate places including
ietf-announce.

In addition, it that is the sort of one-line statement you are
talking about, I'd rather see an RFC that actually explains the
issue and/or the reasoning.  The sentence is a bad case of
insider-speak.

> Alternatively, do you think that RFC 7996 is policy?

Peter and Joel will need to speak for themselves, but I think it
is a tutorial and, while tutorials are not themselves policy,
the advice they give often is.

best,
   john

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 10 Nov 2021 17:05:19 +1100

> On 10 Nov 2021, at 1:42 pm, Brian E Carpenter <[email-masked]> wrote:
> 

Where would you have that work done, then? Would the IAB continue to oversee it? I had thought the whole idea here was to get the IAB out of the loop... and that such documents would be on the Editorial stream, which implies RSWG involvement.

---

From: Jay Daley <[email-masked]>
Date: Wed, 10 Nov 2021 22:23:11 +1300

> On 10/11/2021, at 1:38 PM, Peter Saint-Andre <[email-masked]> wrote:
> 
>>>>>> What I am hearing is that we should add a sentence saying that policies take upon approval by the RSAB, regardless of the timing of publication of an RFC.
>>>>> 
>>>>> WFM.
>>>>> 
>>>>> Peter
>>>>> 
>>>> I originally agreed with this, but I'm rethinking it given other emails that have occurred since this thread started.
>>>> 
>>>> Basically, approval by the RSAB for publication of the document, does not necessarily mean that the LLC/RPC/RSCE has either the funding or the tasking in place to make such things happen.  The period of time between the RSAB approval, and the RPC getting the final document through the process provides some breathing room for the LLC et al to figure out how to do what the document is requesting/directing.
>>>> 
>>>> At the very least, I'd suggest that the RSAB approval be followed by a request for a no-objection ruling on the early implementation from the LLC before any work begins just because neither the RSAB nor the RSWG can obligate funding or even tasking. Think of it as being somewhat similar to the conflict review the IESG does for independent submissions.
>>>> 
>>>> Also, there are documents that won't require/can't be done with early implementation - how are those differentiated during the evaluation process?
>>> 
>>> I see your points. We can change "policies take effect upon approval by the RSAB" to "policies *can* take effect upon approval by the RSAB". Clearly some policies won't actually take effect until processes, practices, and tools have been adjust to make it so.
>>> 
>> "may" not "can"  I believe, and add "unless the LLC makes an objection due to the need to resolve resource or contract issues"
> 

I would prefer omitting that as it makes it sound as if the RPC must implement every new RFC immediately unless the LLC objects, when in reality it needs to plan and schedule and prioritise with the rest of its work, and also consider any extra resourcing it may need to as the LLC for.

Jay

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

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 10 Nov 2021 03:50:38 -0800

Well, I do think we need *some* text because the RPC backlog can be quite
long and if nothing can ever happen until RFC processing completes...

On Wed, Nov 10, 2021 at 1:23 AM Jay Daley <[email-masked]> wrote:

> take upon approval by the RSAB, regardless of the timing of publication of
> an RFC.
>
>
> WFM.
>
> Peter
>
> Basically, approval by the RSAB for publication of the document, does not
> necessarily mean that the LLC/RPC/RSCE has either the funding or the
> process provides some breathing room for the LLC et al to figure out how to
> do what the document is requesting/directing.
>
> request for a no-objection ruling on the early implementation from the LLC
> before any work begins just because neither the RSAB nor the RSWG can
> obligate funding or even tasking. Think of it as being somewhat similar to
> the conflict review the IESG does for independent submissions.
>
> "may" not "can"  I believe, and add "unless the LLC makes an objection due
> to the need to resolve resource or contract issues"
>
>
> I would prefer omitting that as it makes it sound as if the RPC must
> implement every new RFC immediately unless the LLC objects, when in reality
> it needs to plan and schedule and prioritise with the rest of its work, and
> also consider any extra resourcing it may need to as the LLC for.
>
> Jay
>
>
> Peter
>
> --

---

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

Maybe I am misunderstanding your example.  That sure looks like the 
start of an RSWB process (however they want to do it) of figuring out 
what the policy for SVG should be.  Just telling the RPC "do something 
better" is not policy, it is badly formed management.

Whether the RSWG wants to agree on some requrieemnts, appoint a design 
team, or solicit advice (or some combination of those, or something 
else) is up to them, and is not part of the policy.  If they agree on 
requirements, and think that the requirements should be binding in some 
fashion, those could become an RFC.  Or maybe those are an example of an 
informational RFC?

But the one liner is not policy, and is not a directive from the RSWG to 
anyone.

Yours,
Joel

---

From: Joel Halpern Direct <[email-masked]>
Date: Wed, 10 Nov 2021 06:59:00 -0500

As I said in my reply to Brian, working out a new policy on what the SVG 
should be does seem to fall to the RSWG.  And the result would be 
policy.  But "go, do better" is NOT policy.  It's not even good management.

Yours,
Joel

---

From: Jay Daley <[email-masked]>
Date: Thu, 11 Nov 2021 00:59:37 +1300

> On 11/11/2021, at 12:50 AM, Eric Rescorla <[email-masked]> wrote:
> 
> Well, I do think we need *some* text because the RPC backlog can be quite long and if nothing can ever happen until RFC processing completes...

I only meant omitting the "unless the LLC makes an objection …" not the substantive text.

Jay

> 
> On Wed, Nov 10, 2021 at 1:23 AM Jay Daley <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>> On 10/11/2021, at 1:38 PM, Peter Saint-Andre <[email-masked] <mailto:[email-masked]>> wrote:
>> 
> [email-masked] <mailto:[email-masked]>
> -- 

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

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 10 Nov 2021 23:00:45 +1100

I'm confused by your 'go, do better' characterisation - I was addressing Brian's comment about revising the relevant RFC.

> On 10 Nov 2021, at 10:59 pm, Joel Halpern Direct <[email-masked]> wrote:
> 
> As I said in my reply to Brian, working out a new policy on what the SVG should be does seem to fall to the RSWG.  And the result would be policy.  But "go, do better" is NOT policy.  It's not even good management.
> 
> Yours,
> Joel
>

---

From: Eliot Lear <[email-masked]>
Date: Wed, 10 Nov 2021 13:08:20 +0100

Isn't this a bit of art, balancing between management and 
micromanagement?  I could easily imagine the RSWG specifying principles 
that enable good decision making regarding image format, without ever 
mentioning SVG, and I could imagine a healthy discussion in which both 
the RPC and the RSCE contribute.

I could equally imagine a bit more detailed specification, in which we 
say, here are the specific parameters that we specify for SVG 
construction, and maybe even sample code!

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 10 Nov 2021 04:11:12 -0800

> I only meant omitting the "unless the LLC makes an objection …" not the

SGTM

-Ekr

---

From: Joel Halpern Direct <[email-masked]>
Date: Wed, 10 Nov 2021 07:12:24 -0500

Brian's text was "the definition of acceptable SVG in RFCs
requires a major update".  That is not a policy.  It is a statement that 
the RSWG wants to work on something.  It is roughly as meaningful as the 
classic instruction "fetch a rock"... "no, not that rock, a better rock."

Yours,
Joel

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 10 Nov 2021 23:14:05 +1100

Let me be more direct.

If <someone> determines that an update of 7996 is desirable, where is that work done, and who does it? What stream is it published upon?

> On 10 Nov 2021, at 11:12 pm, Joel Halpern Direct <[email-masked]> wrote:
> 
> requires a major update".  That is not a policy.  It is a statement that the RSWG wants to work on something.  It is roughly as meaningful as the classic instruction "fetch a rock"... "no, not that rock, a better rock."
> 
> Yours,
> Joel
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 10 Nov 2021 07:14:51 -0500

I have no desire to legislate what would constitute a policy.  But it 
clearly would have more content than the example.  Given the observed 
community sensitivity on the example Brian chose, I would expect 
something fairly specific.  But whatever the RSWG chose and the RSAB 
approved, I would expect it to be clear enough to at least be actionable 
such that one could understand fairly if the RPC had complied with it.

Yours,
Joel

On 11/10/2021 7:08 AM, Eliot Lear wrote:
>> I'm confused by your 'go, do better' characterisation - I was 
>> addressing Brian's comment about revising the relevant RFC.
>>
>>
>>> As I said in my reply to Brian, working out a new policy on what the 
>>> SVG should be does seem to fall to the RSWG.  And the result would be 
>>>> Where would you have that work done, then? Would the IAB continue to 
>>>> oversee it? I had thought the whole idea here was to get the IAB out 
>>>> of the loop... and that such documents would be on the Editorial 
>>>> stream, which implies RSWG involvement.
>>>> --

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 10 Nov 2021 07:18:56 -0500

I can see several paths.  I am not mandating one.  Here are two, of the 
many possibiities.

The RSWG could write a policy that directs the properties an SVG profile 
replacement should have, and directs the RPC to pick something that 
matches it.
While sensible, given the community sensitivity, I would be very 
surprised if the RWG were willing to do that.

The RSWG could solicit advice, appoint a design team, review the design 
team results, and eventually publish a policy on how diagrams should be 
represented in SVG.  With sufficient consultation during development, I 
could see that working.

Neither of those result in any one line, or even one paragraph, RFCs.

Yours,
Joel

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 10 Nov 2021 23:39:41 +1100

Joel,

> On 10 Nov 2021, at 11:18 pm, Joel M. Halpern <[email-masked]> wrote:
> 
> The RSWG could solicit advice, appoint a design team, review the design team results, and eventually publish a policy on how diagrams should be represented in SVG.  With sufficient consultation during development, I could see that working.

This is roughly how most functional working groups operate.

> Neither of those result in any one line, or even one paragraph, RFCs.

Sure... but can we agree that the process that I quote above could result in an RFC (on the Editorial stream) that updates/obsoletes 79996?

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 10 Nov 2021 07:54:38 -0500

Sorry, I had not realized that the question had changed from small 
non-rfc directives ostensibly coming out of the RSWG.

It seems that an update to RFC 7996 could reasonably come from the RSWG, 
through the process we have defined.  Whether there is also some other 
way it could be done, I lack the imagination to know.

Yours,
Joel

---

From: Jay Daley <[email-masked]>
Date: Thu, 11 Nov 2021 01:58:29 +1300

> On 11/11/2021, at 1:54 AM, Joel M. Halpern <[email-masked]> wrote:
> 
> Sorry, I had not realized that the question had changed from small non-rfc directives ostensibly coming out of the RSWG.
> 
> It seems that an update to RFC 7996 could reasonably come from the RSWG, through the process we have defined.  Whether there is also some other way it could be done, I lack the imagination to know.

Does the draft need to explicitly empower the RSWG to create design teams?

Jay

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 10 Nov 2021 08:04:40 -0500

Since a design team has no authority except to report to the RSWG, I do 
not see why we need to call that out.  I would hope and expect 
reasonable use of approaches to solve problems, as long as they result 
in decisions by the RSWG on the RSWG email list.

In particular, since we have no means or desire to prevent people from 
talking to each other, design teams can and will happen.

Yours,
Joel

---

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

Since design teams are covered by RFC2418, and we are citing RFC2418, I don't think there is any need to specify it.

However, that isn't what bothers me. It's the notion that the RSWG *as currently specified by the draft* is expected to produce highly technical documents like RFC7996bis would be. I fear that this needs changes in the draft, starting with the first sentence of the Abstract.

I'm not against such changes but I don't see how to avoid them without leaving a significant gap.

Regards
    Brian Carpenter

---

From: Eliot Lear <[email-masked]>
Date: Wed, 10 Nov 2021 22:10:38 +0100

I think we have been vague about the level at which the RSWG operates, 
and I would suggest that's a good thing.  It's going to take a while for 
the group to get its bearings.  Nothing beats running code.  So let's be 
careful as to how many changes we make without that running code.

Eliot

On 10.11.21 21:57, Brian E Carpenter wrote:
> Since design teams are covered by RFC2418, and we are citing RFC2418, 
> I don't think there is any need to specify it.
>
> However, that isn't what bothers me. It's the notion that the RSWG *as 
> currently specified by the draft* is expected to produce highly 
> technical documents like RFC7996bis would be. I fear that this needs 
> changes in the draft, starting with the first sentence of the Abstract.
>
>>>> It seems that an update to RFC 7996 could reasonably come from the 
>>>> RSWG, through the process we have defined.  Whether there is also 
>>>> some other way it could be done, I lack the imagination to know.
>>>
>>>>>> The RSWG could solicit advice, appoint a design team, review the 
>>>>>> design team results, and eventually publish a policy on how 
>>>>>> diagrams should be represented in SVG. With sufficient 
>>>>>> consultation during development, I could see that working.
>>>>> Sure... but can we agree that the process that I quote above could 
>>>>> result in an RFC (on the Editorial stream) that updates/obsoletes 
>>>>> 79996?
>>>>> --

---

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

Ack. But if we weasel-word policy as "policy and related matters"
or something like that, we will avoid claims that such things
are out of scope.

Regards
    Brian

---

From: Eliot Lear <[email-masked]>
Date: Thu, 11 Nov 2021 09:11:54 +0100

Yes.

*Your* issue is that we haven't specifically said that the RSWG can work 
at whatever level it needs to accomplish its goals. *Mike's* issue is 
that the scope is too broad.

I think this needs to be addressed in two spots in the text.

> and dissemination of RFCs, and overall management of the RFC Series.

To address Mike's point, I think we need to remove "but are not 
necessarily limited to".  The remit still covers the overall management 
of the series.  One would really have to use one's imagination to go 
beyond that remit while still having something to do with RFCS, and in 
that instance, the RSWG and RSAB can go back to the community to request 
additional authority.

The second change goes to what work the RSWG goes to.  Here Joel and 
others have been quite clear: produce RFCs.  But what those RFCs contain 
is likely to need to vary.  I would very much expect the RSCE to be 
heavily involved in any substantial publication standard (that's why 
that person will earn the big bucks).

So, in Section 3.1.1 (RFC Series Working Group):

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

Change to:

> The RFC Series Working Group (RSWG) shall formulate proposals 
> regarding policies *and* *any necessary* s*upporting specifications 
> and guidelines* that govern the RFC Series.

This further addresses Mark's point that makes it crystal clear that, 
yeah, SVG can be documented.  The words "any necessary" are present to 
not *require *that such specifications emanate from the RSWG when all 
are satisfied with what the LLC is producing.  This also allows for 
leveling to happen as we learn the job.

Thoughts?

Eliot

---

From: Michael StJohns <[email-masked]>
Date: Thu, 11 Nov 2021 08:49:59 -0500

> I don't think there is any need to specify it.

Actually, I'm thinking we need to eliminate design teams in this 
process.  Design teams tend to be somewhat closed, and there isn't 
enough structure in the current document to prevent a design team from 
capturing the process, and removing what small protection we get from 
having an RSWG.  The RSWG will be fairly small, and there is no reason 
that design team discussions should not be captured on the RSWG 
communication process - to include minutes, emails, drafts, etc.  Yes, 
people will talk, but I'd really like to avoid cliques forming to decide 
things behind the scenes.

> changes in the draft, starting with the first sentence of the Abstract.

As I suggested oh so many months ago - this is sort of why we hire 
someone like the RSCE.  But I understand that discussion is a lost cause 
and I don't know how to fix the problem you identify in the previous 
sentence with the structure as currently described within the draft.

If the RSWG can't do a "highly technical document", then I don't expect 
a design team of the RSWG to be able to do it either.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 11 Nov 2021 14:05:24 +0000

Like Mike, I don't see a need for design teams here.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 12 Nov 2021 09:07:17 +1300

> Like Mike, I don't see a need for design teams here.

I think we just don't know until we try. There's no reason to legislate one way or the other.

Design teams in the IETF are normally open these days, so they act as way of keeping detailed technical emails off the WG list, but not as a secret cabal.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 12 Nov 2021 09:08:28 +1300

Eliot,

That works for me, but I'd still prefer if there were a couple of weasel words in the Abstract.

Regards
    Brian

On 11-Nov-21 21:11, Eliot Lear wrote:
> *Your* issue is that we haven't specifically said that the RSWG can work at whatever level it needs to accomplish its goals. *Mike's* issue is that the scope is too broad.
> 
> To address Mike's point, I think we need to remove "but are not necessarily limited to".  The remit still covers the overall management of the series.  One would really have to use one's imagination to go beyond that remit while still having something to do with RFCS, and in that 
instance, the RSWG and RSAB can go back to the community to request additional authority.
> 
> The second change goes to what work the RSWG goes to.  Here Joel and others have been quite clear: produce RFCs.  But what those RFCs contain is likely to need to vary.  I would very much expect the RSCE to be heavily involved in any substantial publication standard (that's why that person will earn the big bucks).
> 
>> The RFC Series Working Group (RSWG) shall formulate proposals regarding policies that govern the RFC Series.
> 
> Change to:
> 
>> The RFC Series Working Group (RSWG) shall formulate proposals regarding policies *and* *any necessary* s*upporting specifications and guidelines* that govern the RFC Series.
> 
> This further addresses Mark's point that makes it crystal clear that, yeah, SVG can be documented.  The words "any necessary" are present to not *require *that such specifications emanate from the RSWG when all are satisfied with what the LLC is producing.  This also allows for leveling to happen as we learn the job.
> 
> Thoughts?
> 
> Eliot
>