Subject: [Rfced-future] Non-approval resolution

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 11 Feb 2021 09:54:52 -0000

It seems to me that we have reached a position where we are stuck between
two positions which I shall express crudely:

1. The WG must be supreme and, while the approval group can express concerns
and return things to the WG for further consideration, the WG must be
allowed to have its way.

2. The approval group in the form of one of its "voting" members must be
allowed to block output of the WG that it considers harmful to the series or
to one of the streams in the series.

These positions are accompanied by fears (valid or not) about how people and
groups might operate, to force through ideas or to block them. Some are
concerned that too many people will have the option to block work based on
an overly wide perceived remit and overriding the will of the community.
Others are concerned that the WG may become dominated by a clique of loud
voices and that key opinions may be overridden in the operation of the
"normal" IETF consensus process. There are probably other nuanced issues
that we don't need to dig up.

I don't believe we are likely to reach consensus to swing to align with
either position 1 or 2 based on what I have seen in this discussion.

So I'd like to make a proposal which is in the form of an escalation
procedure based quite heavily on the processes used by the IESG when
balloting on documents. It goes as follows:

A. The WG last calls its work following the model of an IETF WG. It is
assumed that all members of the approval group will participate in the WG,
and particularly in the WG last call, in an attempt to uncover any of their
concerns early, and to avoid late surprises. It is understood that, from
time to time, a member of the approval group may find it impossible to
participate in a particular discussion: they are encourage to send
delegates.
B. The "voting" members of the approval group review the work and ballot.
    They may ballot Yes, Block, No Position, Abstain, or Recuse.
    - Yes means "I support this work." A Yes ballot may be accompanied by
comments indicating thoughts and issues that should be looked at, but are
non-blocking. 
    - Block means "I have a serious concern that needs to be resolved before
this work can proceed."
    - No Position should only be used in exceptional cases such as illness
or long vacation. Voting members are expected to try to present a different
ballot position.
    - Abstain means "I have a serious concern, but  recognise that it will
not be resolved."
    - Recuse means "I am somehow so involved in this work that it would be
improper for me to have a position."
C. Work proceeds if:
    There is at least one "Yes" and no "Block" ballots.
D. In the event of one or more Block ballots, the work cannot proceed to
completion. There must be discussion in the WG between the members of the
approval group who balloted "Block" and the WG, and the focus of the
discussion must be on addressing the concerns and reaching consensus.
E. All comments in Yes ballots must be returned to the WG and the WG must
attempt to address them through the normal consensus process.
F. In the event of there being exactly one Block ballot, and it being
impossible to reach agreement between the WG and the member of the approval
group who issued the ballot, the approval group will exercise an exception
resolution process as follows:
F1. The approval group will discuss the concern giving rise to the ballot
and any proposed resolution from the WG
F2. The approval group will vote on whether to sustain the Block or to
release the work
F3. The vote shall be by simple majority with the chair of the group holding
a casting vote in the event of a tie.
F4. If the Block is sustained, return to step D.
F5. If the work is released, return to step C.

I am sure that we can bike-shed the details of this. And, before we are
done, we should do that and we should reach a process that we can all agree
upon.

But, in the mean time I am interested to know whether *something*similar* to
this could address the concerns of both sides of the current debate.

Thanks,
Adrian

---

From: Adam Roach <[email-masked]>
Date: Thu, 11 Feb 2021 10:35:27 -0600

On 2/11/21 03:54, Adrian Farrel wrote:
> groups might operate, to force through ideas or to block them.

I like this framing, because it really throws into relief the core issue 
that I think is causing an impasse, even if it hasn't been brought forth 
explicitly: which group is more likely to be subject to capture by 
people who will make decisions that are subjectively bad for the series? 
A small, closed group, or a large open one?

The calculus might change a bit one way or the other depending on 
whether the closed group is directly appointed, indirectly appointed, or 
comprised primarily of ex-officio members, but I think this question is 
really the elephant in the room that we need to address.

/a

---

From: Brian Rosen <[email-masked]>
Date: Thu, 11 Feb 2021 12:04:38 -0500

Adam

Where do you stand on his proposed resolution?

> On Feb 11, 2021, at 11:35 AM, Adam Roach <[email-masked]> wrote:
> 
> I like this framing, because it really throws into relief the core issue that I think is causing an impasse, even if it hasn't been brought forth explicitly: which group is more likely to be subject to capture by people who will make decisions that are subjectively bad for the series? A small, closed group, or a large open one?
> 
> The calculus might change a bit one way or the other depending on whether the closed group is directly appointed, indirectly appointed, or comprised primarily of ex-officio members, but I think this question is really the elephant in the room that we need to address.
> 
> /a
> 
> -- 
> Rfced-future mailing list
> [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: Fri, 12 Feb 2021 08:54:05 +1300

> 1. The WG must be supreme

No. That's the whole point of having an approval body.

> I am sure that we can bike-shed the details of this. 

I'm pretty sure we shouldn't do that, which is why my proposal is much simpler and intentionally lacks details, but IMHO has exactly the same effect:

*The approval body shall operate by consensus.*

That's all. Just the dictionary definition of "consensus". How they reach consensus is their choice.

If we must spell it out, Adrian's formulation is fine, although I'd prefer the traditional "Discuss" to "Block".

Regards
   Brian C

---

From: Michael StJohns <[email-masked]>
Date: Thu, 11 Feb 2021 15:05:50 -0500

On 2/11/2021 11:35 AM, Adam Roach wrote:
> I like this framing, because it really throws into relief the core 
> issue that I think is causing an impasse, even if it hasn't been 
> brought forth explicitly: which group is more likely to be subject to 
> capture by people who will make decisions that are subjectively bad 
> for the series? A small, closed group, or a large open one?
>
> whether the closed group is directly appointed, indirectly appointed, 
> or comprised primarily of ex-officio members, but I think this 
> question is really the elephant in the room that we need to address.

Adam - I've seen many times over my years with the IETF where a large 
group has been captured by a smaller group and made decisions that could 
be argued to be bad along at least one axis or another.  In fact, that 
was one of the reasons that I've been from time to time urging that the 
CFRG become a WG instead.

I don't think there's a strong argument that a random small group of 
self-selected experts is better than a community selected group picked 
using the criteria of specific expertise.   In fact, the selection of 
the IESG is exactly that.  Or would you argue that your selection as AD 
was flawed and you should have been replaced by a self-selected group 
claiming expertise in ART?

*sigh*

Mike

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 12 Feb 2021 10:22:00 +1100

I think that this assessment is close enough to how things are going.  I might have said that it wasn't "fears" on my own part, in the perhaps deluded view that my objection was more principled.  That is, I want no individual to have the power to overwhelm the process in any direction, whether that be stagnation or toward their personal goals.  But I don't think the exact reason matter much.

The formulation of the process seems fine.  With a bunch of quibbles:

* I think that Brian's consensus thing is how things will work in practice, but we need a backstop and this is reasonable.  

* I would note that the Abstain/No Position/Recuse distinctions are not process relevant and so likely only serve to enable posturing, which might not be helpful (I've seen abstention in the IESG used this way and I believe it to be unhealthy), but that's a minor niggle.

* I don't think that the chair acting as tie-breaker is a good idea.  This group doesn't need a privileged role like that (and they might not even need a chair given the likely size).  I think that overturning a blocking position should take more people voting to overturn than voting to sustain.  For a group of size 4, that means 3 out of 4 and I think that's entirely appropriate.

I would enhance this with:

* We need an explicit process for public comment periods for proposals before approval can occur.  There probably needs to be a fixed duration for that comment period and then a time limit on when approvals are completed.  These might be fairly generous given the non-urgent nature of the work, but I think that we can't allow unbounded time.

* I would add that the request for approval of a document should come with a report that details dissent in the working group and that any individual can have their dissent position explicitly included in that report in their own words.  I am thinking here specifically about RSA/E, because this seems to be particularly important.

* I would add that any block position needs to come with a clear statement about the reasons for it.  We might want to develop guidelines for what is and isn't valid reasons for that.  I like that this explicitly includes discussion of that position, but I think that discussion needs a concrete starting point.

There are obviously many failure modes that can be invented where the approvals body and WG end up at loggerheads and this all breaks down.  As we've noted before, invoking a higher authority might be necessary, but that needs to be very carefully constrained.  We've a history of relying on appeals without invoking them in this organization, which I think is a fine tradition to continue.

On Thu, Feb 11, 2021, at 20:54, Adrian Farrel wrote:
> [email-masked]
> https://www.iab.org/mailman/listinfo/rfced-future
>

---

From: Adam Roach <[email-masked]>
Date: Thu, 11 Feb 2021 18:03:08 -0600

I could live with something of this general shape, although it's 
certainly not my top choice.

Process notwithstanding, this proposal is fundamentally position #2 with 
"one of" replaced by "a simple majority of," which still falls back to 
the capture question. The whole proposal would be made significantly 
more palatable if we had an appeals process that allowed for outcome 
based on substance rather than process, but I recognize that this runs 
into a sticky conversation about which body receives the appeal.

/a

On 2/11/21 11:04, Brian Rosen wrote:
>> On Feb 11, 2021, at 11:35 AM, Adam Roach <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>

---

From: Adam Roach <[email-masked]>
Date: Thu, 11 Feb 2021 18:03:59 -0600

On 2/11/21 14:05, Michael StJohns wrote:
> Or would you argue that your selection as AD was flawed and you should 
> have been replaced by a self-selected group claiming expertise in ART? 

To be fair, this characterization effectively matches the facts on the 
ground; see, e.g., 
https://www6.ietf.org/iesg/appeal/response-to-klensin-2008-06-13.txt

The closer we can hew to this model where the approving body has very 
little power in the face of strong community sentiment, the closer we 
come to finding a compromise between the two positions Adrian lays out.

/a

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 12 Feb 2021 11:13:32 +1100

I'm roughly in the same boat; there are some details that need bikeshedding^H^H^Hrefinement, but I could live with it.

I agree that we need to figure out something for appeals; in general, multiple layers of approval/appeal increases confidence in the work, and it's something we should figure out, even if finding the stuckee is hard.

Cheers,

> On 12 Feb 2021, at 11:03 am, Adam Roach <[email-masked]> wrote:
> 
> I could live with something of this general shape, although it's certainly not my top choice.
> 
> Process notwithstanding, this proposal is fundamentally position #2 with "one of" replaced by "a simple majority of," which still falls back to the capture question. The whole proposal would be made significantly more palatable if we had an appeals process that allowed for outcome based on substance rather than process, but I recognize that this runs into a sticky conversation about which body receives the appeal.
> 
> /a
> 

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

---

From: Martin J. Dürst <[email-masked]>
Date: Fri, 12 Feb 2021 16:20:09 +0900

In general, I agree with the direction the discussion is taking. 
However, I have a concern about a point below.

>      There is at least one "Yes" and no "Block" ballots.

This is the point where I have my doubts. As far as I understand, on the 
IESG, a lot of No Objection ballots are tolerated because of the wide 
range of topics the IESG deals with and the large number of drafts. In 
my imagination, RFC-related decisions should be supported by something 
closer to consensus than just a single member being fully in on a 
proposal. The number of proposals should also not be that high, so that 
every member should easily be able to form a well-founded position on 
every proposal. Also, at least in the case of stream managers, illness 
or long vacations should be handled by having a (temporary) replacement 
for the stream manager position, which would extend to the position on 
the approval group.

Regards,   Martin.

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 12 Feb 2021 10:25:29 -0000

Hi Martin,

Top post.

It was a straw man, not a firm position.

My thinking was that "no position" should not be a common event. But there will always be corner cases.

Not that the IESG has "no objection" and "no ballot made". I would say that "no objection" should not exist: say yes or no, but don't say nothing. However, the "no position" is needed just in case circumstances intervene.

A

-----Original Message-----
From: Martin J. Dürst <[email-masked]> 
Sent: 12 February 2021 07:20
To: [email-masked]; [email-masked]
Subject: Re: [Rfced-future] Non-approval resolution

Regards,   Martin.

---

From: Russ Housley <[email-masked]>
Date: Sat, 13 Feb 2021 17:05:11 -0500

Adrian:

I am largely in favor of this approach, assuming that this description is after some form of community Last Call.

Russ

> On Feb 11, 2021, at 4:54 AM, Adrian Farrel <[email-masked]> wrote:
>

---

From: Michael StJohns <[email-masked]>
Date: Sat, 13 Feb 2021 17:19:18 -0500

> to one of the streams in the series.

I think I'm in this last position.  But I think this needs to be a 
default of "fails without approval" rather than "proceeds without a 
block".  Unlike most other documents approved through the IETF system, a 
document in this stream has the possibility of screwing up the entire 
system of documents and hence a bit more care should be taken and a bit 
more approval should be needed before the document becomes the law of 
the land (IETF).

>      There is at least one "Yes" and no "Block" ballots.

I would delete "Abstain"  as not being a possible position.  I'd change 
"Block" to "No".   Members of the approval group are expected to review 
and have a position on all documents.  A "serious concern" with the 
document has to translate to a "No".

I'd change C to "There is at least a majority of "Yes" votes and no more 
than one "No".

Alternately, I'd allow a Block on a first vote and have that cause the 
approval body to enter into a one month delay on a final vote regardless 
of the number of Yes votes.  The WG or other submitter may chose at that 
point to withdraw the document from consideration for final approval to 
address any comments.

I'd also strongly suggest that the WG MUST engage with the approving 
body prior to submission of the documents to ensure that not only are 
the WG desires met, but that the needs of the Streams are considered.

Mike

---

From: Russ Housley <[email-masked]>
Date: Sat, 13 Feb 2021 17:26:48 -0500

> On Feb 13, 2021, at 5:19 PM, Michael StJohns <[email-masked]> wrote:
> 
> I think I'm in this last position.  But I think this needs to be a default of "fails without approval" rather than "proceeds without a block".  Unlike most other documents approved through the IETF system, a document in this stream has the possibility of screwing up the entire system of documents and hence a bit more care should be taken and a bit more approval should be needed before the document becomes the law of the land (IETF).
> 
> 
> I would delete "Abstain"  as not being a possible position.  I'd change "Block" to "No".   Members of the approval group are expected to review and have a position on all documents.  A "serious concern" with the document has to translate to a "No".

I think that Adrian picked these words based on my message.  My message was based on the ballot positions used by the IESG for charters.

I think that "Block" has a connotation that further discussion is welcome.  On the other hand, "No" sounds too final.

Russ

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 13 Feb 2021 22:38:21 -0000

Thanks Russ, all, for comments.

Eliot has asked me to try to synthesise the comments received so far into a refined write-up in time for Thursday's meeting.

No doubt I'll manage this somehow (possibly forgoing something or other 😉)

Adrian

-----Original Message-----
From: Russ Housley <[email-masked]> 
Sent: 13 February 2021 22:05
To: Adrian Farrel <[email-masked]>
Cc: [email-masked]
Subject: Re: [Rfced-future] Non-approval resolution

Adrian:

Russ

---

From: Michael StJohns <[email-masked]>
Date: Sat, 13 Feb 2021 17:53:05 -0500

> I think that "Block" has a connotation that further discussion is welcome.  On the other hand, "No" sounds too final.
Agree. But unlike the rest of the IETF style document processes, this 
group is dealing with a) a very small document set, and b) a very 
focused document set and c) a requirement to involve the approval body 
in the formation of such documents.  If a document makes it to the 
approval body without resolving the approval body comment(s), I'd 
suggest that discussion has already completed and that the person voting 
"no" is acknowledging that process.

Mike

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 16 Feb 2021 06:19:23 -0800

Michael StJohns <[email-masked]> writes:

> If a document makes it to the approval body without resolving the
> approval body comment(s), I'd suggest that discussion has already
> completed and that the person voting "no" is acknowledging that
> process.

So, in your view "no" is really a "never".  IE, it's too late to discuss
further because the discussion has already concluded and there is never
anything beyond this voting point?  IE, this is the last step in the
decision making process?
-- 
Wes Hardaker
USC/ISI

---

From: "StJohns, Michael" <[email-masked]>
Date: Tue, 16 Feb 2021 11:43:56 -0500

> anything beyond this voting point?  IE, this is the last step in the

No.  What I said in the other thread was:

   - Do people agree that any objections must be returned to the WG for
   discussion?

I don't know what that actually does.   Rejected documents (not originating
in the approval body) that don't get approved are in the state that all non
approved documents end up in and the WG or authors can take whatever
actions they want including revising and resubmitting.  I'd say instead
that rejections from the approval body need a cover letter of some sort
similar to how feedback works in the other streams and leave it at that.
Rather than have the approval body process devolve into an adjunct of the
WG process, I’d like there to be a clean separation between the two.  This
also makes clear the two roles for the members of the approval body in both
participating in the crafting of the document sin the WG and the decision
process in the approval body.

Later, mike

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 16 Feb 2021 16:55:27 -0000

Mike, I tried to capture something along these lines in my 2nd cut.

That is:

*	Approval body people should participate in the WG and WGLC
*	The reasons for a Discuss must be clearly stated and communicated to the WG
*	A discusser must attempt to resolve the issue in discussion with the WG

Wordsmithing is welcome.

A

From: Rfced-future <[email-masked]> On Behalf Of StJohns, Michael
Sent: 16 February 2021 16:44
To: Wes Hardaker <[email-masked]>
Cc: [email-masked]; Russ Housley <[email-masked]>
Subject: Re: [Rfced-future] Non-approval resolution

On Tue, Feb 16, 2021 at 09:19 Wes Hardaker <[email-masked] <mailto:[email-masked]> > wrote:

*	Do people agree that any objections must be returned to the WG for discussion?

I don't know what that actually does.   Rejected documents (not originating in the approval body) that don't get approved are in the state that all non approved documents end up in and the WG or authors can take whatever actions they want including revising and resubmitting.  I'd say instead that rejections from the approval body need a cover letter of some sort similar to how feedback works in the other streams and leave it at that.

Rather than have the approval body process devolve into an adjunct of the WG process, I’d like there to be a clean separation between the two.  This also makes clear the two roles for the members of the approval body in both participating in the crafting of the document sin the WG and the decision process in the approval body.

Later, mike

---

From: Michael StJohns <[email-masked]>
Date: Tue, 16 Feb 2021 13:43:10 -0500

On 2/16/2021 11:55 AM, Adrian Farrel wrote:
>
> Mike, I tried to capture something along these lines in my 2^nd cut.
>
> That is:
>

I think the above is reasonable as far as it goes - but I'd really 
suggest there is no "Discuss" vote - just a "No" vote.   An approval 
body member who has issues should have tried to address them in the WG.  
When the document is submitted to the AB, if such issues remain, the AB 
member can either vote Yes maybe indicating in the minutes that these 
issues remain unaddressed, but they won't block on them, or No.  If 
there are sufficient No votes (or insufficient Yes votes), then the fact 
that the issue(s) remain unresolved gets conveyed with the rejection.  
The WG can either try again or abandon the documents.

Unlike the IETF model where the IESG as a whole has little initial input 
into the documents, that can't be the case here if we expect to have a 
functioning RFC system. The AB members MUST be involved in the WG 
activities.  Because of that difference, the IESG discuss model really 
does not fit the RFC model.

> Wordsmithing is welcome.
>
> A
>
> *From:*Rfced-future <[email-masked]> *On Behalf Of 
> *StJohns, Michael
> *Sent:* 16 February 2021 16:44
> *To:* Wes Hardaker <[email-masked]>
> *Cc:* [email-masked]; Russ Housley <[email-masked]>
> *Subject:* Re: [Rfced-future] Non-approval resolution
>
> On Tue, Feb 16, 2021 at 09:19 Wes Hardaker <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Michael StJohns <[email-masked]
>     <mailto:[email-masked]>> writes:
>
> I don't know what that actually does.   Rejected documents (not 
> originating in the approval body) that don't get approved are in the 
> state that all non approved documents end up in and the WG or authors 
> can take whatever actions they want including revising and 
> resubmitting.  I'd say instead that rejections from the approval body 
> need a cover letter of some sort similar to how feedback works in the 
> other streams and leave it at that.
>
> Rather than have the approval body process devolve into an adjunct of 
> the WG process, I’d like there to be a clean separation between the 
> two.  This also makes clear the two roles for the members of the 
> approval body in both participating in the crafting of the document 
> sin the WG and the decision process in the approval body.
>
> Later, mike
>

---

From: Scott Bradner <[email-masked]>
Date: Tue, 16 Feb 2021 13:52:16 -0500

what about non WG documents?  (e.g., individual submissions) 

Scott

> On Feb 16, 2021, at 1:43 PM, Michael StJohns <[email-masked]> wrote:
> 
>> 	• Approval body people should participate in the WG and WGLC
>> 	• The reasons for a Discuss must be clearly stated and communicated to the WG
>> 	• A discusser must attempt to resolve the issue in discussion with the WG
> 
> 
> I think the above is reasonable as far as it goes - but I'd really suggest there is no "Discuss" vote - just a "No" vote.   An approval body member who has issues should have tried to address them in the WG.  When the document is submitted to the AB, if such issues remain, the AB member can either vote Yes maybe indicating in the minutes that these issues remain unaddressed, but they won't block on them, or No.  If there are sufficient No votes (or  insufficient Yes votes), then the fact that the issue(s) remain unresolved gets conveyed with the rejection.  The WG can either try again or abandon the documents.
> 
> Unlike the IETF model where the IESG as a whole has little initial input into the documents, that can't be the case here if we expect to have a functioning RFC system. The AB members MUST be involved in the WG activities.  Because of that difference, the IESG discuss model really does not fit the RFC model.
> 
> 
> 
>>  
>> 
>> Wordsmithing is welcome.
>> 
>>  
>> 
>> A
>> 
>>  
>> 
>> 	• Do people agree that any objections must be returned to the WG for discussion?

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 16 Feb 2021 19:04:04 -0000

OK, thanks Mike.

I’m not going to debate, but I just wanted to say what was underlying my thinking.

It seemed to me that everything you say about getting discussion done in the WG and early seems good. However, I didn’t want to just draw a line at that point when the strength of view of the approval group member might not have been clear, and the discussions in the WG should (possibly) not be predicated on a persons opinion being so powerful. 

The whole point, I hope, is that everything can be a discussion with it being understood that each approval group member has a position that they are bound to defend.

Anyway, onwards to other people’s voices.

Adrian

From: Michael StJohns <[email-masked]> 
Sent: 16 February 2021 18:43
To: [email-masked]; 'Wes Hardaker' <[email-masked]>
Cc: [email-masked]; 'Russ Housley' <[email-masked]>
Subject: Re: [Rfced-future] Non-approval resolution

That is:

1.	Approval body people should participate in the WG and WGLC
2.	The reasons for a Discuss must be clearly stated and communicated to the WG
3.	A discusser must attempt to resolve the issue in discussion with the WG

 

Wordsmithing is welcome.

A

From: Rfced-future  <mailto:[email-masked]> <[email-masked]> On Behalf Of StJohns, Michael
Sent: 16 February 2021 16:44
To: Wes Hardaker  <mailto:[email-masked]> <[email-masked]>
Cc: [email-masked] <mailto:[email-masked]> ; Russ Housley  <mailto:[email-masked]> <[email-masked]>
Subject: Re: [Rfced-future] Non-approval resolution

1.	Do people agree that any objections must be returned to the WG for discussion?

Later, mike

---

From: Michael StJohns <[email-masked]>
Date: Tue, 16 Feb 2021 14:10:10 -0500

> what about non WG documents?  (e.g., individual submissions)

Good catch.  The AB needs to have some sort of buy in for individual 
submissions which suggests that at least the general scope of the IS 
needs to be discussed with the AB near the beginning of the document 
process.    I think the approval process remains the same, but there 
needs to be a flavor of an adoption process - e.g. some AB member has to 
sponsor the document prior to it being submitted for approval and that 
AB member would be responsible for working with the author(s) to deal 
with probable AB pushbacks.

Mike

---

From: Michael StJohns <[email-masked]>
Date: Tue, 16 Feb 2021 14:18:41 -0500

> I’m not going to debate, but I just wanted to say what was underlying 
Not really a debate - but just trying to capture the AB member's dual 
roles as both approvers and being involved in the formation of the 
documents.  I'm not against discussion - just trying to make the point 
that the "DISCUSS" vote in the IESG means something like "I haven't seen 
this before and something looks wonky, can you explain this to my 
satisfaction?" and that there should never be a case where a document 
reaches the approval process where an AB member "hasn't seen this before".

I.e., before the document reaches the approval phase in the AB, it's 
gone through a) consensus discussions and revisions, and b) WG last 
call.  AB issues with the document should be resolved before the 
document is sent to the AB (in other words, in the WG or during WG last 
call) and the AB sends out (if it should?) a c) community last call.

Mike

> It seemed to me that everything you say about getting discussion done 
> in the WG and early seems good. However, I didn’t want to just draw a 
> line at that point when the strength of view of the approval group 
> member might not have been clear, and the discussions in the WG should 
> (possibly) not be predicated on a persons opinion being so powerful.
>
> The whole point, I hope, is that everything can be a discussion with 
> it being understood that each approval group member has a position 
> that they are bound to defend.
>
> *From:*Michael StJohns <[email-masked]>
> *Sent:* 16 February 2021 18:43
> *To:* [email-masked]; 'Wes Hardaker' <[email-masked]>
> *Cc:* [email-masked]; 'Russ Housley' <[email-masked]>
> body member who has issues should have tried to address them in the 
> WG.  When the document is submitted to the AB, if such issues remain, 
> the AB member can either vote Yes maybe indicating in the minutes that 
> these issues remain unaddressed, but they won't block on them, or No.  
> If there are sufficient No votes (or  insufficient Yes votes), then 
> the fact that the issue(s) remain unresolved gets conveyed with the 
> rejection.  The WG can either try again or abandon the documents.
>
> Unlike the IETF model where the IESG as a whole has little initial 
> input into the documents, that can't be the case here if we expect to 
> have a functioning RFC system. The AB members MUST be involved in the 
> WG activities.  Because of that difference, the IESG discuss model 
> really does not fit the RFC model.
>
>     Wordsmithing is welcome.
>
>     A
>
>     *From:*Rfced-future <[email-masked]>
>     <mailto:[email-masked]> *On Behalf Of *StJohns, Michael
>     <mailto:[email-masked]>
>     *Cc:* [email-masked] <mailto:[email-masked]>; Russ
>     Housley <[email-masked]> <mailto:[email-masked]>
>     originating in the approval body) that don't get approved are in
>     the state that all non approved documents end up in and the WG or
>     authors can take whatever actions they want including revising and
>     resubmitting.  I'd say instead that rejections from the approval
>     body need a cover letter of some sort similar to how feedback
>     works in the other streams and leave it at that.
>
>     Rather than have the approval body process devolve into an adjunct
>     of the WG process, I’d like there to be a clean separation between
>     the two.  This also makes clear the two roles for the members of
>     the approval body in both participating in the crafting of the
>     document sin the WG and the decision process in the approval body.
>
>     Later, mike
>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 17 Feb 2021 10:54:01 +1300

> with probable AB pushbacks.

It's a good catch, but I'm inclined to a different answer: just say no.
I'm not seeing why we need a bypass in this case. We need the bypass
in the IETF for topics that simply don't need the overhead of a WG; in
this case we already *have* a WG.

If somebody believes, for example, that all RFCs should be translated
into Elbonian, I think it is necessary and sufficient to tell them to
take it to the working group.

    Brian

---

From: Michael StJohns <[email-masked]>
Date: Tue, 16 Feb 2021 17:02:01 -0500

> take it to the working group.
Probably not.  I actually think there will be a few of these - maybe 
originated by the RPC or by a hired XML expert for example. I may be 
wrong, but the WG is probably the wrong path for some documents.

If someone proposed Elbonian, I'd suggest that the AB probably wouldn't 
approve it if they were anywhere near sane regardless of whether this 
was an IC or a WG sponsored document.

Later, Mike

---

From: Russ Housley <[email-masked]>
Date: Tue, 16 Feb 2021 17:54:54 -0500

> On Feb 16, 2021, at 5:02 PM, Michael StJohns <[email-masked]> wrote:
> 
> Probably not.  I actually think there will be a few of these - maybe originated by the RPC or by a hired XML expert for example. I may be wrong, but the WG is probably the wrong path for some documents.

Just because that is the source of the document, I see no reason that the WG cannot adopt and review them before they get approved.

Russ

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 16 Feb 2021 14:57:33 -0800

> take it to the working group.

I agree. In my experience individual submissions often don't get the level
of scrutiny one might like, and given that we have a standing WG, if you
can't persuade that WG, that's a pretty good sign that the idea shouldn't
proceed.

-Ekr

---

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

> Just because that is the source of the document, I see no reason that the WG cannot adopt and review them before they get approved.

Yes. And the process in the WG could (and should) be very short and 
light if it's a document from the RPC or an XML expert that nobody 
disagrees with, or that is just published for the record, without by 
itself changing anything in the publication process.

Regards,   Martin.