Subject: Diversity and Inclusiveness in the IETF

From: Fernando Gont <[email-masked]>
Date: Mon, 22 Feb 2021 21:07:19 -0300

Folks,

We have submitted a new I-D, entitled "Diversity and Inclusiveness in 
the IETF".

The I-D is available at: 
https://www.ietf.org/archive/id/draft-gont-diversity-analysis-00.txt

We expect that our document be discussed in the gendispatch wg 
(https://datatracker.ietf.org/wg/gendispatch/about/). But given the 
breadth of the topic and possible views, we'll be glad to discuss it
where necessary/applicable/desired.

As explicitly noted in our I-D, we're probably only scratching the 
surface here -- but we believe that our document is probably a good 
start to discuss many aspects of diversity that deserve discussion.

Thanks!

Regards,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: "Bron Gondwana" <[email-masked]>
Date: Tue, 23 Feb 2021 15:19:34 +1100

Thanks Fernando,

I would add to this document something about inertia, backwards compatibility and existing dysfunction.

Many ideas are shut down because they aren't in the right place, or don't fit comfortably into the existing corpus of IETF documents.

When we brought JMAP to the IETF it was after a long process of socialisation, and still there was significant work in the first couple of meetings just to convince people that "this is worth doing, the existing work the IETF has done in this neighborhood is not sufficient".

JMAP also had an authentication scheme in it originally.  It was a good authentication scheme, but applications don't do authentication schemes, that's the bailiwick of OAUTH, where ideas go to die (in my experience, that working group has been dysfunctional for my entire time at IETF - exhibit 'A' being the "Milestones" section of the about page, which lists 6 items all due in 2017)

So we just removed all mention of authentication method and handwaved "the connection will be authenticated", because we wanted to publish something during the decade with years starting '201'.

... all that to say.  One of the biggest barriers to entry in the IETF is stumbling across an area in which no work is able to progress due to entrenched issues within that area.

And I'm not arguing for "no barriers to entry", because there needs to be a sanity check that we're actually producing high quality specifications, and that our specifications are compatible with each other so the entirety of the IETF's work product is a coherent whole.  But it's hard to get started if you don't already have the connections to have your work sponsored by somebody who already knows their way around the IETF's idiosyncrasies.  I'm doing some of that sponsoring myself now for the people from tc39 who are trying to get the IETF to look at defining an extended datetime format.

Cheers,

Bron.

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  [email-masked]

---

From: Keith Moore <[email-masked]>
Date: Mon, 22 Feb 2021 23:33:58 -0500

On 2/22/21 11:19 PM, Bron Gondwana wrote:

> One of the biggest barriers to entry in the IETF is stumbling across 
> an area in which no work is able to progress due to entrenched issues 
> within that area.

+1

> But it's hard to get started if you don't already have the connections 
> to have your work sponsored by somebody who already knows their way 
> around the IETF's idiosyncrasies.
Agree.  And yet, you shouldn't be required to work with any specific 
person to get around those idiosyncrasies.   Perhaps we need better ways 
for new contributors to identify experienced people who can help them 
navigate those treacherous waters?  Or maybe we could do a better job of 
documenting those idiosyncrasies?

Conditions do change over time.  Sometimes people keep fighting old 
battles that made sense at one time based on an old set of conditions, 
but may keep fighting those battles after those conditions have changed 
and the old concerns no longer apply.

Keith

---

From: Dominique Lazanski <[email-masked]>
Date: Tue, 23 Feb 2021 09:18:16 +0100

I would support Bron’s experience and also say that there are several other barriers to entry that I’ve found. One is different approaches to topics than the mainstream IETF approach held by most IETF attendees. I am thinking about privacy/encryption, for example. But the other big barrier to entry is the draft upload tools. For a new person attending for the first time the tools are a relic of 1990 of thereabouts and can be confusing and difficult.

In any case, I shall join the gendispatch group to discuss further!

Dominique

> On 23 Feb 2021, at 05:19, Bron Gondwana <[email-masked]> wrote:
> 
> Thanks Fernando,
> 
>> https://www.ietf.org/archive/id/draft-gont-diversity-analysis-00.txt <https://www.ietf.org/archive/id/draft-gont-diversity-analysis-00.txt>
>> 
>> (https://datatracker.ietf.org/wg/gendispatch/about/ <https://datatracker.ietf.org/wg/gendispatch/about/>). But given the 
>> e-mail: [email-masked] <mailto:[email-masked]>
>   [email-masked] <mailto:[email-masked]>

---

From: Fernando Gont <[email-masked]>
Date: Tue, 23 Feb 2021 05:34:20 -0300

Hello, Bron,

> compatibility and existing dysfunction.

Could you elaborate a bit more on what you mean by each of these?

And, if you could provide examples, and any suggestions on what might be 
done to fix or improve the issue, that would also be nice.

[...]
> 
> ... all that to say.  One of the biggest barriers to entry in the IETF 
> is stumbling across an area in which no work is able to progress due to 
> entrenched issues within that area.

Agree on this one.

> And I'm not arguing for "no barriers to entry", because there needs to 
> be a sanity check that we're actually producing high quality 
> specifications, and that our specifications are compatible with each 
> other so the entirety of the IETF's work product is a coherent whole.  

Also agree on this one.

Thanks!

Regards,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 23 Feb 2021 05:40:23 -0300

Hello, Dominique,

On 23/2/21 05:18, Dominique Lazanski wrote:
> I would support Bron’s experience and also say that there are several 
> other barriers to entry that I’ve found. One is different approaches to 
> topics than the mainstream IETF approach held by most IETF attendees. I 
> am thinking about privacy/encryption, for example.

Could you elaborate a bit more on this one? e.g., some example (so that 
we can understand better what you mean)... and if you can think of 
anything that might be done to improve things in this respect, that 
would also be nice.

> But the other big 
> barrier to entry is the draft upload tools. For a new person attending 
> for the first time the tools are a relic of 1990 of thereabouts and can 
> be confusing and difficult.

FWIW, we have already started to work on a revision of the draft 
(working copy at: 
https://github.com/fgont/diversity/blob/main/draft-gont-diversity-analysis-01.txt), 
and this is what we currently have in the Section 8.2 of the upcoming rev:

---- cut here ----
8.2.  Difficulty in Authoring and Submitting Internet-Drafts

    There are so many formatting rules that an Internet-Draft (and
    eventually an RFC) needs to comply to, that in practice the only
    reasonable way create and submit an Internet-Draft is via the set of
    tools available at: https://tools.ietf.org/ . Tools such as xml2rfc
    are of a lot of help to produce documents that comply with the
    Internet-Draft formatting rules -- but its error messages might
    result cryptic to the unexperienced user.

    The number of tools has expanded so much that they probably deserve
    their own guidelines.  And existing guidelines such as
    [ID-Guidelines] should probably be updated with the assumption that
    Internet-Drafts will be produced with the set of available tools.

       This means that e.g. it becomes less important to the Internet-
       Draft author what formatting rules a document needs to comply to,
       since the existing tools will guarantee such compliance.  On the
       other hand, an author may benefit from guidelines on how to use
       the set of available tools.
---- cut here ----

Is there anything you'd suggest adding to it?

> In any case, I shall join the gendispatch group to discuss further!

Please do, but also feel free to discuss it here if you wish, too.

Thanks a lot!

Regards,

---

From: Dominique Lazanski <[email-masked]>
Date: Tue, 23 Feb 2021 09:50:06 +0100

> On 23 Feb 2021, at 09:40, Fernando Gont <[email-masked]> wrote:
> 
> Hello, Dominique,
> 
>> I would support Bron’s experience and also say that there are several other barriers to entry that I’ve found. One is different approaches to topics than the mainstream IETF approach held by most IETF attendees. I am thinking about privacy/encryption, for example.
> 
> Could you elaborate a bit more on this one? e.g., some example (so that we can understand better what you mean)... and if you can think of anything that might be done to improve things in this respect, that would also be nice.
> 

Sure! This is purely my experience, but I have found it challenging (and hostile) to engage in controversial topics which don’t have consensus. I think encryption is the most obvious one and consolidation another. I don’t want to dwell on the issues, but would rather suggest solutions. I think it would be great to organise open sessions of an hour just on these topics focused specifically on having difficult and challenging conversations only about one topic. Obviously we have open IAB, plenary and etc, but a focused, short meeting would be one idea.

> 
>> But the other big barrier to entry is the draft upload tools. For a new person attending for the first time the tools are a relic of 1990 of thereabouts and can be confusing and difficult.
> 
> FWIW, we have already started to work on a revision of the draft (working copy at: https://github.com/fgont/diversity/blob/main/draft-gont-diversity-analysis-01.txt), and this is what we currently have in the Section 8.2 of the upcoming rev:
> 
> ---- cut here ----

This is great news! I will definitely go to git and add a few things.

Dominique

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 23 Feb 2021 09:51:06 +0000

Hi Fernando,

I just took a quick look at the document and I missed one point that increasingly worries me working in the IETF, namely the increasing number of participants who are not interested to write any code*.
I would include this aspect under diversity, particularly when talking about the new leadership election cycles.

Participating in some working groups I more and more get the impression to sit in a document writing class rather than in an Internet engineering organization.

Ciao
Hannes

*: I am also including authors of protocol specifications that do not implement their own specifications.

-----Original Message-----
From: ietf <[email-masked]> On Behalf Of Fernando Gont
Sent: Tuesday, February 23, 2021 1:07 AM
To: [email-masked]' <[email-masked]>; GENDISPATCH List <[email-masked]>; Keith Moore <[email-masked]>
Subject: Diversity and Inclusiveness in the IETF

Folks,

We have submitted a new I-D, entitled "Diversity and Inclusiveness in the IETF".

The I-D is available at:

We expect that our document be discussed in the gendispatch wg (https://datatracker.ietf.org/wg/gendispatch/about/). But given the breadth of the topic and possible views, we'll be glad to discuss it where necessary/applicable/desired.

As explicitly noted in our I-D, we're probably only scratching the surface here -- but we believe that our document is probably a good start to discuss many aspects of diversity that deserve discussion.

Thanks!

Regards,

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 23 Feb 2021 11:05:53 +0100

On 2021-02-23, at 05:33, Keith Moore <[email-masked]> wrote:
> 
> And yet, you shouldn't be required to work with any specific person to get around those idiosyncrasies.  

While this is a desirable goal, it also is a lofty one.

The reality in *any* organization is that it is easier to do things for people who know the organization than for those who don’t.  (We have a German word for that, Stallgeruch, which is hard to translate, so I’m not going into more details here.)

The objective can only ever be to make the organization *more* accessible.
I believe finding a shepherd for new work is exactly the right way to approach the IETF, and I applaud Bron for playing this role with datetime-new.

(I found Bron’s telling of the deleterious effects of fashions like “everything must be done in OAuth” refreshing; our work has also been hit by this one, but is now slowly emerging, albeit in a rather damaged way, from ACE.  But avoiding fashions is maybe orthogonal to making the organization more accessible from the outside — fashions damage insiders, too.  It is also not easy to recognize a fashion from a groundswell.)

Grüße, Carsten

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 23 Feb 2021 11:00:04 +0000

Hi Bron,

I have to respond to your statements about the OAuth working group below.

While we do not pay attention to keeping the charter page up-to-date, we have been able to advance our documents, produce many implementations, and got those deployed all over the Internet.

The bar for acceptance of new work varies among working group in the IETF. Some working groups develop technology that got widely deployed and hence randomly changing specs isn't such a great idea because you have to consider the deployment situation as well. This is a situation many IETF working groups face. Reaching (widespread) deployment is great on one hand and a pain on the other.

There are other groups, which are early in their lifecycle. In those groups you do not need to worry about deployments, backwards compatibility or even any source code.

In general, Rifaat and I are always open for anyone in the IETF (and outside) to reach out to us, if they want to bring new work forward to the group. Sometimes proposed work fits into the group and sometimes it does not. The work on JOSE, for example, was put into a separate working group even though it was initially developed for use with JSON Web Tokens.

I don't recall having chatted with you or with someone from the JMAP community on the use of OAuth. Sorry if my memory does not serve me well today.  Typically, applications just use OAuth and therefore there is no need to reach out to the OAuth working group.

Ciao
Hannes

From: ietf <[email-masked]> On Behalf Of Bron Gondwana
Sent: Tuesday, February 23, 2021 5:20 AM
To: [email-masked]
Subject: Re: Diversity and Inclusiveness in the IETF

Thanks Fernando,

Cheers,

Bron.

The I-D is available at:

Thanks!

Regards,
--
Fernando Gont
SI6 Networks
e-mail: [email-masked]<mailto:[email-masked]>
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  [email-masked]<mailto:[email-masked]>

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 23 Feb 2021 11:01:09 +0000

Dominique, could you expand on your privacy/encryption experience a little bit?

Ciao
Hannes

From: ietf <[email-masked]> On Behalf Of Dominique Lazanski
Sent: Tuesday, February 23, 2021 9:18 AM
To: Bron Gondwana <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: Diversity and Inclusiveness in the IETF

Dominique

On 23 Feb 2021, at 05:19, Bron Gondwana <[email-masked]<mailto:[email-masked]>> wrote:

Thanks Fernando,

Cheers,

Bron.

The I-D is available at:

Thanks!

Regards,

---

From: "Bron Gondwana" <[email-masked]>
Date: Tue, 23 Feb 2021 22:50:49 +1100

Without wishing to litigate the entire issue here (happy to remove the wider IETF list and just talk on the OAuth group), we never brought any work to the OAuth group because everybody who we spoke to warned us that nothing would get done.

There's a term "missing stair" https://en.wikipedia.org/wiki/Missing_stair which describes this phenomenon, where "everybody knows" something, but new participants are forced to discover it through either having someone tell them quietly, or just notice it for themselves.

...

Just as an anecdote, the last time I bothered to attend an OAuth meeting in person I had this to say about it on our internal slack channel when asked:"they can't agree about what they don't agree on".

The topic that had taken basically the entire meeting and had been totally unproductive - was a particular key in a JSON Web Token going to clash with a reserved word in either javascript itself or one of the other environments in which this token had to be evaluated.  There were people saying "this won't work, just rename the key" and others saying "I like this name and insist upon us keeping it".  No progress was made that day.

In fact, here's the extract of my report on the OAuth meeting at IETF102 (a detailed long email with pictures of poutine, icecream, and a report on every session I attended).  Names extracted to protect the others involved, but other text left exactly as it was, complete with typoes:

> *Thursday 19th: (Aug 2018)*
> 
> *9:30am* OAUTH <https://datatracker.ietf.org/meeting/102/materials/agenda-102-oauth-03>:  Fecking OAUTH as they say.  I came out of this saying "they can't even agree about what they don't agree on".  <Name redacted> says it was even worse in the past.  What a fustercluck.  Don't expect anything workwhile out of this group unfortunately.  <Other name redacted> and I were just looking at each other like WTF the entire time.

Maybe it's become heaps better since then.  But I wouldn't want to have been a new participant trying to get anything done in that session.

...

The authentication flow as originally put into JMAP (before it came to the IETF) can be seen in the initial draft here if you're interested:

https://www.ietf.org/archive/id/draft-jenkins-jmap-00.txt

But we decided in the interests of expediency to just drop it rather than trying to progress that work anywhere at the IETF.

Regards,

Bron.

> The bar for acceptance of new work varies among working group in the IETF. Some working groups develop technology that got widely deployed and hence randomly changing specs isn’t such a great idea because you have to consider the deployment situation as well. This is a situation many IETF working groups face. Reaching (widespread) deployment is great on one hand and a pain on the other.

> I don’t recall having chatted with you or with someone from the JMAP community on the use of OAuth. Sorry if my memory does not serve me well today.  Typically, applications just use OAuth and therefore there is no need to reach out to the OAuth working group.

> *From:* ietf <[email-masked]> *On Behalf Of * Bron Gondwana
> *Sent:* Tuesday, February 23, 2021 5:20 AM
> *To:* [email-masked]
> *Subject:* Re: Diversity and Inclusiveness in the IETF

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Tue, 23 Feb 2021 07:40:43 -0500

So you have never reached out to us to try to bring any work to the WG, and
based on attending one meeting and hearing from a few people, you formed a
strong opinion and declared that "nothing would get done"? that seems odd.

For your information, last year we published 4 RFCs, and we already have 3
documents with the IESG and more to come.

If you have anything you want to bring to the OAuth WG, Hannes and I would
be happy to discuss this with you or anyone that wants to bring work to the
OAuth WG.

Regards,
 Rifaat

On Tue, Feb 23, 2021 at 6:52 AM Bron Gondwana <[email-masked]>
wrote:

> Without wishing to litigate the entire issue here (happy to remove the
> wider IETF list and just talk on the OAuth group), we never brought any
> work to the OAuth group because everybody who we spoke to warned us that
> nothing would get done.
>
> There's a term "missing stair" https://en.wikipedia.org/wiki/Missing_stair
> which describes this phenomenon, where "everybody knows" something, but new
> participants are forced to discover it through either having someone tell
> them quietly, or just notice it for themselves.
>
> ...
>
> Just as an anecdote, the last time I bothered to attend an OAuth meeting
> in person I had this to say about it on our internal slack channel when
> asked:"they can't agree about what they don't agree on".
>
> The topic that had taken basically the entire meeting and had been totally
> unproductive - was a particular key in a JSON Web Token going to clash with
> a reserved word in either javascript itself or one of the other
> environments in which this token had to be evaluated.  There were people
> saying "this won't work, just rename the key" and others saying "I like
> this name and insist upon us keeping it".  No progress was made that day.
>
> In fact, here's the extract of my report on the OAuth meeting at IETF102
> (a detailed long email with pictures of poutine, icecream, and a report on
> every session I attended).  Names extracted to protect the others involved,
> but other text left exactly as it was, complete with typoes:
>
> *9:30am* OAUTH
> <https://datatracker.ietf.org/meeting/102/materials/agenda-102-oauth-03>:
> Fecking OAUTH as they say.  I came out of this saying "they can't even
> agree about what they don't agree on".  <Name redacted> says it was even
> worse in the past.  What a fustercluck.  Don't expect anything workwhile
> out of this group unfortunately.  <Other name redacted> and I were just
> looking at each other like WTF the entire time.
>
>
> Maybe it's become heaps better since then.  But I wouldn't want to have
> been a new participant trying to get anything done in that session.
>
> ...
>
> The authentication flow as originally put into JMAP (before it came to the
> IETF) can be seen in the initial draft here if you're interested:
>
> But we decided in the interests of expediency to just drop it rather than
> trying to progress that work anywhere at the IETF.
>
> Regards,
>
> Bron.
>
> While we do not pay attention to keeping the charter page up-to-date, we
> have been able to advance our documents, produce many implementations, and
> got those deployed all over the Internet.
>
>
>
> The bar for acceptance of new work varies among working group in the IETF.
> Some working groups develop technology that got widely deployed and hence
> randomly changing specs isn’t such a great idea because you have to
> consider the deployment situation as well. This is a situation many IETF
> working groups face. Reaching (widespread) deployment is great on one hand
> and a pain on the other.
>
>
>
> There are other groups, which are early in their lifecycle. In those
> groups you do not need to worry about deployments, backwards compatibility
> or even any source code.
>
>
>
> In general, Rifaat and I are always open for anyone in the IETF (and
> outside) to reach out to us, if they want to bring new work forward to the
> group. Sometimes proposed work fits into the group and sometimes it does
> not. The work on JOSE, for example, was put into a separate working group
> even though it was initially developed for use with JSON Web Tokens.
>
>
>
> I don’t recall having chatted with you or with someone from the JMAP
> community on the use of OAuth. Sorry if my memory does not serve me well
> today.  Typically, applications just use OAuth and therefore there is no
> need to reach out to the OAuth working group.
>
>
>
> Ciao
>
> Hannes
>
>
>
> Many ideas are shut down because they aren't in the right place, or don't
> fit comfortably into the existing corpus of IETF documents.
>
>
>
> When we brought JMAP to the IETF it was after a long process of
> socialisation, and still there was significant work in the first couple of
> meetings just to convince people that "this is worth doing, the existing
> work the IETF has done in this neighborhood is not sufficient".
>
>
>
> JMAP also had an authentication scheme in it originally.  It was a good
> authentication scheme, but applications don't do authentication schemes,
> that's the bailiwick of OAUTH, where ideas go to die (in my experience,
> that working group has been dysfunctional for my entire time at IETF -
> exhibit 'A' being the "Milestones" section of the about page, which lists 6
> items all due in 2017)
>
>
>
> So we just removed all mention of authentication method and handwaved "the
> connection will be authenticated", because we wanted to publish something
> during the decade with years starting '201'.
>
>
>
> ... all that to say.  One of the biggest barriers to entry in the IETF is
> stumbling across an area in which no work is able to progress due to
> And I'm not arguing for "no barriers to entry", because there needs to be
> a sanity check that we're actually producing high quality specifications,
> and that our specifications are compatible with each other so the entirety
> of the IETF's work product is a coherent whole.  But it's hard to get
> started if you don't already have the connections to have your work
> sponsored by somebody who already knows their way around the IETF's
> idiosyncrasies.  I'm doing some of that sponsoring myself now for the
> people from tc39 who are trying to get the IETF to look at defining an
> extended datetime format.
>
>
>
> Cheers,
>
>
>
> Bron.
>
>
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>
>
> --

---

From: "Bron Gondwana" <[email-masked]>
Date: Tue, 23 Feb 2021 23:46:34 +1100

On Tue, Feb 23, 2021, at 23:40, Rifaat Shekh-Yusef wrote:
> So you have never reached out to us to try to bring any work to the WG, and based on attending one meeting and hearing from a few people, you formed a strong opinion and declared that "nothing would get done"? that seems odd.

Based on a few meetings, and having heard from many people.

> For your information, last year we published 4 RFCs, and we already have 3 documents with the IESG and more to come.

That's good to hear.

> If you have anything you want to bring to the OAuth WG, Hannes and I would be happy to discuss this with you or anyone that wants to bring work to the OAuth WG.

Thanks.  I don't mean to pick on OAuth specifically, but I also would recommend that you ask around and see whether my view of the culture of the OAuth working group is widely shared within the IETF or whether I've managed to find myself inside a small echo chamber that has a poor opinion of the welcoming-ness of the working group.

Either way, the fact that the participants of the JMAP working group (including myself) who were all new to the IETF at the time were warned that OAuth is not a place where you can reasonably expect to get your work advanced is an indictment of SOMETHING, and that's worth having a think about in terms of making the IETF a welcoming place.

Regards,

Bron.

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 23 Feb 2021 12:46:48 +0000

Hi Bron,

Let me also tell you a personal story. I was in the army in Austria and a commander of a small group. Everyone on the base knew about a pub in the city that was extremely dangerous and, according to stories, you would most likely get stabbed there. I was wondering about that place and went there. Guess what: I was there alone with the waitress. Everyone was too afraid to go there.

Maybe there is a lesson here. Just give it a try*.

Getting back to the OAuth group: Groups typically go through cycles. At the beginning when participants do not know each other the discussions are often rough. When there is not much content (typically during a requirements gathering phase) everyone has an opinion to share. As time goes on, the situation improves and everyone gets to know each other better, hangs around after the official WG meetings and meets at non-IETF events. That’s where it gets more civilized. We went through those stages as well.

Groups that work on exciting technologies also attract “rock stars” (as I call them). We had those in the OAuth group as well. It caused a lot of stress for the entire group but also for us chairs. When you have several people who do not accept a proposal different than their own then it gets tricky. Unfortunately, chairs don’t have much to say in the IETF either.

I believe it helped us to get together in workshops (we organized a series of OAuth workshops), met at industry events (the Internet Identity Workshop, etc.) and scheduled regular “virtual office hours”. Of course, we still have disagreements and it would be a lie to say that all our meetings have been productive. Productivity has, however, been increased. The meetings were certainly passionate. On the other hand, I have been in working group meetings where there was no passion, no discussion and no productivity. Not great either.

I don’t know whether it is already too late for your document (which is dated 2016) to consider the use of OAuth but Rifaat and I are happy to put you on the spot in one of our future virtual office hours or virtual interim meetings.

Ciao
Hannes

PS: This is not a general life advice. There are many things you better skip...

From: Bron Gondwana <[email-masked]>
Sent: Tuesday, February 23, 2021 12:51 PM
To: Hannes Tschofenig <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: Diversity and Inclusiveness in the IETF

...

Thursday 19th: (Aug 2018)

9:30am OAUTH<https://datatracker.ietf.org/meeting/102/materials/agenda-102-oauth-03>:  Fecking OAUTH as they say.  I came out of this saying "they can't even agree about what they don't agree on".  <Name redacted> says it was even worse in the past.  What a fustercluck.  Don't expect anything workwhile out of this group unfortunately.  <Other name redacted> and I were just looking at each other like WTF the entire time.

...

Regards,

Bron.

Hi Bron,

Ciao

Hannes

From: ietf <[email-masked]<mailto:[email-masked]>> On Behalf Of Bron Gondwana
Sent: Tuesday, February 23, 2021 5:20 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: Diversity and Inclusiveness in the IETF

Thanks Fernando,

Cheers,

Bron.

Folks,

the IETF".

The I-D is available at:

Thanks!

Regards,

--

Fernando Gont

SI6 Networks

--

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 23 Feb 2021 13:37:10 +0000

Hiya,

On 23/02/2021 08:18, Dominique Lazanski wrote:
> One is different approaches to topics than the mainstream IETF
> approach held by most IETF attendees. 
> I am thinking about privacy/encryption...
That topic differs from others in this discussion
in that the IETF has repeatedly debated it in lots
of detail, and with many different opinions being
factored in, and over decades, and has established a
set of rough consensus positions after significant
informed debate on a topic where IETF participants
are pretty well qualified to claim expertise.

Other aspects of this discussion relate to things
where we've not really noticed that we even have a
position, e.g. the use of terms that were considered
ok in the past, but aren't today, or where we're not
at all expert, e.g. handling our own biases.

I think our approach to handling claims that we'd
be better to change should validly differ in the
above two cases - it is *much* harder to bring
really new information in the former case than in
the latter for example.

Cheers,
S.

---

From: Keith Moore <[email-masked]>
Date: Tue, 23 Feb 2021 08:56:34 -0500

> While this is a desirable goal, it also is a lofty one.

To clarify, one of the complaints that we have heard is that a newcomer 
was told that he had to work with one specific person or he could not 
expect to succeed in IETF.

I certainly agree that it's likely to remain difficult for a newcomer to 
get consensus around an RFC in an established area without help from a 
more experienced IETF participant.

(Though I also remember that when I first started writing drafts, the 
notion of "shepherd" did not exist yet.   I definitely had supportive 
comments and constructive suggestions from other participants via 
private email after I submitted my initial draft, and I had been on the 
working group mailing list since before the group was chartered so I was 
familiar with the conversation. IETF was smaller then than it is now, 
but not that much smaller. What's changed is that we have more 
bureaucracy, more rules, and a much wider and more diverse range of 
increasingly narrow interests.)

> I believe finding a shepherd for new work is exactly the right way to approach the IETF, and I applaud Bron for playing this role with datetime-new.

I don't have a problem with people being encouraged to find a shepherd 
(though perhaps not required to do so).   I only have a problem if 
someone is told "you MUST work with this one person". Sometimes this 
kind of relationship can be used to manipulate or use the newer person 
to support poor technical or political positions.

> (I found Bron’s telling of the deleterious effects of fashions like “everything must be done in OAuth” refreshing; our work has also been hit by this one, but is now slowly emerging, albeit in a ra…

Since I consider OAuth rather limited in its applicability (especially 
if you don't believe every application should be tied to the web) and 
kind of dangerous (from a privacy perspective), I was appalled to read that.

Keith

---

From: Dan Harkins <[email-masked]>
Date: Tue, 23 Feb 2021 06:21:23 -0800

Hi Hannes,

> I just took a quick look at the document and I missed one point that increasingly worries me working in the IETF, namely the increasing number of participants who are not interested to write any co…

   That's a great point! One of the attractions (to me, at least) of the 
IETF was
that it wasn't some guy with some slides and a story. It was someone 
with an idea,
a reference implementation of the idea, and results of (partially) 
deploying the
code and seeing what it did. That was very compelling. We learned things 
from the
running code that actually helped improve the specification. We were doing
engineering!

   When I think back on it, such a demand to have running code must've 
been quite
a barrier to inclusiveness (which might've had an impact on some axes of 
diversity)
for some. But isn't that a good thing? Doesn't a certain amount of 
exclusivity, or
demand for some standard for participation, result in better product? I 
think it
does. We should be engineering the Internet. I hope we don't throw out 
the baby
with the bathwater when we get so focused on diversity and inclusion.

   Yes, there has been less and less a demand on running code (sadface 
emoji) and
I share your worry. Not only are some participants not interested in 
writing any
code, we are also coming up with work that does not require any code at 
all. Look
at the WG that people want to charter here! There is no demand for any code
whatsoever. And there is even a reluctance to state a linkage between 
proposal and
desired result, the basis of our engineering-- "how we get there with 
this idea" is
not to be discussed. This is all very worrying.

   regards,

   Dan.

-- 
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius

---

From: Roman Danyliw <[email-masked]>
Date: Tue, 23 Feb 2021 14:29:40 +0000

Hi!

From: ietf <[email-masked]> On Behalf Of Bron Gondwana
Sent: Tuesday, February 23, 2021 7:47 AM
To: Rifaat Shekh-Yusef <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: Diversity and Inclusiveness in the IETF

That's good to hear.

[Roman] In addition to regular cadence of proposed standard publications noted above, I would additionally note that all of these documents came with a model behavior of multiple implementations by WGLC - typically 3+.  The WG has not only managed to steadily complete its work items in the IETF but also interest an implementor community to ensure this work is used.

Regards,
Roman

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 23 Feb 2021 10:20:51 -0500

On Tue, Feb 23, 2021 at 9:30 AM Roman Danyliw <[email-masked]> wrote:

> *Sent:* Tuesday, February 23, 2021 7:47 AM
> *To:* Rifaat Shekh-Yusef <[email-masked]>
> *Cc:* [email-masked]; [email-masked]
> So you have never reached out to us to try to bring any work to the WG,
> and based on attending one meeting and hearing from a few people, you
> formed a strong opinion and declared that "nothing would get done"? that
> seems odd.
>
>
>
> [Roman] In addition to regular cadence of proposed standard publications
> noted above, I would additionally note that all of these documents came
> with a model behavior of multiple implementations by WGLC – typically 3+.
> The WG has not only managed to steadily complete its work items in the IETF
> but also interest an implementor community to ensure this work is used.
>

And way back when I was AD, OAuth was by far the most productive working
group I managed.  They put out what felt like about 3 documents a meeting
for full publication.  I was the AD for 3 years, ending in 2017 when EKR
became an AD.

There was a bit of management as a result of the number of experts and
varying use cases for their environments, but even with that, OAuth was
very productive.  Since your document was 2016, I was likely the AD.  Yes,
the meetings had challenges at times, but we worked through it and things
got done.

Best regards,
Kathleen

-- 

Best regards,
Kathleen

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 23 Feb 2021 10:42:13 -0500

While not exactly on point, participants in this thread may be
interested in https://tools.ietf.org/html/rfc4144

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [email-masked]

---

From: Fernando Gont <[email-masked]>
Date: Tue, 23 Feb 2021 12:20:59 -0300

On 23/2/21 06:51, Hannes Tschofenig wrote:
> Hi Fernando,
> 
> I just took a quick look at the document and I missed one point that
> increasingly worries me working in the IETF, namely the increasing
> number of participants who are not interested to write any code*.

It could be the case that people are not interested, or that they don't 
have the time, or that they are not familiar with an open source project 
to contribute code. It could be any of them, and it's probably difficult 
to tell.

In some cases, whether a WG gives value to an implementation might 
encourage or discourage work on an implementation.

And then there are other things, such as:
* Each open source project has it's own culture.

* Some are very welcoming. Others not so much.

* Some will help for you to implement things, others (usually smaller) 
projects might try or want to implement stuff themselves.

And, as with other things, whether somebody has support from his/her 
employer will also have an effect -- e.g., if you have a pay job and do 
IETF stuff independently, then you probably won't have enough time to 
work on a draft and participating in the discussions, let alone 
implementing it.

Then there are other things. e.g., I once did multiple implementations 
fo a document I had co-authored, and provided pointers to the 
implementations in an appendix. One IETF participant took the time to 
ask each project to back out the commits "because the document had not 
yet become an RFC".

> I would include this aspect under diversity, particularly when
> talking about the new leadership election cycles.

Could you elaborate a bit more on this one? And what you'd like to see?

> Participating in some working groups I more and more get the
> impression to sit in a document writing class rather than in an
> Internet engineering organization.

One possible explanation is that energy is a finite resource: the more 
bureaucracy and politics involved, the lesser the time to commit to 
other things.

Thanks,

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 23 Feb 2021 18:13:35 +0100

On 2021-02-23, at 16:20, Fernando Gont <[email-masked]> wrote:
> 
> In some cases, whether a WG gives value to an implementation might encourage or discourage work on an implementation.

Not an unimportant point.

If the perception of people bringing work is that acceptance in the IETF is mostly aleatoric, they’ll think twice before investing in an implementation before significant advancement.

This is particularly true if they already have a proprietary implementation that will need significant work before it makes all of IETF’s checkmarks.

I’m not saying anything of this is wrong or actually fixable.

Grüße, Carsten

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 24 Feb 2021 09:20:11 +1300

I suggest up-levelling this sub-thread away from one specific WG to a more general point, which IMNSHO is not really about diversity or inclusiveness at all.

Some newcomers to the IETF, even if they have many years of professional experience, find it hard to get started here, and a good fraction of them give up. (I dare say that we could actually measure that with a clever look at the statistics.) In particular, people with a specific goal (get WG X to do Y) are often disappointed.

I don't think that has anything to do with diversity or inclusivity. It has to do with:
a) The Internet is complicated. Problems that look simple turn out to be very hard. That can look like the IETF is being difficult.
b) The IETF has learned the hard way that narrowly chartered WGs tend to succeed (or fail quickly). If WG X isn't chartered to do Y, it won't get done there.
c) Yes, the process of building support for Y, and if necessary building support for a Y BOF and forming a Y WG, is complex both technically and sociologically. That's nothing to do with diversity or inclusiveness. It's just hard.
d) Sometimes the IETF has actually taken a strategic decision that precludes Y. I'm not sure what aspects of privacy/encryption Dominique refers to, but there's no doubt that the IETF has long-standing consensuses in those areas and *of course* that would be very hard to change. That doesn't excuse bad interpersonal behaviour, of course.

Regards
   Brian Carpenter

---

From: Keith Moore <[email-masked]>
Date: Tue, 23 Feb 2021 16:46:05 -0500

On 2/23/21 3:20 PM, Brian E Carpenter wrote:

> d) Sometimes the IETF has actually taken a strategic decision that precludes Y. I'm not sure what aspects of privacy/encryption Dominique refers to, but there's no doubt that the IETF has long-standing consensuses in those areas and*of course*  that would be very hard to change. That doesn't excuse bad interpersonal behaviour, of course.

I mostly agree with the above, except that I do think that inclusivity 
(or lack thereof) is often a factor for reasons other than you cite 
above.   People /are/ discriminated against because of their employers 
(or who their employers aren't), the way they use the English language 
and whether that causes them difficulty, their cultural conventions and 
how well those conventions mesh with expectations of IETF participants, 
their technical backgrounds, whether they seem to "know their places" in 
others' eyes, and a great many other reasons.

(I do take some exception to (b).   IETF often fails to resolve 
fundamental tussles by making WGs that are narrowly focused, and this 
results in a kind of fragmentation of the Internet that encourages 
architectural dead ends.   But trying to resolve the tussle as a 
precondition for trying to make progress doesn't always work well either.)

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 24 Feb 2021 10:50:28 +1300

Hannes,

> I just took a quick look at the document and I missed one point that increasingly worries me working in the IETF, namely the increasing number of participants who are not interested to write any co…

Can you justify "increasing number"? I don't mean compared to 1986, but compared (for example) to 2011? As long as I can remember, people have been concerned about participants who are "goers" rather than "doers" at meetings, and you seem to be adding a further concern, "doers" whose action is to write text rather than write code.

Also, you don't mention operators, whose role is not to write code at all but whose contribution to the IETF is essential. So that's another category of "doers".

I'd like to see some actual facts about these various categories of "doers". What % were they 10 or 20 years ago, and what % are they now? Has the hackathon changed the numbers? Etc.

> I would include this aspect under diversity, particularly when talking about the new leadership election cycles.

Yes, it should be on NomCom's radar. The need for enough ops people has long been understood, but recent development experience is also relevant.

> Participating in some working groups I more and more get the impression to sit in a document writing class rather than in an Internet engineering organization.

Since our principal output is text, that isn't so surprising, but I think there's a case for sending any spec that does not adhere to RFC7942/BCP205 back to the WG.

> *: I am also including authors of protocol specifications that do not implement their own specifications.

That's a bit cruel. In larger organisations, it might be totally infeasible. But again, RFC7942 is our friend.

Regards
    Brian

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 24 Feb 2021 08:57:06 +1100

> On 24 Feb 2021, at 2:20 am, Kathleen Moriarty <[email-masked]> wrote:
[...]
> And way back when I was AD, OAuth was by far the most productive working group I managed.  They put out what felt like about 3 documents a meeting for full publication.  I was the AD for 3 years, ending in 2017 when EKR became an AD.
> 
> There was a bit of management as a result of the number of experts and varying use cases for their environments, but even with that, OAuth was very productive.  Since your document was 2016, I was likely the AD.  Yes, the meetings had challenges at times, but we worked through it and things got done.

Measuring productivity through the number of documents published is not a good habit for us to get into; it gives incentive to all of the wrong kinds of behaviours. Having some success metrics for our work has come up in the IAB a few times, but we haven't made much progress.  

Cheers,

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

---

From: Keith Moore <[email-masked]>
Date: Tue, 23 Feb 2021 17:00:59 -0500

On 2/23/21 4:57 PM, Mark Nottingham wrote:

> Measuring productivity through the number of documents published is not a good habit for us to get into; it gives incentive to all of the wrong kinds of behaviours.

+1.

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Tue, 23 Feb 2021 17:11:03 -0500

On Tue, Feb 23, 2021 at 4:57 PM Mark Nottingham <[email-masked]> wrote:

> Measuring productivity through the number of documents published is not a
> good habit for us to get into;

The number of documents published was in response to a comment that
"nothing would get done" at the OAuth WG. Which is clearly not true.

> it gives incentive to all of the wrong kinds of behaviours.

Can you elaborate on these wrong behaviours?

Regards,
 Rifaat

> Having some success metrics for our work has come up in the IAB a few
> times, but we haven't made much progress.
>
> Cheers,
>
>
> --
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: "Bron Gondwana" <[email-masked]>
Date: Wed, 24 Feb 2021 09:18:55 +1100

On Wed, Feb 24, 2021, at 09:11, Rifaat Shekh-Yusef wrote:
>> Measuring productivity through the number of documents published is not a good habit for us to get into;
> 
> The number of documents published was in response to a comment that "nothing would get done" at the OAuth WG. Which is clearly not true.

Yeah, that wasn't a very clear comment, sorry, though I would still say that having your milestones all say 2017 doesn't suggest to a drive-by tourist that the group is making progress.  I'm not sure if there's a norm across the IETF that 

The impression that I got when joining IETF was that OAuth would not be welcoming to any new work which didn't fit their existing view of the world, and that they were not making good progress with the work they were trying to do.  Maybe that impression was wrong - if so, it was definitely a widely held wrong impression among the people I talked to.

Bron.

---

From: Mary Barnes <[email-masked]>
Date: Tue, 23 Feb 2021 16:26:16 -0600

Hannes,

Ditto to what Brian said.

I no longer write code although I have written LOTS of code for lots of
systems for nearly 20 years that have run in the real world for decades
(there's still Nortel DMS cranking away out there).   And, while I write
specs, I do work very closely with those implementing the specs and I don't
write specs for things that aren't being considered as potential
products/real systems.    I ask lots of questions when I'm working with
those coding, so I'm confident folks do understand what it is they're
implementing.   I worked with  contractors implementing ACME for one
company a few years back and I knew they didn't understand because I could
see the questions they were asking in the open forums and I knew they were
misinterpreting those responses.  I found the place in the Let's Encrypt
code where they needed to hook in the new code and I was almost at the
point of writing the code myself over a weekend with my son, but it was
their job.

There's far more value in my being able to educate the folks coding,
provide architectural feedback, talk to vendors to ensure that what they
are providing meets the requirements (security in particular) as well as
testing the system after it's been coded and providing feedback.   And, in
my experience, the coding is the easy part. When I was a developer, that
was the fun part - the reward after you got all the required documentation
written.   And, I always develop specs from the perspective that a
developer needs to use that as the basis for writing code, so I know how I
would want things written to facilitate that process.

So, your point about people writing specs not being the ones writing code
is a little judgemental.  I would say "elitist" and that's how it comes
off, but I don't consider those that write code necessarily to be the
elite.  But, it is this notion that there are certain types of people at
IETF that are amongst the elite that is one of the issues around
inclusion.

Regards,
Mary.

On Tue, Feb 23, 2021 at 3:51 PM Brian E Carpenter <
[email-masked]> wrote:

> increasingly worries me working in the IETF, namely the increasing number
> of participants who are not interested to write any code*.
>
> Can you justify "increasing number"? I don't mean compared to 1986, but
> compared (for example) to 2011? As long as I can remember, people have been
> concerned about participants who are "goers" rather than "doers" at
> meetings, and you seem to be adding a further concern, "doers" whose action
> is to write text rather than write code.
>
> Also, you don't mention operators, whose role is not to write code at all
> but whose contribution to the IETF is essential. So that's another category
> of "doers".
>
> I'd like to see some actual facts about these various categories of
> "doers". What % were they 10 or 20 years ago, and what % are they now? Has
> the hackathon changed the numbers? Etc.
>
> > I would include this aspect under diversity, particularly when talking
> about the new leadership election cycles.
>
> Yes, it should be on NomCom's radar. The need for enough ops people has
> long been understood, but recent development experience is also relevant.
>
> > Participating in some working groups I more and more get the impression
> to sit in a document writing class rather than in an Internet engineering
> organization.
>
> Since our principal output is text, that isn't so surprising, but I think
> there's a case for sending any spec that does not adhere to RFC7942/BCP205
> back to the WG.
>
> > Ciao
> > Hannes
> >
> That's a bit cruel. In larger organisations, it might be totally
> infeasible. But again, RFC7942 is our friend.
>
> Regards
>     Brian
> >
> > To: [email-masked]' <[email-masked]>; GENDISPATCH List <
> [email-masked]>; Keith Moore <[email-masked]>
> > We expect that our document be discussed in the gendispatch wg (
> https://datatracker.ietf.org/wg/gendispatch/about/). But given the
> breadth of the topic and possible views, we'll be glad to discuss it where
> necessary/applicable/desired.
> >
> surface here -- but we believe that our document is probably a good start
> to discuss many aspects of diversity that deserve discussion.
> >
> > Thanks!
> >
> > Regards,
> > --
> > Fernando Gont
> > SI6 Networks
> Gendispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gendispatch
>

---

From: Bill Woodcock <[email-masked]>
Date: Tue, 23 Feb 2021 23:26:36 +0100

> On Feb 23, 2021, at 10:50 PM, Brian E Carpenter <[email-masked]> wrote:

Yep.

PCH has been an active participant in the IETF for some 28 years, and we’re not a code-writing shop, we’re an operator.  We have very strong feelings about what’s needed, and we also know that we aren’t going to be the ones writing that code, we’re going to be the ones fielding it and trying to make it scale.  So, yes, we care about the success of the IETF and the open standards process and multistakeholderism, because it’s all vital to our being able to hold up our end of things.

Writing code is one critical aspect of the IETF.  Writing specifications is another critical aspect of the IETF.  Testing interoperability is yet another.  None of these stand alone, and none work without the others.

                                -Bill

---

From: Tim Bray <[email-masked]>
Date: Tue, 23 Feb 2021 14:34:03 -0800

Fair enough, but since this started around the OAuth working group, my
perception is that those RFCs don't just get published, they get adopted.
Or they used to back when I worked full time in the identity space.

On Tue, Feb 23, 2021 at 2:01 PM Keith Moore <[email-masked]>
wrote:

> > Measuring productivity through the number of documents published is not
> a good habit for us to get into; it gives incentive to all of the wrong
> kinds of behaviours.
>
> +1.
>
>
>
>

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 23 Feb 2021 14:39:24 -0800

Replying to Rifaat's e-mail but not replying to him specifically.

Hi folks,

I don't think the question of whether OAuth is a good or bad WG group is
really a productive one in general, and it's especially hard for me to see
how it's going to let us make progress on questions of DEI. This seems like
precisely the kind of thing that's going to lead to a bunch of hard
feelings without making progress. I think we can all agree that the IETF
culture isn't perfect and that there are cases where we make it hard for
new people to get involved, so maybe we could focus instead on those
aspects of our culture.

I would suggest that if people have problems with the way the OAuth WG is
being run they ought to take it up with the AD (Roman Danyliw), or, failing
that, on the IETF list.

-Ekr

On Tue, Feb 23, 2021 at 2:12 PM Rifaat Shekh-Yusef <[email-masked]>
wrote:

>> > And way back when I was AD, OAuth was by far the most productive
>> working group I managed.  They put out what felt like about 3 documents a
>> meeting for full publication.  I was the AD for 3 years, ending in 2017
>> when EKR became an AD.
>> >

---

From: "Bron Gondwana" <[email-masked]>
Date: Wed, 24 Feb 2021 09:41:54 +1100

On Wed, Feb 24, 2021, at 09:39, Eric Rescorla wrote:
> I don't think the question of whether OAuth is a good or bad WG group is really a productive one in general, and it's especially hard for me to see how it's going to let us make progress on questions of DEI. This seems like precisely the kind of thing that's going to lead to a bunch of hard feelings without making progress. I think we can all agree that the IETF culture isn't perfect and that there are cases where we make it hard for new people to get involved, so maybe we could focus instead on those aspects of our culture.
> 
> I would suggest that if people have problems with the way the OAuth WG is being run they ought to take it up with the AD (Roman Danyliw), or, failing that, on the IETF list.

Agree - and sorry for derailing the conversation with this thing!

Bron.

---

From: Keith Moore <[email-masked]>
Date: Tue, 23 Feb 2021 19:24:10 -0500

> > Measuring productivity through the number of documents published is 
> not a good habit for us to get into; it gives incentive to all of the 
> wrong kinds of behaviours.
>
> +1.
>
On 2/23/21 5:34 PM, Tim Bray wrote:

> perception is that those RFCs don't just get published, they get 
> adopted.  Or they used to back when I worked full time in the identity 
> space.

Just to clarify, my "+1" above had nothing to do with the number of 
documents produced by the OAuth WG.   I was talking about the number of 
documents produced by IETF in general.

Keith

---

From: "Jim Fenton" <[email-masked]>
Date: Tue, 23 Feb 2021 17:10:19 -0800

On 23 Feb 2021, at 5:56, Keith Moore wrote:

> notion of "shepherd" did not exist yet.   I definitely had 
> supportive comments and constructive suggestions from other 
> participants via private email after I submitted my initial draft, and 
> I had been on the working group mailing list since before the group 
> was chartered so I was familiar with the conversation. IETF was 
> smaller then than it is now, but not that much smaller. What's changed 
> is that we have more bureaucracy, more rules, and a much wider and 
> more diverse range of increasingly narrow interests.)

If the sort of “shepherd” you’re referring to is a Document 
Shepherd, by the time one is assigned many newcomers would have long 
since given up. My experience is that a shepherd is assigned once a 
document has reached WG rough consensus and wants to advance the 
document. Of course the document isn’t finished at that point and 
still has to pass muster with IESG, but a lot has had to happen to get 
to that point.

The various mentor programs do more to promote diversity and 
inclusiveness than document shepherds, IMO.

-Jim

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 24 Feb 2021 00:47:03 -0500

I am worried by the advice 'use OAUTH' but for a very different reason.

OAUTH and SAML are both attempts to provide a secure authentication scheme
that works within the very particular and very peculiar environment of Web
browsers. They are schemes that necessarily involve techniques that are
rightly regarded as alchemy if not outright witchcraft.

That is fine, that is more than fine if you are developing an
authentication scheme for use within Web browsers (or if you are developing
whatever SAML and OAUTH are these days, neither was originally billed as
authentication). But it is completely inappropriate to ever suggest let
alone demand that anyone use a technology whose primary design constraint
is to work around the voodoo of Javascript, URIs, HTTP cookies etc. etc. in
an application where none of those legacy issues apply.

One of the big problems of IETF is that a lot of people don't think about
how to get their scheme deployed and when they do, their plan is to tie it
to some other group as a boat anchor. Back when we were doing DKIM and SPF
we had to tell certain DNS folk that the fact that almost no DNS Registrars
offered customers the ability to specify new RRTypes was their problem and
was going to remain their problem no matter how loudly they tried to
complain that it should become our problem.

In the case of OAUTH, there is another problem in that OAUTH really isn't a
very open protocol from the standpoint of the user. I can use my Google or
my Facebook or my Twitter accounts to log in via OAUTH at a large number of
sites. But if I want to use any other OAUTH provider I am completely out of
luck. Or at least I will be until this becomes one of the multifaceted
complaints in the anti-trust hearings coming soon to a capitol hill near
you. And yes, that is a consequence of how the protocol has been deployed,
but that probably not going to get people very far on capitol hill.

The Internet is for everyone. The Internet is for end users.

I am really not that interested in who makes the ingredients except to the
extent that it determines what sort of cake emerges. One of the unexpected
side effects of Web 2.0 has been that it has greatly centralized power in
the hands of a tiny number of individuals. Individuals who are at best
accountable to shareholders, but in the case of some of them, a separate
share class ensures that they are accountable to nobody. In neither case
are the people with power accountable to end users because they are not
even customers, they are the product.

What I am interested in is the extent to which Internet technologies are
Technologies of Freedom. The question we need to ask ourselves is 'does
this technology increase end user autonomy or increase their reliance on
third parties'.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 24 Feb 2021 17:01:22 +1100

Just to +1 and add my bit: in my mind one of the fundamental flaws of the Web is that it is basically a platform construction toolkit, without any of the checks or balances we put into *real* internet platforms to assure that there isn't one chokepoint with all of the power. As a result, it's tilted heavily towards winner-take-all economists through accrual of network effects and data advantages.

We should not follow this pattern in IETF specifications, whether or not they're associated with the Web. OAUTH-as-deployed might be one good example, but WEBRTC is equally problematic in this regard. WEBTRANS smells like it's primarily going to benefit big platforms who want to control the entire end user experience (and have the resources to exploit it), and let's not even get started about WPACK.

Yes, federation is hard. Yes, standards are slow and not as able to respond. Yes, the commercial incentives for silo'd platforms to invest aren't present. However, there's a *huge* push by competition authorities and regulators to find remedies for the concentrations of power in these few hands, and in many minds interoperability standards -- enforced by legal instruments -- are a primary means of getting there. This is potentially game-changing, in terms of the work that's possible to ship here.

I wrote a bit more about this recently:
  https://www.mnot.net/blog/2021/02/18/no-news

Cheers,

> On 24 Feb 2021, at 4:47 pm, Phillip Hallam-Baker <[email-masked]> wrote:
> 
> OAUTH and SAML are both attempts to provide a secure authentication scheme that works within the very particular and very peculiar environment of Web browsers. They are schemes that necessarily involve techniques that are rightly regarded as alchemy if not outright witchcraft.
> 
> That is fine, that is more than fine if you are developing an authentication scheme for use within Web browsers (or if you are developing whatever SAML and OAUTH are these days, neither was originally billed as authentication). But it is completely inappropriate to ever suggest let alone demand that anyone use a technology whose primary design constraint is to work around the voodoo of Javascript, URIs, HTTP cookies etc. etc. in an application where none of those legacy issues apply.
> 
> One of the big problems of IETF is that a lot of people don't think about how to get their scheme deployed and when they do, their plan is to tie it to some other group as a boat anchor. Back when we were doing DKIM and SPF we had to tell certain DNS folk that the fact that almost no DNS Registrars offered customers the ability to specify new RRTypes was their problem and was going to remain their problem no matter how loudly they tried to complain that it should become our problem. 
> 
> In the case of OAUTH, there is another problem in that OAUTH really isn't a very open protocol from the standpoint of the user. I can use my Google or my Facebook or my Twitter accounts to log in via OAUTH at a large number of sites. But if I want to use any other OAUTH provider I am completely out of luck. Or at least I will be until this becomes one of the multifaceted complaints in the anti-trust hearings coming soon to a capitol hill near you. And yes, that is a consequence of how the protocol has been deployed, but that probably not going to get people very far on capitol hill.
> 
> 
> I am really not that interested in who makes the ingredients except to the extent that it determines what sort of cake emerges. One of the unexpected side effects of Web 2.0 has been that it has greatly centralized power in the hands of a tiny number of individuals. Individuals who are at best accountable to shareholders, but in the case of some of them, a separate share class ensures that they are accountable to nobody. In neither case are the people with power accountable to end users because they are not even customers, they are the product.
> 
> What I am interested in is the extent to which Internet technologies are Technologies of Freedom. The question we need to ask ourselves is 'does this technology increase end user autonomy or increase their reliance on third parties'.

---

From: Larry Masinter <[email-masked]>
Date: Tue, 23 Feb 2021 22:07:56 -0800

Cogent argument that brings to focus on the  Subject:  topic what seemed like a “side” conversation about friendliness of the OAUTH wg. 

From: ietf <[email-masked]> On Behalf Of Phillip Hallam-Baker
Sent: Tuesday, February 23, 2021 9:47 PM
To: Kathleen Moriarty <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: Diversity and Inclusiveness in the IETF

---

From: Jim Manico <[email-masked]>
Date: Wed, 24 Feb 2021 01:26:32 -0500

I think it’s important to point out that OAuth is not an authentication protocol. It’s for delegation. OAuth is one of the most mis-used protocols on the modern web. If you really want to support end users, a good place to start is to make it clear to developers what OAuth is really for so secure solutions are built as opposed to the dumpster fire that OAuth solutions have become today.

Regards,
--
Jim Manico
@Manicode
Secure Coding Education

> On Feb 24, 2021, at 12:48 AM, Phillip Hallam-Baker <[email-masked]> wrote:
> 
>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 24 Feb 2021 07:36:55 +0100

>> (Though I also remember that when I first started writing drafts, the notion of "shepherd" did not exist yet.   I definitely had supportive comments and constructive suggestions from other participants via private email after I submitted my initial draft, and I had been on the working group mailing list since before the group was chartered so I was familiar with the conversation. IETF was smaller then than it is now, but not that much smaller. What's changed is that we have more bureaucracy, more rules, and a much wider and more diverse range of increasingly narrow interests.)
> 
> If the sort of “shepherd” you’re referring to is a Document Shepherd, by the time one is assigned many newcomers would have long since given up. My experience is that a shepherd is assigned once a document has reached WG rough consensus and wants to advance the document. Of course the document isn’t finished at that point and still has to pass muster with IESG, but a lot has had to happen to get to that point.
> 
> The various mentor programs do more to promote diversity and inclusiveness than document shepherds, IMO.

Shepherd maybe wasn’t the best choice of word (no, I didn’t mean the document shepherd).

A mentor is someone who helps a person becoming more productive in the IETF.
In our current program, this is more of a temporary arrangement, for an IETF or so.

What is really useful for a new technology to come in is someone who is rooted in the IETF, but also understands that new technology and helps the promoters of that technology to frame their proposal in a way that it makes sense in the IETF.  Somewhat different from a mentor.

If it is clear where the new technology is to go, a WG chair can sometimes do that job.
When there isn’t a good fit, that technology shepherd is more sorely needed, and more difficult to find.

Grüße, Carsten

---

From: "Bron Gondwana" <[email-masked]>
Date: Wed, 24 Feb 2021 18:06:52 +1100

> I think it’s important to point out that OAuth is not an authentication protocol. It’s for delegation. OAuth is one of the most mis-used protocols on the modern web. If you really want to support e…

https://en.wikipedia.org/wiki/The_purpose_of_a_system_is_what_it_does

Which suggests that if the OAuth solutions deployed today are dumpster fires, then ... well, that's what OAuth 2 does.

My biggest problem with OAuth as an outsider is that it doesn't solve the NxM problem.  You can't build a client which can OAuth against any arbitrary OAuth service that provides a standard protocol, because you need to get an API key for your particular application from each service provider.  This just doesn't scale, which is a large part of Phillip's complaint as well.

Of course, I came into the IETF having already read https://web.archive.org/web/20120731155632/http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/ - which was one of the things which made me wary of the IETF in the first place, and keen to not let everything I touched get over-complicated.

Bron.

---

From: Keith Moore <[email-masked]>
Date: Wed, 24 Feb 2021 02:22:17 -0500

This.

- Keith

On 2/24/21 12:47 AM, Phillip Hallam-Baker wrote:
> OAUTH and SAML are both attempts to provide a secure authentication 
> scheme that works within the very particular and very peculiar 
> environment of Web browsers. They are schemes that necessarily involve 
> techniques that are rightly regarded as alchemy if not outright 
> witchcraft.
>
> authentication scheme for use within Web browsers (or if you are 
> developing whatever SAML and OAUTH are these days, neither was 
> originally billed as authentication). But it is completely 
> inappropriate to ever suggest let alone demand that anyone use a 
> technology whose primary design constraint is to work around the 
> voodoo of Javascript, URIs, HTTP cookies etc. etc. in an application 
> where none of those legacy issues apply.
>
> One of the big problems of IETF is that a lot of people don't think 
> about how to get their scheme deployed and when they do, their plan is 
> to tie it to some other group as a boat anchor. Back when we were 
> doing DKIM and SPF we had to tell certain DNS folk that the fact that 
> almost no DNS Registrars offered customers the ability to specify new 
> RRTypes was their problem and was going to remain their problem no 
> matter how loudly they tried to complain that it should become our 
> problem.
>
> In the case of OAUTH, there is another problem in that OAUTH really 
> isn't a very open protocol from the standpoint of the user. I can use 
> my Google or my Facebook or my Twitter accounts to log in via OAUTH at 
> a large number of sites. But if I want to use any other OAUTH provider 
> I am completely out of luck. Or at least I will be until this becomes 
> one of the multifaceted complaints in the anti-trust hearings coming 
> soon to a capitol hill near you. And yes, that is a consequence of how 
> the protocol has been deployed, but that probably not going to get 
> people very far on capitol hill.
>
>
> I am really not that interested in who makes the ingredients except to 
> the extent that it determines what sort of cake emerges. One of the 
> unexpected side effects of Web 2.0 has been that it has greatly 
> centralized power in the hands of a tiny number of individuals. 
> Individuals who are at best accountable to shareholders, but in the 
> case of some of them, a separate share class ensures that they are 
> accountable to nobody. In neither case are the people with power 
> accountable to end users because they are not even customers, they are 
> the product.
>
> What I am interested in is the extent to which Internet technologies 
> are Technologies of Freedom. The question we need to ask ourselves is 
> 'does this technology increase end user autonomy or increase their 
> reliance on third parties'.
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 24 Feb 2021 07:22:24 +0000

Hi Mary,

It is great to hear that you also consider coding the fun part.

Note that I am not saying that those who do not write code are not allowed to participate in the working group. Far from the truth. If you have read through the OAuth discussion you may have noticed that I am a big advocate of involving an wide range of expertise.

To the point: IMHO there has to be a difference between the document author and other participants, most of which are passive. I see the role of a document author being more than just the person writing the text. Hopefully that person cares enough about the work he or she proposes to go the extra mile. If a document author does not care about implementing his or her protocol then we have a problem.

Implementations, even if they are just prototypes, provide valuable feedback during the work on a specification. Someone has to do this work. Writing an implementation of a protocol can easily be several times the effort of writing a specification.
I doubt it is a good approach to just wait till someone does the work for you.

I am seeing this happening today in the IETF in many working groups.

Do you agree that

  *   Implementations provide valuable feedback during the standardization work,
  *   Someone has to do the implementation work,
  *   Implementations are time consuming (even if they are fun for many to write)?

The culture of hands-on work needs to be more than a responsibility of the document authors. It is a culture that has to cut across the organization, from working group chairs to the IESG. Currently, there are disincentives to work on code as a document author.

I want people with hands-on experience in the leadership of an engineering organization. For me this is a form of diversity.

I hope this clarifies my point and convinces you that this is not about an elitist view.

Ciao
Hannes

From: Mary Barnes <[email-masked]>
Sent: Tuesday, February 23, 2021 11:26 PM
To: Brian E Carpenter <[email-masked]>
Cc: Hannes Tschofenig <[email-masked]>; Fernando Gont <[email-masked]>; [email-masked]; GENDISPATCH List <[email-masked]>; Keith Moore <[email-masked]>
Subject: Re: [Gendispatch] Diversity and Inclusiveness in the IETF

Hannes,

I no longer write code although I have written LOTS of code for lots of systems for nearly 20 years that have run in the real world for decades (there's still Nortel DMS cranking away out there).   And, while I write specs, I do work very closely with those implementing the specs and I don't write specs for things that aren't being considered as potential products/real systems.    I ask lots of questions when I'm working with those coding, so I'm confident folks do understand what it is they're implementing.   I worked with  contractors implementing ACME for one company a few years back and I knew they didn't understand because I could see the questions they were asking in the open forums and I knew they were misinterpreting those responses.  I found the place in the Let's Encrypt code where they needed to hook in the new code and I was almost at the point of writing the code myself over a weekend with my son, but it was their job.

There's far more value in my being able to educate the folks coding, provide architectural feedback, talk to vendors to ensure that what they are providing meets the requirements (security in particular) as well as testing the system after it's been coded and providing feedback.   And, in my experience, the coding is the easy part. When I was a developer, that was the fun part - the reward after you got all the required documentation written.   And, I always develop specs from the perspective that a developer needs to use that as the basis for writing code, so I know how I would want things written to facilitate that process.

So, your point about people writing specs not being the ones writing code is a little judgemental.  I would say "elitist" and that's how it comes off, but I don't consider those that write code necessarily to be the elite.  But, it is this notion that there are certain types of people at IETF that are amongst the elite that is one of the issues around inclusion.

Regards,
Mary.

On Tue, Feb 23, 2021 at 3:51 PM Brian E Carpenter <[email-masked]<mailto:[email-masked]>> wrote:
Hannes,

Regards
    Brian
> From: ietf <[email-masked]<mailto:[email-masked]>> On Behalf Of Fernando Gont
> To: [email-masked]<mailto:[email-masked]>' <[email-masked]<mailto:[email-masked]>>; GENDISPATCH List <[email-masked]<mailto:[email-masked]>>; Keith Moore <[email-masked]<mailto:[email-masked]>>

--
Gendispatch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/gendispatch
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 24 Feb 2021 07:33:28 +0000

Hi Keith, Hi Phil,

I am trying to level up a bit here and not focus on OAuth or SAML.

When someone suggests you to use a certain technology then there is typically an entire context that comes with the question that led to this recommendation. Since we don’t know the context, it is hard to say whether the recommendation is reasonable.

I think we can all agree that there are many aspects involved of making a technology choice. Some of those choices are business related, with the availability of software and with the familiarity of the concepts by those using the technology.

What I also see happening again and again is that people confuse protocols with the deployment of protocols. Phil does this below too. Just because Facebook, Google & Co decide to use OAuth in some specific way does not mean that OAuth cannot be deployed by others in a completely different way.

Unfortunately, I don’t see how any of this relates to the diversity discussion. I would therefore suggest to move this discussion to the OAuth group. There are so many aspects in Phil’s email that require clarifications...
Ciao
Hannes

From: ietf <[email-masked]> On Behalf Of Keith Moore
Sent: Wednesday, February 24, 2021 8:22 AM
To: [email-masked]
Subject: Re: Diversity and Inclusiveness in the IETF

This.

- Keith

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 24 Feb 2021 07:49:27 +0000

Hi Carsten,

> What is really useful for a new technology to come in is someone who is rooted in the IETF, but also understands that new technology and helps the promoters of that technology to frame their propos…

I am wondering whether we are a bit naive about the guidance we can provide to newcomers. The bias among engineers is so huge. Look at the discussion this week where we have learned
* to use OAuth,
* not to go to the OAuth group because "ideas go there to die", and
* we have seen that many don't understand OAuth but are not afraid to share their view nevertheless.

Guess how many perspectives you will get when you ask about some other area of work (NAT, IoT security, etc.).

I have seen one IETF persons making one statement in a working group meeting in the morning and the completely opposite statement in another group in the afternoon.
You can almost expect that the positions change from one meeting to the next.  I am not going to mention examples and persons.

Ciao
Hannes

---

From: S Moonesamy <[email-masked]>
Date: Wed, 24 Feb 2021 00:15:08 -0800

Hi Fernando, Keith,
>We have submitted a new I-D, entitled "Diversity and Inclusiveness 

Thanks for submitting an I-D about the topic.  Some of the issues in 
the draft were identified previously: http://r.elandsys.com/r/49289

Companies operating at the regional or local level do not see the ROI 
(Section 4).  The problem is more complicated than that.  The 
approach taken was to provide aid through fellowships.  The 
organization which provided fellowships was not too happy about the 
IETF reviewing that.  There was some past feedback for the 
"university problem".  There was someone who explained the 
problem.  I don't remember whether it was fixed.

There has been suggestions over the years to provide summaries of 
discussions instead of sticking to "read the archives".

The stance over the years was that attendance fees are to support the 
IETF.  That could have been true in the past.  The total meeting 
revenue in 2018 was USD 3,908,825 and the total meeting expenses was 
3,089,369.  I doubt that the IETF would be cover its expenses if it 
relied on meeting attendance to cover its expenses.

As a comment about IETF culture, I see people using it as a reference 
for other groups to follow.  In my opinion, it might be viewed as 
offensive or against the social norms of the group.

Regards,
S. Moonesamy

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 24 Feb 2021 08:47:40 +0000

Hi Brian,

Thanks for the questions.

> Can you justify "increasing number"? I don't mean compared to 1986, but compared (for example) to 2011? As long as I can remember, people have been concerned about participants who are "goers" rath…

[Hannes] I started noticing it after the IETF started the hackathons, which gave implementers more visibility. In the groups I participate in, I regularly ask around for volunteers to join the hackathon. Then, you get an idea who is interested to participate and who isn't. The hackathons are also a "light" form of coding because you are selecting a really small specification aspect only. Hence, the bar is pretty low for entry. At f2f hackathons you also have a number of people joining who use the event to chat. So, you have to take this into account as well.

[Hannes] Since I am attending a small number of the working groups I am obviously curious whether others have made a similar observation. Maybe I am hanging around in the "wrong" groups. I also attend OAuth and TLS, which are different. In those two groups a lot of implementation and deployment work is happening.

> Also, you don't mention operators, whose role is not to write code at all but whose contribution to the IETF is essential. So that's another category of "doers".

[Hannes] Actually, I wouldn't make this distinction because it is really about the persons involved. Every bigger organization has people who are more disconnected from the engineering than others. That's totally fine. Also consider that we are not talking about writing product-quality implementations in this conversation. Those implementations are often, with the level of specialization in our world, created and maintained by bigger teams in a company. With our regularly changing drafts I would recommend to wait with product-quality code till the specification matures or is completed.

> I'd like to see some actual facts about these various categories of "doers". What % were they 10 or 20 years ago, and what % are they now? Has the hackathon changed the numbers? Etc.

[Hannes] We could collect some numbers. I doubt it would be easy to collect them from the past. We could re-use the document shepherd writeup. Already today we (at least Rifaat and I do it) indicate whether there are implementations of a specific specification. We could add information about testing, hackathon participations, and details about the implementations. We could capture whether the authors themselves have worked on the code or someone else. If it was someone else, we could try to loop them into the discussion to collect the feedback.

> Since our principal output is text, that isn't so surprising, but I think there's a case for sending any spec that does not adhere to RFC7942/BCP205 back to the WG.

[Hannes] On the surface, it looks like we are producing text. But actually we want much more. We want running code (in the sense of deployed code) and we should expand it to "running secure code".
I think that this is the biggest mental obstacle. If we believe our work is done when the specification is done, then we will fail to reach the full potential of our work. I understand that this message is inconvenient because many participants have difficulties to influence the deployment or even implementations. This is also the cause of a lot of frustration in the IETF work because person A says or writes "I went feature foo." but persons B and C then need to implement 'foo' and then deploy it. Needless to say that persons B and C are less excited about doing the work for person A. IMHO this is the root cause of many conflicts as far as I can see.

> That's a bit cruel.

[Hannes] The IETF mission statement says that we care about "engineering quality" and "running code" then we have to figure out how we get there. As mentioned in other conversations, for me this means more use of formal methods for security protocols and implementations supporting specifications. I would also point to the need for testing but I am already now stretching the limits of what people are willing to hear...

> In larger organisations, it might be totally infeasible. But again, RFC7942 is our friend.

[Hannes] As mention above, I am not asking for product-quality code. For what I am trying to accomplish, namely to feed implementation experience back into the specification work, I would already be happy to get the implementers involved. Having worked in a big telco equipment manufacturer myself I know that the implementers do not start their work until the specification is finished (or even years later). So, you would need some prototyping work while you are writing the spec. At least when I was working for this unnamed telco equipment manufacturer, developing prototypes and PoCs was in scope of my work.

Ciao
Hannes

---

From: Vittorio Bertola <[email-masked]>
Date: Wed, 24 Feb 2021 10:39:44 +0100 (CET)

>     Il 24/02/2021 08:22 Hannes Tschofenig <[email-masked]> ha scritto:
> 
> 
The question is whether you *only* (mostly) want coders in the leadership, or whether you *also* want coders in the leadership. This makes a lot of difference in evaluating your position.

Coming from my own IETF experience, which of course is just about a small subset of everything that is happening here, I'd say that the IETF has the opposite problem - the IETF does not seem to have a way, or even the desire, to acquire non-technical perspectives on what it is doing, so whenever a new protocol ends up prompting significant regulatory, business or social changes, they seem to come unexpectedly; the non-technical stakeholders that were not involved in the design phase get mad at the IETF, and the people at the IETF are surprised (sometimes even offended) by that reaction. And then you get a debate on whether code is law or not and whether the socio-economic implications of new technologies have to be considered by the technologists, which I thought we had closed forever at the turn of the century.

(But sorry, possibly this is not a discussion in topic for gendispatch - it is more for a new WG on diversity and inclusiveness ;-) )

--

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] mailto:[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Keith Moore <[email-masked]>
Date: Wed, 24 Feb 2021 04:46:26 -0500

On 2/24/21 3:47 AM, Hannes Tschofenig wrote:

> [Hannes] I started noticing it after the IETF started the hackathons, 
> which gave implementers more visibility. In the groups I participate 
> in, I regularly ask around for volunteers to join the hackathon. Then, 
> you get an idea who is interested to participate and who isn't. The 
> hackathons are also a "light" form of coding because you are selecting 
> a really small specification aspect only. Hence, the bar is pretty low 
> for entry. At f2f hackathons you also have a number of people joining 
> who use the event to chat. So, you have to take this into account as 
> well. 

I don't recall whether I've been present when you were asking for 
volunteers, but in general I think it might help attract participants if 
people know how low the bar is.   I've sometimes wondered whether I need 
to have my own implementation of a protocol in order to participate 
usefully.

I can also say that another reason I've never joined a hackathon is that 
this would require another couple of nights of travel expense when my 
funds are often already strained getting to the meetings.   (Though it 
has occasionally occurred to me that attending the hackathon might 
actually be a better investment than attending WG meetings.)   Remote 
hackathons would reduce the hotel expense but maybe take more time away 
from paying work.  When I've had employer support for attending IETF, I 
doubt that employer would have wanted to pay for me to attend a hackathon.

> I think that this is the biggest mental obstacle. If we believe our work is done when the specification is done, then we will fail to reach the full potential of our work. I understand that this me…

My impression is that IETF has always been (at least since 1990 which is 
about when I started) much more about producing specifications than 
code.  Implementation experience was always valued in WG discussions, 
but implementations were not the main goal or even an explicit goal 
except as needed for advancement beyond Proposed.    Part of this was 
rooted in experience that interoperability was obtained from clear 
specifications of "bits on the wire", rather than by either APIs or a 
reference implementation.    But conditions were somewhat different 
then, because then you had more diverse hardware, (you still had 
machines with 36-bit words for example), more diversity in operating 
systems, and it wasn't the case that you could expect the same 
programming languages to be supported everywhere. (perhaps not even C).

I welcome the efforts to attract more developers, as I believed for long 
time that IETF specifications were becoming a bit distant from 
implementation realities.  So I saw the hackathon and efforts to attract 
open source developers as corrections that were somewhat overdue.

I don't find myself thinking that specification authors or editors need 
to be developers (IMO other skills are more important to writing a good 
specification).   But it really helps to have some people in the WG and 
in the conversation who are working on at least prototype or reference 
implementations.

Keith

p.s. among other kinds of "doers" whose clue might benefit IETF work, I 
might suggest people who understand how to make effective configuration 
and user interfaces.    Especially in the area of security but not 
exclusively so.   Ease of configuration and use are some of the 
important reasons why proprietary solutions succeed over standard 
solutions.   I'm not saying that IETF should specify user interfaces but 
rather that protocols need to be designed with ease of configuration and 
use in mind.

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 24 Feb 2021 11:36:13 +0100

On 2021-02-24, at 11:22, Warren Parad <wparad=[email-masked]> wrote:
> 
> Should we solve the NxM problem, and if so, how do you propose we do that?

Let GNAP do that.

Grüße, Carsten

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 24 Feb 2021 11:36:05 +0000

Hi Vittorio,

I also want people with hands-on experience in leadership. In general, I wanted to raise the importance of skills in this discussion. For some reason it seems to have gotten lost. You added even more requirements below, which I am also fine with.

From my experience in the IAB I must say it is not so easy to attract the regulatory community and economist. We had some success with the former category simply because some IETF people ended up working in the regulatory space and some of the working groups had pretty strong ties to the regulatory space (e.g. emergency services, privacy, telecommunications). Henning Schulzrinne, for example, worked for the FCC and shared his experience at IAB plenaries. We also tried to involve economists and the work by Eliot needs to be mentioned, see https://www.iab.org/activities/workshops/itat/. I am not sure where this effort ended up.

Would I like to see a guy like Henning with his IETF / FCC experience in the IETF leadership. Definitely. Would he want to do that? Most likely not.

Ciao
Hannes

From: Vittorio Bertola <[email-masked]>
Sent: Wednesday, February 24, 2021 10:40 AM
To: Hannes Tschofenig <[email-masked]>
Cc: GENDISPATCH List <[email-masked]>; [email-masked]
Subject: Re: [Gendispatch] Diversity and Inclusiveness in the IETF

Il 24/02/2021 08:22 Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> ha scritto:

--

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked]<mailto:[email-masked]>
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: "Bron Gondwana" <[email-masked]>
Date: Wed, 24 Feb 2021 22:39:11 +1100

On Wed, Feb 24, 2021, at 22:04, Warren Parad wrote:
> I would prefer Bron to answer that question, as they are the one who started this email thread.

You can also use he when talking about me, or she for that matter - I do enough group fitness classes where it's roughly assumed that the entire class is female, and I have an ambiguous enough name that I'm used to it.  Most people use "he" most of the time.

> However let's look at GNAP, I've honestly been struggling to understand at least one fully documented case that GNAP supports. It seems in every document the only thing that is clear is GNAP wants to allow "everything", doesn't actually talk about an example.

That's my biggest fear for GNAP - it too will try to be everything to everybody and wind up being nothing to nobody because the super flexible "everything protocol" is the same as no protocol at all, since you have to special-case everybody you talk to anyway.

> By NxM, I assume we mean that the end user or client is free to select whichever AS they want, in a way which the RS can verify the AS credential and the user identity, without the RS having to (and really without the ability to limit) which AS are allowed.

Let's get down to use cases then, rather than talking in abstracts.

I'm an end user with a copy of {The Bat email client} and I want to connect it to {Gmail} + {Yahoo} + {My ISP}.  It supports {POP3}, a widely popular open standard.  I want to be able to authenticate to each of those services without saving my plaintext passwords on my hard disk where the next {Windows ME} virus will exfiltrate them to {Noextraditionistan} and all my {Dogecoin} will then be exfiltrated from my {Paybuddy} account, leaving me destitute.

But, {The Bat} doesn't have a trusted client cert from my isp, because who does - so there's no good protocol for me - it's either plaintext auth, or it's some architecture astronaut multi-party nonsense that's massively over specified and doesn't work half the time.  So I write a plain text password on a post-it note which is lying in the dust under my monitor because the glue has gone bad, and I hope I never accidentally click "remember me" when I type it in.

That's been the reality of the end user experience for very many years.

NxM means that you can authenticate an arbitrary client against an arbitrary server so long as they are both speaking a known public protocol, without needing to build a trust relationship between the client vendor and the server vendor first.

Any "trust relationship" is made through a user both who trusts the client and trusts the server, and it's not transitive over to other users of the same client and the same server.  The client author doesn't need to get a signed "I trust you" from every single server, and the server author doesn't have to go identify every single client.

That's what NxM means to a user, the ability to use arbitrary clients with arbitrary servers so long as they both implement a documented protocol.  Interoperability.

OAuth has not given interoperability in the NxM sense outside some simple web use cases.  They're nice and all, but they don't tend to be useful with open protocols - OAuth gets used for accessing proprietary API endpoints after getting an access key for a single provider.  At least you get Nx1 or 1xM out of it depending who's the N and who's the M, and maybe some of your code can rhyme so you're not doing everything from scratch each time.

This is the sorry story of real open protocols.  The floor for true interoperability is still username + password over cleartext, over hopefully a TLS tunnel that's providing some level of protection.  Most so than a few years ago when Fastmail wrote our "starttls considered harmful"[1] objection to the IETF's habit at the time of putting a "STARTTLS" upgrade into an initially plaintext protocol, where an active intercepter could just strip the "I support STARTTLS" indicator from the protocol and convince the client to send the credentials in the clear.

We're a little better mostly these days, but it's still a tirefire, and in my heart I do hold the OAuth working group's squatting on this area of the landscape while failing to address this burning need partially responsible.  The result (as Phillip pointed out upthread) has been a consolidation towards a few big players - because NxM becomes tractable when you reduce the N and M to small enough numbers.

Bron.

[1] https://www.fastmail.help/hc/en-us/articles/360058753834-SSL-TLS-and-STARTTLS

---

From: "Bron Gondwana" <[email-masked]>
Date: Wed, 24 Feb 2021 22:46:39 +1100

> rather that protocols need to be designed with ease of configuration and 

Oh for sure - considering user use-cases first and foremost is vital for having decent specifications.  This is a group that's even harder to attract to something like the IETF (and harder to keep, particularly if their knowledge gets swatted down by people who don't see the value).

... despite all this negative comment, I've got to say that the IETF generally produces better specs in a lot of way (including usability) than many proprietary APIs I've had the displeasure of interacting with, so for all that we could be better - we're pretty bloody good already.  Yay.

Bron.

---

From: "Bron Gondwana" <[email-masked]>
Date: Wed, 24 Feb 2021 23:15:15 +1100

On Wed, Feb 24, 2021, at 23:09, Warren Parad wrote:
> (I tend to trend lightly in the pronoun area, mostly because I'm shocked that openid included gender but not pronouns)
> 
> I hadn't heard that to be called the NxM problem, so that definitely cleared up the potential confusion (at least for me).
> 
> I think GNAPs lack of clarity is a non sequitur for the handling or not of the multitrust arbitrary-client with arbitrary-service, however it's lack of clarity for me prevents me from knowing whether GNAP actually seeks to solve this problem. So from an OAuth WG perspective we can still ask:
> 
> *Is this or should this problem be left to GNAP to solve, or is an OAuth WG responsibility?*

Honestly I think the problem space is the whole ietf's responsibility. Protocols that allow an end user to safely transfer data between two parties that don't have a pre-existing trust relationship are a key part of enabling user freedom and user choice.

Bron.

> *Warren Parad*

> Founder, CTO

> Secure your user data with IAM authorization as a service. Implement Authress <https://authress.io/>.
> 
> 
> On Wed, Feb 24, 2021 at 12:39 PM Bron Gondwana <[email-masked]> wrote:
>> __

---

From: Neil Madden <[email-masked]>
Date: Wed, 24 Feb 2021 12:20:56 +0000

On 24 Feb 2021, at 11:39, Bron Gondwana <[email-masked]> wrote:
>> […]

Does the following meet your needs?

You type your email address into {The Bat} to begin configuration. {The Bat} does discovery [1][2] to locate the OAuth/OIDC server for {My ISP}. The discovery document reveals that {My ISP} supports open dynamic client registration [3][4] so {The Bat} registers and gets issued with a client id and client secret. {The Bat} then does a normal OAuth flow to get an access token to access your emails from {My ISP}. If you later stop using {The Bat} you can go to your page on {My ISP} and revoke its access because it has a unique client id.

[1]: https://openid.net/specs/openid-connect-discovery-1_0.html <https://openid.net/specs/openid-connect-discovery-1_0.html>
[2]: https://tools.ietf.org/html/rfc8414 <https://tools.ietf.org/html/rfc8414> 
[3]: https://openid.net/specs/openid-connect-registration-1_0.html <https://openid.net/specs/openid-connect-registration-1_0.html>
[4]: https://tools.ietf.org/html/rfc7591 <https://tools.ietf.org/html/rfc7591> 

> That's what NxM means to a user, the ability to use arbitrary clients with arbitrary servers so long as they both implement a documented protocol.  Interoperability.

That’s fine for your use-case, but that isn’t everybody’s use-case. Other use-cases (such as Open Banking) involve regulatory or policy frameworks in which open dynamic client registration is not appropriate. JMAP could have an RFC describing the use of OAuth with JMAP that mandates open dynamic client registration and discovery.

— Neil

-- 
ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>

---

From: Aaron Parecki <[email-masked]>
Date: Wed, 24 Feb 2021 05:44:53 -0800

> You type your email address into {The Bat} to begin configuration. {The
Bat} does discovery [1][2] to locate the OAuth/OIDC server for {My ISP}.
The discovery document reveals that {My ISP} supports open dynamic client
registration [3][4] so {The Bat} registers and gets issued with a client id
and client secret. {The Bat} then does a normal OAuth flow to get an access
token to access your emails from {My ISP}. If you later stop using {The
Bat} you can go to your page on {My ISP} and revoke its access because it
has a unique client id.

Like Neil says, the building blocks are all already there. The fact that
companies choose not to use them is not because the technology isn't there,
it's because it's a business problem.

I'd be thrilled if the NxM problem were solved in practice, but
unfortunately that doesn't seem to be what's happened in the market. The
technical solution has been there a long time, so there's something else
going on.

When I've brought up this topic in the past, most of the responses I've
gotten from the "big players" are along the lines of "lol we're not going
to let someone's software talk to us unless we have a legal arrangement
with the developer". The fact that dynamic client registration is barely
used is more because these service operators want the software developers
to agree to their terms of service before being able to access APIs.

This is all to say that I agree it'd be nice to solve this problem, but in
the end, the IETF can't tell companies what to do with their products and
services.

Aaron

On Wed, Feb 24, 2021 at 4:21 AM Neil Madden <[email-masked]>
wrote:

> I'm an end user with a copy of {The Bat email client} and I want to
> connect it to {Gmail} + {Yahoo} + {My ISP}.  It supports {POP3}, a widely
> popular open standard.  I want to be able to authenticate to each of those
> services without saving my plaintext passwords on my hard disk where the
> next {Windows ME} virus will exfiltrate them to {Noextraditionistan} and
> all my {Dogecoin} will then be exfiltrated from my {Paybuddy} account,
> leaving me destitute.
>
> But, {The Bat} doesn't have a trusted client cert from my isp, because who
> does - so there's no good protocol for me - it's either plaintext auth, or
> it's some architecture astronaut multi-party nonsense that's massively over
> specified and doesn't work half the time.  So I write a plain text password
> on a post-it note which is lying in the dust under my monitor because the
> glue has gone bad, and I hope I never accidentally click "remember me" when
> I type it in.
>
> NxM means that you can authenticate an arbitrary client against an
> arbitrary server so long as they are both speaking a known public protocol,
> without needing to build a trust relationship between the client vendor and
> the server vendor first.
>
>
> You type your email address into {The Bat} to begin configuration. {The
> Bat} does discovery [1][2] to locate the OAuth/OIDC server for {My ISP}.
> The discovery document reveals that {My ISP} supports open dynamic client
> registration [3][4] so {The Bat} registers and gets issued with a client id
> and client secret. {The Bat} then does a normal OAuth flow to get an access
> token to access your emails from {My ISP}. If you later stop using {The
> Bat} you can go to your page on {My ISP} and revoke its access because it
> has a unique client id.
>
> [1]: https://openid.net/specs/openid-connect-discovery-1_0.html
> [2]: https://tools.ietf.org/html/rfc8414
> [3]: https://openid.net/specs/openid-connect-registration-1_0.html
> [4]: https://tools.ietf.org/html/rfc7591
>
>
> Any "trust relationship" is made through a user both who trusts the client
> and trusts the server, and it's not transitive over to other users of the
> same client and the same server.  The client author doesn't need to get a
> signed "I trust you" from every single server, and the server author
> doesn't have to go identify every single client.
>
> That's what NxM means to a user, the ability to use arbitrary clients with
> arbitrary servers so long as they both implement a documented protocol.
> Interoperability.
>
>
> That’s fine for your use-case, but that isn’t everybody’s use-case. Other
> use-cases (such as Open Banking) involve regulatory or policy frameworks in
> which open dynamic client registration is not appropriate. JMAP could have
> an RFC describing the use of OAuth with JMAP that mandates open dynamic
> client registration and discovery.
>
>
> — Neil
>
>
-- 
---
Aaron Parecki
https://aaronparecki.com

---

From: Jim Willeke <[email-masked]>
Date: Wed, 24 Feb 2021 09:59:21 -0500

But in reality, Just "because the technology" is there there leaves out the
practicality of creating a secure implementation. Sure, you could write it
off as "a business problem" but many of the developers are small and not
unusually single person operations that do not have the resources to create
a specific team, or even a specific person, to work through all the
specifications that are involved.

I do believe, in general, specific implementations should not be within
the specifications but a "Best Practices" or "Common Implementations"
document to coincide with the specifications might be in order.

Just spend some time on https://stackexchange.com/filters/4229/oauth and
you will see the issue and struggles.

--
-jim
Jim Willeke

On Wed, Feb 24, 2021 at 8:46 AM Aaron Parecki <[email-masked]> wrote:

>> But, {The Bat} doesn't have a trusted client cert from my isp, because
>> who does - so there's no good protocol for me - it's either plaintext auth,
>> or it's some architecture astronaut multi-party nonsense that's massively
>> over specified and doesn't work half the time.  So I write a plain text
>> password on a post-it note which is lying in the dust under my monitor
>> because the glue has gone bad, and I hope I never accidentally click
>> "remember me" when I type it in.
>>
>> Any "trust relationship" is made through a user both who trusts the
>> client and trusts the server, and it's not transitive over to other users
>> of the same client and the same server.  The client author doesn't need to
>> get a signed "I trust you" from every single server, and the server author
>> That's what NxM means to a user, the ability to use arbitrary clients
>> with arbitrary servers so long as they both implement a documented
>> protocol.  Interoperability.
>>
>>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 24 Feb 2021 10:18:17 -0500

On Wed, Feb 24, 2021 at 2:35 AM Hannes Tschofenig <[email-masked]>
wrote:

> When someone suggests you to use a certain technology then there is
> typically an entire context that comes with the question that led to this
> recommendation. Since we don’t know the context, it is hard to say whether
> the recommendation is reasonable.
>
>
>
> I think we can all agree that there are many aspects involved of making a
> technology choice. Some of those choices are business related, with the
> availability of software and with the familiarity of the concepts by those
> using the technology.
>
>
>
> What I also see happening again and again is that people confuse protocols
> with the deployment of protocols. Phil does this below too. Just because
> Facebook, Google & Co decide to use OAuth in some specific way does not
> mean that OAuth cannot be deployed by others in a completely different way.
>

I am not confused, I merely don't accept that the distinction is a useful
one. I know what HTTP and HTML were supposed to be. I also know what they
have become and that there is no way to go back.

The fact that a technology has become one of the factors in reinforcing a
duopoly position is far more relevant to the question of whether a group
should be told that they must use it than ANY aspect of the
technology itself. Yes, OAUTH is capable of supporting a different
ecosystem to the one that it has established. But when an application is
built on OAUTH, they don't get to change the ecosystem.

It is the same in PKI. There is absolutely nothing stopping anyone from
implementing the PGP Web of Trust in X.509. Mark Shuttleworth actually got
pretty far in doing just that. But nobody is ever going to be able to use
that system because there are simply too many assumptions about how the
formats are used built into the deployed infrastructure.

Unfortunately, I don’t see how any of this relates to the diversity
> discussion. I would therefore suggest to move this discussion to the OAuth
> group. There are so many aspects in Phil’s email that require
> clarifications...
>

If you noticed, I had actually broadened the issue of folk insisting on
their technology being used to include the SPF/DKIM experience which was
quite different.

What I think some of the grownups need to start thinking about is just what
is going to be happening over the next five to ten years as various
politicians decide to wield anti-trust against what they are now calling
big tech. The ostrich strategy that has worked so far is not likely to work
for very much longer.

Google and Facebook in particular would be well advised to start sending
lawyers to all the standards meetings in which they participate. Or at the
very least the ones that are being attended by lawyers who work for the FTC
and EU anti-trust divisions.

---

From: Justin Richer <[email-masked]>
Date: Wed, 24 Feb 2021 10:18:22 -0500

I agree that the NxM problem is the purview of the whole IETF, but it’s something that we’re particularly interested in over in GNAP. As the editor of OAuth’s dynamic registration extension and the GNAP core protocol, I hope I can add to this conversation.

From a technical standpoint, OAuth’s dynamic client registration lets arbitrary clients talk to an AS, but the trust isn’t there in practice. On top of that I think this problem is exacerbated by a fundamental protocol design element of OAuth: the client_id that’s required. That field means there’s an assumption that a relationship was set up between the pieces of software, implied to be trusted by admins at the AS. Sure you can get that client_id under special circumstances, but there’s still a special weight handed to that and the dynamic stuff feels like you’re giving up control as an AS. In GNAP, the relationship is inverted, and it’s designed as “dynamic-first”, with pre-registered clients being an optimization on top of that.

Does this solve the NxM problem? No, because companies are still going to decide that they only talk to keys or identifiers that they know ahead of time. But the protocol puts the dynamic case forward as baseline and fits in much better with the likes of JMAP than OAuth ever could:

- {The Bat} creates a key pair.
- {User} enters their email address into {Bat}, {Bat} does discovery (maybe that’s a JMAP thing? Webfinger?) and finds the JMAP server and the GNAP endpoint for authentication as an option.
- {Bat} talks to the GNAP AS at {ISP} and presents the key it just made up. {ISP} has never seen this key, but knows how to talk GNAP and get the user to authorize {Bat} to access email.
- {User} does this using GNAP and gets back an access token that’s tied to the key {Bat} made back at the beginning. That token is tied (at the {ISP}) to the user’s account.

Yes, you can do all of this today with OAuth (and people have done so), but OAuth’s basic model of “go do discovery and registration first and THEN talk to me” is a trust impediment more than it is a technical impediment. The “negotiation” part of the GNAP name comes from the philosophy of “start talking first and figure out what you need as you go”. Instead of jumping through hoops to get something you can trust, you just start in and then decide how much you trust it. A corporate rollout could use its own key distribution mechanism and static registration to limit which client instances talk back to the company server, regardless of which accounts would authorize access on top of that. An internet-facing service is going to be more likely to take a TLS approach, of “I’ll talk to you in a secure fashion without caring who you are right now”.

We really are trying to make GNAP a consistent protocol at its core and learn from problems with OAuth in the wild, all while letting GNAP address a wider variety of use cases. I agree that GNAP could be clearer about specific use cases, and we’re working on the spec still so any help here is appreciated. 

 — Justin

> On Feb 24, 2021, at 7:15 AM, Bron Gondwana <[email-masked]> wrote:
> 
> 
> 
>> Is this or should this problem be left to GNAP to solve, or is an OAuth WG responsibility?
> 
>> Warren Parad
>> On Wed, Feb 24, 2021 at 12:39 PM Bron Gondwana <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> [1] https://www.fastmail.help/hc/en-us/articles/360058753834-SSL-TLS-and-STARTTLS <https://www.fastmail.help/hc/en-us/articles/360058753834-SSL-TLS-and-STARTTLS>
>> 
>> --
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

---

From: Aaron Parecki <[email-masked]>
Date: Wed, 24 Feb 2021 07:21:33 -0800

> Sure, you could write it off as "a business problem" but

I did not mean to suggest that I was *writing it off* as a business
problem.

It *is* a very real problem, and I would very much like to see a solution,
however based on my experience it is not something that technology will
solve. This is demonstrated by the fact that there are all the pieces in
place already yet many organizations refuse to adopt them, and it’s
definitely not for a lack of understanding.

Aaron

On Wed, Feb 24, 2021 at 7:01 AM Jim Willeke <[email-masked]> wrote:

> But in reality, Just "because the technology" is there there leaves out
> the practicality of creating a secure implementation. Sure, you could write
> it off as "a business problem" but many of the developers are small and not
>> > You type your email address into {The Bat} to begin configuration.
>> {The Bat} does discovery [1][2] to locate the OAuth/OIDC server for {My
>> ISP}. The discovery document reveals that {My ISP} supports open dynamic
>> client registration [3][4] so {The Bat} registers and gets issued with a
>> client id and client secret. {The Bat} then does a normal OAuth flow to get
>> an access token to access your emails from {My ISP}. If you later stop
>> using {The Bat} you can go to your page on {My ISP} and revoke its access
>> because it has a unique client id.
>>
>> This is all to say that I agree it'd be nice to solve this problem, but
>> in the end, the IETF can't tell companies what to do with their products
>> and services.
>>
>> Aaron
>>
>>
>>
>>
>>> That’s fine for your use-case, but that isn’t everybody’s use-case.
>>> Other use-cases (such as Open Banking) involve regulatory or policy
>>> frameworks in which open dynamic client registration is not appropriate.
>>> JMAP could have an RFC describing the use of OAuth with JMAP that mandates
>>> open dynamic client registration and discovery.
>>>
>>>
>>> — Neil
>>>
>>>
-- 
---
Aaron Parecki
https://aaronparecki.com

---

From: Mary Barnes <[email-masked]>
Date: Wed, 24 Feb 2021 10:17:34 -0600

On Wed, Feb 24, 2021 at 1:22 AM Hannes Tschofenig <[email-masked]>
wrote:

> Note that I am not saying that those who do not write code are not allowed
> to participate in the working group. Far from the truth. If you have read
> through the OAuth discussion you may have noticed that I am a big advocate
> of involving an wide range of expertise.
>
>
>
> To the point: IMHO there has to be a difference between the document
> author and other participants, most of which are passive. I see the role of
> a document author being more than just the person writing the text.
> Hopefully that person cares enough about the work he or she proposes to go
> the extra mile. If a document author does not care about implementing his
> or her protocol then we have a problem.
>
>
>
> Implementations, even if they are just prototypes, provide valuable
> feedback during the work on a specification. Someone has to do this work.
> Writing an implementation of a protocol can easily be several times the
> effort of writing a specification.
>
>    - Implementations provide valuable feedback during the standardization
>    work,
>
> [MB] I totally agree. [/MB]

>
>    -
>    - Someone has to do the implementation work,
>
> [MB] Definitely.  And, per the point brought up about operators, they
generally aren't the ones writing the code, their vendors are. [/MB]

>
>    -
>    - Implementations are time consuming (even if they are fun for many to
>    write)?
>
> [MB]  They can be very time consuming and in my experience the issue is
more that folks are often busy working other products out while I might be
working on specs, so they often don't have the time to dedicate while specs
are being written.  And, in the places I've worked unless there's a spec in
place, folks aren't going to be implementing something.  That wasn't the
case in one of the groups I was with in Nortel way back when, but it has
been in recent years (partly because I fell back in time to the more
traditional telecom world where that is the standard development process).
[/MB]

>
>    -
>
>
>
> The culture of hands-on work needs to be more than a responsibility of the
> document authors. It is a culture that has to cut across the organization,
> from working group chairs to the IESG. Currently, there are disincentives
> to work on code as a document author.
>
[MB] I see disincentives in that some companies have people in roles where
they wouldn't have time to code because they're doing work well beyond IETF
and within their organization, they are just not viewed as part of the
group that codes.  You get into corporate politics and people not wanting
people in other groups to do work that they view as the purview of their
group.  I can't tell you how much of that I've dealt with.   [/MB]

>
>
> I want people with hands-on experience in the leadership of an engineering
> organization. For me this is a form of diversity.
>
[MB] The hands-on experience is great and certainly brings
significant value.  But, there's also diversity in terms of industries that
use the output of IETF and the sort of work they need IETF to do.
Certainly, I think the majority of the work is about people contributing to
and reviewing specs from the perspective of whether it's good enough that
you could write working, interoperable code based on the spec.  But, having
people that will be deploying products that are based on those specs
involved, is also extremely important.   And, having people that understand
real user experience (and not how things work from an engineer's view) is
also important.  And, of course, the work I do is generally at a higher
layer than your own, so that is why my view is slightly different than
yours.  And, honestly, I think appreciating that there can be two different
views of a situation, with both being equally valid, that is not something
IETFers do very well at all.   [/MB]

> *From:* Mary Barnes <[email-masked]>
> *Sent:* Tuesday, February 23, 2021 11:26 PM
> *To:* Brian E Carpenter <[email-masked]>
> *Cc:* Hannes Tschofenig <[email-masked]>; Fernando Gont <
> [email-masked]>; [email-masked]; GENDISPATCH List <
> *Subject:* Re: [Gendispatch] Diversity and Inclusiveness in the IETF
>
>
>
> Hannes,
>
>
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 24 Feb 2021 11:22:10 -0500

I don't do hackathons because I don't do coding on a laptop and I certainly
don't do good coding while jetlagged. At this point my rig has a 42 inch 4K
monitor flanked by two matched 30"ers. And I am starting to think about
swapping out the 30"ers for two more 4Ks.

The hackathon is one of the things I think could probably be more
productive as a virtual experience.

What I plan to do for the Mesh is to set up a test service using the
reference code that is conservative in what it accepts and liberal in what
it sends. Which is something I can do using my approach to coding.

---

From: Tim Bray <[email-masked]>
Date: Wed, 24 Feb 2021 08:34:35 -0800

The OAuth work has successfully built a perfectly reasonable syntax and
protocol for exchanging identity and attribute assertions, and that's
fine.  What it hasn't done is opened up the world of Identity Provision,
but that's not a technical problem.

OAuth flowed out of OpenID back in the day. The core idea of OpenID,
beginning with the attractive but wrong notion that URIs are a good way for
people to identify themselves, was that service providers should be
prepared to trust arbitrary identity providers.  At the moment, nobody has
figured out an automated way for services to figure out which  identity
providers they want to trust. The counter-argument is that service
providers should just trust people to pick appropriate identity providers,
and it has never in my experience succeeded in convincing a single lawyer
or business-policy type.

On Wed, Feb 24, 2021 at 7:21 AM Justin Richer <[email-masked]> wrote:

> I agree that the NxM problem is the purview of the whole IETF, but it’s
> something that we’re particularly interested in over in GNAP. As the editor
> of OAuth’s dynamic registration extension and the GNAP core protocol, I
> hope I can add to this conversation.
>
> From a technical standpoint, OAuth’s dynamic client registration lets
> arbitrary clients talk to an AS, but the trust isn’t there in practice. On
> top of that I think this problem is exacerbated by a fundamental protocol
> design element of OAuth: the client_id that’s required. That field means
> there’s an assumption that a relationship was set up between the pieces of
> software, implied to be trusted by admins at the AS. Sure you can get that
> client_id under special circumstances, but there’s still a special weight
> handed to that and the dynamic stuff feels like you’re giving up control as
> an AS. In GNAP, the relationship is inverted, and it’s designed as
> “dynamic-first”, with pre-registered clients being an optimization on top
> of that.
>
> Does this solve the NxM problem? No, because companies are still going to
> decide that they only talk to keys or identifiers that they know ahead of
> time. But the protocol puts the dynamic case forward as baseline and fits
> in much better with the likes of JMAP than OAuth ever could:
>
> - {User} enters their email address into {Bat}, {Bat} does discovery
> (maybe that’s a JMAP thing? Webfinger?) and finds the JMAP server and the
> GNAP endpoint for authentication as an option.
> - {Bat} talks to the GNAP AS at {ISP} and presents the key it just made
> up. {ISP} has never seen this key, but knows how to talk GNAP and get the
> user to authorize {Bat} to access email.
> - {User} does this using GNAP and gets back an access token that’s tied to
> the key {Bat} made back at the beginning. That token is tied (at the {ISP})
> to the user’s account.
>
> Yes, you can do all of this today with OAuth (and people have done so),
> but OAuth’s basic model of “go do discovery and registration first and THEN
> talk to me” is a trust impediment more than it is a technical impediment.
> The “negotiation” part of the GNAP name comes from the philosophy of “start
> talking first and figure out what you need as you go”. Instead of jumping
> through hoops to get something you can trust, you just start in and then
> decide how much you trust it. A corporate rollout could use its own key
> distribution mechanism and static registration to limit which client
> instances talk back to the company server, regardless of which accounts
> would authorize access on top of that. An internet-facing service is going
> to be more likely to take a TLS approach, of “I’ll talk to you in a secure
> fashion without caring who you are right now”.
>
> We really are trying to make GNAP a consistent protocol at its core and
> learn from problems with OAuth in the wild, all while letting GNAP address
> a wider variety of use cases. I agree that GNAP could be clearer about
> specific use cases, and we’re working on the spec still so any help here is
> appreciated.
>
>  — Justin
>
> (I tend to trend lightly in the pronoun area, mostly because I'm shocked
> that openid included gender but not pronouns)
>
> I hadn't heard that to be called the NxM problem, so that definitely
> cleared up the potential confusion (at least for me).
>
> I think GNAPs lack of clarity is a non sequitur for the handling or not of
> the multitrust arbitrary-client with arbitrary-service, however it's lack
> of clarity for me prevents me from knowing whether GNAP actually seeks to
> solve this problem. So from an OAuth WG perspective we can still ask:
>
> Honestly I think the problem space is the whole ietf's responsibility.
> Protocols that allow an end user to safely transfer data between two
> parties that don't have a pre-existing trust relationship are a key part of
> enabling user freedom and user choice.
>
> Bron.
>
>
> *Warren Parad*
> Founder, CTO
> You can also use he when talking about me, or she for that matter - I do
> enough group fitness classes where it's roughly assumed that the entire
> class is female, and I have an ambiguous enough name that I'm used to it.
> Most people use "he" most of the time.
>
> However let's look at GNAP, I've honestly been struggling to understand at
> least one fully documented case that GNAP supports. It seems in every
> document the only thing that is clear is GNAP wants to allow "everything",
> doesn't actually talk about an example.
>
>
> That's my biggest fear for GNAP - it too will try to be everything to
> everybody and wind up being nothing to nobody because the super flexible
> "everything protocol" is the same as no protocol at all, since you have to
> special-case everybody you talk to anyway.
>
> By NxM, I assume we mean that the end user or client is free to select
> whichever AS they want, in a way which the RS can verify the AS credential
> and the user identity, without the RS having to (and really without the
> ability to limit) which AS are allowed.
>
>
> OAuth has not given interoperability in the NxM sense outside some simple
> web use cases.  They're nice and all, but they don't tend to be useful with
> open protocols - OAuth gets used for accessing proprietary API endpoints
> after getting an access key for a single provider.  At least you get Nx1 or
> 1xM out of it depending who's the N and who's the M, and maybe some of your
> code can rhyme so you're not doing everything from scratch each time.
>
> This is the sorry story of real open protocols.  The floor for true
> interoperability is still username + password over cleartext, over
> hopefully a TLS tunnel that's providing some level of protection.  Most so
> than a few years ago when Fastmail wrote our "starttls considered
> harmful"[1] objection to the IETF's habit at the time of putting a
> "STARTTLS" upgrade into an initially plaintext protocol, where an active
> intercepter could just strip the "I support STARTTLS" indicator from the
> protocol and convince the client to send the credentials in the clear.
>
> We're a little better mostly these days, but it's still a tirefire, and in
> my heart I do hold the OAuth working group's squatting on this area of the
> landscape while failing to address this burning need partially
> responsible.  The result (as Phillip pointed out upthread) has been a
> consolidation towards a few big players - because NxM becomes tractable
> when you reduce the N and M to small enough numbers.
>
> Bron.
>
> [1]
> https://www.fastmail.help/hc/en-us/articles/360058753834-SSL-TLS-and-STARTTLS
>
> --

---

From: Christian Huitema <[email-masked]>
Date: Wed, 24 Feb 2021 08:37:34 -0800

On 2/24/2021 1:39 AM, Vittorio Bertola wrote:
>> The culture of hands-on work needs to be more than a responsibility 
>> of the document authors. It is a culture that has to cut across the 
>> organization, from working group chairs to the IESG. Currently, there 
>> are disincentives to work on code as a document author.
>>
>> I want people with hands-on experience in the leadership of an 
>> engineering organization. For me this is a form of diversity.
>>
> The question is whether you *only* (mostly) want coders in the 
> leadership, or whether you *also* want coders in the leadership. This 
> makes a lot of difference in evaluating your position.

Vittorio,

The word "coder" is a somewhat insulting way to refer to software 
developers. Please stop. This vocabulary implies a hierarchy in which 
the specifications are developed by superior specification writers, then 
handed down to subservient "coders" who merely translate it into 
computer code. This is a very reductive way of considering software 
development. For example, it completely discards the interaction between 
implementation, deployment, testing, and user feedback. In the IETF, the 
writing of good specifications has always benefited from such 
interactions, and we want that to continue.

-- Christian Huitema

---

From: Warren Parad <[email-masked]>
Date: Wed, 24 Feb 2021 11:22:31 +0100

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.

On Wed, Feb 24, 2021 at 8:08 AM Bron Gondwana <[email-masked]>
wrote:

> I think it’s important to point out that OAuth is not an authentication
> protocol. It’s for delegation. OAuth is one of the most mis-used protocols
> on the modern web. If you really want to support end users, a good place to
> start is to make it clear to developers what OAuth is really for so secure
> solutions are built as opposed to the dumpster fire that OAuth solutions
> have become today.
>
>
> Which suggests that if the OAuth solutions deployed today are dumpster
> fires, then ... well, that's what OAuth 2 does.
>
> My biggest problem with OAuth as an outsider is that it doesn't solve the
> NxM problem.  You can't build a client which can OAuth against any
> arbitrary OAuth service that provides a standard protocol, because you need
> to get an API key for your particular application from each service
> provider.  This just doesn't scale, which is a large part of Phillip's
> complaint as well.
>
> Of course, I came into the IETF having already read
> https://web.archive.org/web/20120731155632/http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/
> - which was one of the things which made me wary of the IETF in the first
> place, and keen to not let everything I touched get over-complicated.
>
> Bron.
>
> --

---

From: Warren Parad <[email-masked]>
Date: Wed, 24 Feb 2021 12:04:40 +0100

I would prefer Bron to answer that question, as they are the one who
started this email thread.

Would you agree with that statement?

Warren Parad

Founder, CTO

---

From: Warren Parad <[email-masked]>
Date: Wed, 24 Feb 2021 13:09:14 +0100

*Is this or should this problem be left to GNAP to solve, or is an OAuth WG
responsibility?*

Warren Parad

Founder, CTO

---

From: Michael Richardson <[email-masked]>
Date: Wed, 24 Feb 2021 12:05:14 -0500

Justin Richer <[email-masked]> wrote:
    > arbitrary clients talk to an AS, but the trust isn’t there in
    > practice.

As an example of a fail even in a closed ecosystem: neither Google nor
Facebook nor LinkedIn nor .. permit one to login to them with themselves.
Even if we believe that there are business reasons why they wouldn't delegate
to another, the fact is that they don't delegate to themselves.

What's the use case?  I'll give you two:
  1) parent/child
  2) boss/secretary (*)

My kid is subject to Google Classroom.  A great idea, rather poorly implemented.
The parent interface is basically non-existent.  The advice, from *GOOGLE*
(and my school board) is, in order to find out what your child is
doing... have them share their password with you, the parent.  I read this,
and went WTF?  Doesn't that go against all of the authentication security
precepts that Google and others have been telling us?

(*) - yes there are limited abilities to do this within gmail.  But, it
      does not extend throughout the ecosystem.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 24 Feb 2021 12:14:05 -0500

On Wed, Feb 24, 2021 at 11:37 AM Christian Huitema <[email-masked]>
wrote:

> Il 24/02/2021 08:22 Hannes Tschofenig <[email-masked]>
> <[email-masked]> ha scritto:
>
> The question is whether you *only* (mostly) want coders in the leadership,
> or whether you *also* want coders in the leadership. This makes a lot of
> difference in evaluating your position.
>
> Vittorio,
>
> developers. Please stop. This vocabulary implies a hierarchy in which the
> specifications are developed by superior specification writers, then handed
> down to subservient "coders" who merely translate it into computer code.
> This is a very reductive way of considering software development. For
> example, it completely discards the interaction between implementation,
> deployment, testing, and user feedback. In the IETF, the writing of good
> specifications has always benefited from such interactions, and we want
> that to continue.
>
+1

I don't write much protocol code, I write synthesizers that write the code
for me. I try to work at the highest level of abstraction possible.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 24 Feb 2021 09:28:32 -0800

> matter how loudly they tried to complain that it should become our 

We had a solution for that which was to use the IIM KRS concept which 
was just HTTP. It would have solved the weakness of relying on DNSSec 
trivially too. People were worried about performance, but DoH pretty 
much shows that was probably not well founded. A PKI using a HTTPS key 
server would scale just fine these days.

Mike

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 24 Feb 2021 17:41:09 +0000

Hi Phil,

Thanks for the quick response. A few remarks below.

> I am not confused, I merely don't accept that the distinction is a useful one. I know what HTTP and HTML were supposed to be. I also know what they have become and that there is no way to go back.

> The fact that a technology has become one of the factors in reinforcing a duopoly position is far more relevant to the question of whether a group should be told that they must use it than ANY aspect of the technology itself. Yes, OAUTH is capable of supporting a different ecosystem to the one that it has established. But when an application is built on OAUTH, they don't get to change the ecosystem.

> It is the same in PKI. There is absolutely nothing stopping anyone from implementing the PGP Web of Trust in X.509. Mark Shuttleworth actually got pretty far in doing just that. But nobody is ever going to be able to use that system because there are simply too many assumptions about how the formats are used built into the deployed infrastructure.

You are raising an important point, which is described in this "Tussle in Cyberspace" paper:
https://groups.csail.mit.edu/ana/Publications/PubPDFs/Tussle%20in%20Cyberspace%20Defining%20Tomorrows%20Internet%202005's%20Internet.pdf

I believe you are arguing along the lines of the authors in that paper.

My opinion is that such an approach is not practical for three reasons:

- Our work is contribution driven. If there is a bias in the solution towards a specific deployment then it is because contributions pushed it into that direction. Not only is it necessary to have someone contribute a solution but you also need the group to review it.
- Making protocols suitable for all possible deployments introduces complexity. Particularly for security protocols this is often unwanted.
- Someone needs to be interested to turn the flexibility of the specs into code and then into deployments. In OAuth, for some reason, personal data stores, for example, have not been successful in the market.

Do I understand the issue you raise correctly?

> If you noticed, I had actually broadened the issue of folk insisting on their technology being used to include the SPF/DKIM experience which was quite different.
> What I think some of the grownups need to start thinking about is just what is going to be happening over the next five to ten years as various politicians decide to wield anti-trust against what they are now calling big tech. The ostrich strategy that has worked so far is not likely to work for very much longer.
> Google and Facebook in particular would be well advised to start sending lawyers to all the standards meetings in which they participate. Or at the very least the ones that are being attended by lawyers who work for the FTC and EU anti-trust divisions.

Fair enough. A difficult topic to think about.

Ciao
Hannes

---

From: Vittorio Bertola <[email-masked]>
Date: Wed, 24 Feb 2021 18:47:18 +0100 (CET)

>     Il 24/02/2021 17:37 Christian Huitema <[email-masked]> ha scritto:
> 
>     Vittorio,
> 
>     The word "coder" is a somewhat insulting way to refer to software developers. Please stop. This vocabulary implies a hierarchy in which the specifications are developed by superior specification writers, then handed down to subservient "coders" who merely translate it into computer code. This is a very reductive way of considering software development. For example, it completely discards the interaction between implementation, deployment, testing, and user feedback. In the IETF, the writing of good specifications has always benefited from such interactions, and we want that to continue.
> 
Of course (originally being a software writer myself, and still doing it as a hobby) this was not my intention, and personally I never heard any software developer complaining that "coder" is an insulting term. But if it is, I apologize for using it, and we should just add it to the list of problematic words, so that everyone is aware that it should not be used at the IETF.

Then, I also suggest that the list is handed out to every new subscriber of any IETF mailing list, because this is not the first time that I use a perfectly normal term in my native language / environment and I find someone jumping up and taking the issue as an offense (the last time was with the term "militant", when chatting on this same issue).

As a result, I am feeling like I should just stop participating in these discussions for fear of using the wrong choice of language and getting publicly shamed (and in my own culture, like in the Far East, in Arab cultures and elsewhere, "saving your face" in public is paramount). So, ironically, language correctness leads to self-censorship and exclusion.

Now, while we are at it, I also note that sometimes there are extremely offensive terms in my culture that are being commonly used in this discussion. The main example is "race"; in Italy, in Germany(*) and in other European cultures, using the term "race" to refer to a subset of mankind, implying that more than one "human race" exists, or suggesting that there are "race issues" and "race diversities" to be considered, is considered outright racism. I was shocked the first time I saw the term used as a category, but then I realized that there was no intention to offend - just a different linguistic background - and I moved on.

But if the principle is that nobody's sensitivity has to be offended, I think that we should definitely stop using the term "race" in this conversation or anywhere at the IETF.

(*) e.g. see https://www.dw.com/en/dont-use-the-term-race-german-scientists-urge/a-50390582

--

---

From: Keith Moore <[email-masked]>
Date: Wed, 24 Feb 2021 12:54:22 -0500

On 2/24/21 12:41 PM, Hannes Tschofenig wrote:

> - Our work is contribution driven.
True, but IETF does have some influence.   We're not bound to accept 
every contribution (especially if there are reservations about it), and 
we sometimes are able to impose some additional requirements on 
contributed work.   (Whether we do so wisely is a different question.)
> - Making protocols suitable for all possible deployments introduces complexity. Particularly for security protocols this is often unwanted.

Yes but it seems to me that we have a poor track record of anticipating 
what deployment is likely to look like, and also a poor track record of 
designing with some awareness of likely deployment.   (Perhaps 
especially for security protocols.) Clearly we can't perfectly predict 
the future, but some people are able to make very good educated guesses.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 24 Feb 2021 13:02:55 -0500

On 2/24/21 12:47 PM, Vittorio Bertola wrote:

> As a result, I am feeling like I should just stop participating in 
> these discussions for fear of using the wrong choice of language and 
> getting publicly shamed (and in my own culture, like in the Far East, 
> in Arab cultures and elsewhere, "saving your face" in public is 
> paramount). So, ironically, language correctness leads to 
> self-censorship and exclusion. 

Excellent point.

Please, people, we have participants from all over the world speaking a 
wide variety of languages.   Let's not publicly rebuke people for 
choosing a word that might have not quite the right shade of meaning, or 
might not be the perfect choice from someone else's perspective.   
Especially given that these shades of meaning can vary from one place to 
another even among native English speakers.  If we can tell what the 
speaker intended, that should be sufficient.   And public rebuke of 
language distracts from the main discussion.   If it's really important 
to try to correct someone, a polite, private note is probably better.

And contributors will generally adjust the words they use over time 
based on observation of others' writing and subtle feedback.   That's 
how people quite naturally become more fluent.

Keith

(FWIW I thought "coder" was fine.)

---

From: Fernando Gont <[email-masked]>
Date: Wed, 24 Feb 2021 15:05:48 -0300

On 24/2/21 14:47, Vittorio Bertola wrote:
>> the specifications are developed by superior specification writers, 
>> then handed down to subservient "coders" who merely translate it into 
>> development. For example, it completely discards the interaction 
>> between implementation, deployment, testing, and user feedback. In the 
>> IETF, the writing of good specifications has always benefited from 
>> such interactions, and we want that to continue.
>>
> Of course (originally being a software writer myself, and still doing it 
> as a hobby) this was not my intention, and personally I never heard any 
> software developer complaining that "coder" is an insulting term. But if 
> it is, I apologize for using it, and we should just add it to the list 
> of problematic words, so that everyone is aware that it should not be 
> used at the IETF.

I'd ask that participants be aware that a number of us speak English as 
a second language. So, while at times we might be aware that for some 
there might be differences (at times subtle) in the meaning of such 
words, other times we're not simply aware about them, or may overlook 
them (since English is not our native language).

For instance, the word "coder" has no equivalent in Spanish (the 
equivalent would be "codificador", but you'd never use that for coder or 
programmer). So it shouldn't come as a surprise that a Spanish-speaking 
person uses "programmer" to refer to "coder", "software developer" or 
"programmer" (itself), or that somehow mixes up these words.

The same probably applies to other languages.

I guess following Postel's advice might be of use here.

Thanks,

---

From: Michael Thomas <[email-masked]>
Date: Wed, 24 Feb 2021 10:19:59 -0800

On 2/24/21 10:05 AM, Fernando Gont wrote:
>
> I'd ask that participants be aware that a number of us speak English 
> as a second language. So, while at times we might be aware that for 
> some there might be differences (at times subtle) in the meaning of 
> such words, other times we're not simply aware about them, or may 
> overlook them (since English is not our native language).
>
> equivalent would be "codificador", but you'd never use that for coder 
> or programmer). So it shouldn't come as a surprise that a 
> Spanish-speaking person uses "programmer" to refer to "coder", 
> "software developer" or "programmer" (itself), or that somehow mixes 
> up these words.
>
Dave Oran once told me that I should be careful of using idioms where 
possible so as not to confuse people for whom English wasn't their first 
language. It's frankly amazing to me how many idioms a lot of 
non-English-as-first-language get. Heck, it can even be confusing 
between American English and UK English. I think the burden should be on 
native English speakers to be more plain and not too clever even though 
it's extremely tempting at times.

Mike

---

From: Fernando Gont <[email-masked]>
Date: Wed, 24 Feb 2021 15:23:42 -0300

Hello, Vittorio,

[....]
> Then, I also suggest that the list is handed out to every new subscriber 
> of any IETF mailing list, because this is not the first time that I use 
> a perfectly normal term in my native language / environment and I find 
> someone jumping up and taking the issue as an offense (the last time was 
> with the term "militant", when chatting on this same issue).

I couldn't agree more with you.

Just to provide yet another example, last year it was argued on this 
list what greeting with "cheers" (as o¡in "bye") could also result 
offensive -- when I had always assumed that it was simply an informal 
and polite way of saying "bye".

> As a result, I am feeling like I should just stop participating in these 
> discussions for fear of using the wrong choice of language and getting 
> publicly shamed (and in my own culture, like in the Far East, in Arab 
> cultures and elsewhere, "saving your face" in public is paramount). So, 
> ironically, language correctness leads to self-censorship and exclusion.

Isn't there an implicit irony in expecting people from completely 
different cultures and origins, who do not speak the language natively, 
to speak their one's own language in a flawless manner, in the name of 
inclusiveness and diversity?

The fact that people pick one language (out of many, regardless of how 
prominent or widespread it may be), remove a few words, and dare to call 
it "inclusive language", in a way, still amuses me.

Thanks,

---

From: Christian Hopps <[email-masked]>
Date: Wed, 24 Feb 2021 13:25:28 -0500

You just need the right laptop: https://www.tomshardware.com/news/expanscape-aurora <https://www.tomshardware.com/news/expanscape-aurora>

:)

Chris.

> On Feb 24, 2021, at 11:22 AM, Phillip Hallam-Baker <[email-masked]> wrote:
> 
> I don't do hackathons because I don't do coding on a laptop and I certainly don't do good coding while jetlagged. At this point my rig has a 42 inch 4K monitor flanked by two matched 30"ers. And I am starting to think about swapping out the 30"ers for two more 4Ks.
> 
> The hackathon is one of the things I think could probably be more productive as a virtual experience.
> 
> 
> What I plan to do for the Mesh is to set up a test service using the reference code that is conservative in what it accepts and liberal in what it sends. Which is something I can do using my approach to coding.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 24 Feb 2021 15:51:23 -0300

> 
> Now, while we are at it, I also note that sometimes there are extremely 
> offensive terms in my culture that are being commonly used in this 
> discussion. The main example is "race"; in Italy, in Germany(*) and in 
> other European cultures, using the term "race" to refer to a subset of 
> mankind, implying that more than one "human race" exists, or suggesting 
> that there are "race issues" and "race diversities" to be considered, is 
> considered outright racism. I was shocked the first time I saw the term 
> used as a category, but then I realized that there was no intention to 
> offend - just a different linguistic background - and I moved on.
> 
> But if the principle is that nobody's sensitivity has to be offended, I 
> think that we should definitely stop using the term "race" in this 
> conversation or anywhere at the IETF.

As noted, it seems to me that a lot of the discussion around language is 
how a specific group feels about a specific set of words, because of 
their own historical background...where the rest needs to learn about 
those cultural issues and adapt accordingly (probably without the same 
policy necessarily applying the other way around).

I should also note that, if people are also concerned about historical 
background of words, I'm sure they should also be concerned about 
anything that contains a national symbol/flag or religious symbol (*).
And in that light, there should also be a recommendation in that respect.

(*) e.g., a simple rosary would be deemed as completely harmless in my 
place (I do wear one, although it's not visible),  but it may certainly 
come across quite differently to e.g. people in some parts of Bosnia or 
Belfast (for obvious reasons... which I do understand... and which you 
don't need to go back a long time in history to understand).

Inclusiveness and diversity seem to be way more complex than what some 
seem to imply, and it implies a lot more than cherry-picking on specific 
items that would make a group look "nice and following the trend".

Thanks,

---

From: "Bron Gondwana" <[email-masked]>
Date: Thu, 25 Feb 2021 09:30:33 +1100

> From a technical standpoint, OAuth’s dynamic client registration lets arbitrary clients talk to an AS, but the trust isn’t there in practice. On top of that I think this problem is exacerbated by a…

Yep, this is the big point - OAuth is designed to require the the third leg of trust that creates the NxM problem.

If that dotted line between client and server requires a pre-existing trust relationship rather than the trust being entirely mediated by the user choosing to connect client A with server B, then you have the NxM problem.  This is the "you can only have your John Deere tractor serviced by an approved John Deere service centre" problem.  You can only use this client with servers who have pre-approved it.  Or fall back to the "cash of the internet" - plain text passwords.

> We really are trying to make GNAP a consistent protocol at its core and learn from problems with OAuth in the wild, all while letting GNAP address a wider variety of use cases. I agree that GNAP co…

Excellent.  This is precisely what I've been waiting for for these very many years as a viable replacement for storing a password locally on disk.  Just having the server able to distinguish between different client instances for the same user is a big start, because you can de-authorise one without having to lock out every connection - even if the user is still entering their password during the setup phase each time.

This is what Fastmail already do with our own app, creating a long-lived access token and storing that on the device rather than storing the password itself - and you can log out any one client from your security settings page.  What's missing is a standard way to do that with any IMAP client.  The initial JMAP authentication proposal was a very simple case of pretty much this, build into to the protocol so everyone would do it.

Making it easy to connect up arbitrary clients with per-client tokens the default, and easy rather than almost impossible to do in practice is where the big difference comes in.

Bron.

---

From: Christian Huitema <[email-masked]>
Date: Wed, 24 Feb 2021 17:39:22 -0800

On 2/24/2021 1:46 AM, Keith Moore wrote:
>> I think that this is the biggest mental obstacle. If we believe our 
>> work is done when the specification is done, then we will fail to 
>> reach the full potential of our work. I understand that this message 
>> is inconvenient because many participants have difficulties to 
>> influence the deployment or even implementations. This is also the 
>> cause of a lot of frustration in the IETF work because person A says 
>> or writes "I went feature foo." but persons B and C then need to 
>> implement 'foo' and then deploy it. Needless to say that persons B 
>> and C are less excited about doing the work for person A. IMHO this 
>> is the root cause of many conflicts as far as I can see.
>
> My impression is that IETF has always been (at least since 1990 which 
> is about when I started) much more about producing specifications than 
> except as needed for advancement beyond Proposed.

Yes, at the end of the day the IETF will produce specifications. But 
there is a world of differences between specifications that result only 
from theoretical considerations and specifications that were produced 
and tested by developing implementations. It is a bit like the famed 
difference between theory and practice.

> Part of this was rooted in experience that interoperability was 
> obtained from clear specifications of "bits on the wire", rather than 
> by either APIs or a reference implementation.    But conditions were 
> somewhat different then, because then you had more diverse hardware, 
> (you still had machines with 36-bit words for example), more diversity 
> in operating systems, and it wasn't the case that you could expect the 
> same programming languages to be supported everywhere. (perhaps not 
> even C). 

Similar considerations happen today. Different languages of course, but 
also different deployment conditions, dealing with different load 
balancers, different architectures of server farms, firewalls, 
transmission medias... And, by the way, developing in C is somewhat 
controversial these days, but there are different schools of thought 
about what the replacement language should be.

-- Christian Huitema

---

From: Jen Linkova <[email-masked]>
Date: Thu, 25 Feb 2021 14:20:19 +1100

> running code that actually helped improve the specification. We were doing

It's a very interesting comment, about 'not enough people writing the
code'. Since I've joined the IETF I've been hearing people complaining
about 'not enough operators here, where are they?'
I'm a network engineer who has to deal with routers and switches
running vendor's code and with endpoints running various OSes.
So while I have some ideas of what improvements I need from a given
protocol, I'd not be writing actual implementations, because I have no
places to actually run it in the production.
I'd rather collaborate with people who can write that code much faster
and better than I would ever be able so I can run their code in
production and provide some feedback from my operational experience.

> code, we are also coming up with work that does not require any code at all.

Well, plenty of work in the Ops area is like that but I do not think
it's a bad thing necessary.
Are you saying we shouldn't be documenting best (and worst) practices?
-- 
SY, Jen Linkova aka Furry

---

From: Theresa Enghardt <[email-masked]>
Date: Wed, 24 Feb 2021 19:59:59 -0800

Hi Fernando, Keith,

> https://www.ietf.org/archive/id/draft-gont-diversity-analysis-00.txt

Thank you for this document.

One perspective that I missed in this document is academia, as I have 
participated in the IETF as an academic for a few years.

The document mentions "Universities" as an example of organizations for 
which IETF participation might not [be] attractive or feasible. I'm not 
sure I agree.

Some benefits of participating in the IETF for researchers, PhD 
students, etc, potentially to be added to Section 4 as a separate group, 
include:

- Getting feedback on your work, e.g., assumptions you may be making, 
things you may have overlooked, direction for future work
- Input for your own teaching (learning about the IETF and its processes 
has very much enhanced discussions with my students)
- Making industry connections, e.g., for joint projects
- Professional networking, career advancement

When it comes to attending IETF meetings, I think it's worth mentioning 
that they are sometimes co-located with ANRW, an academic workshop, and 
that a lot of IRTF meetings are taking place during the same week. Also, 
there are efforts in the IRTF, such as the IRTF research prize, which 
may help PhD students get an ROI for their IETF-related work, feedback, 
and the opportunity to attend an IETF meeting.

Of course, a lot of the same structural problems that the draft mentions 
still apply to academics, and not all universities are "equal" (e.g., 
big/famous ones probably often have an easier time sending people than 
smaller ones).

One specific example would be Economic Constraints, Section 9: 
Universities usually have a travel budget and they may also have rules 
on how much a hotel is allowed to cost per night. IETF hotels are 
usually, if not always, outside of that budget, and overflow hotels are, 
too. I've usually managed to find something in adequate distance, but it 
did feel a bit strange to be basically excluded from the "official" hotels.

That's just my initial thoughts, and feel free to include them in the draft.

Best,
Theresa

---

From: Fernando Gont <[email-masked]>
Date: Thu, 25 Feb 2021 01:35:51 -0300

Hello, Theresa,

Thanks a lot for your comments! In-line...

On 25/2/21 00:59, Theresa Enghardt wrote:
[....]
> - Professional networking, career advancement

Probably part of the issue here is that our I-D talks about 
"participation", where we probably meant something along the lines of 
"active participation" or "making contributions to the IETF" -- e.g., 
reviewing documents, submitting Internet-Drafts, etc.

What you describe does indeed seem beneficial, but in principle doesn't 
seem to necessarily contribute to the work of the IETF.

   -- but please do correct me if I'm missing something or 
miss-interpreting what you're saying...

> and the opportunity to attend an IETF meeting.

We should certainly incorporate something along these lines -- I'll come 
back to you once we have crafted text along this lines. (of course, if 
you have specific text that you'd like to suggest, please do let us know!)

FWIW, what you note is one of the motivations/arguments for e.g. 
introducing f2f meeting fee waivers -- since in such cases there could 
be people that might be able to attend the meeting (space/time-wise), 
but might not be able to do it as a result of the meeting fees. IIRC, 
netdev was also hosted next to the IETF meeting in the past.

[...]
> too.

I couldn't agree more. In fact, from our perspective this was actually 
assumed (!)... but we should definitely spell this out.  (the same 
probably also applies to the list of "recommended restaurants" that 
somehow circulate in the attendee mailing-lists, as well as some 
interesting 90USD+/meal dinners that get organized during the week).

> I've usually managed to find something in adequate distance, but it 

Believe me that I know exactly what you mean. :-)

Thanks a lot!

Regards,

---

From: Dan Harkins <[email-masked]>
Date: Wed, 24 Feb 2021 21:22:53 -0800

> Are you saying we shouldn't be documenting best (and worst) practices?
   Huh?

   I don't believe I have ever said that and I don't believe I have
ever said anything even close to that.

   Dan.

---

From: Theresa Enghardt <[email-masked]>
Date: Wed, 24 Feb 2021 21:56:30 -0800

Hi Fernando,

See inline:

On 24.02.21 20:35, Fernando Gont wrote:
>> students, etc, potentially to be added to Section 4 as a separate
>> group, include:
>>
>> - Input for your own teaching (learning about the IETF and its
>> processes has very much enhanced discussions with my students)
> What you describe does indeed seem beneficial, but in principle
> doesn't seem to necessarily contribute to the work of the IETF.
>

I was talking about active participation, too.

For example, if a researcher goes and presents their work at an IETF
Working Group meeting, I would consider that an IETF contribution, e.g.,
that the Working Group can get ideas from. For instance, a few years
ago, we have had several academics present their work in TAPS, and that
was definitely a lot of helpful input. Not sure how common this style of
contribution is, but I think it does happen especially when a smaller WG
is in an "early stage" where they benefit from a lot of input and ideas.
(Of course, a lot of work that is relevant to IETF Working Groups is
getting presented at IRTF sessions, e.g., MAPRG, IRTF Open, or at ANRW.
But I can understand if you consider these out of scope for your document.)

Another way for academics to contribute is to implement (part of) a
draft as an academic exercise, or have a student implement it as a
project, and then give feedback to the Working Group. We have had
multiple such implementations in TAPS. Even if the implementation is
most likely not going to be widely deployed, and even if development may
not continue beyond the duration of a project, it is still helpful input
for the Working Group. And for the academic, it gives the implementer a
relevant and interesting project to work on, the implementer gets some
experience with IETF technology, and they get to make professional
connections, which can result in further collaboration. Definitely a
win-win, and something that I've seen happen at IETF hackathons.

Moreover, academics may submit an idea as an Internet Draft just to get
feedback on it. Even if maybe the draft will not make it all the way to
an RFC, or some parts of the original draft may be taken out and become
part of a different draft, etc, it can be a very valuable perspective
for the academic. Again, I have seen this happen in TAPS.

Finally, I liked reviewing drafts even as an academic, because it helped
me understand current work better, which, again, may provide context and
input for future research.

Perhaps as an additional perspective, at ANRW 2018, Sharon Goldberg gave
a brief presentation on why and how academics may want to participate in
the IETF, see the first 10-15 minutes of this recording:
https://www.youtube.com/watch?v=gSvZcMAcC_0

> netdev was also hosted next to the IETF meeting in the past.

Yes, definitely. Now maybe it would also be interesting to consider if
the demographics of participants in the IRTF or in Netdev are
substantially different from the participants in the IETF.

>> Universities usually have a travel budget and they may also have
>> rules on how much a hotel is allowed to cost per night. IETF hotels
>> are usually, if not always, outside of that budget, and overflow
>> hotels are, too.
>

Agreed. I think it's a good idea to mention that the meeting fee is not
the only economic barrier to participation, but often, flight and hotel
are much more expensive. (Especially for students, for whom the meeting
fee is reduced.)

Best,
Theresa

---

From: Christian Huitema <[email-masked]>
Date: Wed, 24 Feb 2021 22:01:50 -0800

> win-win, and something that I've seen happen at IETF hackathons.

Yes, there are many ways academics can contribute. Look for example at 
the work Robin Marx did on structured QUIC logs formats and 
visualization tools. Part of his PhD, but also a very valuable 
contribution to the working group, with many implementation 
standardizing on the log format that he proposed and running his tools. 
That was great.

-- Christian Huitema

---

From: S Moonesamy <[email-masked]>
Date: Wed, 24 Feb 2021 22:13:19 -0800

Hi Rifaat,
At 04:40 AM 23-02-2021, Rifaat Shekh-Yusef wrote:
>So you have never reached out to us to try to bring any work to the 
>WG, and based on attending one meeting and hearing from a few 
>people, you formed a strong opinion and declared that "nothing would 
>get done"? that seems odd.

I suggest looking at it from a different perspective.  A person who 
is new to the IETF attends a working group session held at some 
exotic location.  There are the usual active participants debating 
during the session.  There isn't any significant progress on the 
issue(s) in his/her opinion.  Would he/she commit more time to engage 
in that working group?

Regards,
S. Moonesamy

---

From: Fernando Gont <[email-masked]>
Date: Thu, 25 Feb 2021 03:13:19 -0300

Hi, Theresa,

On 25/2/21 02:56, Theresa Enghardt wrote:
[...]
> I was talking about active participation, too.

Oops, my bad. Thanks for the clarification!

> Working Group meeting, I would consider that an IETF contribution, e.g.,

Indeed it is. I thought you were implying meeting attendance, without 
necessarily contributing. -- my bad.

> But I can understand if you consider these out of scope for your document.)

I think what you describe is definitely within scope.

That said, in my experienve, in many cases groups seem to receive points 
for peer-reviewed conference papers, but not for IRTF/IETF-style of 
participation, unfortunately. So making it to the IETF will typically be 
harder (in terms of funding) than e.g. attending to an IEEE or ACM 
conference.

[...]

This is all indeed very valid. I'll do my best to come up with text to 
incorporate this into our document (thanks, btw!).

[....]
> substantially different from the participants in the IETF.

I'll check to see if there are any stats available for those.

> are much more expensive. (Especially for students, for whom the meeting

Will try to spell these things out more clearly in the next rev.

Thanks a lot for your comments!

Regards,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 25 Feb 2021 03:17:05 -0300

Hi, Christian,

> standardizing on the log format that he proposed and running his tools. 

FWIW, for the most part we were implying the extent to which Academia 
might e.g. fund participation. We'll certainly expand on this topic, 
since the discussion regarding Academia is certainly incomplete/inaccurate.

Thanks,

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 25 Feb 2021 08:15:10 +0000

Hi Jen,

> So while I have some ideas of what improvements I need from a given protocol, I'd not be writing actual implementations, because I have no places to actually run it in the production.
> I'd rather collaborate with people who can write that code much faster and better than I would ever be able so I can run their code in production and provide some feedback from my operational experience.

It is important in this discussion to distinguish a couple of things.

- First, there is prototyping software that helps to provide input while writing the specification. Ideas that look great on paper may not necessarily work well when implemented.
- Second, not everyone in the working group is likely to implement a given protocol. However, someone has do the work. If we write specifications without any implementation input then the quality will be lower.

I am arguing that at least the authors of documents should have enough incentives to prototype their own specs. The leadership can help to create a culture in the IETF where implementation work is valued.

So, if you are an author of a protocol spec then you should IMHO also verify the spec via an implementation.

There are lots of specifications that do not describe protocols and hence they may not need any implementation work. They will benefit from different input, as some of the other folks on this list have pointed out. This may, for example, be operational know-how to configure already implemented protocols and to make observations with the installed base. This is an important area, as Henning Schulzrinne pointed out in his paper "Networking Research - A Reflection in the Middle Years", see https://arxiv.org/abs/1809.00623.

I hope this clarifies my statements.

Let's look at an example. The drafts you are involved in*, such as draft-ietf-6man-grand-03, look like protocol specifications to me (although I am not participating in 6man). If you care enough about draft-ietf-6man-grand, which I am assuming since you the sole author,  you might want to check whether the content is actually sound. This can happen in various ways, such as by doing a prototype or by testing configurations (if that's appropriate).

Ciao
Hannes

*: I hope I searched correctly.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 25 Feb 2021 08:21:57 +0000

As someone who has chaired several working groups it is my experience that even with the best preparation the meetings are unpredictable. It is unpredictable because we are dealing with humans. To avoid total chaos many working groups meet outside the official meeting time to discuss and prepare contentious topics. Sometimes this works and sometimes this does not.

If you want to always have "shiny and happy" meetings then we need to stage them, like in politics. In some cases you have to submit questions upfront and only the answers are read to you. I don't think you would want this either.

I think we have to tune our expectations a bit: not everything works right from the start and not everyone gets what he or she wants.

Ciao
Hannes

-----Original Message-----
From: ietf <[email-masked]> On Behalf Of S Moonesamy
Sent: Thursday, February 25, 2021 7:13 AM
To: Rifaat Shekh-Yusef <[email-masked]>; [email-masked]
Subject: Re: Diversity and Inclusiveness in the IETF

Hi Rifaat,
At 04:40 AM 23-02-2021, Rifaat Shekh-Yusef wrote:
>formed a strong opinion and declared that "nothing would get done"?
>that seems odd.

I suggest looking at it from a different perspective.  A person who is new to the IETF attends a working group session held at some exotic location.  There are the usual active participants debating during the session.  There isn't any significant progress on the
issue(s) in his/her opinion.  Would he/she commit more time to engage in that working group?

Regards,
S. Moonesamy

---

From: S Moonesamy <[email-masked]>
Date: Thu, 25 Feb 2021 04:12:47 -0800

Hi Hannes,
At 12:21 AM 25-02-2021, Hannes Tschofenig wrote:
>If you want to always have "shiny and happy" meetings then we need 
>to stage them, like in politics. In some cases you have to submit 
>questions upfront and only the answers are read to you. I don't 
>think you would want this either.

I probably did not follow the meeting of your working group.  I would 
have to read the minutes to see whether there was any contentious issue.

As a general comment, I can guess what some participants will say at 
the microphone as I have interacted with those persons over the 
years.  I would not expect any participant to submit questions 
upfront as it does not make sense to travel to an exotic location to 
answer those questions.

Regards,
S. Moonesamy

---

From: Theresa Enghardt <[email-masked]>
Date: Thu, 25 Feb 2021 08:16:16 -0800

Hi Fernando,

On 2/24/21 10:13 PM, Fernando Gont wrote:
> That said, in my experienve, in many cases groups seem to receive 
> points for peer-reviewed conference papers, but not for 
> IRTF/IETF-style of participation, unfortunately. So making it to the 
> IETF will typically be harder (in terms of funding) than e.g. 
> attending to an IEEE or ACM conference.

That is true. With ANRW, you at least get to present a short paper or 
poster at a workshop, so that's a step in the right direction.

Good point about publications. RFCs are publications, too, so there is 
definitely some ROI in (co-)authoring an RFC as an academic. However, 
usually the entire process takes much longer than writing academic 
papers. And I'm not sure how academia at large values RFCs relative to 
papers, but at least in the part that I know, I would say they're valued.

I think some academic institutions explicitly value it if researchers 
give "input to practice", demonstrate the applicability of their work, 
etc. So that could be used as a reason for presenting at IETF meetings, 
too, though most academic institutions would not understand the 
difference between IETF and IRTF sessions.

You're welcome and good luck with the next revision!

Best,
Theresa

---

From: Warren Parad <[email-masked]>
Date: Wed, 24 Feb 2021 17:48:29 +0100

I'll add just one more thing here, even if the protocol exists, the
clarity, and was supported, I'm not sure that it would even be that widely
used. Thinking about this from the user perspective, I just can't imagine
how many would really choose to even need or want to set up these other
mechanisms. There is a very small community dedicated to web3.0 which
supports browser extensions to log in to various tools via crypto
blockchains.

There's still only a handful, and identity providers, who are actually in
this WG, can attest to supporting N+ number of AS and WebAuthN, and
username/password, and likely anything else users want. As one of them, we
add anything and everything that application developers want to support. So
it isn't the lack of paradigms, RFCs, or general neglect (/lack of desire)
to implement these. The blocking factor is the symbiotic evolution of user
desires, platform capabilities, and AS features. So as all AS don't support
all features, and as it seems the capabilities are there, even if they were
supported by user facing applications, there is still further that the
community as a whole needs to go to adopt the mindset of wanting to bring
custom unverified AS to the table.

Warren Parad

Founder, CTO

On Wed, Feb 24, 2021 at 5:34 PM Tim Bray <[email-masked]> wrote:

>> - {User} does this using GNAP and gets back an access token that’s tied
>> to the key {Bat} made back at the beginning. That token is tied (at the
>> {ISP}) to the user’s account.
>>
>> I think GNAPs lack of clarity is a non sequitur for the handling or not
>> of the multitrust arbitrary-client with arbitrary-service, however it's
>> lack of clarity for me prevents me from knowing whether GNAP actually seeks
>> to solve this problem. So from an OAuth WG perspective we can still ask:
>>
>> However let's look at GNAP, I've honestly been struggling to understand
>> at least one fully documented case that GNAP supports. It seems in every
>> We're a little better mostly these days, but it's still a tirefire, and
>> in my heart I do hold the OAuth working group's squatting on this area of
>> the landscape while failing to address this burning need partially

---

From: Seán Kelleher <[email-masked]>
Date: Thu, 25 Feb 2021 08:22:20 +0000

Just to clarify, I assume in this discourse that the "server" in this
client and server relationship refers to an AS/RS pair in OAuth
terminology? Based on this, one big sticking point for me on the
applicability of NxM, or even 1xM, is that all of the "M" RSs need to
publish the same interface for any meaningful implementation in the first
place.

It probably makes more sense with email clients, since as Bron said, there
is the common standard of POP. If we assume that all the email services
that we want to connect to publish the same POP interface, and would accept
tokens in the same way, then the way the authZ is handled is indeed the
point of divergence that needs to be resolved.

However, we're talking about NxM in the general case here. I feel like
using the likes of discovery and dynamic registration, etc. that's already
supported by OAuth, the "N" part of this equation is surmountable. But each
of the "M" servers also need to export the same interface, otherwise a
client is going to have to write custom code to deal with talking to the
service after the authZ step anyway, reintroducing the "problem" part of
the NxM problem.

As such, I would actually suggest constraining this discussion to just the
POP NxM problem rather than NxM in general because, for me at least, the
authZ part of the general case is the most "solved" part of the problem,
and the outstanding work lies more in consolidating the "M" RS interfaces.

On Wed, 24 Feb 2021 at 22:32, Bron Gondwana <[email-masked]> wrote:

> Yep, this is the big point - OAuth is designed to require the the third
> leg of trust that creates the NxM problem.
>
>
>
> If that dotted line between client and server requires a pre-existing
> trust relationship rather than the trust being entirely mediated by the
> user choosing to connect client A with server B, then you have the NxM
> problem.  This is the "you can only have your John Deere tractor serviced
> by an approved John Deere service centre" problem.  You can only use this
> client with servers who have pre-approved it.  Or fall back to the "cash of
> the internet" - plain text passwords.
>
> Excellent.  This is precisely what I've been waiting for for these very
> many years as a viable replacement for storing a password locally on disk.
> Just having the server able to distinguish between different client
> instances for the same user is a big start, because you can de-authorise
> one without having to lock out every connection - even if the user is still
> entering their password during the setup phase each time.
>
> This is what Fastmail already do with our own app, creating a long-lived
> access token and storing that on the device rather than storing the
> password itself - and you can log out any one client from your security
> settings page.  What's missing is a standard way to do that with any IMAP
> client.  The initial JMAP authentication proposal was a very simple case of
> pretty much this, build into to the protocol so everyone would do it.
>
> Making it easy to connect up arbitrary clients with per-client tokens the
> default, and easy rather than almost impossible to do in practice is where
> the big difference comes in.
>
> Bron.
>
> --

---

From: Seán Kelleher <[email-masked]>
Date: Thu, 25 Feb 2021 08:41:05 +0000

> leg of trust that creates the NxM problem.

I believe the snippet of Justin's that you quoted actually shows you how
you can forgo the trust element using dynamic client registration. It still
allows a "server" to identify requests and impose security policies via the
client ID, but without requiring the client author to manually register the
client in advance of using it (e.g. in the case where the client author
doesn't even know what servers the client is going to be connecting to).
You still need the client ID, but anyone can get one whenever they need it.

I'm also feeling a bit of confusion arising from a conflation of terms
between the regular client/server model and the terminology used in OAuth.
To be clear, in OAuth, the level of trust between the client and authZ
server only really depends on policy; as mentioned, dynamic client
registration can be used if you don't need any trust between the client and
AS.

---

From: Lars Eggert <[email-masked]>
Date: Thu, 25 Feb 2021 19:29:48 +0200

Hi,

On 2021-2-25, at 18:16, Theresa Enghardt <[email-masked]> wrote:
> That is true. With ANRW, you at least get to present a short paper or poster at a workshop, so that's a step in the right direction.

that was actually the main motivation for collocating ANRW always with the IETF - typically, academics can justify conference and workshop travel much more easily than standards travel.

> Good point about publications. RFCs are publications, too, so there is definitely some ROI in (co-)authoring an RFC as an academic. However, usually the entire process takes much longer than writing academic papers. And I'm not sure how academia at large values RFCs relative to papers, but at least in the part that I know, I would say they're valued.

One thing we did to increase the value of RFCs to academics was to assign them DOIs, which at least for universities in some geos is a prerequisite to even recognizing RFCs as academic output.

Thanks,
Lars

---

From: Andrew Campling <[email-masked]>
Date: Thu, 25 Feb 2021 17:39:28 +0000

>> for the first time the tools are a relic of 1990 of thereabouts and 
>> can be confusing and difficult.

+1 

> FWIW, we have already started to work on a revision of the draft (working copy at: 

This made me smile as GitHub is itself an excellent example of a tool being a barrier to entry for new participants.  I've been using word processors since the early '80s (WordStar back in the day), don't understand why anyone would opt to use a different tool to write a document.  I know that this point of view will not be accepted by many current IETF participants but it seems particularly perverse to use a software development tool to write documents when there are many widely available options that are far better suited to the task (many of which support collaborative writing).  

If the intent is to broaden participation by people from different disciplines then I'd urge the use of more commonly used tools wherever possible.  

Andrew

---

From: Fernando Gont <[email-masked]>
Date: Thu, 25 Feb 2021 14:54:32 -0300

On 25/2/21 14:39, Andrew Campling wrote:
[...]
[....]
>
>   > This made me smile as GitHub is itself an excellent example of a
> tool being a barrier to entry for new participants.

Note: I'm using github just as a file repository. I don't request or
expect people to create an account, or send pull requests. And where
certainly *not* using github as an issue tracker.

 > I've been using word processors since the early '80s (WordStar back in
 > the day), don't understand why anyone would opt to use a different
 > tool to write a document.  I know that this point of view will not be
 > accepted by many current IETF participants but it seems particularly
 > perverse to use a software development tool to write documents when
 > there are many widely available options that are far better suited to
 > the task (many of which support collaborative writing).

FWIW, we're editing the xml source with simple text editors (Linux gedit 
in my case), and then processing it with the xml2rfc tool.

So far, we're bouncing the text among co-authors, changes are applied, 
and then git is essentially used as a simple e.g. ftp alternative -- 
that's it.

And, since you've raised it: I personally agree that requiring the use 
of git/github does represent yet another barrier.

> If the intent is to broaden participation by people from different 
> disciplines then I'd urge the use of more commonly used tools 
> wherever possible.

I might as well upload the document via ftp/sftp, and subsequently 
provide an URL. git/gihub was simply easier.

But in no way we require or even expect the reader to use git/github.
(I do understand that other folks or wgs do... but that's not the case 
for this document).

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 25 Feb 2021 15:00:42 -0300

> that was actually the main motivation for collocating ANRW always with the IETF - typically, academics can justify conference and workshop travel much more easily than standards travel.

That's certainly interesting. We'll add a note about this along with 
Theresa's other comments.

> One thing we did to increase the value of RFCs to academics was to assign them DOIs, which at least for universities in some geos is a prerequisite to even recognizing RFCs as academic output.

Was the rationale documented anywhere?  (since this might be of value to 
note/reference, along with your other note above).

Thanks!

Regards,

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 25 Feb 2021 19:24:49 +0000

Nothing requires anyone to use Git or GitHub.

On the other hand, many (millions) of people do, people who often write open source code, and we want to engage with that community. As seems common for the IETF, it's up to the WG to decide.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 25 Feb 2021 16:34:41 -0300

> Nothing requires anyone to use Git or GitHub.

If a WG somewhat requires use of github, then the barrier is there.

> On the other hand, many (millions) of people do, people who often
> write open source code, and we want to engage with that community. 

My take is that engaging the open source community has more to do with 
lowering the barrier (including the economic barrier), and taking their 
input seriously, than with crafting documents with the tools said 
community usually employs when crafting code.

Similarly, to the extent that has been possible, I've tried to engage 
them asking for specific questions or trying to produce patches for 
their projects -- which tends to work better in terms of engaging them 
than "please look at my draft/spec... it's on gihub, btw".

Just my two cents,

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 25 Feb 2021 19:48:52 +0000

>    If a WG somewhat requires use of github, then the barrier is there.

Since no person, or no WG, has infinite resources, almost any attempts to engage some people mean that some others feel left out.  (Note the almost)

The IETF still maintains that no matter how git/GitHub are used, the classic mechanisms of email, etc., still must be used. Does that mean some conversations aren't fully discussed on the email, and some people feel left out? Yes.  Some people also dislike MIME email, and the moving away from IPv4 and FTP.  Things change.  For myself, I am just glad that we're not commenting on things via SMS.  I am tempted to create an OnlyFans account for ACME or HTTPAPI, tho. :)

---

From: Fernando Gont <[email-masked]>
Date: Thu, 25 Feb 2021 17:09:43 -0300

On 25/2/21 16:48, Salz, Rich wrote:
> Since no person, or no WG, has infinite resources, almost any
> attempts to engage some people mean that some others feel left out.
> (Note the almost)

Why do you think git/github will engage somebody that would otherwise 
not be engaged?

> The IETF still maintains that no matter how git/GitHub are used, the
> classic mechanisms of email, etc., still must be used.

When discussions end up spread over gihub and email lists, that's not a 
nice feature, IMO.

> Does that mean
> some conversations aren't fully discussed on the email, and some
> people feel left out? Yes.  Some people also dislike MIME email,

I use the least common denominator: plain text email.

Still most email clients will mangle patches sent via email -- which 
happens to be the normal workflow some projects such as the linux kernel 
and openbsd -- so at least for those things you'll probably resort to 
mutt or the like.

> and
> the moving away from IPv4 and FTP.  Things change.  For myself, I am
> just glad that we're not commenting on things via SMS.  I am tempted
> to create an OnlyFans account for ACME or HTTPAPI, tho. :)

My take is: if the tool improves your workflow, go for it. If it will 
get in the way, don't.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 25 Feb 2021 20:17:55 +0000

not be engaged?

Don't know for sure.  Have some guesses.  But that doesn't seem productive (like the OAUTH threads).

    get in the way, don't.

And my point is that improvement for some is bad for others and that's the way things are.

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 25 Feb 2021 12:26:44 -0800

> On the other hand, many (millions) of people do, people who often write open source code, and we want to engage with that community. As seems common for the IETF, it's up to the WG to decide.

Really, we engaged with the open source community by starting using GitHub?

What I saw is the opposite:  Open source developers were already working with the IETF, and some of them shoved GitHub down our throats.  This is not the IETF trying to be inclusive, this is developers trying to tell us how to do our job.

And yes, I am a coder and git and vim is where I spend most of my professional time.

-- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug

---

From: Keith Moore <[email-masked]>
Date: Thu, 25 Feb 2021 15:27:06 -0500

On 2/25/21 12:39 PM, Andrew Campling wrote:

> This made me smile as GitHub is itself an excellent example of a tool being a barrier to entry for new participants.
+1.
> I've been using word processors since the early '80s (WordStar back in the day), don't understand why anyone would opt to use a different tool to write a document.

I would like to make it be the case that anyone could submit a document 
written with their favorite word processor, and for that document to be 
converted to whatever format we want to use.   I actually think this is 
feasible for document submission.   If nothing else, most word 
processors can generate some flavor of HTML, and that HTML could be 
stripped down to its bare essence and converted to rfc2xml.   It's 
entirely doable, probably with a relatively small amount of python 
code.   (You do need some conventions for representing metadata in HTML 
that can be input with a word processor, but I think I see how to do 
that too.)

But if we insist on one particular word processor, that will create a 
huge mess.   Having multiple parties edit the same document in 
succession with different tools (even if they're supposedly all 
compatible with the same format) results in a document that some people 
won't be able to read or edit, won't display or print consistently, 
etc., and may not be repairable.     And all of those document formats 
are moving targets.

> I know that this point of view will not be accepted by many current IETF participants but it seems particularly perverse to use a software development tool to write documents when there are many widely available options that are far better suited to the task (many of which support collaborative writing).

Actually, I doubt there is a single option that is better and which 
supports collaborative writing.  Because forcing thousands of volunteers 
to use a common set of proprietary tools (many of which are unreliable, 
profoundly dysfunctional, expensive, and have abysmal user interfaces) 
is absolutely unacceptable.

Keith

---

From: Fernando Gont <[email-masked]>
Date: Thu, 25 Feb 2021 17:30:55 -0300

On 25/2/21 17:17, Salz, Rich wrote:
> Don't know for sure.  Have some guesses.  

This is not the first "proposal" associated with diversity (in this 
case, engagin open source developers) with not much of a rationale 
behind it :-) , so to speak...

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 25 Feb 2021 20:40:19 +0000

The rationale is that there are millions of people using GitHub, and if do documents with their toolchain, we will get more feedback from developers than if we tried to draw them into our toolchain.  I didn't realize that was what you were asking me.  This rationale was stated multiple times in the GIT WG.

Marc:
> What I saw is the opposite:  Open source developers were already working with the IETF, and some of them shoved GitHub down our throats. 

Interesting viewpoint.  Did you attend any of the WG meetings?  I didn't see your name in the mailing list archives.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 26 Feb 2021 09:44:28 +1300

> issue(s) in his/her opinion.  Would he/she commit more time to engage 

That is not a simple question with a simple answer. If the person (or
their employer) has a strong interest in the topic, they will invest
the time to follow the email discussions, understand what is going on
behind the apparent lack of progress, and decide how best to engage in
and influence the conversation. Anybody with much experience in complex
debates (whether or not in SDOs) will already know that things take
time (months or years). If the person has casual interest, they may 
decide to leave the topic alone and check back a year later. Any 
choice between those two extremes is possible, depending on the case.
I've certainly chosen many points on that scale during my time
at the IETF (and the Global Grid Forum when it existed, and minor
engagements with other SDOs).

Certainly, if one is not patient, persistent and open to argument,
one will not succeed in the IETF, but that is nothing to do
with diversity and inclusiveness. How we (those already here)
treat newcomers is of course important, but that is a quite
different question from the one you asked.

We already advise newcomers to watch the discussion for a while
before contributing [1]. Perhaps that advice should be strengthened.

Regards
    Brian

[1] https://www.ietf.org/about/participate/get-started/starting/

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 25 Feb 2021 12:45:43 -0800

> Interesting viewpoint.  Did you attend any of the WG meetings?  I didn't see your name in the mailing list archives.

Of the gendispatch WG meetings?  No.  I was responding to the email in ietf@

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 25 Feb 2021 12:49:49 -0800

On Thu, Feb 25, 2021 at 12:40 PM Salz, Rich <rsalz=
[email-masked]> wrote:

> The rationale is that there are millions of people using GitHub, and if do
> documents with their toolchain, we will get more feedback from developers
> than if we tried to draw them into our toolchain.  I didn't realize that
> was what you were asking me.  This rationale was stated multiple times in
> the GIT WG.
>

FWIW, my impression of the situation is the same as Rich's. I can say with
confidence that when TLS decided to adopt Github it was because we had seen
that it worked well in H2. With that said, I do think it made it easier for
people to get involved, in part because it was easy to offer small changes
without subscribing to a list, etc. It certainly made it easier to accept
such contributions.

-Ekr

> Marc:
> > What I saw is the opposite:  Open source developers were already working
> with the IETF, and some of them shoved GitHub down our throats.
>
> Interesting viewpoint.  Did you attend any of the WG meetings?  I didn't
> see your name in the mailing list archives.
>
>
> --
> Gendispatch mailing list
> [email-masked]

---

From: Keith Moore <[email-masked]>
Date: Thu, 25 Feb 2021 15:50:43 -0500

> The rationale is that there are millions of people using GitHub, and if do documents with their toolchain, we will get more feedback from developers than if we tried to draw them into our toolchain…

It seems to me that trying to favor one group of participants over 
others is exactly the opposite of inclusiveness.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 25 Feb 2021 18:16:44 -0300

On 25/2/21 17:49, Eric Rescorla wrote:
[...]
>     The rationale is that there are millions of people using GitHub, and
>     if do documents with their toolchain, we will get more feedback from
>     developers than if we tried to draw them into our toolchain.  I
>     didn't realize that was what you were asking me.  This rationale was
>     stated multiple times in the GIT WG.
> 
> FWIW, my impression of the situation is the same as Rich's.

Using the same toolchain, per se, doesn't seem like a rationale (note, 
I'm *not* challenging whether it was effective in your experience, but 
why rather why it was expected ot make a difference).

> I can say 
> with confidence that when TLS decided to adopt Github it was because we 
> had seen that it worked well in H2. With that said, I do think it made 
> it easier for people to get involved, in part because it was easy to 
> offer small changes without subscribing to a list, etc.

Ok, so this seems to imply that part of the thing is that subcribing to 
the mailing-lists is seen as part of the problem.

What about e.g. the archives for the discussions, for future reference? 
Is github.com expected to take on that role?

> It certainly made it easier to accept such contributions.

Certainly this kind of think may make the life of some easier, and the 
life of others more painful. But there *is* an implied tradeoff here. 
It's not a win-win thing.

Thanks,

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 26 Feb 2021 10:21:00 +1300

> One thing we did to increase the value of RFCs to academics was to assign them DOIs, which at least for universities in some geos is a prerequisite to even recognizing RFCs as academic output.

Nevertheless, it is in general hard to get RFCs recognised as valuable for tenure and promotion purposes, compared to more traditional publication streams such as highly-rated journals. That's one reason we did https://dl.acm.org/doi/10.1145/1672308.1672315 but I'm not sure it has had much impact.

   Brian

---

From: Keith Moore <[email-masked]>
Date: Thu, 25 Feb 2021 16:25:54 -0500

[private reply]

On 2/25/21 4:21 PM, Brian E Carpenter wrote:

> Nevertheless, it is in general hard to get RFCs recognised as valuable for tenure and promotion purposes, compared to more traditional publication streams such as highly-rated journals. That's one reason we didhttps://dl.acm.org/doi/10.1145/1672308.1672315  but I'm not sure it has had much impact.

Back when I was a university researcher, one of my rejected grant 
proposals got returned with a note from a reviewer that said "you're 
spending time at the wrong conferences and citing the wrong kinds of 
references".   (Referring to IETF conferences and RFCs.)

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 25 Feb 2021 13:35:30 -0800

> why rather why it was expected ot make a difference).

Well, as I said below, for TLS and QUIC we had the experience of HTTP
to draw on, so our expectations were mostly "this will be similar to HTTP".
I can't speak for what caused the HTTP chairs to decide to use GitHub.
Perhaps experience in WHATWG?

> Is github.com expected to take on that role?

Generally yes, though it's of course possible to archive this separately.
Obviously, there are pluses and minuses here, but in my experience
GitHub makes doing the archaeology on what resulted in a given
decision quite a bit easier because you can use 'git blame' and the
commit history to find when the change was introduced and through
that the discussion (i.e., issue/PR) that lead to it.

> It's not a win-win thing.

It's very rare to find a change that doesn't inconvenience someone, and
given that we had a whole WG on this topic, I don't think it's that useful
to relitigate the relative pluses and minuses of Github usage.

-Ekr

---

From: Fernando Gont <[email-masked]>
Date: Thu, 25 Feb 2021 18:41:45 -0300

On 25/2/21 17:40, Salz, Rich wrote:
 > On 25/2/21 17:26, Marc Petit-Huguenin wrote:
[...]
> Interesting viewpoint.  Did you attend any of the WG meetings?  I didn't see your name in the mailing list archives.

Well, as per this discussion, it seems that mailing-lists and 
mailing-lists archives don't really matter much, anyway  ?

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 26 Feb 2021 11:06:37 +1300

> mailing-lists archives don't really matter much, anyway  ?

Not so; have you read RFC8874?

What happens in GitHub stays in GitHub. As far as IETF consensus goes, RFC2148 remains determinant.

   Brian

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 25 Feb 2021 22:25:26 +0000

>    Using the same toolchain, per se, doesn't seem like a rationale

Reducing a barrier to contribute is worthwhile.  Just as some are advocating being able to submit a draft in any format they have on-hand.

No.  Participating in a high-volume list with no practical ability to filter things out to just the one section of a draft, for example.

It is possible.  Martin's tools already archive all issues and discussions, and the IETF is already making copies of those repositories mentioned in the datatracker.

In my experience, very few things are win-win.

It would be nice if all potential IETF participants were born in the same era and used to the same tools, I suppose.  But it would also be very boring.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 25 Feb 2021 22:28:51 +0000

In another message you said you used to be a university researcher.  Surely, then, you are familiar with the concept of limited resources and first steps.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 25 Feb 2021 19:33:24 -0300

On 25/2/21 19:25, Salz, Rich wrote:
> Reducing a barrier to contribute is worthwhile.  

When you're changing the way of contributing, you're not universally 
"reducing the barrier". -- certainly not for somebody that does't do git.

> Just as some are advocating being able to submit a draft in any format they have on-hand.
> 

Point taken. So... mailing list are seen as a problematic mechanism to 
carry our work?

[...]
F is already making copies of those repositories mentioned in the 
datatracker.
> In my experience, very few things are win-win.

Indeed. That's why claiming that the barriers are lowered is a dificult 
claim.

> It would be nice if all potential IETF participants were born in the same era and used to the same tools, I suppose.  But it would also be very boring.

It's probably also boring that we all use IP....

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 25 Feb 2021 23:49:37 +0000

The IETF has not changed the way people contribute.  Drafts are still posted to the datatracker, mailing lists still exist for feedback and comment (and must be used for confirming consensus, etc).  Just because there are more paths into the datatracker now.  I mean, probably around 1985-1995 we all just FTP'd the documents we wanted to read.  Is anyone going to argue that it's not easier now?

    carry our work?

For some people I think the answer is yes.  It seems that overall use of email is declining, but it's hard to get real numbers without getting tangled up in email marketing newsletter business.  But I feel like you keep trying to have me make blanket assertions and I don't want to do that.

---

From: Keith Moore <[email-masked]>
Date: Thu, 25 Feb 2021 19:21:43 -0500

On 2/25/21 6:49 PM, Salz, Rich wrote:

>>     So... mailing list are seen as a problematic mechanism to carry our work?
>>
>> For some people I think the answer is yes.  It seems that overall use of email is declining, but it's hard to get real numbers without getting tangled up in email marketing newsletter business.

Some people prefer other ways of collaborating, and email also seems 
worse than it used to be.   As far as I can tell there are many reasons 
for that: mobile devices have resulted in reduced attention spans (who 
wants to read and mark up an Internet-Draft over a phone?), increasingly 
inconsistent user experience from one user to another, poor support for 
plain text, spam, a tendency of lots of different programs to clutter 
email with low-value notifications, etc.

It's still hard to beat email for IETF's purposes, though: it's very 
accessible and inclusive, low cost, doesn't require proprietary 
interfaces, easy to archive (and allows storage of arbitrary metadata in 
the message header), searchable, can use it without risk of vendor 
lockin, and seems to offer less risk to participants' privacy than other 
collaboration tools.

More generally I think the very nature of IETF - collaboration between 
large numbers of individuals from all over the planet and working in a 
wide variety of environments - inevitably requires some compromises.   
We will sometimes need to use tools that aren't our first choices, and 
we may need to use those tools differently than we'd use, say, with 
co-workers at our employers.   We can probably adapt and improve those 
interfaces over time, but some balance will need to be maintained 
because the same tool that optimizes one person's experience is likely 
to pessimize someone else's.

Keith

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 25 Feb 2021 19:49:53 -0500

My RFCTool takes Markdown and Word format documents and converts them to
Word, Markdown, HTML, TXT and XML2RFC.

Most of my source documents are a combination of Word and Markdown.
Generating Markdown examples much easier than generating Word.

The Word document format is an open standard at this point and pretty much
every word processor out there can generate output in it.

The reason for choosing HTML over Word is that HTML editors mostly suck.

On Thu, Feb 25, 2021 at 3:28 PM Keith Moore <[email-masked]>
wrote:

> > This made me smile as GitHub is itself an excellent example of a tool
> being a barrier to entry for new participants.
> +1.
> the day), don't understand why anyone would opt to use a different tool to
> write a document.
>
> > I know that this point of view will not be accepted by many current IETF
> participants but it seems particularly perverse to use a software
> development tool to write documents when there are many widely available
> options that are far better suited to the task (many of which support
> collaborative writing).
>

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 26 Feb 2021 02:19:27 +0100

On 25. Feb 2021, at 21:27, Keith Moore <[email-masked]> wrote:
> 
> I would like to make it be the case that anyone could submit a document written with their favorite word processor, and for that document to be converted to whatever format we want to use.   I actually think this is feasible for document submission.

This works if the draft is written by a single person.
This approach does not lend itself to cooperative editing, for many reasons.

Grüße, Carsten

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 25 Feb 2021 20:42:57 -0500

I think there are actually two issues related to authoring approaches 
that we do not currently handle very well.

First is probably not our problem as an organization.  That is the one 
you allude to below.  If there are multiple authors, they need a tooling 
approach that the authors collectivly can work with.  Whether that is 
github, passing source around, having a single pen-holder, ... is up to 
the author team.

There is however a second problem.  Namely the ability for the WG to 
take charge of the document when the author either can't or doesn't.  I 
still remember how much work the new author had to do with the ForCES 
protocol spec to convert the document from a very messy (and error 
prone) word format to the XML that we could edit in tools that would 
work for us. (The previous author / editor had left her company and 
therefore was no longer supported to do the work.)

Yours,
Joel

---

From: Larry Masinter <[email-masked]>
Date: Thu, 25 Feb 2021 18:06:28 -0800

Keith is talking about formats for submission. For collaboration, there's a generation of collaborative tools from Google Docs to Dropbox and Microsoft tools that are a lot better than GitHub for collaboration.

I'd suggest, though, starting with a conservative rule: any Internet Draft may be SUBMITTED in any of the RFC OUTPUT formats: XML2RFC, plain text, simple HTML, PDF. ("simple HTML" needs definition but it isn't hard).

You can use whatever collaborative tool you want, though you might have to do a conversion, but that's true for Markdown and GitHub use.    And every one of the collaborative document tools offer at least one of those formats.
--
https://LarryMasinter.net https://interlisp.org

> From: ietf <[email-masked]> On Behalf Of Carsten Bormann
> Sent: Thursday, February 25, 2021 5:19 PM
> To: Keith Moore <[email-masked]>
> Cc: [email-masked]
> Subject: Re: document writing/editing tools used by IETF
> 
> feasible for document submission.
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 25 Feb 2021 21:06:24 -0500

My tools accept input in either word or markdown and can round trip
losslessly between them.

---

From: Keith Moore <[email-masked]>
Date: Thu, 25 Feb 2021 21:45:35 -0500

On 2/25/21 9:06 PM, Larry Masinter wrote:

>   For collaboration, there's a generation of collaborative tools from Google Docs to Dropbox and Microsoft tools that are a lot better than GitHub for collaboration.

Better in what sense?  I try to not let most of my computers talk to 
Google, for example, because they're so invasive.   (Not sure about 
Dropbox or Microsoft because I basically never have any reason to use 
anything produced by either.)

Keith

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 25 Feb 2021 22:18:02 -0500

On Thu, Feb 25, 2021 at 9:08 PM Larry Masinter <[email-masked]> wrote:

> Keith is talking about formats for submission. For collaboration, there's
> a generation of collaborative tools from Google Docs to Dropbox and
> Microsoft tools that are a lot better than GitHub for collaboration.
>

There only needs to be a single interface to the ID/RFC system.

My model is to allow the authors to edit the drafts in Word/Markdown and
create HTML output close to what the ID/RFC system produces. When they have
agreed on an update, they send the .xml file to the submission system.

So

Source: Word (for spell checked text), Markdown (for machine generated text)
Review: HTML (caveman TXT if people must).
Submit: XML2RFC

I regard XML2RFC to be a submission format and nothing more. At the moment,
it is generated as a file format along with the HTML and TXT versions but I
am thinking about moving to a separate submit command which would interface
directly to the ID submission system. This would allow some housekeeping
functions to be done more smoothly.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 26 Feb 2021 01:29:56 -0300

Hi, Rich,

On 25/2/21 20:49, Salz, Rich wrote:
> The IETF has not changed the way people contribute.  Drafts are still
> posted to the datatracker, mailing lists still exist for feedback and
> comment (and must be used for confirming consensus, etc).  Just
> because there are more paths into the datatracker now.  I mean,
> probably around 1985-1995 we all just FTP'd the documents we wanted
> to read.  Is anyone going to argue that it's not easier now?

Based on some comments it seems that in some cases a significant 
fraction of the discussion moved to github. Hence my question.
In such a case, participants are kind of required to participate in github.

I didn't participate much (if at all) in the recommendations regarding 
the use of github in the ietf. And my assumtion was that for the most 
part it was more of a "use it if deemed useful", but was assuming the 
discussions that would lead to changes to remain in the mailing-lists.

> For some people I think the answer is yes.  It seems that overall use
> of email is declining, but it's hard to get real numbers without
> getting tangled up in email marketing newsletter business.  But I
> feel like you keep trying to have me make blanket assertions and I
> don't want to do that.

No, no. It was a honest question. Me I wasn't aware about some of the 
assumptions that were mentioned in the thread... hence my questions.

Thanks,

---

From: S Moonesamy <[email-masked]>
Date: Thu, 25 Feb 2021 21:43:20 -0800

Hi Brian,
>engagements with other SDOs).

My guess on a draft which I presented to GENDISPATCH was that it was 
unlikely that it would be sponsored by the Responsible Area 
Director.  It was better, in my opinion, to get the so-called 
"running code" experience on that.

In my opinion, whether it was a simple question or not depends on the 
level of experience of the persons engaged in the exchange.  The 
debates are, in general, complex given the vested interests.  I 
remember a question which was asked in a session about the IETF which 
was partially funded by an organization I am affiliated with.  A 
young woman from West Africa asked the speaker how he gets paid for 
what he what he was doing.  It was an awkward moment as there is an 
expectation that people residing in Africa should not ask such a 
question to a person who resides outside the region.

>different question from the one you asked.

The "open to argument" is actually related to diversity.  In some 
cultures direct confrontation is viewed as immature and unnecessary.

>before contributing [1]. Perhaps that advice should be strengthened.

The advice to newcomers is likely against IETF Consensus [1].

Regards,
S. Moonesamy

1. There was a discussion about "adults in the room".

---

From: Larry Masinter <[email-masked]>
Date: Thu, 25 Feb 2021 22:07:47 -0800

Better in the sense that they were explicitly designed and managed for the exact purpose of document publication and review, unlike GitHub, which was designed for managing code in some programming languages, and only poorly adapted for editing technical specifications.

You can do your own search but, for example,
https://getvoip.com/blog/2020/06/25/document-collaboration-tools/

certainly I don't propose IETF select one. My proposal is a restriction of yours: not to allow ANY format for an I-D but just to allow document submission in HTML or PDF (and not just plain text or XML2RFC).

The reasoning is to allow authors/editors to choose their own development tools, most of which can produce PDF or HTML but few can produce (legible) text/plain or XML2RFC.

Historical note: My co-author of RFC 1867 in 1995 was working on Xerox DocuShare, which needed form-based file upload for online document collaboration.

> From: Keith Moore <[email-masked]>
> Sent: Thursday, February 25, 2021 6:46 PM
> To: Larry Masinter <[email-masked]>; 'Carsten Bormann' <[email-masked]>
> Cc: [email-masked]
> >   For collaboration, there's a generation of collaborative tools from Google
> Docs to Dropbox and Microsoft tools that are a lot better than GitHub for
> collaboration.
> 
> Better in what sense?  I try to not let most of my computers talk to Google,
> for example, because they're so invasive.   (Not sure about Dropbox or
> Microsoft because I basically never have any reason to use anything
> produced by either.)
> 
> Keith
>

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 26 Feb 2021 08:36:02 +0100

> For collaboration, there's a generation of collaborative tools from Google Docs to Dropbox and Microsoft tools that are a lot better than GitHub for collaboration.

I’m sorry, Larry, you’d have to have a very weird sense of “better” to believe that.

I have had extensive exposure to the MS-Word type of “collaboration” (I was the editor of RFC 3095 which was done in MS-Word, with 16 collaborators).  The English language does not have words to describe that experience.

For hacking out a quick draft, shared editors like Google Docs are fine (we mostly use hedgedoc née codimd née hackmd for that, and it sure is fun).  For structured, controlled collaboration in a large team, nothing beats VCS systems like git, and github has a lot of mindshare in the tools around that process (issue tracking etc.).  

It is simply hilarious to imagine the QUIC or HTTPBIS WGs typing away at a shared Google doc.  That’s not how it works.  Specs are code, and there is a good reason why creating good documents (like the core ones of the above WGs) benefits from experience in collaborating on code.

Grüße, Carsten

---

From: Lars Eggert <[email-masked]>
Date: Fri, 26 Feb 2021 09:50:43 +0200

Hi,

On 2021-2-25, at 20:00, Fernando Gont <[email-masked]> wrote:
> Was the rationale documented anywhere?  (since this might be of value to note/reference, along with your other note above).

not as far as I know. This was discussed a bunch of times at various IRSG meetings ~5 years ago. (As as the decision on how to schedule the ANRW.)

Thanks,
Lars

---

From: Lars Eggert <[email-masked]>
Date: Fri, 26 Feb 2021 09:54:49 +0200

Hi,

On 2021-2-25, at 23:21, Brian E Carpenter <[email-masked]> wrote:
> Nevertheless, it is in general hard to get RFCs recognised as valuable for tenure and promotion purposes, compared to more traditional publication streams such as highly-rated journals.

completely agreed. DOIs don't fully solve the problem, they are a first required step. Some tenure committees operate under rules that don't makes it difficult to consider evaluating something that doesn't have a DOI.

> That's one reason we did https://dl.acm.org/doi/10.1145/1672308.1672315 but I'm not sure it has had much impact.

Yes, that is an invaluable document when RFCs are able to be considered for evaluation.

Thanks,
Lars

---

From: Julian Reschke <[email-masked]>
Date: Fri, 26 Feb 2021 08:55:22 +0100

Am 26.02.2021 um 04:18 schrieb Phillip Hallam-Baker:
> On Thu, Feb 25, 2021 at 9:08 PM Larry Masinter <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Keith is talking about formats for submission. For collaboration,
>     there's a generation of collaborative tools from Google Docs to
>     Dropbox and Microsoft tools that are a lot better than GitHub for
>     collaboration.
>
>
> create HTML output close to what the ID/RFC system produces. When they
> have agreed on an update, they send the .xml file to the submission system.
> ...

I'll +1 Carsten's "specs are code".

The huge benefit of a text-based, easily-diffable format is that you can
put it under source control, and then have tools that show who changed
what and when (and optimally why). For every single change, not just
between submitted IDs. For instance, for the HTTP core documents, that
history goes back to December 2007 (and it has survived conversion from
Subversion to Git).

If you can do that with Word, I'd definitively like to see that.

Best regards, Julian

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 26 Feb 2021 09:05:40 +0100

+1

For me, one of the greatest virtues of the IETF work style has always
been that I wasn't forced to use MS Office (or similar software, which
is often even worse).

Lada

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: Lars Eggert <[email-masked]>
Date: Fri, 26 Feb 2021 10:34:32 +0200

> If a WG somewhat requires use of github, then the barrier is there.

It may be a barrier to some. It may also *lower* the barrier for others. It's a tradeoff.

For example: The QUIC WG uses GitHub extensively. That has made it very easy for the engineers that are implementing QUIC stacks at various organizations to participate in the WG, because much of that development already happens on GitHub and so the WG process is more approachable. For many of these engineers, QUIC is their first involvement in the IETF, and using tools and workflows that are familiar hence lowers the bar for their participation. On the flip side, several longtime IETF participants were not very familiar with GitHub and its workflows, and the WG's heavy use of them required some adjustment, making it a bit more challenging for them for a while. Personally, I believe this was a worthwhile tradeoff to make, given that we needed to manage the design of a very complex protocol, but YMMV.

Thanks,
Lars

---

From: Lars Eggert <[email-masked]>
Date: Fri, 26 Feb 2021 10:38:25 +0200

On 2021-2-25, at 22:09, Fernando Gont <[email-masked]> wrote:
> When discussions end up spread over gihub and email lists, that's not a nice feature, IMO.

It is possible to configure GitHub so that issue discussion is reflected onto a mailing list, and email responses get reflected into the web issue system. QUIC uses the quic-issues@ mailing list for that. That mailing list is an IETF list, searchable and archived.

Thanks,
Lars

---

From: Fernando Gont <[email-masked]>
Date: Fri, 26 Feb 2021 06:09:56 -0300

Hi, Lars,

> It may be a barrier to some. It may also *lower* the barrier for others. It's a tradeoff.

That's essentially what I tried to note.

FWIW, I only had one experience of github usage in an IETF wg, and the 
result wasn't probably the best -- discussion split in to different 
places, some huge monolithic pull requests, and other things. -- of 
course, this doesn't talk about the tool, but rather about how it was 
used.  -- Glad it worked differently for QUIC!

Out of curiosity: has the experience been documented such that e.g. 
other groups could learn/reproduce the adjustments you referred to?

Thanks,

---

From: Lars Eggert <[email-masked]>
Date: Fri, 26 Feb 2021 11:17:10 +0200

On 2021-2-26, at 11:09, Fernando Gont <[email-masked]> wrote:
> Out of curiosity: has the experience been documented such that e.g. other groups could learn/reproduce the adjustments you referred to?

I think RFC8874/8875 capture what we did.

Thanks,
Lars

---

From: Colin Perkins <[email-masked]>
Date: Fri, 26 Feb 2021 11:03:07 +0000

> On 25 Feb 2021, at 16:16, Theresa Enghardt <[email-masked]> wrote:
> 
> Hi Fernando,
> 
>> That said, in my experienve, in many cases groups seem to receive points for peer-reviewed conference papers, but not for IRTF/IETF-style of participation, unfortunately. So making it to the IETF will typically be harder (in terms of funding) than e.g. attending to an IEEE or ACM conference.
> 

I think this is very much country dependent. The UK government, for example, explicitly evaluates impact beyond academia when assessing university research, so promotion committees generally value standards work, but that’s certainly not true everywhere.

Colin

> I think some academic institutions explicitly value it if researchers give "input to practice", demonstrate the applicability of their work, etc. So that could be used as a reason for presenting at IETF meetings, too, though most academic institutions would not understand the difference between IETF and IRTF sessions.
> 

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

---

From: "Andrew McConachie" <[email-masked]>
Date: Fri, 26 Feb 2021 12:38:11 +0100

> If you can do that with Word, I'd definitively like to see that.

Have folks considered setting up a MediaWiki instance and simply writing 
documents as wiki pages?

Pros:
* used by millions of people
* open source
* online collaboration
* supports multiple editing frontends
* built-in diffs
* extensive change tracking and rollback features
* built-in issue tracking
* can write in markdown
* user permissions settings for editing
* import/export anything that supports markdown

If there’s a feature you want for online collaborative document 
creation there’s a good chance MediaWiki already has it.

—Andrew

---

From: Vittorio Bertola <[email-masked]>
Date: Fri, 26 Feb 2021 12:56:27 +0100 (CET)

>     Il 25/02/2021 21:49 Eric Rescorla <[email-masked]> ha scritto:
> 
>     I do think it made it easier for people to get involved, in part because it was easy to offer small changes without subscribing to a list, etc. It certainly made it easier to accept such contributions.
> 
My experience is the exact opposite - there were a number of times in which I wanted to propose text for a document, but then I was pointed at Github, and I am not at ease with it and did not have a lot of time for it. So I gave up or, rather than working on actual text, I just replied on the mailing list making my points and suggestions in a more general way. Unfortunately, this makes your points less likely to be included, since the authors would have to make the effort to write the text for you, or, even if you provide text on the mailing list, the effort to copy and turn it into a pull request.

Some do, some don't; and even if they do, you are placed in the difficult position to ask someone else to do "your" job. Even admitting that you may need help with the tools, in this environment, is a bit scary - it's like admitting in public that you are not "good enough" to participate in the IETF. This gets even worse if you know that your contribution is "diverse" enough for you to expect that some of the regular participants will not receive it well.

In the end, as Lars correctly pointed out, this is a tradeoff. There are instruments that are easier to use for some groups but harder for others. There are instruments that work better with certain types of contributions, and other instruments that work better with other types. So, the choice of instruments is not neutral - it can tilt the balance in participation.

It may indeed be that Github is optimal, maximizing contributions from the people that have more to say. It may also be that it is functional to the preservation of the current leadership and culture of the organization, making it difficult for people with other backgrounds to participate effectively. I do not feel expert enough in the IETF to make a judgement on this, but the issue is clearly there.

--

---

From: Bill Woodcock <[email-masked]>
Date: Fri, 26 Feb 2021 13:04:54 +0100

> On Feb 26, 2021, at 12:56 PM, Vittorio Bertola <vittorio.bertola=[email-masked]> wrote:
> There were a number of times in which I wanted to propose text for a document, but then I was pointed at Github

Eh, don’t let the code-monkeys get you down.  If they knew what they were talking about, they’d say it in IRR poem records.  :-)

> I just replied on the mailing list making my points and suggestions.

This is the way.

                                -Bill

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 26 Feb 2021 09:48:08 -0600

On Fri, Feb 26, 2021 at 2:06 AM Ladislav Lhotka <[email-masked]>
wrote:

> >> For collaboration, there's a generation of collaborative tools from
> Google Docs to Dropbox and Microsoft tools that are a lot better than
> GitHub for collaboration.
> >
> > I have had extensive exposure to the MS-Word type of “collaboration” (I
> was the editor of RFC 3095 which was done in MS-Word, with 16
> collaborators).  The English language does not have words to describe that
> experience.
>
> +1
>

I think a lot of people would like to use Word because of wide spread use
of MS Office in workplace. It is almost standard there. Appreciating this
even Apple comes up with Office for MAC software.

I disagree with those who say MS-Word collaboration is not good, that means
you don't know Word well :)

Having said that I have always preferred to use XML2RFC tool and continue
to use it. I am sure some people will always be happy using Word.

Behcet

> Lada
>
> >
> > For hacking out a quick draft, shared editors like Google Docs are fine
> (we mostly use hedgedoc née codimd née hackmd for that, and it sure is
> fun).  For structured, controlled collaboration in a large team, nothing
> beats VCS systems like git, and github has a lot of mindshare in the tools
> around that process (issue tracking etc.).
> >
> > It is simply hilarious to imagine the QUIC or HTTPBIS WGs typing away at
> a shared Google doc.  That’s not how it works.  Specs are code, and there
> is a good reason why creating good documents (like the core ones of the
> above WGs) benefits from experience in collaborating on code.
> >
> > Grüße, Carsten
> >
>
> --
> Ladislav Lhotka
> Head, CZ.NIC Labs

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 26 Feb 2021 16:52:42 +0100

On 2021-02-26, at 16:48, Behcet Sarikaya <[email-masked]> wrote:
> 
> I disagree with those who say MS-Word collaboration is not good, that means you don't know Word well :)

Well, the reality is, I’m going to collaborate with people who don’t know MS-Word well.

(And that is true of any tool, so an important metric of a tool is how much damage  a noob can do inadvertently.)

Grüße, Carsten

---

From: Justin Richer <[email-masked]>
Date: Fri, 26 Feb 2021 11:08:46 -0500

Right, it’s possible to patch OAuth to do this, but the whole “registration equals trust” mindset is baked into OAuth at a really core level. That’s one of the main reasons there’s been hesitance at deploying dynamic registration. It’s an extension that changes your trust model’s assumptions, and does so in a way that is challenging for a lot of large scale providers.

That’s why I personally think it’s really important that we get away from that registration model in GNAP, so we don’t repeat that same problem in the same way. Some people will still deploy GNAP with static registration, but this model becomes more exceptional than baseline. The philosophy of what’s considered an extension vs. default is important.

 — Justin

> On Feb 25, 2021, at 3:41 AM, Seán Kelleher <[email-masked]> wrote:
> 
> I believe the snippet of Justin's that you quoted actually shows you how you can forgo the trust element using dynamic client registration. It still allows a "server" to identify requests and impose security policies via the client ID, but without requiring the client author to manually register the client in advance of using it (e.g. in the case where the client author doesn't even know what servers the client is going to be connecting to). You still need the client ID, but anyone can get one whenever they need it.
> 
> I'm also feeling a bit of confusion arising from a conflation of terms between the regular client/server model and the terminology used in OAuth. To be clear, in OAuth, the level of trust between the client and authZ server only really depends on policy; as mentioned, dynamic client registration can be used if you don't need any trust between the client and AS.
> 
> On Thu, 25 Feb 2021 at 08:22, Seán Kelleher <[email-masked] <mailto:[email-masked]>> wrote:
> Just to clarify, I assume in this discourse that the "server" in this client and server relationship refers to an AS/RS pair in OAuth terminology? Based on this, one big sticking point for me on the applicability of NxM, or even 1xM, is that all of the "M" RSs need to publish the same interface for any meaningful implementation in the first place.
> 
> It probably makes more sense with email clients, since as Bron said, there is the common standard of POP. If we assume that all the email services that we want to connect to publish the same POP interface, and would accept tokens in the same way, then the way the authZ is handled is indeed the point of divergence that needs to be resolved.
> 
> However, we're talking about NxM in the general case here. I feel like using the likes of discovery and dynamic registration, etc. that's already supported by OAuth, the "N" part of this equation is surmountable. But each of the "M" servers also need to export the same interface, otherwise a client is going to have to write custom code to deal with talking to the service after the authZ step anyway, reintroducing the "problem" part of the NxM problem.
> 
> As such, I would actually suggest constraining this discussion to just the POP NxM problem rather than NxM in general because, for me at least, the authZ part of the general case is the most "solved" part of the problem, and the outstanding work lies more in consolidating the "M" RS interfaces.
> 
> On Wed, 24 Feb 2021 at 22:32, Bron Gondwana <[email-masked] <mailto:[email-masked]>> wrote:

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 26 Feb 2021 17:17:56 +0100

On 26. 02. 21 16:48, Behcet Sarikaya wrote:
> 
> 
> On Fri, Feb 26, 2021 at 2:06 AM Ladislav Lhotka <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     > On 2021-02-26, at 03:06, Larry Masinter <[email-masked]
>     >> For collaboration, there's a generation of collaborative tools
>     from Google Docs to Dropbox and Microsoft tools that are a lot
>     better than GitHub for collaboration.
>     >
>     > I have had extensive exposure to the MS-Word type of
>     “collaboration” (I was the editor of RFC 3095 which was done in
>     MS-Word, with 16 collaborators).  The English language does not have
>     words to describe that experience.
> 
>     +1
> 
> I think a lot of people would like to use Word because of wide
> spread use of MS Office in workplace. It is almost standard there.
> Appreciating this even Apple comes up with Office for MAC software.

That's fine, but it doesn't mean that Word (or Office Open XML) format
is best for distributed development, archivation and exchange of RFC
documents. RFCs written in 1996 version of Word would not be readable
with today's version.

> means you don't know Word well :)
This is perfectly possible. I just concluded long ago that using Word is
detrimental to my mental health, I think I was trying to integrate texts
from a dozen or so contributors at that time.

> 
> Having said that I have always preferred to use XML2RFC tool and
> continue to use it. I am sure some people will always be happy using Word.

Certainly, I just don't want to be forced to do the same.

Lada

> 
> Behcet
> 
>     Lada
> 
>     >
>     > For hacking out a quick draft, shared editors like Google Docs are
>     fine (we mostly use hedgedoc née codimd née hackmd for that, and it
>     sure is fun).  For structured, controlled collaboration in a large
>     team, nothing beats VCS systems like git, and github has a lot of
>     mindshare in the tools around that process (issue tracking etc.). 
>     >
>     > It is simply hilarious to imagine the QUIC or HTTPBIS WGs typing
>     away at a shared Google doc.  That’s not how it works.  Specs are
>     code, and there is a good reason why creating good documents (like
>     the core ones of the above WGs) benefits from experience in
>     collaborating on code.
>     >
>     > Grüße, Carsten
>     >
> 
>     -- 
>     Ladislav Lhotka
>     Head, CZ.NIC Labs

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 26 Feb 2021 11:18:08 -0500

My problem with XML2RFC format is simple: I learned how to use SGML
properly when working on HTML and the XML2RFC format breaks so many rules
it is really hard to remember what the peculiarities are. HTML was well
established when the format was proposed but everything had to be done
different. The revised version is an improvement but it is a C++ solution,
it can't address the fundamentally bad decisions of what it is built on.
Nor can XML overcome all the idiocies of SGML.

What I suspect Larry was referring to when he said Microsoft has better
tools for this is their collaboration tools rather than Word. Though I do
like using Word because it has annotation features and change tracking
built in.

On Fri, Feb 26, 2021 at 10:49 AM Behcet Sarikaya <[email-masked]>
wrote:

>> > It is simply hilarious to imagine the QUIC or HTTPBIS WGs typing away
>> at a shared Google doc.  That’s not how it works.  Specs are code, and
>> there is a good reason why creating good documents (like the core ones of
>> the above WGs) benefits from experience in collaborating on code.
>> >
>> > Grüße, Carsten
>> >
>>
>> --
>> Ladislav Lhotka
>> Head, CZ.NIC Labs

---

From: Tim Bray <[email-masked]>
Date: Fri, 26 Feb 2021 08:31:55 -0800

On Fri, Feb 26, 2021 at 8:10 AM Justin Richer <[email-masked]> wrote:

> Right, it’s possible to patch OAuth to do this, but the whole
> “registration equals trust” mindset is baked into OAuth at a really core
> level. That’s one of the main reasons there’s been hesitance at deploying
> dynamic registration. It’s an extension that changes your trust model’s
> assumptions, and does so in a way that is challenging for a lot of large
> scale providers.
>

Justin is correct but being extremely diplomatic. “There’s been hesitance”,
as he puts it, translates in practice to some lawyer or VP saying “You want
to accept auth assertions for business transactions from unknown parties?
I have no interest in jail time, so forget it.”

>
> That’s why I personally think it’s really important that we get away from
> that registration model in GNAP, so we don’t repeat that same problem in
> the same way. Some people will still deploy GNAP with static registration,
> but this model becomes more exceptional than baseline. The philosophy of
> what’s considered an extension vs. default is important.
>
>  — Justin
>
>> It probably makes more sense with email clients, since as Bron said,
>> there is the common standard of POP. If we assume that all the email
>> services that we want to connect to publish the same POP interface, and
>> would accept tokens in the same way, then the way the authZ is handled is
>> indeed the point of divergence that needs to be resolved.
>>
>> As such, I would actually suggest constraining this discussion to just
>> the POP NxM problem rather than NxM in general because, for me at least,
>> the authZ part of the general case is the most "solved" part of the
>> problem, and the outstanding work lies more in consolidating the "M" RS
>> interfaces.
>>
>>> Does this solve the NxM problem? No, because companies are still going
>>> to decide that they only talk to keys or identifiers that they know ahead
>>> of time. But the protocol puts the dynamic case forward as baseline and
>>> fits in much better with the likes of JMAP than OAuth ever could:
>>>
>>> Making it easy to connect up arbitrary clients with per-client tokens
>>> the default, and easy rather than almost impossible to do in practice is
>>> where the big difference comes in.
>>>
>>> Bron.
>>>
>>> --

---

From: Aaron Parecki <[email-masked]>
Date: Fri, 26 Feb 2021 08:32:51 -0800

Dynamic client registration does exist in OAuth:
https://tools.ietf.org/html/rfc7591

The point is that basically nobody uses it because they don't want to allow
arbitrary client registration at their ASs. That's likely due to a
combination of pre-registration being the default model in OAuth for so
long (the Dynamic Client Registration draft was published several years
after OAuth 2.0), as well as how large corporations have decided to run
their ASs where they want to have (what feels like) more control over the
things talking to their servers.

On Fri, Feb 26, 2021 at 8:22 AM Warren Parad <wparad=
[email-masked]> wrote:

> A) I don't think it is helpful to talk about what other WGs are doing, or
> how GNAP attempts to fix or not fix these problems.
> B) Sharing statements like this:
>
>> dynamic registration
> Don't help everyone come to the same conclusion, Who is "we" here, it begs
> the question "is there a mindset baked into OAuth", I think to work
> effectively we need to be talking about how to best to tackle challenges
> everyone and anyone brings up and not fallback on arbitrary statements. It
> would be one thing to point to a document which outlines the exact issues
> with dynamic registration and then we could potentially have a valuable
> conversation about "are those reasons still relevant or do we need to
> revisit."
>
> Right now it seems there is "Someone in the past decided this was a bad
> idea, so we can't do it", rather than actually having the conversation
> about it.
>
> Just based on the conversation, it seems like the obvious right thing to
> do is provide dynamic registration in OAuth. Will client developers do the
> wrong thing, sure. Might it be challenging to support in a simple way,
> maybe. But having the addition to OAuth to solve the problem is better than
> nothing, and further it starts to change the mindset that dynamic
> registration is and should be provided when appropriate.
>
> Warren Parad
>
> Founder, CTO
> On Fri, Feb 26, 2021 at 5:11 PM Justin Richer <[email-masked]> wrote:
>
>>>> This is what Fastmail already do with our own app, creating a
>>>> long-lived access token and storing that on the device rather than storing
>>>> the password itself - and you can log out any one client from your security

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 26 Feb 2021 11:40:43 -0500

I spend rather too much time doing disinformation analysis these days. But
one of the issues that keeps coming up is what Sartre called a 'bad faith'
argument which is an unfortunate term in that people end up doing it
without being aware of it, no malice involved.

What Sartre was describing was an argument in which there are two separate
frames of reference used. The first frame is used to establish that X
applies, then once that is achieved the first frame is discarded and X is
interpreted in the second frame.

To take an example:

Frame 1: Tony Blair implemented many polices that are described in a paper
by Milton Friedman when the latter was shilling for a position in the
Democratic administration of Harry Truman: Blair is a 'neoliberal'.

Frame 2: Neoliberal Milton Friedman shilled for and was successful in
getting a consulting role in the Pinochet regime. Therefore neoliberals
support Pinochet. Therefore Blair supports Pinochet. Therefore Blair
supports the mass murder of 30,000 people.

I am seeing similar in the OAUTH discussion:

Frame 1: X must use OAUTH it is simple!

Frame 2: You have to understand how to apply OAUTH correctly. The
Turbo-encabulator mode is very powerful let me stroke my beard while you
come to that understanding.

And yes, folk are going to get upset about having their arguments presented
in this fashion but I really don't know how else to get through to them the
reasons why the people on the receiving end of those arguments are getting
upset.

There is a real problem in trying to get across unwelcome information. The
ground problem for many of us with OAUTH is that we simply cannot
understand it. And we rather suspect the problem isn't on our side. I have
come to find that not being able to understand things that exceed a certain
complexity is actually a profound advantage in architecture. The real value
of formal methods turns out to be they force people to reduce the problem
to something simple enough to write proofs about.

This is one of the reasons I would like to see the IETF move towards a W3C
style plenary in which WGs are required to provide short introductions to
what they do. No, not status reports: an elevator pitch. Because if nobody
in the group can describe what is going on with clarity, well perhaps they
don't know themselves.

it is really difficult to know what to do in these circumstances. I tell
people my criteria for adopting a technology early on. If they meet my
criteria, I will attempt to make use of their work product. But I feel
absolutely no obligation to do so if they don't.

---

From: Keith Moore <[email-masked]>
Date: Fri, 26 Feb 2021 11:43:11 -0500

> Appreciating this even Apple comes up with Office for MAC software.
Yes, I'm sure that one of the reasons some people like to use Word is 
that they're already familiar with it from their workplaces.
> means you don't know Word well :)

You say that like it's a bad thing :)

Also a lot of people don't use Word but use some other WP program that 
claims to support Word format.   In my experience this generally works 
ok for a single conversion, but works really poorly when people using 
different tools try to alternate editing passes, exchanging documents 
back and forth using "Word" format.

I personally detest Word because I've spent so much time fighting it 
when I only wanted it to do very simple things.   Other WYSIWYG tools 
that support Word format seem to be no better and often slightly worse.

But I think IETF should try to let all contributors use the tools that 
they're comfortable with using, and thereby minimize conflicts over 
which tools to use when collaborating.   But we probably can't support 
everything and we should be pragmatic about it.   I suspect that 
"pragmatic" looks something like: (a) let document editors use whatever 
they want for initial drafts, and when there are multiple editors let 
them decide among themselves. (b) Allow internet-draft uploads in a 
reasonable variety of formats (e.g. text, xml2rfc, pdf, maybe html with 
some constraints (the devil is in the details), but in any case 
something that the IETF tools can convert to pdf and ideally plain text 
also).  (c) "final" copies (say, prior to WGLC but maybe earlier if the 
WG wants to use github or something like it) should be in xml2rfc or 
anything else the RFC Series Editor will accept.

(But the sooner the authors/editors try converting to the final format, 
the less likely they'll get bitten by conversion errors late in the 
process.   Late surprises are never fun.)

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 26 Feb 2021 11:49:00 -0500

On 2/26/21 11:40 AM, Phillip Hallam-Baker wrote:

> This is one of the reasons I would like to see the IETF move towards a 
> W3C style plenary in which WGs are required to provide short 
> introductions to what they do. No, not status reports: an elevator pitch. 

We actually had similar plenaries, long ago, as a way to keep the 
broader community informed about what individual WGs were doing. First 
thing Monday mornings, as I recall.

---

From: Julian Reschke <[email-masked]>
Date: Fri, 26 Feb 2021 17:55:49 +0100

Am 26.02.2021 um 17:18 schrieb Phillip Hallam-Baker:
> properly when working on HTML and the XML2RFC format breaks so many
> rules it is really hard to remember what the peculiarities are.
 > ...

Such as? One or two examples would be great.

Best regards, Juloan

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 26 Feb 2021 18:47:07 +0100

> Such as? One or two examples would be great.

The most consequential rule that was broken was not putting text into attributes.

Moving @title to <name> fixes the most egregious problem, but I think many linger.

Grüße, Carsten

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 26 Feb 2021 19:05:46 +0000

As someone who has used just about all of the front-end tools mentioned in this thread (with front-end, I'm excluding all the processing tools because I've only used a few of those), I'd like to say that I really enjoy collaborative editing of markdown in GitHub and find it to be an excellent tool that is fully accessible to anyone with an Internet connection and a browser. I recently finished a document with a bunch of people-who-do-not-write-code -- some of whom didn't even have a GH account before this. I provided instructions. The only people who had issues contributing were the ones who never tried. Everyone who read the instructions and tried had no problem. If I had to provide instructions to someone who had never used Word, I suspect it would be a lot harder. Not to mention the cost of a Word license. One of the things that became clear in this process is that some people think you need to be running git on a local machine; that's not true.

If anyone is curious, these are the instructions I provided:
====================
## Signing up for a GitHub (GH) account

Everyone needs a GitHub account to participate. To set up a GH account, go to https://github.com/ and enter a preferred username, the email address you want to associate with the account (personal or work, depending on preferences and your corporate policies), and a password.  GH will impose username uniqueness and password strength.

## Signing in to GH

The https://github.com/ page defaults to "Sign Up". Click "Sign In" at the upper right to get the "Sign In" page if you already have an account.

## Using the GitHub UI

In the [repository](https://github.com/ <account>/<repo>), click on the file you want to edit, and then click on the pencil icon in the upper right of the file. Do your edits. When done, scroll to the bottom of the page, **select the checkbox that says "Create a new branch for this commit and start a pull request"** (this is really important), and click on the "Propose Changes" button. If the button says "Commit Changes" instead of "Propose Changes", then you need to click the "Create a new branch for this commit and start a pull request" button first. On the next page that appears, click "Create pull request". If you think some description of your changes might help, feel free to enter something in the "Leave a comment" box (either for Propose Changes or the Pull Request).

If you want to work on the Pull Request (PR) over time or provide additional edits to your existing PR, you can do this at any time before the PR is merged. To do this, you simply edit files in your newly created branch. Select your branch from the pulldown menu (default branch in the pulldown is "Main") at the upper left of the [<account>/<repo> Code](https://github.com/bitag-twg-org/bitag2.0) page. The pulldown menu is located right under the `<> Code` tab heading. After your PR is merged, that branch will be automatically deleted.

## Using Markdown

======================
This last part of the instructions had a link to https://guides.github.com/features/mastering-markdown/.
For an IETF draft that is going to be processed using kramdown-rfc2629, I would also include a link to https://github.com/cabo/kramdown-rfc2629.
I haven't used mmark or Phil's tools.
But I don't think the average author needs (or should need) to know much more than headers, paragraphs, lists, and IETF references. The first 3 are really, really simple. References aren't hard.

And that's it. I think if we made GH draft authoring this simple for people in IETF, opposition to it would disappear.
The main thing I think is missing is easy set up of GH workflows to create XML and HTML artifacts.

I find the "I hate Word" vs "I hate GH" argument to be futile. Just make it this easy for everyone to use GH and there'd be no argument.

Barbara

---

From: Christian Huitema <[email-masked]>
Date: Fri, 26 Feb 2021 12:11:27 -0800

On 2/26/2021 8:31 AM, Tim Bray wrote:

> On Fri, Feb 26, 2021 at 8:10 AM Justin Richer <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     “registration equals trust” mindset is baked into OAuth at a
>     really core level. That’s one of the main reasons there’s been
>     hesitance at deploying dynamic registration. It’s an extension
>     that changes your trust model’s assumptions, and does so in a way
>     that is challenging for a lot of large scale providers.
>
>
> Justin is correct but being extremely diplomatic. “There’s been 
> hesitance”, as he puts it, translates in practice to some lawyer or VP 
> saying “You want to accept auth assertions for business transactions 
> from unknown parties?  I have no interest in jail time, so forget it.”

Tim's point is very important. It shows a tension between "blindly 
accepting authentication claims from unknown parties", which would 
indeed lead to adversarial business consequences, and "only accepting 
authentication claims from parties that have been marked as trusted by 
my organization", which in theory looks safe but in practice drives 
concentration. If the trust decision is delegated to each site, we have 
the recipe for a network effect, in which only a very small set of big 
organizations can provide authentication for everybody, and collect the 
corresponding data and statistics.

This is both a very hard problem and an urgent problem. An IETF working 
group works on a hard issue and produces an incomplete solution. Big 
companies can fill the gaps by providing their own value. The result is 
further concentration of the Internet.

Such problems are very hard, but they are not impossible to solve. Look 
for example at PKI and its supporting infrastructure like the CAB Forum. 
It is not perfect, but at least it had the property of allowing web 
sites to use HTTPS without routing all authentication transactions 
through third parties. Wouldn't it be nice if we had a federation system 
on top of OAUTH? I suppose that is difficult. Not a reason to not try...

-- Christian Huitema

---

From: Michael Thomas <[email-masked]>
Date: Fri, 26 Feb 2021 12:36:45 -0800

On 2/26/21 12:11 PM, Christian Huitema wrote:
>> hesitance”, as he puts it, translates in practice to some lawyer or 
>> VP saying “You want to accept auth assertions for business 
>> transactions from unknown parties?  I have no interest in jail time, 
>> so forget it.”
>
>
> concentration. If the trust decision is delegated to each site, we 
> have the recipe for a network effect, in which only a very small set 
> of big organizations can provide authentication for everybody, and 
> collect the corresponding data and statistics.
>
> This is both a very hard problem and an urgent problem. An IETF 
> working group works on a hard issue and produces an incomplete 
> solution. Big companies can fill the gaps by providing their own 
> value. The result is further concentration of the Internet.
>
> Such problems are very hard, but they are not impossible to solve. 
> Look for example at PKI and its supporting infrastructure like the CAB 
> Forum. It is not perfect, but at least it had the property of allowing 
> web sites to use HTTPS without routing all authentication transactions 
> through third parties. Wouldn't it be nice if we had a federation 
> system on top of OAUTH? I suppose that is difficult. Not a reason to 
> not try...
>
>
I'm coming to the conclusion that federation is inherently a bad idea 
for many of the reasons that Christian cites above. What's even worse is 
that for OAUTH in particular use in native apps is ripe for "master" 
password harvesting making all of the things he cites and then it's not 
even secure.

What we should really be doing here is going back to first principles: 
this is being driven mainly from the desire to have single sign on so 
that we don't have to type passwords over and over. Passwords sent over 
the internet are the source of lots of problems but these days they are 
not inevitable. With webcrypto (simple) or webauthn (crypto dongles) we 
can enroll device and service specific asymmetric keys directly into the 
services without the need for either a password or a trusted third party 
at all. This keeps the relationship between user and service as it 
should be: 1:1.

See: https://out.mtcc.com/hoba-bis/

Mike

---

From: David Waite <[email-masked]>
Date: Fri, 26 Feb 2021 14:36:02 -0700

> On Feb 26, 2021, at 9:32 AM, Aaron Parecki <[email-masked]> wrote:

> The point is that basically nobody uses it because they don't want to allow arbitrary client registration at their ASs. That's likely due to a combination of pre-registration being the default model in OAuth for so long (the Dynamic Client Registration draft was published several years after OAuth 2.0), as well as how large corporations have decided to run their ASs where they want to have (what feels like) more control over the things talking to their servers.

Do you disagree that this gives them control over which things talk to their servers?

FWIW my personal mental model here is pretty simple:

With users, there are services you provide anonymously and services you provide only to registered/authenticated/trusted parties for various reasons. Once you are delegating user access, you still have many of the same reasons to provide access to anonymous or registered/authenticated/trusted delegates.

Dynamic registration arriving later and requiring additional complexity has unfortunately encouraged registration in use cases where anonymous clients might have been acceptable, but shifting the timelines or complexity balance would not  have changed business needs for authentication and trust of delegates. Omitting registration would have caused businesses to use other protocols that met their needs.

If AS’s are only getting what feels like proper control for their business needs, we should attempt to give them the actual control they require.

-DW

---

From: Aaron Parecki <[email-masked]>
Date: Fri, 26 Feb 2021 13:49:30 -0800

> Do you disagree that this gives them control over which things talk to
their servers?

Yes -- with a public client, I can impersonate a "real" app and it's
basically non-detectable by the AS. For a theoretical example, if I wanted
to use the Instagram API but they restrict which apps can upload photos to
only their own mobile apps, I can find the client ID of their own app, then
do an OAuth flow using their own client ID, and without a client secret it
looks the same as their own client. I'm unlikely to be able to get
arbitrary users to authorize my app because of limits and checks on the
redirect URI, but I can certainly do it myself for my own account. This is
the sort of false sense of security provided by the client registration
step I'm talking about.

I'd love to solve the app identity problem too, but that's only possible
with cooperation from the mobile OSs.

Aaron

On Fri, Feb 26, 2021 at 1:36 PM David Waite <[email-masked]>
wrote:

> > The point is that basically nobody uses it because they don't want to
> allow arbitrary client registration at their ASs. That's likely due to a
> With users, there are services you provide anonymously and services you
> provide only to registered/authenticated/trusted parties for various
> reasons. Once you are delegating user access, you still have many of the
> same reasons to provide access to anonymous or
> registered/authenticated/trusted delegates.
>
> Dynamic registration arriving later and requiring additional complexity
> has unfortunately encouraged registration in use cases where anonymous
> clients might have been acceptable, but shifting the timelines or
> complexity balance would not  have changed business needs for
> authentication and trust of delegates. Omitting registration would have
> caused businesses to use other protocols that met their needs.
>
> If AS’s are only getting what feels like proper control for their business
> needs, we should attempt to give them the actual control they require.
>
> -DW

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 26 Feb 2021 23:32:05 +0000

From: ietf <[email-masked]> on behalf of Phillip Hallam-Baker <[email-masked]>
Date: Wednesday, February 24, 2021 at 8:23 AM
To: Keith Moore <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: coders in IETF (was: Diversity and Inclusiveness in the IETF)

The Hackathon is typically more about determining what to code, discussing approaches with others, or testing that bits of code work with bits that others are writing. I doubt that the volume and quality of code produced during the Hackathon is as high as one might produce in one’s customized work environment. However, it provides the opportunity to be in the same space/room/conference with others working on the same code, similar code, or standards related to the code.

The feedback we have received is that while many find online IETF Hackathons useful, they are not as productive as in person Hackathons. People can code in a quite space any time. Getting a group of people with different but related interests together is more challenging.  Online hackathons help some with this, in person hackathons help even more.

I am sure that would be helpful and much appreciated as well.

Cheers,
Charles

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 27 Feb 2021 11:15:51 -0500

On Fri, Feb 26, 2021 at 11:32 AM Tim Bray <[email-masked]> wrote:

> saying “You want to accept auth assertions for business transactions from
> unknown parties?  I have no interest in jail time, so forget it.”
>

Getting back to the general case rather than litigating one particular
protocol. I have on many occasions found that the response to raising an
issue in the IETF is to be told that the solution is I should go and
'educate them' to understand that their concern doesn't matter.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 27 Feb 2021 13:31:47 -0500

One of the reasons I have switched from using the pandoc markdown used by
Carsten's tool to github markdown is that the latter is used by Git.

I agree Git has advantages over mailing lists. But we are using a tool that
isn't designed to meet our specific needs. I am for entirely separate
reasons looking at requirements for a tool that is designed to meet those
needs (but for a different community).

Previous attempts to get a discussion going on what tool we would want...
haven't exactly been successful. They turn into a github vs mailing list
editor war when my interest is quite different.

On Fri, Feb 26, 2021 at 2:11 PM STARK, BARBARA H <[email-masked]> wrote:

> As someone who has used just about all of the front-end tools mentioned in
> this thread (with front-end, I'm excluding all the processing tools because
> I've only used a few of those), I'd like to say that I really enjoy
> collaborative editing of markdown in GitHub and find it to be an excellent
> tool that is fully accessible to anyone with an Internet connection and a
> browser. I recently finished a document with a bunch of
> people-who-do-not-write-code -- some of whom didn't even have a GH account
> before this. I provided instructions. The only people who had issues
> contributing were the ones who never tried. Everyone who read the
> instructions and tried had no problem. If I had to provide instructions to
> someone who had never used Word, I suspect it would be a lot harder. Not to
> mention the cost of a Word license. One of the things that became clear in
> this process is that some people think you need to be running git on a
> local machine; that's not true.
>
> Everyone needs a GitHub account to participate. To set up a GH account, go
> to https://github.com/ and enter a preferred username, the email address
> you want to associate with the account (personal or work, depending on
> preferences and your corporate policies), and a password.  GH will impose
> username uniqueness and password strength.
>
> ## Signing in to GH
>
> The https://github.com/ page defaults to "Sign Up". Click "Sign In" at
> the upper right to get the "Sign In" page if you already have an account.
>
> ## Using the GitHub UI
>
> In the [repository](https://github.com/ <account>/<repo>), click on the
> file you want to edit, and then click on the pencil icon in the upper right
> of the file. Do your edits. When done, scroll to the bottom of the page,
> **select the checkbox that says "Create a new branch for this commit and
> start a pull request"** (this is really important), and click on the
> "Propose Changes" button. If the button says "Commit Changes" instead of
> "Propose Changes", then you need to click the "Create a new branch for this
> commit and start a pull request" button first. On the next page that
> appears, click "Create pull request". If you think some description of your
> changes might help, feel free to enter something in the "Leave a comment"
> box (either for Propose Changes or the Pull Request).
>
> If you want to work on the Pull Request (PR) over time or provide
> additional edits to your existing PR, you can do this at any time before
> the PR is merged. To do this, you simply edit files in your newly created
> branch. Select your branch from the pulldown menu (default branch in the
> pulldown is "Main") at the upper left of the [<account>/<repo> Code](
> https://github.com/bitag-twg-org/bitag2.0) page. The pulldown menu is
> located right under the `<> Code` tab heading. After your PR is merged,
> that branch will be automatically deleted.
>
> ## Using Markdown
>
> ======================
> This last part of the instructions had a link to
> https://guides.github.com/features/mastering-markdown/.
> For an IETF draft that is going to be processed using kramdown-rfc2629, I
> would also include a link to https://github.com/cabo/kramdown-rfc2629.
> But I don't think the average author needs (or should need) to know much
> more than headers, paragraphs, lists, and IETF references. The first 3 are
> really, really simple. References aren't hard.
>
> And that's it. I think if we made GH draft authoring this simple for
> people in IETF, opposition to it would disappear.
> I find the "I hate Word" vs "I hate GH" argument to be futile. Just make
> it this easy for everyone to use GH and there'd be no argument.
>
> Barbara
>
>
>

---

From: "John Levine" <[email-masked]>
Date: 27 Feb 2021 14:01:59 -0500

>editor war when my interest is quite different.

I agree that neither mailing lists nor github are ideal for the way the IETF works
today but I would be very unhappy if we invented yet another bespoke locally maintained
bunch of software.

We're strange but it's hard to imagine that we're so strange that there isn't an
existing package somewhere that will do the job either as is or with minor
customization.

R's,
John

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 27 Feb 2021 20:09:52 +0100

On 2021-02-27, at 19:31, Phillip Hallam-Baker <[email-masked]> wrote:
> 
> pandoc markdown used by Carsten's tool

That would be a different tool.

Kramdown-rfc is based on kramdown, one of the longstanding well-established markdown parsers.
(Its github history reaches back 12 years to 2008, and it already was an established project by then.  
By the way, kramdown is a Patreon creator — if you like kramdown-rfc, you may want to consider becoming a patron to its parent project.)

Pandoc combines another well-established markdown parser with a generator and conversion machinery to and from arcane formats, including MOOX (Microsoft’s Open Office XML, specifically .docx).  
Pandoc is sometimes used as a supplement to other markdown tools just for its math handling capabilities.

(Pandoc would have taken the world already, but development requires ghc, the Glasgow Haskell compiler, which is a self-bootstrapping compiler that can be rather capricious to install.  
A threshold that is worth crossing!)

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Sat, 27 Feb 2021 14:32:27 -0500

John Levine <[email-masked]> wrote:
    > I agree that neither mailing lists nor github are ideal for the way the
    > IETF works today but I would be very unhappy if we invented yet another
    > bespoke locally maintained bunch of software.

That's true.

    > We're strange but it's hard to imagine that we're so strange that there
    > isn't an existing package somewhere that will do the job either as is
    > or with minor customization.

You are stating this completely backwards.
We aren't strange, we are brilliant, and it's hard for others to understand
our needsd.

There were in fact, existing tools when we started: they were airplanes and hotels,
but we were strange, and we wanted to access remote computers without travel,
so we invented Telnet.  For many industries, they have stuck to travel up to
and including the beginning of the pandemic.  Many senior executives had
never used teleconference before the pandemic for instance: people came to them.

That bespoke system wasn't for everyone, so in the 1990s, some people outside
of the IETF, at a science laboratory turned built our "FTP" protocol into
HTTP+WWW, which we then took over the world as the way to access remote
computation.

People keep saying that our bespoke tools are somehow backwards, and that
other people have done a better job.  But it's almost always the opposite in
my opinion.

Our bespoke tools lead the way for others.  We know what we want, and we know
how our technology can be used to deliver it.   Others don't, so they
re-invent things over and over and over again.

We did this with Jabber+Audio, and then video streams for remote meetings,
and there were a dozen immitators.  They couldn't figure out cross-platform,
couldn't anticipate mobile devices and chromebooks and TVs with Internet
connections. Some even spread malware due to lack of "Security
Considerations", so we did our own based upon webrtc.

Now everyone does webrtc: but the other tools still regularly fail to provide
the right integrations.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 27 Feb 2021 14:35:37 -0500

On Sat, Feb 27, 2021 at 2:10 PM Carsten Bormann <[email-masked]> wrote:

> By the way, kramdown is a Patreon creator — if you like kramdown-rfc, you
> may want to consider becoming a patron to its parent project.)
>

With respect, we are both mistaken on this.

The plaintext escape on github is ''''
The plaintext escape in pandoc is ~~~~

And rather than aligning with github, what I seem to have actually done is
to switch to align with your tool in the examples I generate. As I recall,
my tool now accepts either. At this point the only difference in the tools
is the approach to handling the initial input of metadata and some details
about how references are handled.

I see the github/pandoc thing as a consequence of there not having been a
specification written for markdown which has held things back.

(Pandoc would have taken the world already, but development requires ghc,
> the Glasgow Haskell compiler, which is a self-bootstrapping compiler that
> can be rather capricious to install.

My tool runs on Windows, macOS and Linux without any additional
installations. Its just a single executable at this point.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 27 Feb 2021 14:54:02 -0500

On Sat, Feb 27, 2021 at 2:02 PM John Levine <[email-masked]> wrote:

> In article <
> [email-masked]> you
> write:
> IETF works
> isn't an

My plan is not to develop a niche tool for the IETF.

At this point I have a Threshold Key Infrastructure that enables a cloud
service to control decryption of data that the service cannot decrypt
itself. That is all open specifications, open source code and can use
either the ICANN DNS or the Mesh callsign registry to provide open
discovery. The code is very nearly complete.

As I said in a recent conference call, I am not a communist. I know that
the commercial potential of this work is significant. I am mostly doing
this because I want something to do but I wouldn't mind a Turing award and
I certainly wouldn't mind more loot.

I have designed my TKI so that it has the potential to add value to
products in many different industry sectors. Of course, most people in the
industry will ignore the ideas until there is a commercial threat to their
business. That happened with the Web as well. It was only after the White
House adopted the Web that the dotcom boom really started and every CEO was
suddenly asking if they should have a corporate Web site.

Since nobody buys raw technology, I am going to need an application that
provides an effective demonstration of the potential. And a collaboration
tool in which all the data is encrypted, including in the cloud is one of
the technology demonstrations that is probably the easiest to get venture
capital funding for.

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 27 Feb 2021 21:01:16 +0100

> never used teleconference before the pandemic for instance: people came to them.

Thank you Michael.

This was the best [email-masked] posting of the year so far, and it has good odds of staying the best for the entire year.

Grüße, Carsten

---

From: Keith Moore <[email-masked]>
Date: Sat, 27 Feb 2021 15:13:20 -0500

> today but I would be very unhappy if we invented yet another bespoke locally maintained

Perhaps someone could explain in more detail why bespoke software is 
inherently a Bad Thing.   IMO, forcing people to use poor nonstandard 
tools and accept vendor lockin is inherently a Bad Thing.

Keith

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 27 Feb 2021 21:13:29 +0100

> With respect, we are both mistaken on this.

???

You Keep Using That Word “pandoc", I Do Not Think It Means What You Think It Means

> The plaintext escape in pandoc is ~~~~

The pandoc markdown support took the tilde style from the then prevalent way of writing fenced code blocks, which was introduced as an alternative to indicating code blocks by simply indenting them at least 4 spaces in the original markdown spec [1].

[1]: https://daringfireball.net/projects/markdown/syntax#precode

Github flavored markdown introduced code blocks fenced with three (!) backticks (!); I don’t know why they saw a need to change the custom(*); maybe they couldn’t be motivated to keep holding the shift key for three key presses, or nobody at github took the effort to study the current custom.

Grüße, Carsten

(*) I’m saying “custom”, but really it was the “standard”, except that we are using this word in a different meaning.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 28 Feb 2021 09:15:41 +1300

> existing package somewhere that will do the job either as is or with minor

You'll never, ever get everybody to agree on this topic, because people come at it with different backgrounds, habits and skill sets. So it's futile to expect that everybody will be happy.

I really don't think we'll get anything significantly better than what we have now as the reference/archival/canonical format, which is xml2rfcv3. Why? Because it expresses what our document series needs in the way of metadata. That's all. It's ugly to look at, but we don't expect typical readers to look at it. It's ugly to edit, which many of us don't actually care about (I'm perfectly happy to edit it with XML Copy Editor, as it happens), but we have kramdown to avoid that ugliness.

That's quite separate from how we manage collaborative editing. GitHub is one way, and it suits some people. Quite a few of us used Subversion in the past; we did in fact use Subversion and trac as the basis for the ION documents experiment. If you want to see what it looked like:
https://web.archive.org/web/20080216034049/http://www.ietf.org/IESG/content/ions.html
IMHO, mixing Subversion and trac was complicated and confusing. I'm willing to believe that GitHub is better.

I've used "track changes" for collaborative development of .doc and .docx documents, and found it confusing and error-prone when more than say, two, authors were involved.

I am quite confident you will never get broad consensus on the best approach to collaborative editing. As long as we stick to BCP25, this doesn't matter, because editing is only a tool and not a method of determining consensus. Allowing individual authoring teams and WGs to choose the method of collaborative editing that suits them best seems good to me.

   Brian

---

From: Michael Richardson <[email-masked]>
Date: Sat, 27 Feb 2021 15:19:22 -0500

> thing Monday mornings, as I recall.

Yes, my first IETF, 36 had that.  By IETF40, they were gone, considered a
waste of common time.  There clearly was some value that we are now partially
missing.

There have been a few IAB Tech plenaries and SAAG presentations that fall
into the elevator pitch.  Tiru Reddy most recently did one on DOTS, for instance.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 27 Feb 2021 21:28:20 -0500

> waste of common time.  There clearly was some value that we are now

It is precisely the sort of exercise that like not repainting, you can miss
once or twice without issue. But if you stop doing it altogether you
suddenly realize was necessary.

And what really annoys is that we keep being told that the value of having
the meetings we do is that the areas can cross-fertilize.

This is also the sort of thing that has a lot of value for new members and
less for the old hands. So the folk in authority get rid of them because
they don't need them but they are blind to the fact that they have just
pulled up the drawbridge for new participants.

> into the elevator pitch.  Tiru Reddy most recently did one on DOTS, for

HOTRFC as well

---

From: "John Levine" <[email-masked]>
Date: 28 Feb 2021 03:00:08 -0000

In article <4064.1614454347@localhost>,
Michael Richardson  <[email-masked]> wrote:
>but we were strange, and we wanted to access remote computers without travel, ...

Indeed, but that was many decades ago. There are some ways in which the
IETF is cutting edge, some in which we are amusingly backward. Most
of the people I deal with can send an e-mail that says "I highlighted
the changes in yellow" and all of their correspondents see the yellow
text. Try that here. Remember that MIME was invented in the IETF and
HTML down the virtual hall from here, both about 30 years ago.

People do all sorts of online collaboration these days using tools
that have been developed over multiple decades. It is sheer hubris to
imagine that we are so special that nobody else could have built
collaboration tools that would work for us.

R's,
John
-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Keith Moore <[email-masked]>
Date: Sat, 27 Feb 2021 22:41:04 -0500

On 2/27/21 10:00 PM, John Levine wrote:

> It is sheer hubris to imagine that we are so special that nobody else 
> could have built collaboration tools that would work for us. 

No it's not, because:

  * IETF does have fairly unique requirements.  Few organizations
    collaborate among thousands of volunteer contributors and reviewers
    to write complex technical documents that must be universally
    accessible, publicly searchable, and archived.
  * Nearly all existing collaboration tools with the assumption that
    those collaborating can be forced to use those tools (e.g. because
    employers require it), whereas IETF cannot reasonably do that
    especially if (a) the tools are platform-specific, (b) the tools
    have significant per-user costs (we can't expect IETF participants
    to pay to use a common toolset), or (c) the tools violate users'
    privacy (which is true of all web sites that use tracking cookies) 
    (Want examples of sheer hubris, consider the many companies who
    think it's perfectly ok to track every bit of personal behavior that
    they possibly can of millions or billions of people.)
  * Most of these collaboration tools have vendor-lockin as part of
    their design, limiting their applicability for an organization that
    needs its documents to be maintainable for many decades.
  * Many collaboration tools do not work well for attendees in highly
    diverse time zones, especially if they expect people to watch for
    incoming instant messages.
  * Many collaboration tools that I see have lousy facilities for
    searching and archiving.
  * We are capable of evolving the tools we use to meet our needs, much
    more than can be said for tools that others provide.
  * Most of the collaboration tools that I see are actually worse than
    email in nearly every respect.
  * Any tools that are maintained by some company out there have a
    decent chance of not existing within a few years, or existing only
    in a form that isn't compatible with older files.   That goes even
    for tools made by Big Companies.
  * Forcing people to use crippled tools kills innovation.

I'm not saying that there absolutely is no solution out there, but it's 
pretty hard to beat what we have with COTS tools, and much easier and 
safer to do what we're doing than to expect some company to provide what 
we need.

Keith

---

From: Michael Richardson <[email-masked]>
Date: Sun, 28 Feb 2021 18:20:36 -0500

John Levine <[email-masked]> wrote:
    > IETF is cutting edge, some in which we are amusingly backward. Most of
    > the people I deal with can send an e-mail that says "I highlighted the
    > changes in yellow" and all of their correspondents see the yellow

Yup, and those same people also click on the links that install malware on
their computer, and require billions of dollars/year of protection against
trojans.

This is partially our fault, because we let text/html be a thing rather than
the much safer text/rich.  And we continue to allow text/html on our lists
for reasons I don't understand.

(I'm among those who don't render text/html by default, even though I could)

[Besides, highlighting changes in *yellow* is stupid, and it represents a
failure of our protocols.  You should highlight changes as mark-up, or as a
delta against a webdav]

---

From: Christian Huitema <[email-masked]>
Date: Sun, 28 Feb 2021 15:34:35 -0800

-- Christian Huitema 

> On Feb 28, 2021, at 3:20 PM, Michael Richardson <[email-masked]> wrote:
> 

And that's one of our failings, for which "blame the user" is a poor excuse.

-- Christian Huitema

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 1 Mar 2021 00:35:28 +0100

> On 2021-03-01, at 00:20, Michael Richardson <[email-masked]> wrote:
> 
> You should highlight changes 

…by writing something like
https://www.rfc-editor.org/rfc/rfc8949.html#section-appendix.g

(Indication of verbatim changes can be done by a diff tool — let the computer do the counting.
But the computer usually does not know the rationale for a change…
That’s why you need *changesets* and *commit comments*, best coupled to a discussion thread.)

I think much of the discussion of collaboration tools has a blub problem.
Please see http://www.paulgraham.com/avg.html "Beating the Averages" — ignore the annoying self-patting, but the really important concept of blub comes up about 1/3 down.

Grüße, Carsten

Aargh, I’m increasing my ietf@ article count again

---

From: John Wroclawski <[email-masked]>
Date: Sun, 28 Feb 2021 22:37:25 -0500

> On Feb 25, 2021, at 4:21 PM, Brian E Carpenter <[email-masked]> wrote:

Seconding Brian’s comment (and Keith’s in the next msg), the DOI effort and CCR articles were excellent, necessary first steps, but by themselves they’re not likely to change the landscape very much, I think.

The issue is more fundamental. Academia wishes to claim that its highest value publications are “original research”, and consensus-driven standards with the stated goal of codifying existing or emerging practice don’t “look” like that. My weasel words are because both sides of this stereotype are sometimes truly true and sometimes, well, not. But it's the perception, and it’ll be really hard to get the academic publication world to weigh RFCs heavily without changing it in some way.

Which, I think, might possibly be doable. Academia does have other values - you can get brownie points for a good survey paper, for example, because you’re "systematizing knowledge" - and increasingly (although not as much as one might hope) work that validates research results by showing the they’re repeatable is seen as publishable. But the trick here is to frame this as a case that RFCs and IETF participation advance some substantive academic value - not just to argue that they follow the “form” of academic publication by being peer-reviewed and having DOIs. I’m not sure if anyone’s every quite tried to do this, but it seems at least potentially possible.

—john

---

From: "John Levine" <[email-masked]>
Date: 28 Feb 2021 22:59:10 -0500

In article <3196.1614554436@localhost> you write:
>-=-=-=-=-=-

This kind of snark is not very helpful. Rendering colors in HTML has
nothing to do with whether a system has security bugs that let random
web links install software.  Even lynx can render colors and it's not
going to install anything.

>failure of our protocols.  You should highlight changes as mark-up, or as a

Interesting guess, but in this case wrong.

R's,
John

---

From: "Bron Gondwana" <[email-masked]>
Date: Mon, 01 Mar 2021 15:35:23 +1100

> As such, I would actually suggest constraining this discussion to just the POP NxM problem rather than NxM in general because, for me at least, the authZ part of the general case is the most "solve…

Sorry for the delay in responding - real life got in they way of this general discussion.

Yes, the common standard of POP - or indeed any common standard.  A fine example of common standards is the move towards many devices being charged by USB-C these days.  Previously, there was this:

https://en.wikipedia.org/wiki/Common_external_power_supply

Why?  So you that you don't need a new charger for each new device.

The whole point of being a standards org is to try to guide each "M" towards exporting the same interface when providing the same (or similar enough) underlying service, so that the network effects of interoperability are realised.

So yes, constrain to POP (and IMAP, and SMTP submission, and file storage, and calendars, and ... everything where there's enough similarity that clients should be able to portably interoperate with multiple services).

Right now the problem with POP/IMAP/etc is that the interoperable authentication choice is "username+password".  There's nothing better than that because there's no Micro-USB-like thing that has sufficient technical and political clout behind it that everyone implements it.

Bron.

---

From: "Bron Gondwana" <[email-masked]>
Date: Mon, 01 Mar 2021 15:40:17 +1100

> My experience is the exact opposite - there were a number of times in which I wanted to propose text for a document, but then I was pointed at Github, and I am not at ease with it and did not have…

Hmm.  Do you have some examples of this that you can point at?

Bron.

---

From: Keith Moore <[email-masked]>
Date: Mon, 1 Mar 2021 00:05:49 -0500

> HTML down the virtual hall from here, both about 30 years ago.
Ok, but to be fair: HTML is a disaster for email.   Way back in the 
mid-1990s most of us thought it would work out ok, and more likely to 
succeed than text/richtext.   But we didn't really take the time to 
understand the nature of the problem in either case.    It's hard to 
write a good html editor for email, especially one that handles inline 
replies properly, and every single HTML editor for email I know of 
botches this.    Accidentally delete the line or invisible space before 
or after a change in format and it's likely to completely mess up your 
formatting, say by merging one correspondent's text with another.  HTML 
doesn't handle annotations well either because (gasp) text messages are 
not naturally hierarchical like HTML (and its *ML predecessors) expect 
them to be.   HTML hasn't exactly been a stable target either, and 
there's lots of variation among MUAs regarding which features are 
supported. It's hard to send an email message that looks more-or-less 
the same to every recipient.

(And, IMO unfortunately, a lot of MUAs take liberties with presentation 
of email messages, which only exacerbates the above problems.)

At the same time HTML is so widely deployed that it's very hard to 
deploy something that works better.

The specific behavior you cite above is actually due to a failure of 
standardization, because the vast majority of Big Corporate environments 
have settled on 1 of about 2 email products overall.   Highlighting text 
in yellow doesn't work as well in IETF because IETF participants are 
(fortunately) still more diverse than Big Corporate employees.

Keith