Subject: [Gendispatch] Additional text around SAA for bcp45bis

From: Lars Eggert <[email-masked]>
Date: Tue, 20 Jul 2021 16:06:48 +0300

Hi,

the SAA team has collected some updates and clarifications around their purpose and operation, and Dhruv has provided a PR to bcp45bis for them:

https://github.com/larseggert/bcp45bis/pull/1/files

Would this change be something the community would supportive of?

Thanks,
Lars

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 20 Jul 2021 13:08:57 +0000

>    https://github.com/larseggert/bcp45bis/pull/1/files

Looks good to me.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 20 Jul 2021 10:56:55 -0700

Made one comment but generally LGTM

On Tue, Jul 20, 2021 at 6:09 AM Salz, Rich <rsalz=
[email-masked]> wrote:

> --
> Gendispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gendispatch
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 20 Jul 2021 14:08:52 -0400

And this is where I start to feel like we are falling down the slope 
into moving discussions to github.  To which I have a strong and 
repeatedly stated objection.

The particular change EKR proposes is fine.  I think it may even be a 
good idea.  It could also have been easily captured in an email to the 
list.  And since it is actually a matter of policy more than wording, in 
my opinion should have been sent to the list.

Yours,
Joel

On 7/20/2021 1:56 PM, Eric Rescorla wrote:
> On Tue, Jul 20, 2021 at 6:09 AM Salz, Rich 
> <rsalz=[email-masked] <mailto:[email-masked]>> 
> wrote:
> 
>     <https://github.com/larseggert/bcp45bis/pull/1/files>
> 
>     Looks good to me.
> 
>     -- 
>     Gendispatch mailing list
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/gendispatch>
> 
>

---

From: Mary Barnes <[email-masked]>
Date: Tue, 20 Jul 2021 15:11:17 -0500

+1 to Joel's comments on using github for discussion rather than the
mailing list.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 20 Jul 2021 13:20:17 -0700

> my opinion should have been sent to the list.

I feel like we've all got pretty fixed opinions on the use of Github, but
in this
particular case, ISTM that:

1. This is a personal draft (albeit by the IETF chair)
2. The proposed text was on Github not the list.

So isn't it kind of a personal choice how I make comments?

-Ekr

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 20 Jul 2021 21:28:21 +0100

FWIW, I'm not a fan of using github instead of mailing list
discussion, (mostly because of how it works best for sets
of people in nearby TZ's with v. similar workflows, and v.
badly for others not in such a set)... but...

> So isn't it kind of a personal choice how I make comments?

I agree with ekr on this one. There is an I-D, there's a PR
for the GH version of that on which ekr made a comment. If
accepted, those changes (which seem uncontroversial to me)
will be in a revised I-D, there's no real rush to get this
right and changing later will be fine.

Cheers,
S.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 21 Jul 2021 08:35:46 +1200

On 21-Jul-21 08:20, Eric Rescorla wrote:
> 
> 
> On Tue, Jul 20, 2021 at 11:09 AM Joel M. Halpern <[email-masked] <mailto:[email-masked]>> wrote:
> 
> I feel like we've all got pretty fixed opinions on the use of Github, but in this

As long as it doesn't subvert the final text being exposed to the
list, I don't think it matters too much.

fwiw I am happy with the proposal and EKR's amendment.

otoh, the draft doesn't cite RFC2119 and I don't think we really
need SHOUTY NORMATIVE words in this document.

   Brian

>     > <rsalz=[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
>     > wrote:
>     >
>     >      > https://github.com/larseggert/bcp45bis/pull/1/files <https://github.com/larseggert/bcp45bis/pull/1/files>
>     >     <https://github.com/larseggert/bcp45bis/pull/1/files <https://github.com/larseggert/bcp45bis/pull/1/files>>
>     >
>     >     Looks good to me.
>     >
>     >     --
>     >     Gendispatch mailing list
>     >     [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>     >     https://www.ietf.org/mailman/listinfo/gendispatch <https://www.ietf.org/mailman/listinfo/gendispatch>
>     >     <https://www.ietf.org/mailman/listinfo/gendispatch <https://www.ietf.org/mailman/listinfo/gendispatch>>
>     >
>     >
> 
>     -- 
>     Gendispatch mailing list
>     https://www.ietf.org/mailman/listinfo/gendispatch <https://www.ietf.org/mailman/listinfo/gendispatch>
> 
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 20 Jul 2021 16:58:44 -0400

I considered objecting to the posting of the proposed change only on 
github, but then expecting the WG to pay attention to it.  (Using github 
for a group of editors working together on a private draft is clearly 
within the rules.)

I did not want to do so, because there is a tension between clarity of 
editorial change and making sure content is on the list.  But if you are 
going to use the original posting beign on github as a reason for the 
comments to be there, then I guess you force me to object to that.

Yours,
Joel

On 7/20/2021 4:20 PM, Eric Rescorla wrote:
>      > <rsalz=[email-masked]
>     <mailto:[email-masked]>
>     <mailto:[email-masked]
>     <mailto:[email-masked]>>>
>      > wrote:
>      >
>      >      > https://github.com/larseggert/bcp45bis/pull/1/files
>      >     <https://github.com/larseggert/bcp45bis/pull/1/files
>     <https://github.com/larseggert/bcp45bis/pull/1/files>>
>      >
>      >     Looks good to me.
>      >
>      >     --
>      >     Gendispatch mailing list
>     <mailto:[email-masked] <mailto:[email-masked]>>
>      >     <https://www.ietf.org/mailman/listinfo/gendispatch
>     <https://www.ietf.org/mailman/listinfo/gendispatch>>
>      >
>      >
> 
>     -- 
>     Gendispatch mailing list

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 20 Jul 2021 17:08:29 -0400

Given that the draft was posted, and comments were requestedd on the WG 
email list, I expect folks to provide comments on the WG email list.
I will grant that it is still an individual draft.  But then...
1) almsot by definition gendispatch drafts tend to be fuzzy on that, as 
gendispatch will choose as a WG how to dispatch that individual draft.
2) The draft is from the IETF chair.  It is almost impossible for the 
IETF chair to actual have an unofficial draft.  By virtual of his 
writing it, it has more standing.  (Which is why frequently IETF chairs 
ask other people to write drafts, so as to keep roles clean.)

Given that this was an edge case in terms of standing, I think it is 
important that comments be on the list.  The fact that EKR and Lars 
would prefer to see discussions in PR doesn't change that.

Yours,
Joel

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 20 Jul 2021 14:12:47 -0700

At the risk of just boring everyone...

Suppose I had just emailed Lars privately with my comments. Would you
object to that?

-Ekr

On Tue, Jul 20, 2021 at 2:08 PM Joel M. Halpern <[email-masked]> wrote:

> >>      > <rsalz=[email-masked] <mailto:
> [email-masked]> <mailto:[email-masked] <mailto:
> [email-masked]>>>
> >>      > wrote:
> >>      >
> >>      >      > https://github.com/larseggert/bcp45bis/pull/1/files <
> https://github.com/larseggert/bcp45bis/pull/1/files>
> >>      >     <https://github.com/larseggert/bcp45bis/pull/1/files <
> https://github.com/larseggert/bcp45bis/pull/1/files>>
> >>      >
> >>      >     Looks good to me.
> >>      >
> >>      >     --
> >>      >     Gendispatch mailing list
> >>      >     [email-masked] <mailto:[email-masked]> <mailto:
> [email-masked] <mailto:[email-masked]>>
> >>      >     https://www.ietf.org/mailman/listinfo/gendispatch <
> https://www.ietf.org/mailman/listinfo/gendispatch>
> >>      >     <https://www.ietf.org/mailman/listinfo/gendispatch <
> https://www.ietf.org/mailman/listinfo/gendispatch>>
> >>      >
> >>      >
> >>
> >>      --
> >>      Gendispatch mailing list
> >>      https://www.ietf.org/mailman/listinfo/gendispatch <
> https://www.ietf.org/mailman/listinfo/gendispatch>
> >>
> >>
> >
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 20 Jul 2021 17:18:02 -0400

Given that the author requested discussion on the list, I would have 
assumed that on-list followup of substantive issues (and for all I agree 
with ti, this is substantive) would be on list.

In other working groups with a cleaner distinction between adopted and 
not-yet-adotped, and with other authors, I probably would have kept 
quiet even if I was surprised.

In this case, the sequence of events looks liek sliding down an 
unfortuante slope.

Yours,
Joel

PS: In case it is unclear, I am not attributing any malign or devious 
intent to you EKR.  You did this in the way that seemed obvious and 
simple to you.

On 7/20/2021 5:12 PM, Eric Rescorla wrote:
> On Tue, Jul 20, 2021 at 2:08 PM Joel M. Halpern <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>      >> On Tue, Jul 20, 2021 at 11:09 AM Joel M. Halpern
>     <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >>
>      >>      > Made one comment but generally LGTM
>      >>      >
>      >>      > On Tue, Jul 20, 2021 at 6:09 AM Salz, Rich
>      >>      > <rsalz=[email-masked]
>     <mailto:[email-masked]>>
>     <mailto:[email-masked]>>>>
>      >>      > wrote:
>      >>      >
>      >>      >      >
>      >>      >     <https://github.com/larseggert/bcp45bis/pull/1/files
>     <https://github.com/larseggert/bcp45bis/pull/1/files>>>
>      >>      >
>      >>      >     Looks good to me.
>      >>      >
>      >>      >     --
>      >>      >     Gendispatch mailing list
>      >>      > [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>
>      >>      > https://www.ietf.org/mailman/listinfo/gendispatch
>      >>      >     <https://www.ietf.org/mailman/listinfo/gendispatch
>     <https://www.ietf.org/mailman/listinfo/gendispatch>>>
>      >>      >
>      >>      >
>      >>
>      >>      --
>      >>      Gendispatch mailing list

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 20 Jul 2021 14:19:31 -0700

> intent to you EKR.  You did this in the way that seemed obvious and

Thank you for clarifying this. I appreciate it and FWIW I had not gotten the
impression that you were implying that.

-Ekr

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 21 Jul 2021 09:17:01 +1000

Overall, looks good; I left a comment/question.

> On 20 Jul 2021, at 11:06 pm, Lars Eggert <[email-masked]> wrote:
> 
> Hi,
> 

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

---

From: Lars Eggert <[email-masked]>
Date: Wed, 21 Jul 2021 10:54:25 +0300

Hi,

On 2021-7-21, at 0:08, Joel M. Halpern <[email-masked]> wrote:
> Given that this was an edge case in terms of standing, I think it is important that comments be on the list.  The fact that EKR and Lars would prefer to see discussions in PR doesn't change that.

I posted a link to the GitHub PR when asking for feedback, because that was the easiest way for me to present the proposed changes, and in a form that is IMO very clear and lets those that feel inclined to do so provide suggestions in a form that is very easy for me to merge without messing something up.

Nowhere did I say that I preferred discussion on GitHub over discussions on the list, or that I wouldn't incorporate suggestions made on the list?

I'll note that it is common practice to include links to document content in emails, instead of the text itself - for example, I-D announcements don't include the text of an I-D but a pointer to it.

Thanks,
Lars

---

From: Lars Eggert <[email-masked]>
Date: Wed, 21 Jul 2021 10:55:56 +0300

Hi,

thanks for the suggestions on the list and in GitHub; a version of the proposed change with those rolled in is at https://github.com/larseggert/bcp45bis/pull/1/files

Thanks,
Lars

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 21 Jul 2021 08:49:54 -0400

1) I did not object to your initial posting on this topic.  I understood 
the tradeoff you made.  My concern is the conclusion other people drew 
that commenting via the github was the right way to do things.  EKR and 
I have discussed on list his (useful) modification.  I was then struck 
that someone else chose to post a comment on the github rather than on 
list.  That is exactly the slope I am concerned about.

2( Maybe I should have left off the comment about rpeferences.  It was 
based on my observations of other discussions, not on this incident. 
Sorry if it was out of line.

Yours,
Joel

---

From: "Rodney W. Grimes" <[email-masked]>
Date: Wed, 21 Jul 2021 07:07:55 -0700 (PDT)

> I'll note that it is common practice to include links to document content in emails, instead of the text itself - for example, I-D announcements don't include the text of an I-D but a pointer to it.

List,

There is a slight difference here in those links, the I-D announcements
are to what I shall call an "internal IETF source", while the github,
and yes, in many other cases are "external sources".  The future of
internal sources are well within the control of the IETF, the future
of external sources are indeterminate, and at times, when doing
historical research of mail threads to understand how a decision
or piece of text came about is much easier if the external set of
sources is minimus.

I do think it is a slippery slope to start using  github and pull
requests for what was solicited on list discussion.

It is trivial to work around, and that would of been to post not
just the URL, but also the full text of the pull request to
the mailling list.

Regards,
-- 
Rod Grimes                                                 [email-masked]

---

From: Rob Sayre <[email-masked]>
Date: Wed, 21 Jul 2021 15:32:40 -0700

> email list, I expect folks to provide comments on the WG email list.

Is there a specific BCP / rule that applies here? I have read RFC 8874.

It seems to me that GitHub is quite a bit more transparent than private
email, or conversations during in-person IETF meetings, so it doesn't
bother me.

More generally, pushing back on this stuff seems like trying to fight the
ocean. Every organization uses similar tools now. I haven't been working on
software as long as some others, but I do remember commenting on patches
via email. That era is gone.

thanks,
Rob

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 21 Jul 2021 19:19:18 -0400

RFC *874 gives working groups the ability to decide, by rough consensus 
of the group, to make use to various degrees of github.

Specifically, until the group decides explicitly that topics are to be 
discussed on github, discussions for the WG (such as Lars' request for 
feedback) are supposed (by multiple long standing RFCs) to take place on 
the WG email list.

Someone asked "would it have been different if the suggestion had been 
by private email"?   My answer, as I understand the process, is that 
either Lars or the proposer would have repeated the suggestion to the 
list, so that it could be discussed.  (Note that the premise here is 
that the change is substantive, not merely editorial.  We give editors 
the room to make editorial corrections, and to accept them any way they 
want.)

Maybe I am tilting against the inevitable.  of course, with the rate of 
change of tools, by the time it is actually inevitable, something else 
will be inevitable instead.

Yours,
Joel

PS: I am not of either the camp "this is old and therefore good" or 
"this is new and therefore better".  I am however of the camp that if we 
want to change our procedures, we should do so by agreement, not by 
accident.  I believe that most of the folks pushing for changes also are 
trying to be explicit about getting agreement.

On 7/21/2021 6:32 PM, Rob Sayre wrote:
> More generally, pushing back on this stuff seems like trying to fight 
> the ocean. Every organization uses similar tools now. I haven't been 
> working on software as long as some others, but I do remember commenting 
> on patches via email. That era is gone.
> 
> thanks,
> Rob
> 
>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 21 Jul 2021 16:46:05 -0700

On Wed, Jul 21, 2021 at 4:19 PM Joel M. Halpern <[email-masked]> wrote:

> list, so that it could be discussed.

I mean, one of us might have. But before GitHub I routinely took proposed
changes in email or in private feedback of other kinds and folded them into
the next document rev and just informed the WG in some kind of email or
presentation summary.

More generally, I'm not aware of any IETF rules that say that people need
to raise issues on list or that the editors need to take any proposed
substantive changes to the list before they are folded into the draft, as
opposed to after. If I'm wrong here, can you provide a citation to the
relevant RFC?

-Ekr

(Note that the premise here is

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 21 Jul 2021 21:05:03 -0400

I do not expect it is written down that crisply, and I am not going to 
search.
However, the following things are the case:

Working group decisions are to be made on the list (8874 creates the 
option for a WG to change that.)

Once a document is adopted by a working group, it belongs to the WG. 
While we refer to the pen holders as authors they are expected to 
reflect the will of the working group.

For non-controversial but substantive changes, that does often translate 
to changing the document and then telling the WG.   For larger changes, 
it is usually the other way around.

Having said all that, you can argue that this case is small enough that 
it could fall into the first category.   And you could argue that the 
document was not adopted.

It may be therefore that I over-reacted to your proiding the feedback 
the way you did.

On the other hand, this is a sensitive working group, dealing with IETF 
process.  Going out of our way to maintain visibility.  And the fact 
that in response to your posting, commentary on your change itself 
appeared on the github but not on the list seems to lend credence to my 
concern.

So, I grant that legalistically I may be over-reacting.  But 
pragmatically, it seems to be a problem.

Put differently, the change you proposed could easily have been 
described in an email.  With an explanation of why you were making it.
If one is strict about the fact that documents aare almost never adopted 
in this WG (they are dispatched), it would lead one to claiming the 
right to use whatever technique one wants for discussions here.  Which I 
think is counter to the spirit of 8874.

Yours,
Joel

PS: Apologies to the gendispatch chairs for dragging us into this 
meta-discussion.   We have no appropriate place as far as I can tell to 
discuss IETF process at the moment.

On 7/21/2021 7:46 PM, Eric Rescorla wrote:
> 
> 
> On Wed, Jul 21, 2021 at 4:19 PM Joel M. Halpern <[email-masked] 
> I mean, one of us might have. But before GitHub I routinely took 
> proposed changes in email or in private feedback of other kinds and 
> folded them into the next document rev and just informed the WG in some 
> kind of email or presentation summary.
> 
> More generally, I'm not aware of any IETF rules that say that people 
> need to raise issues on list or that the editors need to take any 
> proposed substantive changes to the list before they are folded into the 
> draft, as opposed to after. If I'm wrong here, can you provide a 
> citation to the relevant RFC?
> 
> -Ekr
> 
> 
>      > On Tue, Jul 20, 2021 at 2:08 PM Joel M. Halpern

---

From: Rob Sayre <[email-masked]>
Date: Wed, 21 Jul 2021 18:20:03 -0700

> option for a WG to change that.)

Since we're discussing procedural matters, I must point out that this is
not the case. RFC8874 is Informational.

"An 'Informational' specification is published for the general information
of the Internet community, and does not represent an Internet community
consensus or recommendation."

I understand that some people in the community don't like that some
discussions have tended to move to GitHub or equivalent, but I do not think
many people object, or even have an opinion.

thanks,
Rob

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 22 Jul 2021 14:06:50 +1000

On Thu, Jul 22, 2021, at 11:20, Rob Sayre wrote:
> Since we're discussing procedural matters, I must point out that this 
> is not the case. RFC8874 is Informational.

I suspect Joel was using a shorthand here.  8874 explains how the rules of 2418 can be applied; it doesn't modify those rules, it just documents a narrow application of those rules that has been shown to be effective.

It also acknowledges circumstances similar to what is going on here too.  That is, it recognizes that decisions can be made without list discussion, accidentally or otherwise.

Still, this isn't a working group item, and even if it were, I see nothing unusual or alarming in what happened.  That assessment holds even if this were a formal working group item and the working group had deliberately rejected the use of 8874.  After all, if Lars was not using a public repository, a lot of the feedback could have been private, if only to keep the noise of the list.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 22 Jul 2021 07:05:11 -0400

Except that Lars is asking for community views, and he is treating the 
draft as if it *is* an IETF draft, and doing so from a very powerful 
position.  It is that appearance that is muddying the waters here.  Lars 
can still make whatever changes he wants to the draft, but doing so 
without consultation might upset whatever support there is for the 
draft.  Thus the mud (and I know a lot about mud ;-).  And that's 
particularly unfortunate when we are talking about a process draft about 
how we communicate.

And Joel's point about not having a place to discuss these sorts of meta 
points shouldn't be lost.  It leads me to think that the draft and our 
approach to IETF community communication is just horribly broken.

Eliot

---

From: Christian Huitema <[email-masked]>
Date: Thu, 22 Jul 2021 10:36:23 -0700

I would not say that the draft is broken, but this episode clearly 
exposes an interesting tension. Look at the progression. Draft authors 
use GitHub to coordinate the editing of the document: fair, well within 
everybody's idea of process. As the discussion goes on the mailing list, 
draft authors capture key points of the discussion and open 
corresponding issues on GitHub: again, fair, authors do need a way to 
keep track of needed improvements. Draft authors prepare updates and 
push them as PR: here again, fair, authors can the tools to agree on the 
next of the next edits. But then we do have a big tension. Some working 
group members will be very tempted to comment directly on the issues and 
PR in the GitHub repo, because it seems more efficient than pushing yet 
another email on the thread. Other working group members point out that 
this is not the agreed process, that all discussions should take place 
on the list. Insert comparison with private email to draft authors, etc. 
Add the point that there are usually many more draft contributors than 
the listed authors.

This is a mess. I see why the process asks participants to not shortcut 
the discussion on the mailing list. I also see that these shortcuts are 
a very efficient way to save time and organize comments. It comes down 
to personal habits. Software developers are very much at ease using 
issues and PRs, and perceive the insistence on using email as a form of 
hazing. Traditional protocol experts see these tools as a way to evade 
process and cut corners. Blocking the tools will in the long run exclude 
one class of participants. Allowing free use will maybe disenfranchise 
another class of participants. Kinda blocking while kinda allowing will 
just create a mess.

For the specific case in point, my proposed compromise would be to 
formalize working group adoption. The process for private drafts could 
be private, but once the draft is formally adopted the authors would 
have to follow the process adopted by the WG.

-- Christian Huitema

On 7/22/2021 4:05 AM, Eliot Lear wrote:
> position.  It is that appearance that is muddying the waters here.  
> Lars can still make whatever changes he wants to the draft, but doing 
> so without consultation might upset whatever support there is for the 
> particularly unfortunate when we are talking about a process draft 
> about how we communicate.
>
> And Joel's point about not having a place to discuss these sorts of 
> meta points shouldn't be lost.  It leads me to think that the draft 
> and our approach to IETF community communication is just horribly broken.
>
> Eliot
>
>> I suspect Joel was using a shorthand here.  8874 explains how the 
>> rules of 2418 can be applied; it doesn't modify those rules, it just 
>> documents a narrow application of those rules that has been shown to 
>> be effective.
>>
>> It also acknowledges circumstances similar to what is going on here 
>> too.  That is, it recognizes that decisions can be made without list 
>> discussion, accidentally or otherwise.
>>
>> Still, this isn't a working group item, and even if it were, I see 
>> nothing unusual or alarming in what happened.  That assessment holds 
>> even if this were a formal working group item and the working group 
>> had deliberately rejected the use of 8874.  After all, if Lars was 
>> not using a public repository, a lot of the feedback could have been 
>> private, if only to keep the noise of the list.
>>
>
>

---

From: Rob Sayre <[email-masked]>
Date: Thu, 22 Jul 2021 11:39:57 -0700

On Thu, Jul 22, 2021 at 10:36 AM Christian Huitema <[email-masked]>
wrote:

> Other working group members point out that this is not the agreed process,
> that all discussions should take place on the list.
>

I think your characterization of the debate is accurate, except for this
part. RFC 2418 says only:

"Many working group participants hold that mailing list discussion is the
best place to consider and resolve issues and make decisions."

It's definitely true that many WGs decide to force everything onto the
mailing list, but that is not required, and it is not the default.

Recently, WGs like HTTP, QUIC and TLS moved a lot of discussion to GitHub.
Some people are not used to that method of working, and don't like it.
However, it's not against the rules, or counter to any agreed process.

I also agree that there's nothing wrong with doing these edits on GitHub,
even in a list-focused WG, as long as the resulting draft is discussed on
the list.

thanks,
Rob

---

From: Jay Daley <[email-masked]>
Date: Fri, 23 Jul 2021 07:51:40 +1200

I have a practical suggestion for all of this, which may even be inadvertently on-topic for gendispatch.

How about setting up an integration testing working group with a mailing list and an associated GitHub repository and using that both as a teaching tool and for experimenting with GitHub configuration and customisation to see if we can get a list<->GitHub integration that people on both sides of the fence are happy with?

Jay

> On 23/07/2021, at 6:39 AM, Rob Sayre <[email-masked]> wrote:
> 
> On Thu, Jul 22, 2021 at 10:36 AM Christian Huitema <[email-masked] <mailto:[email-masked]>> wrote:
> Other working group members point out that this is not the agreed process, that all discussions should take place on the list.
> 
> 
> I think your characterization of the debate is accurate, except for this part. RFC 2418 says only:
> 
> "Many working group participants hold that mailing list discussion is the best place to consider and resolve issues and make decisions."
>  
> It's definitely true that many WGs decide to force everything onto the mailing list, but that is not required, and it is not the default.
> 
> Recently, WGs like HTTP, QUIC and TLS moved a lot of discussion to GitHub. Some people are not used to that method of working, and don't like it. However, it's not against the rules, or counter to any agreed process.
> 
> I also agree that there's nothing wrong with doing these edits on GitHub, even in a list-focused WG, as long as the resulting draft is discussed on the list.
> 
> thanks,
> Rob
> 
> -- 
> Gendispatch mailing list
> [email-masked]

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

---

From: Eliot Lear <[email-masked]>
Date: Thu, 22 Jul 2021 17:33:41 -0400

Hi Christian

I really like the way you describe the tension.  We all have our 
preferences and our reasons for them. To me, it is better for a group to 
simply decide which world they are primarily going to live in, and then 
live in that world, so as not to bifurcate conversations.  That solves a 
great many problems, like worrying about having to retread conversations 
due to others being surprised, or some feeling disadvantaged by the 
process for having not used the In tool.

Also, to be fair to Lars, the IETF chair job is no picnic, and trying to 
make progress in small steps is often the only way to do so.   IMHO 
we've just run out of runway, and Joel's point should provide us an 
opportunity to open a more serious discussion about how we communicate.  
Mark has written a draft about the IETF list, but I would rather we back 
off and look at what the organization needs.

As a matter of practice, history, and practicality, I disagree with Rob 
Sayre that there is no default.  RFC 2418 states plainly that-

> An IETF working group MUST have a general Internet mailing list.  Most 
> of the work of an IETF working group will be conducted on the mailing 
> list.

And the Tao largely says the same thing.  This only really matters if 
participants really can't agree on working methods. Regardless, I would 
rather we hit this issue head on, and that we hit our other 
communications problems head on as well.  I won't try to engineer the 
solution in this email, tho.

Eliot

---

From: Rob Sayre <[email-masked]>
Date: Thu, 22 Jul 2021 15:10:06 -0700

> > of the work of an IETF working group will be conducted on the mailing

Fair. This all does depend on how one interprets the circa 1998 RFC. I
thought this part meant "in public, online", but others seem to think it
means SMTP.

The RFC does allow for design teams (which can be public with open
membership), and I tend to view active GitHub participants as
self-selecting design teams.

> And the Tao largely says the same thing.

The Tao is Informational (2418 is a BCP), and out of date.

> This only really matters if
> rather we hit this issue head on
>

I do think that something like the WG Jay suggests is a good idea.

thanks,
Rob

---

From: Lars Eggert <[email-masked]>
Date: Fri, 23 Jul 2021 15:49:43 +0300

Hi,

I merged the PR; an rfcdiff of the current editor's copy against -02 is at https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-eggert-bcp45bis.txt&url2=https://larseggert.github.io/bcp45bis/draft-eggert-bcp45bis.txt

I plan to submit the editor's copy as -03 when the I-D submission window reopens.

Thanks,
Lars

---

From: Keith Moore <[email-masked]>
Date: Tue, 27 Jul 2021 09:44:43 -0400

> Would this change be something the community would supportive of?

I do not believe that the proposed changes are sufficient, and strongly 
object to the proposal in the cited PR request.

I do fully agree with the need for an SAA, and IMO every deliberative 
body of significant importance needs such a role to maintain comity in 
discussions and (perhaps more importantly) keep them from going off the 
rails due to interpersonal disputes. However it is absolutely essential 
that this role be both independent of the leadership and narrowly 
constructed, so that the SAA does not and cannot be used to marginalize 
people whose input the leadership wishes to suppress.

I strongly believe that the SAA role has been abused in the past in 
precisely this way, and that this has had, and may continue to have, a 
significant chilling effect on IETF's ability to serve as a 
consensus-making body for the benefit of the broader Internet community.

Neither the IETF Chair nor the IESG should be choosing SAAs, nor should 
they be setting policy for SAAs.   I would be fine with the SAAs being 
chosen by either the IAB or the Nomcom.   The SAAs should strictly 
follow IETF Consensus as stated in BCP45 and other IETF Consensus 
documents.

The policies should be relatively unambiguous, and uniformly interpreted 
without prejudice for or against any individual.   So the SAAs should 
NOT be encouraged to "take into account the overall nature of the 
postings by an individual and whether particular postings are an 
aberration or typical".    But neither should the SAAs' remedies be 
limited to restricting posting by a person or of a thread - lesser 
remedies should be available so that occasional inappropriate postings 
can be remedied without drastic action.

All SAA actions (other than private feedback to an individual) should be 
recorded so that they are visible to the community.

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 27 Jul 2021 09:51:13 -0400

On 7/22/21 1:36 PM, Christian Huitema wrote:

> use GitHub to coordinate the editing of the document: fair, well 
> within everybody's idea of process. As the discussion goes on the 
> mailing list, draft authors capture key points of the discussion and 
> open corresponding issues on GitHub: again, fair, authors do need a 
> way to keep track of needed improvements. Draft authors prepare 
> updates and push them as PR: here again, fair, authors can the tools 
> to agree on the next of the next edits. But then we do have a big 
> tension. Some working group members will be very tempted to comment 
> directly on the issues and PR in the GitHub repo, because it seems 
> more efficient than pushing yet another email on the thread. Other 
> working group members point out that this is not the agreed process, 
> that all discussions should take place on the list. Insert comparison 
> with private email to draft authors, etc. Add the point that there are 
> usually many more draft contributors than the listed authors.
>
> This is a mess. I see why the process asks participants to not 
> shortcut the discussion on the mailing list. I also see that these 
> shortcuts are a very efficient way to save time and organize comments. 
> It comes down to personal habits. Software developers are very much at 
> ease using issues and PRs, and perceive the insistence on using email 
> as a form of hazing. Traditional protocol experts see these tools as a 
> way to evade process and cut corners. Blocking the tools will in the 
> long run exclude one class of participants. Allowing free use will 
> maybe disenfranchise another class of participants. Kinda blocking 
> while kinda allowing will just create a mess.
>
I agree with Christian's description of the situation.   I do not know 
of a good solution.

In general, when a discussion is fragmented by any means, it becomes 
difficult for all participants to keep track of what's being said, more 
difficult to determine whether consensus exists or what it is.   
Frequent interim meetings (whether in person or virtual) present similar 
problems.

Keith

---

From: Andrew Campling <[email-masked]>
Date: Tue, 27 Jul 2021 19:15:27 +0000

On Tue 22nd July 2021 at 14:51, Keith Moore <[email-masked]> wrote:
> I agree with Christian's description of the situation.   I do not know of a good solution.
>
> In general, when a discussion is fragmented by any means, it becomes difficult for all participants to keep track of what's being said, more difficult to determine whether consensus exists or what it is. Frequent interim meetings (whether in person or virtual) present similar problems.

+1

Issues relating to the use of GitHub continue to crop up on various mailing lists, clearly current working practices are not satisfactory.  This seems like a good topic to raise yet again at the IETF Plenary tomorrow.  

Andrew

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 27 Jul 2021 12:22:28 -0700

On Tue, Jul 27, 2021 at 12:15 PM Andrew Campling
<[email-masked]> wrote:

> difficult to determine whether consensus exists or what it is. Frequent
> interim meetings (whether in person or virtual) present similar problems.
>
> +1
>
> Issues relating to the use of GitHub continue to crop up on various
> mailing lists, clearly current working practices are not satisfactory.
> This seems like a good topic to raise yet again at the IETF Plenary
> tomorrow.
>

Well, I agree that the current practices are not satisfactory, but that's
because there are strong disagreements about what the best practices are,
and so we have a compromise which doesn't fully satisfy anyone, that being
the nature of compromise.

-Ekr

---

From: Rob Sayre <[email-masked]>
Date: Sat, 31 Jul 2021 00:41:39 -0700

I noticed I was having hard time distinguishing parts of this discussion
from the classic “Simple Sabotage Field Manual”.  Here is the most relevant
section:

Organizations and Conferences

   - *Insist on doing everything through “channels.” Never permit
   short-cuts to be taken in order to expedite decisions.*
   - *Make “speeches.” Talk as frequently as possible and at great length.
   Illustrate your “points” by long anecdotes and accounts of personal
   experiences.*
   - *When possible, refer all matters to committees, for “further study
   and consideration.” Attempt to make the committee as large as possible —
   never less than five.*
   - *Bring up irrelevant issues as frequently as possible.*
   - *Haggle over precise wordings of communications, minutes, resolutions.*
   - *Refer back to matters decided upon at the last meeting and attempt to
   re-open the question of the advisability of that decision.*
   - *Advocate “caution.” Be “reasonable” and urge your fellow-conferees to
   be “reasonable” and avoid haste which might result in embarrassments or
   difficulties later on.*