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

From: "Martin Thomson" <[email-masked]>
Date: Mon, 01 Nov 2021 21:50:04 +1100

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

How would you distinguish this from a "full" appointment, such that it warrants a note like this?

---

From: Jay Daley <[email-masked]>
Date: Tue, 2 Nov 2021 08:33:40 +1300

> On 1/11/2021, at 11:50 PM, Martin Thomson <[email-masked]> wrote:
> 

This process is limited, as per the first clause, to a situation where there is already an RSCE but they are unavailable.  It does not cover the situation where the post is empty and so the full appointment process has to be followed then.

Jay

> 
> -- 
> Rfced-future mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/rfced-future
> 

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

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 02 Nov 2021 08:39:51 +1100

On Tue, Nov 2, 2021, at 06:33, Jay Daley wrote:
> This process is limited, as per the first clause, to a situation where 
> there is already an RSCE but they are unavailable.  It does not cover 
> the situation where the post is empty and so the full appointment 
> process has to be followed then.

Ok, then this is fine.

---

From: Michael StJohns <[email-masked]>
Date: Thu, 4 Nov 2021 17:26:48 -0400

On 10/22/2021 4:13 AM, Eliot Lear wrote:
> Dear Colleagues,
>
> This begins the two week last call on 
> draft-iab-rfcedfp-rfced-model-05.[1]  This call will run through 
> Friday, 5 Nov 2021.  Please send your comments to this mailing list.  
> We will address any issues that are raised during our IETF time slot 
> (and of course on list).
>
> Brian and Eliot
>
> [1] https://datatracker.ietf.org/doc/html/draft-iab-rfcefdp-rfced-model
>
>

Hi - I've got some specific comments and changes for the -05 document 
which I'll include below.  I still owe text for the "heritage" section 
and that's taking longer.   I apologize for the delay, but life got in 
my way.

Overall, this generally reads well and reflects my understanding of 
where we are in the discussions.

This is going to use a combo of the PDF page numbers and the section 
number so bear with me:

Section 1, numbered item 1 beginning Policy definition.   This is worded 
in a way that implies more authority to the RSWG than is planned.  
Instead replace the second sentence here (and the similar language in 
Section 2 third para with:

"This is the responsibility of both the RFC Series Working Group (RSWG), 
which proposes policy, and the RFC Series Approval Board (RSAB), which 
evaluates and approves or rejects such proposals."

Section 1, numbered item 2 top of page 4 first sentence: s/through 
publication of/of the concepts described in/.  Insert "Editorial" before 
"Series".

Following para s/documents are produced/RFCs are produced/

Section 2, 3rd para change from above.  Also, that first sentence is a 
run on.

Section 2, 4th para s/Policy implementation/Implementation of policy/.   
s/ultimate authority/direction/.  Insert after "LLC)" "on behalf of the 
community".

Section 3, first para s/that are//  There are also missing commas.   
Insert after (RSWG) - ", pass a community last call, "

Section 3.1.2 first para - s/RSWG/RSWG and the community last call/

Section 3.1.2 top of page 8 bullet beginning "Voting on approval..." 
place holder as I haven't seen the last text here and I don't want to 
dig through the piles of emails to try and find it.

Section 3.2.2 page 10 numbered bullet 6.  I may have missed this, but I 
thought the RSWG was responsible for the last call and for doing the 
work of resolving the questions, not the RSAB. DISCUSS.

Section 3.2.4 - 1st para, 2nd sentence = "only on grounds of failure..." 
- how about on a disagreement on community (not just RSWG) consensus?  
DISCUSS.

Section 4.1, 2nd para, first bullet.   I think some language is needed 
here such as insert at end: "or by such legacy RFCs which apply to the 
RPC and which have not yet been superceded by Editorial stream documents 
and the requisite contractual changes."

Section 4.1, 2nd para, last bullet, delete "contractually" - duplicative 
with "contract".

Section 4.1, para at top of page 14 beginning "If individuals..." - this 
is one of the few places that we need specific individuals rather than 
the generic LLC so: s/the IETF LLC look into/the IETF LLC board, the 
IETF ED or a POC designated by the LLC board to look into/

Section 4.3 - first para: The RPC responsibilities will change from time 
to time and are specified by the contract, not by these documents unless 
incorporated by reference.  Suggest  inserting "(as of publication)" 
after "responsibilities" near the end of that long run on sentence.  
Referencing the current contract may also be useful here.

Section 4.4, third bullet last sentence.  Instead:  "However, in the 
interest of time, the disagreement may be resolved as the parties best 
see fit while the RSWG considers whether there is a need to propose a 
more general policy."    Basically, as written it implies the RSWG will 
take action and that is not guaranteed.

Section 4.6.1 Second para.  There should be additional text here 
requiring the LLC to share the draft SOW and solicit input on that draft 
prior to issuing it for proposal.

Section 5, the bullets describing the responsibilities of the RSCE vs 
section 5.2.  I've pretty much lost the argument about constraining the 
RSCE into such a side role, but comparing these bullets to the section 
5.2, I'm not sure I see the point of soliciting community input as the 
RSCE will be virtually invisible to them.  This document neuters the 
RSCE to the point where their only real customer is the RPC.

Section 5.3 - Suggest adding "The COI policy shall not preclude the RPC 
from contracting services from the person or entity performing the RSCE 
function.  Such contracts shall be disclosed publicly".  There are too 
few people that might want to engage with us, and the RPC may not want 
to pay a full time person for some of the tasks we've moved around.  I'd 
prefer making it explicit that the LLC can't make working for the RPC an 
unmanageable COI for the RSCE.

Mike

---

From: Michael StJohns <[email-masked]>
Date: Thu, 4 Nov 2021 18:04:10 -0400

On 10/28/2021 3:16 AM, Eliot Lear wrote:
> Mike, everyone,
>
> First, a point of clarification.  I don't have a strong position. I 
> may not have couched my words properly, but my only bias really is to 
> fix the issues we can now, and not attempt to fix the issues we can't.
>
> Christian has put things rather concretely by suggesting that 
> fundamental parameters of the serious like whether RFCs are immutable 
> might be changed.  There may be other aspects.  But I don't think we 
> get through this without either dropping the word heritage or 
> significantly elaborating it.  I think it may not be necessary to use 
> the word.  See below.
>
> Furthermore, there are enough concerns around this matter, that I 
> don't see how we don't expose the tension at all.  But there is a 
> difference between exposing that tension and trying to govern it. I 
> don't think we do any harm to Eric's concerns if we do the former 
> (EKR, you can and should correct me if you strongly disagree, but see 
> below), and I have very little confidence that we will find any 
> consensus on the latter.
>
> With that in mind, we already have the following in Section 3.2.1:
>
>>    Because policy issues can be difficult and contentious, RSWG
>>    participants and RSAB members are strongly encouraged to work
>>    together in a spirit of good faith and mutual understanding to
>>    achieve rough consensus (see [RFC7282]).  In particular, RSWG members
>>    are encouraged to take RSAB concerns seriously, and RSAB members are
>>    encouraged to clearly express their concerns early in the process and
>>    to be responsive to the community.  All parties are encouraged to
>>    respect the value of each stream and the long-term health and
>>    viability of the RFC Series.
>
> Perhaps it is this last sentence that we might amend:
>
>>  All parties are encouraged to, respect the value of each stream and 
>> the long-term health and
>>  viability of the RFC Series, and to give consideration for both the 
>> factors that have led to the series'  wide acceptance, and those that 
>> require it to evolve to see to its continued success.
>
> Obviously those factors will be a matter of, perhaps intense, debate.  
> Our rough consensus process is designed to allow for that tension to 
> play out; but it requires a modicum of trust, that people will act in 
> good faith toward one another.  You have all generally done an 
> exemplary job of that here.  I hope that spirit would carry forward 
> into the RSWG.
>
> Eliot
>
Eliot, et al -

What I'm looking at is stealing and expanding text from sections 2.2 and 
2.3 of Bob Braden's/ISI's last report for the RFC Editor contract 
(sections titled "Editorial Policy" and "Quality of Documents").  I 
think "principles" is actually the right word vs heritage, but we have a 
heritage of conforming to those principles :-) to the notable success of 
the series.  Ignoring those principles would probably be a Bad Thing (tm).

Basically, identifying what's been critical for the success of the 
series:  readability, stability, allowances for author individuality, et 
al and placing guardrails (metarules) to make sure that changes proposed 
by the RSWG and approved by the RSAB respect such principles seems to me 
to be just good engineering.

I think that's more than a few sentences, but not more than 3-4 
paragraphs in a section probably titled "Principles for RSWG and RSAB 
policy formation"

The text you cite up above is basically motherhood telling people to be 
nice to each other, but doesn't really give them any guidance on how to 
measure "the good of the series" in any meaningful manner or against any 
useful measuring stick.

I apologize again for the delays.   Mike

---

From: Michael StJohns <[email-masked]>
Date: Thu, 4 Nov 2021 18:09:27 -0400

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

The phrase is probably "under contract to the LLC which itself is acting 
on behalf of the community" in most of the cases we talked about.  
Contract implies a negotiated and limited set of both authorities and 
responsibilities.  "acting on behalf" explains who the real customer is.

Mike

---

From: Michael StJohns <[email-masked]>
Date: Thu, 4 Nov 2021 18:24:57 -0400

On 10/30/2021 10:09 PM, Martin J. Dürst wrote:
> Hello Christian, others,
>
> Thanks for mentioning the elephant in the room (changing the way RFCs 
> get 'updated').
>
> This is indeed a problem that may be discussed very actively in the 
> future RSWG and RSAG. But please note that this cannot happen 
> independently of the streams. It's the streams that have the authority 
> on the content of their RFC.
>
> Let's assume that the RSWG and RSAG came up with a way of integrating 
> errata into published RFCs. If any stream refused, that stream's 
> errata would just not participate in this feature.
>
> The dependency is much clearer for more aggressive proposals. Let's 
> assume that the RSWG and RSAG came up with a way of publishing RFCs as 
> 'living standards'. It's very clear that if any stream didn't want 
> that, they just wouldn't use this feature.
>
> I hope that also makes it clear that in particular for more aggressive 
> proposals, the initiative really has to come from the streams, or more 
> correctly, from the bodies behind these streams. Otherwise, any work 
> is bound to be dead on arrival. Overall, it will probably take quite 
> some time and a lot of coordination.
>
> That leads me to the conclusion that whatever statement about heritage 
> we make or do not make, we should be fine, because there isn't too 
> much of a risk of some subgroup in the RSWG to dominate the direction.
>
> Regards,   Martin.
>
>
>
> On 2021-10-28 08:58, Christian Huitema wrote:
>> On 10/27/2021 3:29 PM, Jay Daley wrote:
>>
>>> It seems to me as someone relatively new to the internal workings of 
>>> the RFC series that "heritage" or any similar-meaning term is 
>>> impossible to pin down as a general statement and is best addressed 
>>> during a discussion on a specific proposal in the RSWG.  Unless the 
>>> text is very carefully worded (e.g. with a corollary that change is 
>>> necessary to avoid stagnation) then it would be such a blunt 
>>> instrument that I would expect it to be regularly invoked 
>>> inappropriately and to create friction because those invoking it 
>>> would think they have policy on their side.
>>
>>
>> I don't think of that in terms of heritage so much as principles. I 
>> think we have broad agreement about most principles, such as making 
>> access to the discussion open and free. We also mostly have broad 
>> agreement on preserving continuity of the look and feel of the 
>> series, even if after tortuous debate we finally got  the format to 
>> evolve and allow such things as international characters or vector 
>> graphics. The only principle that I see regularly contested is the 
>> idea that once published, RFC cannot be changed.
>>
>> I hear the arguments on both sides. On one side, RFC are archived 
>> documents, and we don't get to rewrite the past ever, so yes, once a 
>> document is stamped with a number, it is cast in stone. On the other 
>> side, network protocol specifications need to evolve frequently, and 
>> if they evolve developers ought to have a simple mean to access the 
>> latest version of protocol XXX. There is a big tension there, because 
>> if the protocol is known as RFC NNNN, then it cannot change. If it is 
>> known as protocol XXX it can change but then the RFC number becomes 
>> irrelevant. Arguably we have a tension between keeping the series 
>> relevant and maintaining a core principle.
>>
>> Resolving such tensions is exactly what the RSWG should do. I don't 
>> think that we should try to preempt the debate by making statements 
>> about heritage. That leads me to agree with Eric and Elliot.
>>
>> -- Christian Huitema
>>
>
Martin/Christian et al -

Documents have one tag that never changes - the RFC number.  They also 
have other tags that can be added and deleted - STD springs to mind.    
The problem cited above is mostly not a problem that needs to be solved 
in the RFC system, but in the way STDs  (and maybe other sub-series) are 
described to the outside community.

We use RFC on everything because it's well known, but that's a marketing 
issue.  If you want to fix this, then start marketing the STD series in 
a way that makes clear that the RFC number is subordinate (for this 
purpose) to the STD number.  Also, maybe adopt a reference number format 
that's bound in time such as other standards organizations use.   E.g. 
refer to IETF-STD-3-1989-03 instead of RFC 1122, RFC1123.   The 
IETF/IESG is responsible for the mappings from those documents to stable 
references maintained by the RFC editor system - e.g. DOI's.   Say you 
have an errata published for RFC1122 this month - IETF-STD-3a-2021-11 
with mappings to the revised RFC1122 and the original RFC1123.

For the RFC series, the main change here is to allow for quick 
publication of errata changes - but that's more a process change than a 
real change to the RFC series.

So - Market the STD numbers.  Pay someone who has a clue to do the 
marketing for us.   Takes a few years, but you'll eventually get to 
where you want to be.

Later, Mike

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 5 Nov 2021 11:39:27 +1300

> responsibilities.  "acting on behalf" explains who the real customer is.

True, but again quoting RFC 8711:

"Responsiveness to the community. The IETF LLC is expected to act consistently with the documented consensus of the IETF community, to be responsive to the community's needs, and to adapt its decisions in response to consensus-based community feedback."

The tricky issue is that this phrasing is expressly limited to the
"IETF community". I don't have an easy remedy for that limitation. I also
don't want to leave a gap where some future ED can say "show me where it
says I have to listen to the RFC community."

I find myself wondering whether we need to ask the IETF to produce a
very short update to RFC 8711. Alternatively, a decision by the LLC Board
to explicitly include this expectation in the LLC's remit would work.

    Brian

---

From: Jay Daley <[email-masked]>
Date: Fri, 5 Nov 2021 11:51:19 +1300

> On 5/11/2021, at 11:39 AM, Brian E Carpenter <[email-masked]> wrote:
> 

I struggle to imagine any possible situation where someone could claim "yes the RFC community want that but the IETF community doesn’t".

Jay

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

---

From: Michael StJohns <[email-masked]>
Date: Thu, 4 Nov 2021 18:58:05 -0400

On 11/4/2021 6:39 PM, Brian E Carpenter wrote:
> "Responsiveness to the community. The IETF LLC is expected to act 
> consistently with the documented consensus of the IETF community, to 
> be responsive to the community's needs, and to adapt its decisions in 
> response to consensus-based community feedback."
>

Not a problem.  If this happens, the appropriate place to address it is 
with the ED's employer - the LLC board.

> to explicitly include this expectation in the LLC's remit would work.

Except that has exactly the same legal impact as bringing a specific 
issue to the board - e.g. none.  If the LLC board is going to ignore the 
complaint in the first place, knowing that this specific behavior was 
considered bad from before the creation of this document, why would 
writing/modifying a second document have any visible affect?

If you want actual enforceable behavior, write something into the LLC 
agreement or articles of incorporation that refers to RFC8711.  I doubt 
we need that.

Mike

---

From: Michael StJohns <[email-masked]>
Date: Thu, 4 Nov 2021 19:01:02 -0400

> I struggle to imagine any possible situation where someone could claim "yes the RFC community want that but the IETF community doesn’t".

I expect if we ever get to that case, we'll need to create a separate 
LLC under the ISOC specifically for the purpose of housing the RFC 
editor function.

Later, Mike

---

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

> I struggle to imagine any possible situation where someone could claim "yes the RFC community want that but the IETF community doesn’t".

So do I, but people have raised the issue of where authority lies.
Personally, I already said I'm OK with the -05 draft.

     Brian

---

From: Eliot Lear <[email-masked]>
Date: Fri, 5 Nov 2021 09:52:07 +0100

Hi Mike,

Thanks for your comments.  Please see below for proposed dispositions.  
For conciseness, if I indicate that I believe something is editorial, my 
suggestion is that it be left to the editor to incorporate as he deems 
appropriate, without further discussion.  Others are of course free to 
disagree, in which case we'll put each matter on the agenda.  If you 
agree with the below, I'll open up issues accordingly.

> Section 1, numbered item 1 beginning Policy definition.   This is 
> worded in a way that implies more authority to the RSWG than is 
> planned.  Instead replace the second sentence here (and the similar 
> language in Section 2 third para with:
>
> "This is the responsibility of both the RFC Series Working Group 
> (RSWG), which proposes policy, and the RFC Series Approval Board 
> (RSAB), which evaluates and approves or rejects such proposals."
>
Editorial.

> publication of/of the concepts described in/.  Insert "Editorial" 
> before "Series".
>
Editorial.

> Following para s/documents are produced/RFCs are produced/
Editorial
> Section 2, 3rd para change from above.  Also, that first sentence is a 
Editorial

> Section 2, 4th para s/Policy implementation/Implementation of 
> policy/.   s/ultimate authority/direction/.  Insert after "LLC)" "on 
> behalf of the community".
>
Not editorial, but a response to Issue 108.

> Insert after (RSWG) - ", pass a community last call, "
Editorial
> Section 3.1.2 first para - s/RSWG/RSWG and the community last call/
I'm not sure which instance you're referring to.

Currently that text reads:

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

This is subject to change based on the outcome of Issue 97 (resetting 
the 3 month timer).

> Section 3.2.2 page 10 numbered bullet 6.  I may have missed this, but 
> I thought the RSWG was responsible for the last call and for doing the 
There are two last calls; one within the group and one beyond the 
group.  The one within the group occurs at (4).  The one beyond the 
group occurs at (6).  Please note that this is covered in detail in 
Section 3.2.3.  Could you please be more specific as to what you want to 
discuss?

> Section 3.2.4 - 1st para, 2nd sentence = "only on grounds of 
> failure..." - how about on a disagreement on community (not just RSWG) 
> consensus?  DISCUSS.
>
This is, at least in part, Issue 93.  Please see Martin's proposed 
text.  Again, please be more specific in what you want to discuss.

> RPC and which have not yet been superceded by Editorial stream 
> documents and the requisite contractual changes."
>
In my view, this is *not* editorial but also not controversial.  I 
propose that this change simply be adopted.

> Section 4.1, 2nd para, last bullet, delete "contractually" - 
> duplicative with "contract".
>
Editorial.

> Section 4.1, para at top of page 14 beginning "If individuals..." - 
> this is one of the few places that we need specific individuals rather 
> than the generic LLC so: s/the IETF LLC look into/the IETF LLC board, 
> the IETF ED or a POC designated by the LLC board to look into/
>
Not editorial.

> Section 4.3 - first para: The RPC responsibilities will change from 
> time to time and are specified by the contract, not by these documents 
> unless incorporated by reference.  Suggest inserting "(as of 
> publication)" after "responsibilities" near the end of that long run 
> on sentence.  Referencing the current contract may also be useful here.
>
Not editorial.

> more general policy."    Basically, as written it implies the RSWG 
> will take action and that is not guaranteed.
>
This is covered by Issues 93 and 94, to be discussed.

> requiring the LLC to share the draft SOW and solicit input on that 
> draft prior to issuing it for proposal.
>
Not editorial.

> section 5.2.  I've pretty much lost the argument about constraining 
> the RSCE into such a side role, but comparing these bullets to the 
> section 5.2, I'm not sure I see the point of soliciting community 
> input as the RSCE will be virtually invisible to them.  This document 
> neuters the RSCE to the point where their only real customer is the RPC.
>
I am not sure what you are proposing.

> Section 5.3 - Suggest adding "The COI policy shall not preclude the 
> RPC from contracting services from the person or entity performing the 
> RSCE function.  Such contracts shall be disclosed publicly".  There 
> are too few people that might want to engage with us, and the RPC may 
> not want to pay a full time person for some of the tasks we've moved 
> around.  I'd prefer making it explicit that the LLC can't make working 
> for the RPC an unmanageable COI for the RSCE.
>
Not editorial.

Eliot

---

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

I proposed in an earlier mail to replace

"RPC under authority of the IETF LLC”

With

"as contractually overseen by the IETF LLC”

The second phase is already used once in the document and I think it would be more correct to use it everywhere.

From my point of view we don’t necessarily need to add "on behalf of the community” because that’s what is defined in RFC8711 as Brian Carpenter pointed out multiple time already. However, maybe a reference to RFCC8711 would actually be appropriate?

Do people agree?

Mirja

P.S.: Eliot opened issue #122 for this:
https://github.com/intarchboard/program-rfced-future/issues/122

> On 4. Nov 2021, at 23:09, Michael StJohns <[email-masked]> wrote:
> 
> The phrase is probably "under contract to the LLC which itself is acting on behalf of the community" in most of the cases we talked about.  Contract implies a negotiated and limited set of both authorities and responsibilities.  "acting on behalf" explains who the real customer is.
> 
> Mike
> 
> 
> --

---

From: Eliot Lear <[email-masked]>
Date: Fri, 5 Nov 2021 17:13:42 +0100

FWIW I have opened up issues for the below unless I needed more 
information from Mike, with one exception:

> draft prior to issuing it for proposal.

This was actually previously discussed, and the level of detailed was 
negotiated into what the text says.  I have no problem with us 
addressing this point, but I would like to hear from others who would 
support the change, before spending time on it at the meeting.

Eliot

---

From: Michael StJohns <[email-masked]>
Date: Fri, 5 Nov 2021 13:56:12 -0400

On 11/5/2021 4:52 AM, Eliot Lear wrote:
>
> Hi Mike,
>
> Thanks for your comments.  Please see below for proposed 
> dispositions.  For conciseness, if I indicate that I believe something 
> is editorial, my suggestion is that it be left to the editor to 
> incorporate as he deems appropriate, without further discussion.  
> Others are of course free to disagree, in which case we'll put each 
> matter on the agenda.  If you agree with the below, I'll open up 
> issues accordingly.
>
If Editorial means "same meaning, different way of saying it, Peter's 
choice", then this isn't editorial.

As written it says "This is the responsibility of the RFC Series Working 
Group which produces policy proposals...." referring back to "Policy 
definition governing the Series as a whole.   Yes, there is the follow 
on clause of "subject to", but the responsibility as written is tied to 
the proposing, not to the proposing and approval.  The latter is 
correct.  As written it is not.

Try it this way: Read the sentence as a whole, then read it dropping the 
last clause beginning "that", then read it again dropping everything 
beginning with "which". What do you see? Remember how much you hated 
diagramming sentences in English class?  This is a recursive sentence 
with two clauses,  each of which modifies the section before it.  In 
other words, a three-level sentence.

The meaning has to be closer to "Policy definition governing the RFC 
Series as a whole is the joint responsibility of the RSWG which proposes 
policies, and the RSAB which evaluates and approves them." than it 
currently is.

>> publication of/of the concepts described in/. Insert "Editorial" 
Maybe.   The RPC is not "implementing policy" by "publishing documents" 
either in the RFC series or the Editorial sub-series.  I think this is a 
non-controversial change, but needs to be made whether editorial or not.
>> Following para s/documents are produced/RFCs are produced/
Yup.
>>
>> Section 2, 3rd para change from above.  Also, that first sentence is 
>> a run on.
>>
> Editorial
>
See the first item - this needs to track that.
> Not editorial, but a response to Issue 108.
Yes.
>> Insert after (RSWG) - ", pass a community last call, "
Maybe, but non controversial, but the community last call is part of the 
process and is not cited here and needs to be.
> I'm not sure which instance you're referring to.
Sorry - last sentence.  The RSWG rough consensus is not the only 
consideration, it's both the rough consensus of the RSWG, and the sense 
of the community gleaned from the community last call that's important 
here.  RSWG members represent their own points of view, and taken 
collectively may even be out of step with the broader community that 
doesn't have the time to spend nit picking words and comments.  The RSAB 
needs to honor not just the RSWG POV, but pay attention if the community 
has issues the RSWG has decided do not merit their attention.

Probably related to #93, but more general

> This is subject to change based on the outcome of Issue 97 (resetting 
This whole section could use tightening.  I'll wait for the next 
document, but I can live with the general idea here - even though in 
this electronic society, 3 months is pretty much enough time to send 
things around for a snail mail vote - 5 times.
>> I thought the RSWG was responsible for the last call and for doing 
>> the work of resolving the questions, not the RSAB.   DISCUSS.
>>
> Section 3.2.3.  Could you please be more specific as to what you want 
> to discuss?
>
Sorry, the community last call.  As I was reading this, I realized we'd 
falling into cargo cult behavior.  We had the RSAB do the community last 
call because the IESG does the community last call.  That makes less 
sense here for a number of reasons. First, the RSAB and the RSWG have 
exactly the same domain of interests, but slightly different levers, but 
in the IETF the IESG has a much broader domain of interests that the 
WG.  Second, the RSAB consists of folks we've already loaded down with 
other work -  the RSAB is "other duties as assigned", but in the IETF 
the IESG is selected specifically to deal  with the processing of a 
broad swath of documents and related functionality (e.g. WG management 
which is not an RSAB task).  Lastly, the RSWG is where the motivation is 
designed to come from, so they should be the ones doing the donkey work 
of putting the document out for public comment, gathering the responses, 
resolving them in the WG, and if necessary lather rinse, repeat.  The 
RSAB should be getting a document mostly ready for vote - especially 
given the requirement that the RSAB is expected to be active in the RSWG.

So my suggestion here is to move the community last call responsibility 
to the RSWG, specifically the RSWG chairs once they've established the 
RSWG has met consensus.

This is not a line I will die to hold, but I think the division of work 
here is just wrong.

>> failure..." - how about on a disagreement on community (not just 
>> RSWG) consensus?  DISCUSS.
>>
Basically, the RSAB shouldn't be rubber stamping the RSWG if the 
community has other idea, even if the "community" wasn't actively 
participating in the RSWG.  The RSWG is *really* different from an IETF 
WG or even an IRTF RG in that pretty much everything it does can affect 
everyone.

So the proposal is to acknowledge that RSWG consensus is necessary, but 
not sufficient.  There at least needs to be community buy-in or at least 
grudging acceptance and that may not come until the community last call, 
and may not actually be reached even after RSWG re-shuffling if a 
proposal is particularly onerous.

This isn't easily captured inside of #93 but the text to resolve #93 has 
to acknowledge that the RSWG consensus (and the document) isn't the only 
input into the RSAB's decision process.

There's tension here that we need to resolve between an RSWG that trumps 
even the community, or an RSWG that tries at least to act on behalf of 
the community.  This ties in with the other discussions such as those 
from Mark wanting to expand the remit of the RSWG way past what we've 
agreed to.

The text fix here may be simple, but getting there will not be without pain.

>
>> Section 4.1, 2nd para, first bullet.   I think some language is 
>> needed here such as insert at end: "or by such legacy RFCs which 
>> apply to the RPC and which have not yet been superceded by Editorial 
>> stream documents and the requisite contractual changes."
>>
Yes
>> duplicative with "contract".
Yes
>> this is one of the few places that we need specific individuals 
>> rather than the generic LLC so: s/the IETF LLC look into/the IETF LLC 
>> board, the IETF ED or a POC designated by the LLC board to look into/
>>
> Not editorial.
>
Not editorial, but not really controversial.  Refer to Jay for comment 
prior to opening an issue?
>> time to time and are specified by the contract, not by these 
>> documents unless incorporated by reference. Suggest  inserting "(as 
>> of publication)" after "responsibilities" near the end of that long 
>> run on sentence. Referencing the current contract may also be useful 
>> here.
>>
> Not editorial.
>
Maybe.  This section can't be normative or directive because of outside 
issues.  I think that was always the intent, but maybe not captured by 
the text.
>> interest of time, the disagreement may be resolved as the parties 
>> best see fit while the RSWG considers whether there is a need to 
>> propose a more general policy." Basically, as written it implies the 
>> RSWG will take action and that is not guaranteed.
>>
This my text alternate to Martin's in #94.  I don't think this is 
necessarily an RSAB issue for all items.  Basically the rule is that 
decisions get reported to the RSAB/RSWG.  The RSAB may poke its nose in 
immediately, the RSWG will consider whether documents need to be written.

>> draft prior to issuing it for proposal.
Maybe.  This is implied by community input at the end of the second 
para, but just clarifies what a concrete example of that is for the SOW 
process.  This is what the RSOC did for the iRSE. Refer to Jay for 
comment before opening an issue?

> I am not sure what you are proposing.
I'm not sure I am either!   Given the RSCE responsibilities in 5.2, I'd 
replace "...a call for ...community" with "...a call for confidential 
input from the community in the form of a questionnaire on specific RSCE 
responsibilities to the community".    Let's at least try and make this 
useful, rather than a blank sheet where the RSCE gets hit for things 
they aren't responsible for simply because they have RFC Series in their 
title.  Open an issue?
>> RPC from contracting services from the person or entity performing 
>> the RSCE function.  Such contracts shall be disclosed publicly".  
>> There are too few people that might want to engage with us, and the 
>> RPC may not want to pay a full time person for some of the tasks 
>> we've moved around.  I'd prefer making it explicit that the LLC can't 
>> make working for the RPC an unmanageable COI for the RSCE.
>>
> Not editorial.
>
Yup, but we're struggling on how the RSCE and RPC will work together, 
and I have this feeling we're going to stick the RPC with too many 
things they won't necessarily be good at.  Given how few good technical 
editor/publisher candidates I expect we'll get I think we need to make 
clear that the LLC shouldn't COI the RSCE from work subcontracted from 
the RPC.    Open an issue?

---

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

> support the change, before spending time on it at the meeting.
If its been discussed, I'm happy to strike the comment.  I just didn't 
remember anything on point here.

Mike

---

From: Colin Perkins <[email-masked]>
Date: Fri, 5 Nov 2021 19:50:40 +0000

(one comment inline)

> On 5 Nov 2021, at 17:56, Michael StJohns <[email-masked]> wrote:
> 
>> Thanks for your comments.  Please see below for proposed dispositions.  For conciseness, if I indicate that I believe something is editorial, my suggestion is that it be left to the editor to incorporate as he deems appropriate, without further discussion.  Others are of course free to disagree, in which case we'll put each matter on the agenda.  If you agree with the below, I'll open up issues accordingly.
>> 
>>> Section 1, numbered item 1 beginning Policy definition.   This is worded in a way that implies more authority to the RSWG than is planned.  Instead replace the second sentence here (and the similar language in Section 2 third para with:
>>> 
>>> "This is the responsibility of both the RFC Series Working Group (RSWG), which proposes policy, and the RFC Series Approval Board (RSAB), which evaluates and approves or rejects such proposals."
>>> 
>> Editorial.
>> 
> If Editorial means "same meaning, different way of saying it, Peter's choice", then this isn't editorial.  
> 
> As written it says "This is the responsibility of the RFC Series Working Group which produces policy proposals...." referring back to "Policy definition governing the Series as a whole.   Yes, there is the follow on clause of "subject to", but the responsibility as written is tied to the proposing, not to the proposing and approval.  The latter is correct.  As written it is not.  
> 
> Try it this way: Read the sentence as a whole, then read it dropping the last clause beginning "that", then read it again dropping everything beginning with "which". What do you see? Remember how much you hated diagramming sentences in English class?  This is a recursive sentence with two clauses,  each of which modifies the section before it.  In other words, a three-level sentence.
> 
> The meaning has to be closer to "Policy definition governing the RFC Series as a whole is the joint responsibility of the RSWG which proposes policies, and the RSAB which evaluates and approves them." than it currently is.
> 
>> 
>>> Section 1, numbered item 2 top of page 4 first sentence: s/through publication of/of the concepts described in/.  Insert "Editorial" before "Series".
>>> 
>> Editorial.
>> 
> Maybe.   The RPC is not "implementing policy" by "publishing documents" either in the RFC series or the Editorial sub-series.  I think this is a non-controversial change, but needs to be made whether editorial or not.
>>> Section 2, 3rd para change from above.  Also, that first sentence is a run on.
>>> 
>> Editorial
>> 
>>> Section 2, 4th para s/Policy implementation/Implementation of policy/.   s/ultimate authority/direction/.  Insert after "LLC)" "on behalf of the community".
>>> 
>>> Section 3, first para s/that are//  There are also missing commas.   Insert after (RSWG) - ", pass a community last call, "
>>> 
>> Editorial
> Maybe, but non controversial, but the community last call is part of the process and is not cited here and needs to be.
> Sorry - last sentence.  The RSWG rough consensus is not the only consideration, it's both the rough consensus of the RSWG, and the sense of the community gleaned from the community last call that's important here.  RSWG members represent their own points of view, and taken collectively may even be out of step with the broader community that doesn't have the time to spend nit picking words       and comments.  The RSAB needs to honor not just the RSWG POV, but pay attention if the community has issues the RSWG has decided do not merit their attention.
> 
>>> Section 3.1.2 top of page 8 bullet beginning "Voting on approval..." place holder as I haven't seen the last text here and I don't want to dig through the piles of emails to try and find it.
>>> 
>>> Voting on approval of policy documents produced by the RSWG shall be delayed until the vacancy or vacancies have been filled, up to a maximum of 3 months; this clause does not apply to a vacancy of the RSCE role, only of the stream representatives enumerated above.
>> This is subject to change based on the outcome of Issue 97 (resetting the 3 month timer).
>> 
> This whole section could use tightening.  I'll wait for the next document, but I can live with the general idea here - even though in this electronic society, 3 months is pretty much enough time to send things around for a snail mail vote - 5 times.
>> 
>> 
>>> Section 3.2.2 page 10 numbered bullet 6.  I may have missed this, but I thought the RSWG was responsible for the last call and for doing the work of resolving the questions, not the RSAB.   DISCUSS.
>>> 
>> There are two last calls; one within the group and one beyond the group.  The one within the group occurs at (4).  The one beyond the group occurs at (6).  Please note that this is covered in detail in Section 3.2.3.  Could you please be more specific as to what you want to discuss?
>> 
> Sorry, the community last call.  As I was reading this, I realized we'd falling into cargo cult behavior.  We had the RSAB do the community last call because the IESG does the community last call.  That makes less sense here for a number of reasons.  First, the RSAB and the RSWG have exactly the same domain of interests, but slightly different levers, but in the IETF the IESG has a much broader domain of interests that the WG.  Second, the RSAB consists of folks we've already loaded down with other work -  the RSAB is "other duties as assigned", but in the IETF the IESG is selected specifically to deal  with the processing of a broad swath of documents and related functionality (e.g. WG management which is not an RSAB task).  Lastly, the RSWG is where the motivation is designed to come from, so they should be the ones doing the donkey work of putting the document out for public comment, gathering the responses, resolving them in the WG, and if necessary lather rinse, repeat.  The RSAB should be getting a document mostly ready for vote - especially given the requirement that the RSAB is expected to be active in the RSWG.
> 
> So my suggestion here is to move the community last call responsibility to the RSWG, specifically the RSWG chairs once they've established the RSWG has met consensus.
> 
> This is not a line I will die to hold, but I think the division of work here is just wrong.
> 
I disagree. The RSAB members are representatives of their communities, and the community last call is their last chance to ensure their full communities get to give input. Leaving the community last call to the RSWG chairs risks a very insular process. 

>>> Section 3.2.4 - 1st para, 2nd sentence = "only on grounds of failure..." - how about on a disagreement on community (not just RSWG) consensus?  DISCUSS.
>>> 
>> This is, at least in part, Issue 93.  Please see Martin's proposed text.  Again, please be more specific in what you want to discuss.
>> 
> Basically, the RSAB shouldn't be rubber stamping the RSWG if the community has other idea, even if the "community" wasn't actively participating in the RSWG.  The RSWG is *really* different from an IETF WG or even an IRTF RG in that pretty much everything it does can affect everyone.  
> 
> So the proposal is to acknowledge that RSWG consensus is necessary, but not sufficient.  There at least needs to be community buy-in or at least grudging acceptance and that may not come until the community last call, and may not actually be reached even after RSWG re-shuffling if a proposal is particularly onerous.
> 
> This isn't easily captured inside of #93 but the text to resolve #93 has to acknowledge that the RSWG consensus (and the document) isn't the only input into the RSAB's decision process.  
> 
> There's tension here that we need to resolve between an RSWG that trumps even the community, or an RSWG that tries at least to act on behalf of the community.  This ties in with the other discussions such as those from Mark wanting to expand the remit of the RSWG way past what we've agreed to.
> 
>>> Section 4.1, 2nd para, first bullet.   I think some language is needed here such as insert at end: "or by such legacy RFCs which apply to the RPC and which have not yet been superceded by Editorial stream documents and the requisite contractual changes."
>>> 
>> In my view, this is not editorial but also not controversial.  I propose that this change simply be adopted.
>> 
>> 
>> 
> Yes
>> 
>>> Section 4.1, 2nd para, last bullet, delete "contractually" - duplicative with "contract".
>>> 
>> Editorial.
>> 
> Yes
>>> Section 4.1, para at top of page 14 beginning "If individuals..." - this is one of the few places that we need specific individuals rather than the generic LLC so: s/the IETF LLC look into/the IETF LLC board, the IETF ED or a POC designated by the LLC board to look into/
>>> 
>> Not editorial. 
>> 
> Not editorial, but not really controversial.  Refer to Jay for comment prior to opening an issue?
>> 
>>> Section 4.3 - first para: The RPC responsibilities will change from time to time and are specified by the contract, not by these documents unless incorporated by reference.  Suggest  inserting "(as of publication)" after "responsibilities" near the end of that long run on sentence.  Referencing the current contract may also be useful here.
>>> 
>> Not editorial.
>> 
> Maybe.  This section can't be normative or directive because of outside issues.  I think that was always the intent, but maybe not captured by the text.
>> 
>> 
>>> Section 4.4, third bullet last sentence.  Instead:  "However, in the interest of time, the disagreement may be resolved as the parties best see fit while the RSWG considers whether there is a need to propose a more general policy."              Basically, as written it implies the RSWG will take action and that is not guaranteed.
>>> 
> This my text alternate to Martin's in #94.  I don't think this is necessarily an RSAB issue for all items.  Basically the rule is that decisions get reported to the RSAB/RSWG.  The RSAB may poke its nose in immediately, the RSWG will consider whether documents need to be written.
> 
> 
> 
>> 
>>> Section 4.6.1 Second para.  There should be additional text here requiring the LLC to share the draft SOW and solicit input on that draft prior to issuing it for proposal.
>>> 
>> Not editorial.
>> 
> Maybe.  This is implied by community input at the end of the second para, but just clarifies what a concrete example of that is for the SOW process.  This is what the RSOC did for the iRSE.   Refer to Jay for comment before opening an issue?
> 
> 
> 
>> 
>>> Section 5, the bullets describing the responsibilities of the RSCE vs section 5.2.  I've pretty much lost the argument about constraining the RSCE into such a side role, but comparing these bullets to the section 5.2, I'm not sure I see the point of soliciting community input as the RSCE will be virtually invisible to them.  This document neuters the RSCE to the point where their only real customer is the RPC.  
>>> 
> I'm not sure I am either!   Given the RSCE responsibilities in 5.2, I'd replace "...a call for ...community" with "...a call for confidential input from the community in the form of a questionnaire on specific RSCE responsibilities to the community".    Let's at least try and make this useful, rather than a blank sheet where the RSCE gets hit for things they aren't responsible for simply because they have RFC Series in their title.  Open an issue? 
>> 
>>> 
>>> Section 5.3 - Suggest adding "The COI policy shall not preclude the RPC from contracting services from the person or entity performing the RSCE function.  Such contracts shall be disclosed publicly".  There are too few people that might want to engage with us, and the RPC may not want to pay a full time person for some of the tasks we've moved around.  I'd prefer making it explicit that the LLC can't make working for the RPC an unmanageable COI for the RSCE.
>>> 
>> Not editorial.
>> 
> Yup, but we're struggling on how the RSCE and RPC will work together, and I have this feeling we're going to stick the RPC with too many things they won't necessarily be good at.  Given how few good technical editor/publisher candidates I expect we'll get I think we need to make clear that the LLC shouldn't COI the RSCE from work subcontracted from the RPC.    Open an issue?
>> 
>> Eliot
> 
> -- 

-- 
Colin Perkins
https://csperkins.org/

---

From: Colin Perkins <[email-masked]>
Date: Fri, 5 Nov 2021 20:01:33 +0000

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

I’ve re-read this draft, and while I still have some concerns, I can live with the content. Some comments below, many but not all of which are editorial.

Apologies if these overlap with previous comments. 

Near the end of Section 1:

>    In this model, documents are produced and approved through multiple
>    document streams.  The stream manager for each stream is responsible
>    for the content of that stream.  The RFC Editor function is
>    responsible for the packaging and distribution of the documents.  As
>    such, documents from these streams are edited and published by the
>    Production Center.

Is “RFC Editor function” intended here? I thought that was replaced?
Also, the “As such” confuses and seems unnecessary.

Section 2, 2nd paragraph:

>    By contrast, version 3 of the RFC Editor Model, specified here,
>    provides a more consensus-oriented framework (similar in some
>    respects to the structure of technical work within the IETF or IRTF)

The IRTF lacks the explicit requirement for consensus that exists in IETF, so it might be clearer to just use the IETF as the example here.

Section 3, 1st paragraph:

>    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).

The phrase “defined in the open” could be clearer. Maybe “defined through open and public discussion” or similar?

“generated by..the RSWG” - implies that proposals can only be generated by the group, but we also want to allow proposals to originate elsewhere and submitted to the RSWG for discussion.

Section 3.1.1: 

>                                                    The intent is that
>    the RSWG operate in a way similar to working groups in the IETF and
>    research groups in the IRTF.  Therefore, all RSWG meetings shall be
>    open to any participant,

The combination of these can be read as open to any participant in the IETF and IRTF. Perhaps “All RSWG meeting shall be open to all interested persons” to match the later text?

>    All interested persons are welcome to participate in the RSWG
>    (subject to anti-harassment policies as described below).  This
>    includes participants in the IETF and IRTF, IAB and IESG members,
>    ...

“…this includes, but is not limited to, participants in…”

Section 3.1.2: 

>    The appointing bodies shall determine their own processes for
>    appointing RSAB members...

In cases where the IRTF Chair or ISE appoints a delegate, this section uses the term "appointing body” to refer to both the IRTF Chair/ISE, as the appointing body for the RSAB delegate, and to the IAB as appointing body for the IRTF Chair/ISE, within a single paragraph. This may cause confusion.

>    Whenever a new stream is created,

Implies that new streams will be created. It should perhaps be “If a new stream is created”.

>    The RSAB shall annually choose a chair from among its members using a
>    method of its choosing.  If the chair position is vacated during the
>    chair's term, the RSAB should choose a new chair from among its
>    members.

Is it possible for the RSAB chair to step down from the chair role, but remain on the RSAB as a stream representative? 

If the RSAB chair position is vacated because the representative steps down from the RSAB, is there a requirement that the RSAB wait for their replacement to be appointed before selecting a new chair?

Section 3.2.2:

>    1.  An individual participant in the RSWG generates a proposal in the
>        form of an Internet-Draft, which is submitted in full conformance

Should specify where it is submitted.

“An individual participant” - unclear if this is intended to exclude the RSAB members and RSWG chairs, or if they are allowed to submit as individuals but not as holders of those roles. I assume the latter is intended, but the draft should be clarified.

Bullet 3 in Section 3.2.2 explicitly calls out that the RSWG chairs are also expected to participate as individuals. Given that, it would be useful to also highlight here that RSAB members are also expected to participate as individuals.

>    5.  After a comment period of suitable length, the RSWG chairs will
>        determine whether rough consensus for the proposal exists... 

Are the RSWG chairs expected to publicly announce the outcome of the last call? 

>    6.  Once consensus is established in the RSWG, the RSAB shall issue a
>        community call for comments as further described below.  If
>        substantial comments have been received, the RSWG will again
>        consider those comments and make revisions as they see fit.  At
>        this same time, the RSAB will also consider the proposal.

The “If substantial comments have been received…” text is unclear. Should it be “If substantial comments are received in response to the community call for comments, the RSAB may return the draft to the RSWG to consider those comments and make revisions as they see fit”? 

“At this same time, the RSAB will also consider the proposal” - at which time? Unclear if this is while the community call for comments is ongoing, while the RSWG is revising the draft, or after the community call for comments has concluded and any revisions have been made.

>    8.  Once all comments have been addressed, the RSWG chairs will
>        submit the proposal to the RSAB for its consideration.

This seems that it should happen before step 6, to trigger the RSAB to look at the document and issue the community call for comments. 

Step 8 would seem better phrased as the RSWG chairs confirming that that believe comments have been addressed and the document is ready for RSAB ballot.

>    A position of CONCERN may be filed for two reasons:
> 
>    *  The proposal represents a serious problem for the stream or group
>       that a particular member represents.

Is an RSAB member permitted to file a CONCERN ballot if they believe a proposal represents a serious problem for one of the other streams? I’d expect that such issues would be resolved by discussion between the RSAB members leading to the representative for the stream concerned raising a CONCERN, but what happens if there is disagreement amongst the RSAB members?

>    Because RSAB members should have been participating in discussions
>    within the RSWG, no position of CONCERN should ever come as a
>    surprise to the RSWG.

I agree with the intent, but the phrasing allows for bad-faith accusations of surprise. Perhaps something like "RSAB members are expected to participate in the discussions within the RSWG, and raise any concerns and issues during those discussions; accordingly, no position of CONCERN should ever come as a surprise to the RSWG”.

It’s possible that an RSAB member will be made aware of an issue late in the process that would lead to them issuing a CONCERN. It’s obviously desirable if concerns are raised early, but that can’t be guaranteed. An RSAB member needs to be able to raise a late CONCERN (i.e., concern ballots “SHOULD NOT” come as a surprise, not “MUST NOT” come as a surprise). It would be useful to clarify that there are sometimes legitimate cases where a CONCERN may be a surprise, although this should be rare.

>    1.  If a CONCERN exists, discussion will take place within the RSWG.
>        Again, all RSAB members are expected to participate.
> 
>    2.  A proposal without any CONCERN positions is approved.  If
>        substantial changes have been made in order to address CONCERN
>        positions, an additional call for community input might be
>        needed.

Agree with the intent, but would have expected the second sentence of point 2 to be included in point 1.

Also, “have been made” -> “are made"

>    3.  If, after a suitable period of time, any CONCERN positions
>        remain, a vote of the RSAB is taken.  If at least three voting
>        members vote YES, the proposal is approved.

I’m not entirely happy with this, but accept the consensus. However, we also allow for additional streams to be created with their own voting members. If that happens, does this threshold change? It would seem that it should.

>    Notices will always be sent to the rfc-interest mailing list.  The
>    RSAB and RSWG should also send notices to other communities that may
>    be interested in or impacted by a proposal as they see fit, following
>    policies for those communities as appropriate.

Should this also say that: "RSAB members should distribute notice of the call for comments to the communities they represent”?

>    The IETF anti-harassment policy
>    (https://www.ietf.org/about/groups/iesg/statements/anti-harassment-
>    policy/) also applies to the RSWG and RSAB,

I agree that the policy should apply, but the linked IESG statement and RFCs are very IETF specific. Do they need updating to explicitly include the RSWG?

Section 4.1: 

>    *  The general roles and responsibilities of the RPC are defined by
>       RFCs published in the Editorial Stream (i.e., not directly by the
>       RSWG, RSAB, or RSCE).

Needs clarification: changes to the roles and responsibilities of the RPC will be defined in this way. The existing roles and responsibilities remain and are not defined by Editorial stream RFCs (since, at present, there is no editorial stream).

>    The IETF LLC is responsible for the method of and management of the
>    engagement of the RPC.  Therefore, the IETF LLC has authority over
>    negotiating performance targets for the RPC and also has
>    responsibility for ensuring that those targets are adhered to.  The
>    IETF LLC is empowered to appoint a manager or to convene a committee
>    to complete these activities.

Are there any constraints on who the LLC can appoint or on the membership of the committee they may convene? Performance targets can be a contentious issue.

>  4.2.  Implementation-Specific Policies

This section seems perhaps under-specified. Based on past history, I expect the RPC will no something reasonable, but the boundaries of its authority to set policy are not well defined here.

Section 4.4, 1st paragraph: "IRSG research group chair” -> “IRTF research group chair”

Section 5.2:

>    Periodically, the IETF LLC will evaluate the performance of the RSCE,
>    including a call for confidential input from the community.  The IETF
>    LLC will produce a draft performance evaluation for the RSAB (not

Might be clearer as “…will produce a draft evaluation of the RSCE’s performance for review by the RSAB…”?

> 6.  Editorial Stream

I still think this section needs to be explicit that Experimental RFCs cannot be published on the Editorial stream, rather than leaving it implied.

> Appendix A.  Changes from Version 2 of the RFC Editor Model

The content of the Appendix is fine, modulo the nits below, but I would like to see it moved to a main section of the document to make it clear that its contents are as normative as those in the rest of the document.

> A.5.  RFC Series Oversight Committee (RSOC)

The phrasing in this section is imprecise: “abolishes”, “disbands”, or “disestablishes” would be clearer.

> A.6.  RFC Series Advisory Group (RSAG)

"For the avoidance of doubt, this document affirms that the RSAG is obsolete and its charter is no longer in force” – there seems a strange reluctance to be explicit here: the RSAB has been abolished and no longer exists.

Cheers,
Colin

-- 
Colin Perkins
https://csperkins.org/

---

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

On 11/5/2021 3:50 PM, Colin Perkins wrote:
>>>
>>>
>>>> Section 3.2.2 page 10 numbered bullet 6.  I may have missed this, 
>>>> but I thought the RSWG was responsible for the last call and for 
>>>> doing the work of resolving the questions, not the RSAB.   DISCUSS.
>>>>
>>> Section 3.2.3.  Could you please be more specific as to what you 
>>> want to discuss?
>>>
>> Sorry, the community last call.  As I was reading this, I realized 
>> we'd falling into cargo cult behavior.  We had the RSAB do the 
>> community last call because the IESG does the community last call.  
>> That makes less sense here for a number of reasons.  First, the RSAB 
>> and the RSWG have exactly the same domain of interests, but slightly 
>> different levers, but in the IETF the IESG has a much broader domain 
>> of interests that the WG. Second, the RSAB consists of folks we've 
>> already loaded down with other work -  the RSAB is "other duties as 
>> assigned", but in the IETF the IESG is selected specifically to deal  
>> with the processing of a broad swath of documents and related 
>> functionality (e.g. WG management which is not an RSAB task).  
>> Lastly, the RSWG is where the motivation is designed to come from, so 
>> they should be the ones doing the donkey work of putting the document 
>> out for public comment, gathering the responses, resolving them in 
>> the WG, and if necessary lather rinse, repeat.  The RSAB should be 
>> getting a document mostly ready for vote - especially given the 
>> requirement that the RSAB is expected to be active in the RSWG.
>>
>> So my suggestion here is to move the community last call 
>> responsibility to the RSWG, specifically the RSWG chairs once they've 
>> established the RSWG has met consensus.
>>
> I disagree. The RSAB members are representatives of their communities, 
> and the community last call is their last chance to ensure their full 
> communities get to give input. Leaving the community last call to the 
> RSWG chairs risks a very insular process.
>

Hi Colin -

Unless I'm really confused, the information the RSAB will receive in 
both instances is pretty much the same.  All I'm suggesting in that the 
mechanics of the last call - issuing it to all of the identified 
communities, gathering comments in a parseable format, running the 
discussion in the RSWG (including RSAB input), and updating the document 
to resolve things according to the discussion be driven by the RSWG 
chairs instead of one of the RSAB members already working 75% time on 
IESG or IAB or IRTF issues. As I said, not a line I'm drawing, but it 
seems the wrong way to divide the work.

Mike

---

From: Colin Perkins <[email-masked]>
Date: Fri, 5 Nov 2021 20:52:32 +0000

> On 5 Nov 2021, at 20:07, Michael StJohns <[email-masked]> wrote:
> 
> Unless I'm really confused, the information the RSAB will receive in both instances is pretty much the same.  All I'm suggesting in that the mechanics of the last call - issuing it to all of the identified communities, gathering comments in a parseable format, running the discussion in the RSWG (including RSAB input), and updating the document to resolve things according to the discussion be driven by the RSWG chairs instead of one of the RSAB members already working 75% time on IESG or IAB or IRTF issues. As I said, not a line I'm drawing, but it seems the wrong way to divide the work.

RSAB members are more incentivised to consult their respective communities than the RSWG chairs. If everything is working well, the results should be the same. But if the RSWG is getting insular, and RSAB members have more an incentive to seek feedback more widely.

-- 
Colin Perkins
https://csperkins.org/

---

From: Michael StJohns <[email-masked]>
Date: Fri, 5 Nov 2021 17:08:35 -0400

On 11/5/2021 4:52 PM, Colin Perkins wrote:
> But if the RSWG is getting insular, and RSAB members have more an incentive to seek feedback more widely.

This is where I'm not getting you.  Community last calls go to the 
community regardless of who issues the calls.  I would expect there will 
be one or more mailing lists that will get the last call on things from 
the RFC series process and those will be well known and pretty 
automatic.  I expect the RSAB to seek input from their constituencies in 
addition to reviewing community feedback and the RSWG response for 
sufficiency.

Or?

Mike

---

From: Jay Daley <[email-masked]>
Date: Sat, 6 Nov 2021 10:21:21 +1300

> On 6/11/2021, at 6:56 AM, Michael StJohns <[email-masked]> wrote:
> 
> 

It would be better to name a role yes and this should be my role, the ED, because thats the role with day-to-day responsibility here and so that the LLC Board can be the escalation step if someone is concerned that the ED has failed to act.
> Maybe.  This is implied by community input at the end of the second para, but just clarifies what a concrete example of that is for the SOW process.  This is what the RSOC did for the iRSE.   Refer…
Yes that would be good and in line with the LLC’s expected way of working. 
> Yup, but we're struggling on how the RSCE and RPC will work together, and I have this feeling we're going to stick the RPC with too many things they won't necessarily be good at.  Given how few goo…

I can’t see on what basis a COI would be imposed and both the RPC and RSCE are working to a common goal. The RPC contract doesn’t allow for any sort of project fund for the RPC to spend independently so if the RPC wanted the RSCE to do extra contracted work then I doubt the RPC would subcontract with them directly but rather negotiate with the LLC for the LLC to add a SoW to the RSCE contract.  Maybe there might be a situation where the RPC has a staff shortage and wants to directly contract the RSCE to backfill but that still wouldn’t be a COI. 

Ultimately I don’t mind such text being added but perhaps more subtly than mentioning a COI - “Nothing here should prevent the RPC from subcontracting the RSCE”

Jay

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

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 5 Nov 2021 22:30:14 +0100

TIL a new word: guidelie.
Goes into my preferred active vocabulary right away…

(Other nits below.)

I can’t say I am happy with this document, but I may have to accept it as the best that could be achieved at this point.

"The RSCE provides expert advice to the RPC and RSAB on how to implement established policies”.  I would like to make explicit that it is very much the job of the RSCE to watch the actual impact of these policies and to make proposals to remedy any shortcomings and to create continuous improvement, out of actively observing both creation/production and reception.

Others have already commented on the strangely passive role afforded to the RSCE by this document (5: “if requested”, “be consulted”), which needs to be fixed.  Also, it looks like the power of the RSE has to a large part been transferred to whoever calls the shots at the RPC (e.g., see 4.4).  I have a lot of trust in the people who are performing this function now, but policies are made to reduce the need for unconditional reliance on such trust.

Both the RPC and the RSCE ultimately report to the IETF Admin LLC.  Diving a bit deeper into what some may think of as paranoia, these contractual relationships cannot be out in the open, and clearly a future manipulative IED could do a lot of damage here.  I believe we need to develop some rules of transparency here (I’m going to avoid the term whistleblower, but there should be defined emergency communication channels from dependent entities such as RPC and RSCE to entities such as the LLC board, that are not subject to contractual restrictions not already required by US law).

Smaller points:

IRTF RGs can be closed (is this still true? We haven’t practiced this in a while), these are maybe not a role model for the RSWG.

"The IETF LLC is responsible for the method of and management of the engagement of the RPC” — please translate into a form of English that more people can understand.

You cannot submit Errata, only Errata Reports. (#18 in 4.3).
These turn into Errata when being approved (and usually commented on in the approvement process).  [The Errata Reporting process desperately needs some continuous improvement, if anybody wonders why I care about this seemingly trivial mistake.]

(Already mentioned by others: undefined phrasing “in the open”.)

Nits:

“guidelies”

“tools used to authors RFCs”

Grüße, Carsten

> On 2021-10-22, at 10:13, Eliot Lear <[email-masked]> wrote:
> 
> Signed PGP part
> Dear Colleagues,
> 
> <OpenPGP_0x87B66B46D9D27A33.asc>
> 
>

---

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

> The second phase is already used once in the document and I think it would be more correct to use it everywhere.

Yes. "Authority" seems to be a trigger word, so let's not use it.
  
>  From my point of view we don’t necessarily need to add "on behalf of the community” because that’s what is defined in RFC8711 as Brian Carpenter pointed out multiple time already. However, maybe a…

It's not essential, but it might be useful, to remind people that the LLC 
exists and manages the contracts as a matter of established community consensus.

    Brian

---

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

> support the change, before spending time on it at the meeting.

Since this is already standard operating procedure for the LLC, it
is another instance of needing to ensure that RFC8711 applies to
the RFC Editor work. I think Mirja's suggestion is correct: put in
a blanket statement to that effect.

    Brian

---

From: Colin Perkins <[email-masked]>
Date: Fri, 5 Nov 2021 23:25:39 +0000

> On 5 Nov 2021, at 21:30, Carsten Bormann <[email-masked]> wrote:
...
> IRTF RGs can be closed (is this still true? We haven’t practiced this in a while), 

NWCRG is in the process of closing.

Colin (yeah, off topic for this list, I know...)

---

From: Martin J. Dürst <[email-masked]>
Date: Sat, 6 Nov 2021 09:47:44 +0900

Hello Michael,

Your answer below was more on substance (where I don't see much to 
disagree) than on the process/policy issues.

As an example, the fact that RFCs never change is currently very well 
established, and it would take an awful lot to change that. But it's 
important to understand that such a change is not impossible in case the 
community really wanted it. And the process we currently are creating 
should be designed to allow such changes if they really correspond to 
wide community consensus. That should be independent of whether we 
currently (or in the future) agree with them or not (we both clearly 
don't agree with them, at least at this time).

Regards,   Martin.

On 2021-11-05 07:24, Michael StJohns wrote:
> have other tags that can be added and deleted - STD springs to mind. The 
> problem cited above is mostly not a problem that needs to be solved in 
> the RFC system, but in the way STDs  (and maybe other sub-series) are

---

From: Martin J. Dürst <[email-masked]>
Date: Sat, 6 Nov 2021 10:12:08 +0900

> This is not a line I will die to hold, but I think the division of work 

For the record, and having read the followup emails, I agree with 
Michael here. The RSAB members will see where the last call goes in 
their communities, and can always ask the RSWG chairs to add a mailing 
list if they think that list should also newly get the last call 
announcement.

Regards,   Martin.

---

From: Colin Perkins <[email-masked]>
Date: Sat, 6 Nov 2021 10:01:44 +0000

> On 5 Nov 2021, at 21:08, Michael StJohns <[email-masked]> wrote:
> This is where I'm not getting you.  Community last calls go to the community regardless of who issues the calls.  I would expect there will be one or more mailing lists that will get the last call on things from the RFC series process and those will be well known and pretty automatic.  I expect the RSAB to seek input from their constituencies in addition to reviewing community feedback and the RSWG response for sufficiency.
> 
> Or?

For the reason that we don’t ask WG chairs to manage an IETF-wide last call, but rather task the IESG with doing it. If you want to get broad community feedback, you make it the responsibility of those representing the broader communities in the process to ask for feedback. In this case, that’s the RSAB, as the stream representatives. 

And yes, in many cases, that devolves into rsab-secretary@ sends email to the same set of lists the RSWG chairs would have sent email to. But for the more interesting cases, the RSAB members – as community representatives – have the incentive to seek out feedback from their community more broadly than the RSWG chairs who are not embedded in that community.

-- 
Colin Perkins
https://csperkins.org/

---

From: Eliot Lear <[email-masked]>
Date: Sat, 6 Nov 2021 13:02:10 +0100

We'll discuss this point this week.

As a practical matter, I would expect the tooling to kick in such that 
once the chairs have sent the document to the RSAB it just goes out for 
community review (whether from the RSAB chairs or RSWG chairs).  The 
more important point is who you want to interpret the feedback, and 
there we're saying that it's the RSWG in the first instance.  Only an 
appeal of lack of consensus (e.g. failure to follow process) would bring 
the issue to the RSAB.

To me, what this means is that what is more important than who issues 
the call is the wording of the call itself: it must be made clear to 
community members that to have their views noted, they need to 
participate in RSWG discussions.  Simply replying the RSAB has NO 
effect, as things are currently stated.

Eliot

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 7 Nov 2021 08:42:20 +1300

> effect, as things are currently stated.

I agree that the community last call discussion must take place in public,
which in practice means via the RSWG list or the rfc-interest list.
The RSAB shouldn't have a pocket veto (any more than the IESG). But I
think Colin is correct; by symmetry with IETF and IRTF practice, the
approving body should issue the last call. Otherwise, we don't have
effective checks and balances.

     Brian

>>> This is where I'm not getting you.  Community last calls go to the community regardless of who issues the calls.  I would expect there will be 
one or more mailing lists that will get the last call on things from the RFC series process and those will be well known and pretty automatic.  I expect the RSAB to seek input from their constituencies in addition to reviewing community feedback and the RSWG response for sufficiency.
>>>
>>> Or?
>>
>> For the reason that we don’t ask WG chairs to manage an IETF-wide last call, but rather task the IESG with doing it. If you want to get 
broad community feedback, you make it the responsibility of those representing the broader communities in the process to ask for feedback. In this 
case, that’s the RSAB, as the stream representatives.
>>
>> And yes, in many cases, that devolves into rsab-secretary@ sends email 
to the same set of lists the RSWG chairs would have sent email to. But for the more interesting cases, the RSAB members – as community representatives – have the incentive to seek out feedback from their 
community more broadly than the RSWG chairs who are not embedded in that community.

---

From: Michael StJohns <[email-masked]>
Date: Sun, 7 Nov 2021 12:49:07 -0500

> For the reason that we don’t ask WG chairs to manage an IETF-wide last call, but rather task the IESG with doing it. If you want to get broad community feedback, you make it the responsibility of t…

And that's where you run off the rails.  The RSWG and the RSAB BOTH 
represent exactly the same broad community.  As I noted before, the RSWG 
is NOT an IETF WG and the reasons for passing on last call to the IESG 
from the WG do not apply here - basically the RSWG and the RSAB have 
exactly the same domain of interest. If you disagree with that 
statement, I'd like to understand how you think how the RSAB has an 
enclosing domain to the RSWG given ALL the various discussions we've had.

> And yes, in many cases, that devolves into rsab-secretary@ sends email to the same set of lists the RSWG chairs would have sent email to. But for the more interesting cases, the RSAB members – as c…
In what scenario would you expect the RSAB members to ignore their 
community (and the RSAB collectively ignore the Community) when 
evaluating a document and its "legislative history" including the last 
call info?

I don't see it and I'd be surprised if you could craft such a scenario.

Of course, its always possible for the RSAB to be composed of a lazy set 
of gits (github pun crossed with british slang intended) and completely 
fail to meet their responsibilities, but I fail to see how placing the 
last call in their hands including the responsibility for pushing it 
back to the RSWG to fix things (which AIRC doesn't map well to the 
permitted vote types) would prevent that in any case.

Later, Mike

---

From: Michael StJohns <[email-masked]>
Date: Sun, 7 Nov 2021 12:49:25 -0500

On 11/6/2021 3:42 PM, Brian E Carpenter wrote:
> the

This is both cargo cult (doing it the way we've always done it because 
that's the way we've always done it) and a non sequitur.    And still 
not supported by any valid analysis.

So - let's assume we make the change I propose and the RSWG does:

1) Write the document

2) Issue WG last call

3) Resolve WG last call either simply or requiring another round of 
debate and the submission of a new document and a new last call.

4) Issues community last call

5) Resolves (or fails to resolve) community issues and either goes to 
step 2, step 4, or step 6 depending.

The RSAB does

6) Evaluates the output from step 5 and approves or refers the document 
back to the RSWG to *really* address the community issues which are 
right there on the public mailing list for all to see and can't be 
ignored by the RSWG.

So I'm still missing how "we don't have effective checks and balances" 
given that the RSAB still has to evaluate the output of the community 
last call.

Would you care to explain a scenario where C&B fails here?

Later, Mike.

---

From: Eliot Lear <[email-masked]>
Date: Sun, 7 Nov 2021 19:03:02 +0100

Mike, perhaps we really do have some problem in the draft, because you 
and I are reading it differently.  Please see below.

On 07.11.21 18:49, Michael StJohns wrote:
>
>
> The RSAB does
>
> 6) Evaluates the output from step 5 and approves or refers the 
> document back to the RSWG to *really* address the community issues 
> which are right there on the public mailing list for all to see and 
> can't be ignored by the RSWG.

What the draft says is this:

> community call for comments as further described in Section 3.2.3 
> <https://intarchboard.github.io/program-rfced-future/draft-iab-rfcefdp-rfced-model.html#cfc>.
>
> 7. If substantial comments have been received, the RSWG will again 
> consider those comments and make revisions as they see fit. At this 
> same time, the RSAB will also consider the proposal.If substantial 
> changes have been made, additional community calls for comment should 
> be issued by the RSAB, and again comments considered by the RSWG.
>
> 8. Once all comments have been addressed, the RSWG chairs will submit 
> the proposal to the RSAB for its consideration.
>
Nowhere does this draft state that the RSAB evaluates community 
comments.  In particular, that reason doesn't appear in the enumerated 
reasons an RSAB member may object.  Currently, as the draft reads to me, 
the RSAB can only consider a lack of consensus within the RSWG itself if 
someone appeals to the RSAB on that basis (failure of process).

But this actually supports your logic.  The reason that the IESG sends 
out a call is that THEY evaluate community feedback, not an IETF WG.

If we want the RSAB to evaluate community consensus, the draft should be 
far clearer on that point.

Eliot

---

From: Colin Perkins <[email-masked]>
Date: Sun, 7 Nov 2021 18:13:44 +0000

> On 7 Nov 2021, at 17:49, Michael StJohns <[email-masked]> wrote:
> And that's where you run off the rails.  The RSWG and the RSAB BOTH represent exactly the same broad community.  As I noted before, the RSWG is NOT an IETF WG and the reasons for passing on last call to the IESG from the WG do not apply here - basically the RSWG and the RSAB have exactly the same domain of interest. If you disagree with that statement, I'd like to understand how you think how the RSAB has an enclosing domain to the RSWG given ALL the various discussions we've had.

I strongly disagree with that statement.

The RSWG comprises the small subset of the community that cares about process issues. The chairs of the RSWG have the goal of concluding the work done by that group, and have little incentive to seek input from the wider community.

The RSAB members are appointed by the broader community, and represent that broader community in the RSWG. If they believe the RSWG is doing something that warrants more extensive community review, they have an incentive to seek out that wider review. 

Having the RSAB run the community call for comments is an essential check against an RSWG that’s unrepresentative of the broader community.

> In what scenario would you expect the RSAB members to ignore their community (and the RSAB collectively ignore the Community) when evaluating a document and its "legislative history" including the last call info?
> 

The scenario I was crafting was the exact opposite, where the RSWG is ignoring the wider community.

-- 
Colin Perkins
https://csperkins.org/

---

From: Michael StJohns <[email-masked]>
Date: Sun, 7 Nov 2021 13:16:36 -0500

On 11/7/2021 1:03 PM, Eliot Lear wrote:
>> So I'm still missing how "we don't have effective checks and 
>> balances" given that the RSAB still has to evaluate the output of the 
>> community last call. 
>
>
> reasons an RSAB member may object.  Currently, as the draft reads to 
> me, the RSAB can only consider a lack of consensus within the RSWG 
> itself if someone appeals to the RSAB on that basis (failure of process).
>
> If we want the RSAB to evaluate community consensus, the draft should 
> be far clearer on that point.
>
> Eliot
>
If you're saying that the RSWG can ignore community consensus and the 
RSAB has to approve the documents anyway, then there *really* is a 
problem with the document.

As far as the above is concerned, who issues the call in (6) has no 
difference on what the RSWG has to do in (7).

Later, Mike

---

From: Eliot Lear <[email-masked]>
Date: Sun, 7 Nov 2021 20:38:21 +0100

Hi Mike,

Keep in mind: I am not taking a position on what SHOULD be, but merely 
stating what I think the document says.  Please see below.

> problem with the document.
In my interpretation of what is written, nowhere does the RSAB get to 
interpret community consensus.   The RSAB only passes judgment on a 
document based on potential harm to a stream or potential harm to the 
overall health of the series, and not whether there is community consensus.

Community members who object need to be counted for/against the 
consensus by the RSWG chairs.  The RSAB only gets their say if the 
chairs have clearly erred in their calling of consensus, one way or 
another, and their decision is appealed.

If we want the RSAB to interpret community consensus during the 
community call, we should say that.  We do not currently do so.

Eliot

Eliot

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 8 Nov 2021 08:39:57 +1300

On 08-Nov-21 07:13, Colin Perkins wrote:
>> And that's where you run off the rails.  The RSWG and the RSAB BOTH represent exactly the same broad community.  As I noted before, the RSWG is 
NOT an IETF WG and the reasons for passing on last call to the IESG from the WG do not apply here - basically the RSWG and the RSAB have exactly the same domain of interest. If you disagree with that statement, I'd like 
to understand how you think how the RSAB has an enclosing domain to the RSWG given ALL the various discussions we've had.
> Having the RSAB run the community call for comments is an essential check against an RSWG that’s unrepresentative of the broader community.

Exactly. That is the check and balance. IMHO what the draft already says is appropriate and does not need need changing.

     Brian

>> In what scenario would you expect the RSAB members to ignore their community (and the RSAB collectively ignore the Community) when evaluating a 
document and its "legislative history" including the last call info?

---

From: "StJohns, Michael" <[email-masked]>
Date: Sun, 7 Nov 2021 15:11:02 -0500

I’m on my iPad so this is short.

I consider not resolving community consensus  (or for that matter not
asking for and incorporating community comment) to be a failure of process
and as such is one of the reasons the RSAB can reject a document.

Mike

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 7 Nov 2021 16:01:37 -0800

This document seems like it's generally in pretty good shape. Some
comments below.

   *  The RSAB considers those proposals and approves them, returns them
      to the RSWG for further consideration, or declines to publish
      them, as appropriate.

It's actually not quite clear to me that the RSAB can decline to
publish as distinct from just sending the proposal back. What
would that consist of?

   *  If issues arise with the implementation of particular policies,
      the RPC brings those issues to the RSAB, which interprets the
      policies and provides interim guidance to the RPC, informing the
      RSWG of those interpretations.

Is this appealable?

   The RSWG shall operate by rough consensus, a mode of operation
   informally described in [RFC7282].

Please do not cite 7282 in this way. The content does not
have IETF consensus. Just remove the cite.

S 3.1.2.

   *  As the stream representative for the IETF stream, an IESG member
      or a member of the community selected by the IESG

   *  As the stream representative for the IAB stream, an IAB member or
      a member of the community selected by the IAB

Could we simplify this to be "any person selected by the IAB"? That
seems to be what it says.

shall choose?

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

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

I actually don't think this is appropriate for the RPC to decide on
either of these matters. They should be decided by the community.

S 5.1.
   The IETF LLC will form a selection committee, including members from
   the community, that will be responsible for making a recommendation
   to the IETF LLC for the RSCE role.  The selection committee will take
   into account the role definition (https://github.com/intarchboard/
   program-rfced-future/blob/master/Issue12-RSE-role.md) as well as any
   other information that the committee deems necessary or helpful in
   making its decision.  The IETF LLC is responsible for contracting or
   employment of the RSCE.

This link will be a problem, as it is not stable.

On Fri, Oct 22, 2021 at 1:13 AM Eliot Lear <[email-masked]> wrote:

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

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 8 Nov 2021 13:08:15 +1300

> have IETF consensus. Just remove the cite.

Better, cite RFC2418, in particular https://www.rfc-editor.org/rfc/rfc2418.html#section-3.3

    Brian

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 7 Nov 2021 16:14:45 -0800

Agreed. Thanks for reminding me of that.

On Sun, Nov 7, 2021 at 4:08 PM Brian E Carpenter <
[email-masked]> wrote:

> Better, cite RFC2418, in particular
> https://www.rfc-editor.org/rfc/rfc2418.html#section-3.3
>
>     Brian
>
>

---

From: Eliot Lear <[email-masked]>
Date: Mon, 8 Nov 2021 06:59:10 +0100

Thanks, Eric.  I am opening three additional issues based on your 
review.  Please see below.

> publish as distinct from just sending the proposal back. What

Issue 132, not editorial.

I think you're identifying an issue in terms of what happens if there is 
a vote, and there are not three votes to approve a proposal (bottom of § 
3.2.2).  This document doesn't say what happens.  I think what we mean 
to say is this:

> If a vote is taken and the proposal is not approved, it is returned to 
> the RSWG.  The RSWG can then decide whether to attempt to make further 
> changes that would overcome RSAB concerns.

That would match the intro text you quote.

>       RSWG of those interpretations.

Martin has addressed this in his proposal for issues 93 and 94.

> have IETF consensus. Just remove the cite.

Issue 131.  I'm noting Brian's suggestion here.  Editorial.

> seems to be what it says.

Issue #133.  Editorial.  Consistency across streams should be maintained.

>    chair's term, the RSAB should choose a new chair from among its

Issue 130.  Editorial.

"chooses"?  I think Peter is avoiding 2119 language.

> either of these matters. They should be decided by the community.

Mark has opened PR#101 on this.  Please also see his comments.

> This link will be a problem, as it is not stable.

Peter has changed this in his working copy.

Eliot

---

From: Martin J. Dürst <[email-masked]>
Date: Mon, 8 Nov 2021 15:31:55 +0900

Hello Eric, others,

A few comments inline, not all directed at Eric. Text unrelated to my 
comments cut out (I wish more people would take the time to do that).

>        RSWG of those interpretations.

Interesting 'find'. This 'interim guidance' seems close to the 
'statement' discussed in another thread. The main difference seems to be 
that this is only on request. So in theory, if RSWG/RSAG create an RFC 
that asks for a "subscription form of access to newly publish RFCs", 
then the RPC could ask "did you mean RSS or Atom or something else". But 
that's predicated on the LLC not already having made the decision.

> seems to be what it says.

Almost, but not exactly, at least the way I understood it. I think what 
we wanted was something close to

  *  As the stream representative for the IETF stream, preferably
     an IESG member, or otherwise a member of the community selected
     by the IESG

(and likewise for the IAB). Maybe we need to make that explicit, or 
decide it's not what we meant.

> either of these matters. They should be decided by the community.

I agree, mostly. I wouldn't want the RSWG/RSAG to have to discuss each 
and every XML element and attribute. But I would expect some of the 
discussions to get fairly close to that.

My example would be the extension of the allowed characters in RFCs. 
This is both something that has happened recently (in relation the 
overall RFC　history) and that might happen again in the future 
(allowing a wider range of non-ASCII characters in a wider range of 
locations in an RFC with less ASCII explanations).

Let's assume that everybody here agrees that the general policy change 
(allow more than only ASCII in RFCs) is something the RSWG/RSAG would 
have done in an Editorial RFC. Having been involved in the relevant 
discussions, I cannot imagine such a thing to have happened without 
discussing things in quite some detail, in order to address the many and 
varied concerns that people have/had. And I cannot imagine the resulting 
RFC to have just read "allow more than only ASCII in RFCs", because that 
would have left the fear of going too far in many of the participants.

Regards,   Martin.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 8 Nov 2021 03:27:46 -0800

> That would match the intro text you quote.

Yes, this seems reasonable.

I suppose that there might be some cases where this is impossible because
the RSAB objects to the whole concept of the document, but even then it's
possible some massive revision would be acceptable and determining whether
it's the "same" document doesn't really matter (ship of Theseus, etc.)

> Martin has addressed this in his proposal for issues 93 and 94
>

You mean https://github.com/intarchboard/program-rfced-future/pull/101/?
This seems to actually be mnot, so I wasn't sure.

> Issue #133.  Editorial.  Consistency across streams should be maintained.

I agree that this is editorial, but the other bullets read differently
anyway.

> "chooses"?  I think Peter is avoiding 2119 language.

Well, it uses "shall" elsewhere. With that said, I note that this document
doesn't
cite either 2119 or 8174. Should it?

> Mark has opened PR#101 on this.  Please also see his comments.

Yes this seems reasonable.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 8 Nov 2021 03:29:26 -0800

> decide it's not what we meant.

I don't think the current text expresses a preference, and I don't think we
should
do so.

> discussions to get fairly close to that.

Well, I also don't want the RPC to decide it unilaterally. So perhaps we
need some other process for that (which RSWG could invent).

-Ekr

---

From: Eliot Lear <[email-masked]>
Date: Mon, 8 Nov 2021 14:39:07 +0100

Hi EKR,

On 08.11.21 12:27, Eric Rescorla wrote:
> You mean 
> https://github.com/intarchboard/program-rfced-future/pull/101/? This 
> seems to actually be mnot, so I wasn't sure.

That's different.  What the document says is that process issues are 
appealable to the IAB.  What Martin is proposing is that when it comes 
to interim decisions, the content is appealable to the IAB.

> Well, it uses "shall" elsewhere. With that said, I note that this 
> document doesn't

Reading it back, probably.  Others?

Eliot

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 8 Nov 2021 06:15:13 -0800

On Mon, Nov 8, 2021 at 5:39 AM Eliot Lear <[email-masked]> wrote:

> appealable to the IAB.  What Martin is proposing is that when it comes to
> interim decisions, the content is appealable to the IAB.
>

i don't see that proposal. Can you send a link?

-Ekr

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 9 Nov 2021 08:35:18 +1300

On 09-Nov-21 00:27, Eric Rescorla wrote:

> Well, it uses "shall" elsewhere. With that said, I note that this document doesn't

Please not. The English language is perfectly suitable on its own for procedural documents.

     Brian

---

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

> The second phase is already used once in the document and I think it would be more correct to use it everywhere.

As document editor, I think this is an improvement.

Peter

---

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

I tried to make this distinction through the phrasing in the current 
draft, but "working practices" is much clearer - thanks, Brian!

On 10/27/21 4:00 AM, Eliot Lear wrote:
> 
> Does anyone NOT like it?
> 
> Diff below.
> 
> Eliot
> 
> 
> -## Implementation-Specific Policies
> +## Working Practices
> 
> -Under and consistent with the high-level policies defined for the RFC
> -Series in general or particular streams, the RPC shall define more
> -particular policies regarding matters related to the editorial preparation
> +In the absence of a high-level policy documented in an RFC, or to 
> specify the
> +detail of its implementation, the RPC can
> +document working practices regarding the editorial preparation
>   and final publication and dissemination of RFCs. Examples include:
> 
>   * Maintenance of a style guide that defines editorial standards to which
> -  RFCs must adhere (see {{RFC7322}} and the
> -  [style guide web page](https://www.rfc-editor.org/styleguide/)).
> +  RFCs must adhere (see the
> +  [style guide web page](https://www.rfc-editor.org/styleguide/), which
> +  extends {{RFC7322}).
> 
>   * Policies regarding the file formats that are accepted as input to the
>     editing and publication process.
> 
> documents.
>     In the context of the XML vocabulary ({{RFC7991}}), such policies could
> -  include matters such as the exact XML elements and attributes used to
> -  capture the semantic content of RFCs. More generally, such policies
> -  could address the readability and presentation of information in RFCs.
> +  include clarifications regarding XML elements and attributes used to
> +  capture the semantic content of RFCs.
> 
>   ## RPC Responsibilities
> 
> Eliot
> 
> On 27.10.21 05:12, Mark Nottingham wrote:
>> I like it; done.
>>
>>
>>> On 27 Oct 2021, at 2:10 pm, Brian E Carpenter 
>>> <[email-masked]> wrote:
>>>
>>> On 27-Oct-21 12:30, Mark Nottingham wrote:
>>>> Hi Stephen,
>>>> FWIW I think the current text encourages such things even more 
>>>> strongly.
>>>> I agree that the RPC setting policies willy-nilly is concerning, but 
>>>> I also acknowledge that the reality is that they'll need to in some 
>>>> circumstances, else many RFCs will be delayed indefinitely while the 
>>>> RSWG and RSAB chew on an ever-increasing pile of problems.
>>>> A few things we can do to ameliorate that:
>>>> - Make it clear that RPC policies are temporary and subject to 
>>>> review by the RSWG
>>>> - Make it clear that RPC polices are not pre-emptive; although 
>>>> persuasive, they can be overridden by the RSWG
>>>> - Limit the scope of RPC policies
>>>> I think all three are implied by the current text and the proposal, 
>>>> but could be clarified.
>>> If you s/working policies/working practices/ I think it will make the 
>>> intent clear
>>> without undercutting the RSWG/RSAB policy role.
>>>
>>>    Brian
>>>
>>>> Cheers,
>>>>> On 27 Oct 2021, at 10:22 am, Stephen Farrell 
>>>>> <[email-masked]> wrote:
>>>>>
>>>>>
>>>>> Hi Mark,
>>>>>
>>>>> On 27/10/2021 00:12, Mark Nottingham wrote:
>>>>>> How about: 
>>>>>> https://github.com/intarchboard/program-rfced-future/pull/101
>>>>> Apologies if I'm getting the githubbery differy wrong but
>>>>> your suggestion seems to add:
>>>>>
>>>>> "In the absence of a high-level policy documented in an RFC,
>>>>> or to specify the detail of its implementation, the RPC can
>>>>> define working policies regarding the editorial preparation
>>>>> and final publication and dissemination of RFCs."
>>>>>
>>>>> My starting point is to be strongly opposed to that as it
>>>>> puts the RPC in the position of initiating, and being the
>>>>> proponent for, policy changes. That seems to me to be the
>>>>> opposite of where we want to be, despite the inefficiency
>>>>> of where we are:-)
>>>>>
>>>>> Cheers,
>>>>> S.
>>>>>
>>>>>> Cheers,
>>>>>>> On 27 Oct 2021, at 3:03 am, Eliot Lear <[email-masked]> wrote:
>>>>>>> On 26.10.21 05:16, Martin Thomson wrote:
>>>>>>>>> 2) Section 4.2 seems to put the XML format under the exclusive
>>>>>>>>> control of the RPC. Is that really our intent? Likewise for the
>>>>>>>>> 'readability and presentation of RFCs'.
>>>>>>>> I didn't read that text in that way, but in looking again, it
>>>>>>>> could be clearer.
>>>>>>> Again, my favorite question: do you have a preferred correction?
>>>>>>> Eliot
>>>>>> -- Mark Nottingham   https://www.mnot.net/
>>>>> <OpenPGP_0x5AB2FAF17B172BEA.asc>
>>>> -- 
>>>> Mark Nottingham   https://www.mnot.net/
>> -- 
>> Mark Nottingham   https://www.mnot.net/
>>
>>
>

---

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

>> process has to be followed then.

For the avoidance of doubt, we might want to say "the currently 
appointed RSCE" or some such.

Peter

---

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

Hi Colin, thanks for the careful review. I agree with most of your 
feedback and will reply in greater detail after our meeting this week, 
since IMHO these matters don't require discussion there.

---

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

On 11/8/21 4:29 AM, Eric Rescorla wrote:
> 
> On Sun, Nov 7, 2021 at 10:31 PM Martin J. Dürst <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 

<snip/>

> need some other process for that (which RSWG could invent).

When writing that text, I had in mind the sorts of things that come up 
mostly within the editing team itself. Example: authors often structure 
tabulated information as <artwork/> because they can't figure out how to 
make an actual table work, but the editors would prefer to structure 
that information using the <table/> element. However, I see that the 
text as written is overly broad, so I'll propose tighter language.

Peter

---

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

On 11/4/21 4:04 PM, Michael StJohns wrote:
> (sections titled "Editorial Policy" and "Quality of Documents"). 

Do you mean this?

https://www.rfc-editor.org/materials/FinalReport-CY2002-Mar2007.pdf

>  I 

In principle I have no objections to specifying some principles. ;-)

Interestingly, versions 1 and 2 of the RFC Editor Model didn't specify 
such principles, although they do mention some relevant considerations 
such as document quality and accessibility. Life went on and RFCs 
continued to be published in a reasonable fashion.

In addition, RFC 8729 mentions principles such as expert implementation, 
clear management and direction, and appropriate community input (which 
we borrowed for the introduction to our document).

As far as I can see, the ISI report you reference expresses some 
opinions (e.g. "ISI strongly believes that it is important to minimize 
the number of errors in published documents") that don't necessarily 
reflect consensus from within the IETF or RFC communities. I do wonder 
whether this is the time or place to work out such principles, or 
whether that's something the RSWG should do once it's formed.

Peter

---

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

> Goes into my preferred active vocabulary right away…

Oh yes, I can think of many uses for this one!

> "The RSCE provides expert advice to the RPC and RSAB on how to implement established policies”.  I would like to make explicit that it is very much the job of the RSCE to watch the actual impact of…

Section 5 does state that the primary responsibilities of the RSCE include:

    *  Identify problems with the RFC publication process and
       opportunities for improvement

    *  Provide expert advice regarding policy proposals within the RSWG

Do you think we need to expand those descriptions?

> Others have already commented on the strangely passive role afforded to the RSCE by this document (5: “if requested”, “be consulted”), which needs to be fixed. 

The responsibilities mentioned above don't seem passive to me. But Eliot 
made a few suggestions (e.g., remove "if requested") that seemed good.

> Also, it looks like the power of the RSE has to a large part been transferred to whoever calls the shots at the RPC (e.g., see 4.4). 

Section 4.4 is about document-specific disagreements about the 
application of existing policies (or highly constrained, temporary 
workarounds or decisions when there are gaps in existing policies). That 
doesn't strike me as the "power of the RSE" as traditionally exercised, 
which IMHO is more related to policy definition - the very things that 
we're now investing in the community via the RSWG.

> I have a lot of trust in the people who are performing this function now, but policies are made to reduce the need for unconditional reliance on such trust.

Isn't that the entire point of this Program?

> Both the RPC and the RSCE ultimately report to the IETF Admin LLC.  Diving a bit deeper into what some may think of as paranoia, these contractual relationships cannot be out in the open, and clear…

I'm not qualified to speak about these matters (e.g., the extent to 
which U.S. law requires that "these contractual relationships cannot be 
out in the open").

Peter

---

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

Just to make sure --

> On 10 Nov 2021, at 2:05 pm, Peter Saint-Andre <[email-masked]> wrote:
> 

I hope that we can agree that this is not the exclusive purview of the RSCE. 

Cheers,

---

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

> On 10/11/2021, at 2:36 PM, Peter Saint-Andre <[email-masked]> wrote:
> 
> For the avoidance of doubt, we might want to say "the currently appointed RSCE" or some such.

"the RSCE" cannot mean anything else but I don’t object to this change.

Jay

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

---

From: Eliot Lear <[email-masked]>
Date: Wed, 10 Nov 2021 12:46:30 +0100

> I hope that we can agree that this is not the exclusive purview of the RSCE.

I really couldn't imagine otherwise.

Eliot

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 10 Nov 2021 07:55:00 -0700

> I really couldn't imagine otherwise.

Mark, do you think text is needed on this point?

Peter

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 11 Nov 2021 01:57:58 +1100

I've seen people interpret the word 'responsibility' in different ways which might need clarification. So, perhaps.

> On 11 Nov 2021, at 1:55 am, Peter Saint-Andre <[email-masked]> wrote:
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 10 Nov 2021 08:04:35 -0700

OK, I'll attempt clarifications in -06 and share text on list beforehand.

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 16 Nov 2021 14:01:19 -0700

Thanks again, Colin. Comments inline where necessary (I've elided items 
that I've already already addressed elsewhere).

<snip/>

> The IRTF lacks the explicit requirement for consensus that exists in IETF, so it might be clearer to just use the IETF as the example here.

Agreed.

> The phrase “defined in the open” could be clearer. Maybe “defined through open and public discussion” or similar?

Agreed.

> “generated by..the RSWG” - implies that proposals can only be generated by the group, but we also want to allow proposals to originate elsewhere and submitted to the RSWG for discussion.

My working text now reads as follows (incorporating feedback from others 
as well):

###

Policies governing the RFC Series as a whole are defined via open and
public discussion through proposals that are adopted by and discussed
within the RFC Series Working Group (RSWG), that pass a last call for
comments in the working group and broader community, and that are then
approved by the RFC Series Approval Board (RSAB).

###

> The combination of these can be read as open to any participant in the IETF and IRTF. Perhaps “All RSWG meeting shall be open to all interested persons” to match the later text?

Agreed.

> In cases where the IRTF Chair or ISE appoints a delegate, this section uses the term "appointing body” to refer to both the IRTF Chair/ISE, as the appointing body for the RSAB delegate, and to the…

I propose:

###

The appointing bodies, i.e., the stream approval bodies (IESG, IAB,
IRTF chair, ISE), shall determine their own processes for
appointing RSAB members (note that processes related to the RSCE
are described in {{rsce}}). Each appointing body shall have the power
to remove its appointed RSAB member at its discretion at any time.
Appointing bodies should ensure that voting members are seated at
all times and should fill any vacancies with all due speed, if
necessary on a temporary basis.

In the case that the IRTF chair or ISE is incapacitated or otherwise
unable to appoint another person to serve as a delegate,
the IAB (as the appointing body for the IRTF chair and ISE
respectively) shall act as the temporary appointing body for those
streams and shall appoint a temporary member of the RSAB until the
IAB has appointed an IRTF chair or ISE, who can then act as an
RSAB member or appoint a delegate through normal processes.

###

> Implies that new streams will be created. It should perhaps be “If a new stream is created”.

I like "If and when..."

> Is it possible for the RSAB chair to step down from the chair role, but remain on the RSAB as a stream representative?

I see no reason why not.

> If the RSAB chair position is vacated because the representative steps down from the RSAB, is there a requirement that the RSAB wait for their replacement to be appointed before selecting a new cha…

I don't think so.

> “An individual participant” - unclear if this is intended to exclude the RSAB members and RSWG chairs, or if they are allowed to submit as individuals but not as holders of those roles. I assume th…

That wording also doesn't include the possibility of multiple authors. I 
suggest:

###

1. An individual or set of individuals generates a proposal in the form
    of an Internet-Draft (which must be submitted in full conformance
    with the provisions of BCP 78 {{RFC5378}} and BCP 79 {{RFC8179}})
    and asks the RSWG to adopt the proposal as a working group item.

###

> Bullet 3 in Section 3.2.2 explicitly calls out that the RSWG chairs are also expected to participate as individuals. Given that, it would be useful to also highlight here that RSAB members are also…

See above.

> Are the RSWG chairs expected to publicly announce the outcome of the last call?

Good point. I suggest that we add a sentence like this:

    Once the chairs determine that consensus has been
    reached, they shall announce their determination on the RSWG
    discussion list and forward the document to the RSAB.

> “At this same time, the RSAB will also consider the proposal” - at which time? Unclear if this is while the community call for comments is ongoing, while the RSWG is revising the draft, or after th…

Here's what I have now:

###

6. Once consensus is established in the RSWG, the RSAB shall issue a
    community call for comments as further described in {{cfc}}. If
    substantial comments are received in response to the community
    call for comments, the RSAB may return the draft to the RSWG to
    consider those comments and make revisions to address the feedback
    received. In parallel with the community call for comment, the RSAB
    shall also consider the proposal.

###

> This seems that it should happen before step 6, to trigger the RSAB to look at the document and issue the community call for comments.

See text above.

> Step 8 would seem better phrased as the RSWG chairs confirming that that believe comments have been addressed and the document is ready for RSAB ballot.

That seems reasonable. How about this?

8. Once the RSWG chairs confirm that feedback received during the
    community call(s) for comment has been addressed, they shall
    inform the RSAB that the document is ready for balloting by the
    RSAB.

> Is an RSAB member permitted to file a CONCERN ballot if they believe a proposal represents a serious problem for one of the other streams? 

We could say:

    * The proposal represents a serious problem for one or more of
      the individual streams.

> I’d expect that such issues would be resolved by discussion between the RSAB members leading to the representative for the stream concerned raising a CONCERN, but what happens if there is disagreement amongst the RSAB members?

Well, there always might be disagreement. What exactly do you have in 
mind? Something like the IRTF representative raising a CONCERN about the 
impact on the Independent stream, but the ISE disagreeing?

> I agree with the intent, but the phrasing allows for bad-faith accusations of surprise. Perhaps something like "RSAB members are expected to participate in the discussions within the RSWG, and rais…

WFM.

> It’s possible that an RSAB member will be made aware of an issue late in the process that would lead to them issuing a CONCERN. It’s obviously desirable if concerns are raised early, but that can’t…

Agreed. I'll add something like this:

   Notwithstanding, late CONCERN positions are always possible
   if issues are identified during RSAB review..

> Also, “have been made” -> “are made"

Agreed.

> I’m not entirely happy with this, but accept the consensus. However, we also allow for additional streams to be created with their own voting members. If that happens, does this threshold change? I…

We had some discussion about that on list and didn't find a solution 
that addressed this concern. We could, of course, punt this to the 
future: if another stream is created, the RFC that does so could also 
update this document regarding the number of YES votes needed for approval.

Yes.

> I agree that the policy should apply, but the linked IESG statement and RFCs are very IETF specific. Do they need updating to explicitly include the RSWG?

Maybe? The program chairs should talk with the IESG about this.

> Needs clarification: changes to the roles and responsibilities of the RPC will be defined in this way. The existing roles and responsibilities remain and are not defined by Editorial stream RFCs (s…

I think this was fixed by addressing feedback from someone else.

> Are there any constraints on who the LLC can appoint or on the membership of the committee they may convene? Performance targets can be a contentious issue.

I defer to Jay on this topic.

> This section seems perhaps under-specified. Based on past history, I expect the RPC will no something reasonable, but the boundaries of its authority to set policy are not well defined here.

We're trying to find the right balance between specifying too much and 
too little. Do you have suggestions for improvement?

> Section 4.4, 1st paragraph: "IRSG research group chair” -> “IRTF research group chair”

ACK

> Might be clearer as “…will produce a draft evaluation of the RSCE’s performance for review by the RSAB…”?

Sure.

> I still think this section needs to be explicit that Experimental RFCs cannot be published on the Editorial stream, rather than leaving it implied.

I'd rather not re-open that can of worms.

> The content of the Appendix is fine, modulo the nits below, but I would like to see it moved to a main section of the document to make it clear that its contents are as normative as those in the re…

That's fine with me.

> The phrasing in this section is imprecise: “abolishes”, “disbands”, or “disestablishes” would be clearer.

In another thread we settled on "disbands".

> "For the avoidance of doubt, this document affirms that the RSAG is obsolete and its charter is no longer in force” – there seems a strange reluctance to be explicit here: the RSAB has been abolish…

I think we can use "disbanded" here as well.

Peter

---

From: Eliot Lear <[email-masked]>
Date: Tue, 16 Nov 2021 22:06:10 +0100

Just on this:

On 16.11.21 22:01, Peter Saint-Andre wrote:
>> I agree that the policy should apply, but the linked IESG statement 
>> and RFCs are very IETF specific. Do they need updating to explicitly 
>> include the RSWG?
>

I think the only issue here is whether the ombudspeople will take up 
issues from this group.  They might be quite busy.  It is good to 
confirm as we iron out other details.

Eliot

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 16 Nov 2021 22:03:01 -0000

Yes, RFC 7776 was deliberately scoped to “the IETF”.

Might I suggest that, whether or not the RSWG forms part of the IETF, if its business is conducted on an email list hosted by the IETF and if its meetings are conducted as part of IETF meetings, then that will be covered by RFC 7776.

Colin can probably explain how the IRTF has handled the issue and we can adopt that approach.

Cheers,

Adrian

From: Rfced-future <[email-masked]> On Behalf Of Eliot Lear
Sent: 16 November 2021 21:06
To: Peter Saint-Andre <[email-masked]>; Colin Perkins <[email-masked]>
Cc: [email-masked]
Subject: Re: [Rfced-future] **Program Last CALL: draft-iab-rfcefdp-rfc-model-05** Ends 5 Nov 2021

Just on this:

I think the only issue here is whether the ombudspeople will take up issues from this group.  They might be quite busy.  It is good to confirm as we iron out other details.

Eliot

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 16 Nov 2021 15:46:38 -0700

Thanks, Mike, I have a question for Jay on one point at the end.

> unmanageable COI for the RSCE.

Jay, what is your perspective on this?

Peter

---

From: Colin Perkins <[email-masked]>
Date: Tue, 16 Nov 2021 23:00:45 +0000

> On 16 Nov 2021, at 22:03, Adrian Farrel <[email-masked]> wrote:
> 

The IRTF has handled this by stating that the IETF anti-harassment policy applies, and informally involving the ombudsteam when needed. Pete Resnick and I have been talking about the need to formalise this, however, via a document updating RFC 7776. That’s on my to-do list to prepare.

(The situation for IRTF is a little more complex than that for the RSWG, since the IRTF also has to specify the intersection with SIGCOMM CARES for the ANRW.)

Colin

---

From: Michael StJohns <[email-masked]>
Date: Tue, 16 Nov 2021 18:07:51 -0500

> Jay, what is your perspective on this?

This is from Jay's 5 November email.

> things they won't necessarily be good at.  Given how few good 
> technical editor/publisher candidates I expect we'll get I think we 
> need to make clear that the LLC shouldn't COI the RSCE from work 
> subcontracted from the RPC.    Open an issue?
>
>     I can’t see on what basis a COI would be imposed and both the RPC
>     and RSCE are working to a common goal. The RPC contract doesn’t
>     allow for any sort of project fund for the RPC to spend
>     independently so if the RPC wanted the RSCE to do extra contracted
>     work then I doubt the RPC would subcontract with them directly but
>     rather negotiate with the LLC for the LLC to add a SoW to the RSCE
>     contract.  Maybe there might be a situation where the RPC has a
>     staff shortage and wants to directly contract the RSCE to backfill
>     but that still wouldn’t be a COI.
>
AIRC, you're not buying bodies from the RPC, but services.  That 
suggests that subcontracting can happen to meet their contracting 
needs.  Either adding tasks to the SOW via the LLC or having the person 
filling the RSCE role work directly for the RPC for somethings are both 
reasonable and legal approaches.  The former would by definition not 
cause a COI, the latter shouldn't but the LLC could be sticky about it.

Mike

---

From: Jay Daley <[email-masked]>
Date: Wed, 17 Nov 2021 12:15:35 +1300

On 17/11/2021, at 12:08 PM, Michael StJohns <[email-masked]> wrote:
> AIRC, you're not buying bodies from the RPC, but services.  That suggests that subcontracting can happen to meet their contracting needs.  Either adding tasks to the SOW via the LLC or having the person filling the RSCE role work directly for the RPC for somethings are both reasonable and legal approaches.  The former would by definition not cause a COI, the latter shouldn't but the LLC could be sticky about it.  
> 

I don’t object to explicitly saying “The RPC may subcontract the RSCE” or something similar. I prefer framing it like this as what is allowed rather than trying to describe what is not allowed.  

Jay

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 16 Nov 2021 16:17:09 -0700

On 11/16/21 4:15 PM, Jay Daley wrote:
>>>> we've moved around.  I'd prefer making it explicit that the LLC 
>>>> can't make working for the RPC an unmanageable COI for the RSCE.
>>>
>>>     independently so if the RPC wanted the RSCE to do extra
>>>     contracted work then I doubt the RPC would subcontract with them
>>>     directly but rather negotiate with the LLC for the LLC to add a
>>>     SoW to the RSCE contract.  Maybe there might be a situation where
>>>     the RPC has a staff shortage and wants to directly contract the
>>>     RSCE to backfill but that still wouldn’t be a COI.
>>>
>> needs.  Either adding tasks to the SOW via the LLC or having the 
>> person filling the RSCE role work directly for the RPC for somethings 
>> are both reasonable and legal approaches.  The former would by 
>> definition not cause a COI, the latter shouldn't but the LLC could be 
>> sticky about it.
>>
> 
> I don’t object to explicitly saying “The RPC may subcontract the RSCE” 
> or something similar. I prefer framing it like this as what is allowed 
> rather than trying to describe what is not allowed.

That seems reasonable. Would you mind proposing text?

Peter

---

From: Michael StJohns <[email-masked]>
Date: Tue, 16 Nov 2021 18:17:47 -0500

On 11/16/2021 6:15 PM, Jay Daley wrote:
>>> Yup, but we're struggling on how the RSCE and RPC will work 
>>> together, and I have this feeling we're going to stick the RPC with 
>>> too many things they won't necessarily be good at. Given how few 
>>> good technical editor/publisher candidates I expect we'll get I 
>>> think we need to make clear that the LLC shouldn't COI the RSCE from 
>>> work subcontracted from the RPC.    Open an issue?
>>>
>>>     I can’t see on what basis a COI would be imposed and both the
>>>     RPC and RSCE are working to a common goal. The RPC contract
>>>     doesn’t allow for any sort of project fund for the RPC to spend
>>>     SoW to the RSCE contract.  Maybe there might be a situation
>>>     where the RPC has a staff shortage and wants to directly
>>>     contract the RSCE to backfill but that still wouldn’t be a COI.
>>>

I'm OK with this.  Include "contracts disclosed" language as above.

Mike

---

From: Jay Daley <[email-masked]>
Date: Wed, 17 Nov 2021 12:47:33 +1300

> On 17/11/2021, at 12:17 PM, Michael StJohns <[email-masked]> wrote:
> 

This is a bit long-winded but what I’m trying to do is insert this into the existing LLC policy framework around contract publication, COI etc rather than create a special case,

"The RPC service provider may contract services from the RSCE service provider, and vice versa, including for services provided to the IETF LLC.  All contracts between the two must be disclosed to the IETF LLC.  Where those services are related to services provided to the IETF LLC, IETF LLC policies shall apply, including publication of relevant parts of the contract."

Jay

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

---

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

I'm sorry, but in my thoughts I keep comming back to the following:

> decide it's not what we meant.

I think the discussion went into the direction of "that's not what we 
meant". However, I think there are two reasons why I think we should 
reconsider this.

First, "preferably an IESG member" means that the selection could be 
very quick, no need to call for volunteers.

Second, this could express our understanding that this job is not like 
some of the others that in particular the IAB hands out once in a while, 
but where (in my understanding) the assignee is essentially independent 
and doesn't report back, but it is an assignment where the job is to 
stay in close contact with the assigning group or board.

This reminds me of one other issue: The RSE was (and John Levine 
currently is) a liaison member of IAB. If that was the case, does this 
apply to the RSCE? What about liaison to the IESG?

Regards,   Martin.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 17 Nov 2021 11:08:07 +0100

We already have consensus on this text, and last call is closed. EKR 
suggested an editorial and it will be left for the editor.

Eliot

On 17.11.21 10:58, Martin J. Dürst wrote:
>> Almost, but not exactly, at least the way I understood it. I think 
>> what we wanted was something close to
>>
> some of the others that in particular the IAB hands out once in a 
> while, but where (in my understanding) the assignee is essentially 
> independent and doesn't report back, but it is an assignment where the 
> job is to stay in close contact with the assigning group or board.
>

---

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

> stay in close contact with the assigning group or board.

I agree with Eliot; I think we're done on this.

> apply to the RSCE? 

See https://www.ietf.org/archive/id/draft-carpenter-rfced-iab-charter-03.html#name-introduction:

"Note that RFC 2850 states that the RFC Editor appoints a liaison member to the IAB. This does not change."

Do we really need to sweat that in detail (whether it's the RSCE or RPC staff)? If so, it's part of the review of draft-carpenter-rfced-iab-charter.

> What about liaison to the IESG?

Same story, except that the IESG Charter doesn't need updating since it already says

   "The liaisons are selected as appropriate by the bodies they
    represent.  At the time of this writing, the liaisons present
    represent the following bodies:

       The RFC Editor
    ..."

Regards
    Brian

---

From: "StJohns, Michael" <[email-masked]>
Date: Wed, 17 Nov 2021 16:58:32 -0500

So you’re saying that Rfc editor should be read as Rfc series consulting
editor going forward?  That’s not my understanding.

Mike

On Wed, Nov 17, 2021 at 16:49 Brian E Carpenter <[email-masked]>
wrote:

> See
> https://www.ietf.org/archive/id/draft-carpenter-rfced-iab-charter-03.html#name-introduction
> :
>
> Do we really need to sweat that in detail (whether it's the RSCE or RPC
> staff)? If so, it's part of the review of draft-carpenter-rfced-iab-charter.
>

---

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

Brian,

I probably agree with Mike.  With the new changes in positions
and titles, it is not at all clear what the "RFC Editor
appoints..." means.  It may actually make a difference whether
the appointment is made by the RPC or the RSCE, especially
because the latter (no longer as compared to the RSE) has any
direct authority over the RPC.    This is not hard to fix now
and, IMO, worth it if we don't want to invite issues in the
future that we would have no mechanism to resolve [1].  Let's
say "RSCE" if we mean that and, if the ambiguity is intentional,
use "RFC Editor Function" to make that clear.

    john

[1] Other than either the IAB deciding who should be the
liaison/ representative or  the LLC and/or ExecDir stepping in
and saying "you both work for me and I've decided".  I hope we
are in agreement that neither would be a good position to put
anyone in.

--On Wednesday, November 17, 2021 16:58 -0500 "StJohns, Michael"
<[email-masked]> wrote:

> So you're saying that Rfc editor should be read as Rfc
> series consulting editor going forward?  That's not my
> understanding.
> 
> Mike
> 
> On Wed, Nov 17, 2021 at 16:49 Brian E Carpenter
>> >> A few comments inline, not all directed at Eric. Text
>> >> unrelated to my comments cut out (I wish more people would
>> >> take the time to do that).
>> >> 
>> >>>      *  As the stream representative for the IAB stream,
>> >>>      an IAB member
>> or
>> >>> Could we simplify this to be "any person selected by the
>> >>> IAB"? That seems to be what it says.
>> >> 
>> >> Almost, but not exactly, at least the way I understood it.
>> >> I think what we wanted was something close to
>> >> 
>> >>    *  As the stream representative for the IETF stream,
>> >>    preferably an IESG member, or otherwise a member of the
>> >>       community selected by the IESG
>> >> 
>> >> (and likewise for the IAB). Maybe we need to make that
>> >> explicit, or decide it's not what we meant.
>> > 
>> > I think the discussion went into the direction of "that's
>> > not what we meant". However, I think there are two reasons
>> > why I think we should reconsider this.
>> > 
>> > First, "preferably an IESG member" means that the selection
>> > could be very quick, no need to call for volunteers.
>> > 
>> > Second, this could express our understanding that this job
>> > is not like some of the others that in particular the IAB
>> > hands out once in a while, but where (in my understanding)
>> > the assignee is essentially independent and doesn't report
>> > back, but it is an assignment where the job is to stay in
>> > close contact with the assigning group or board.
>> 
>> > This reminds me of one other issue: The RSE was (and John
>> > Levine currently is) a liaison member of IAB. If that was
>> > the case, does this apply to the RSCE?
>> 
>> See
>> https://www.ietf.org/archive/id/draft-carpenter-rfced-iab-cha
>> rter-03.html#name-introduction :
>> 
>> "Note that RFC 2850 states that the RFC Editor appoints a
>> liaison member to the IAB. This does not change."
>> 
>> Do we really need to sweat that in detail (whether it's the
>> RSCE or RPC staff)? If so, it's part of the review of
>> draft-carpenter-rfced-iab-charter.
>> 
>>    "The liaisons are selected as appropriate by the bodies
>>    they represent.  At the time of this writing, the liaisons
>>     present represent the following bodies:
>> 
>>        The RFC Editor
>>     ..."
>> 
>> Regards
>>     Brian
>> 
>> 
>> --

---

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

On 18-Nov-21 10:58, StJohns, Michael wrote:
> So you’re saying that Rfc editor should be read as Rfc series consulting editor going forward?  That’s not my understanding.

No, as "the RFC Editor function" collectively. I thought we'd already settled that.

A lot of these details will become clearer with experience. I think it's a mug's game trying to define them in advance.

    Brian

> 
> Mike
> 
> On Wed, Nov 17, 2021 at 16:49 Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     See https://www.ietf.org/archive/id/draft-carpenter-rfced-iab-charter-03.html#name-introduction <https://www.ietf.org/archive/id/draft-carpenter-rfced-iab-charter-03.html#name-introduction>:
> 
>     Do we really need to sweat that in detail (whether it's the RSCE or 
RPC staff)? If so, it's part of the review of draft-carpenter-rfced-iab-charter.
>     [email-masked] <mailto:[email-masked]>
>     https://www.iab.org/mailman/listinfo/rfced-future <https://www.iab.org/mailman/listinfo/rfced-future>
>

---

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

> use "RFC Editor Function" to make that clear.

I thought this was fixed by Appendix A.1 "RFC Editor Function"
of the draft. I'll of course be happy to make this change
in draft-carpenter-rfced-iab-charter if people want that.

     Brian

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 18 Nov 2021 10:54:26 +1100

+1 - 'RFC Editor' is now a sort of vestigial function that doesn't map 1:1 with any particular role -- it's more of a shorthand for 'something to do with the RFC Series'.

> On 18 Nov 2021, at 8:58 am, StJohns, Michael <[email-masked]> wrote:
> 
> On Wed, Nov 17, 2021 at 16:49 Brian E Carpenter <[email-masked]> wrote:

---

From: Lars Eggert <[email-masked]>
Date: Thu, 18 Nov 2021 11:13:43 +0200

Hi,

On 2021-11-17, at 11:58, Martin J. Dürst <[email-masked]> wrote:
> This reminds me of one other issue: The RSE was (and John Levine currently is) a liaison member of IAB. If that was the case, does this apply to the RSCE? What about liaison to the IESG?

for the IETF stream, it has been operationally useful to have someone from the RPC on the calls and email lists, to facilitate direct discussions of any particular issues of a given doc. (Ditto for IANA.) I don't see a need for any changes here.

Whether the IAB still needs a liaison from the "RFC Editor" and whether this is the RSCE or someone from the RPC is less clear to me under the new structure. But I do think this is up to the IAB to decide?

Thanks,
Lars

---

From: Eliot Lear <[email-masked]>
Date: Thu, 18 Nov 2021 11:02:44 +0100

Hi Lars,

As usual, you have stated things practically.  It is important to 
understand the purpose of the liaison, whether it should come from the 
RPC, the RSCE, or the RSWG/RSAB.  One way to consider the latter is that 
the RSAB member for the stream really is intended to serve this function.

Eliot

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 19 Nov 2021 08:57:06 +1300

On 18-Nov-21 22:13, Lars Eggert wrote:
...

> Whether the IAB still needs a liaison from the "RFC Editor" and whether 
=
> this is the RSCE or someone from the RPC is less clear to me under the =
> new structure. But I do think this is up to the IAB to decide?

True, but they should decide soon, because it's part of the proposed
IAB charter update (new version very soon now as Lars has requested).

> the RSAB member for the stream really is intended to serve this function.

Not really. That person is *from* the IAB, and the liaison member of the
IAB is *from* the RFC Editor function. Two different roles.

    Brian