Re: [Gendispatch] Diversity and Inclusiveness in the IETF

[Mary Barnes <mary.ietf.barnes@xxxxxxxxx>]

On Wed, Feb 24, 2021 at 1:22 AM Hannes Tschofenig <Hannes.Tschofenig@xxxxxxx> wrote:

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,

[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]

 

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

 

Ciao

Hannes

 

 

 

From: Mary Barnes <mary.ietf.barnes@xxxxxxxxx>
Sent: Tuesday, February 23, 2021 11:26 PM
To: Brian E Carpenter <brian.e.carpenter@xxxxxxxxx>
Cc: Hannes Tschofenig <Hannes.Tschofenig@xxxxxxx>; Fernando Gont <fgont@xxxxxxxxxxxxxxx>; ietf@xxxxxxxx; GENDISPATCH List <gendispatch@xxxxxxxx>; Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx>
Subject: Re: [Gendispatch] Diversity and Inclusiveness in the IETF

 

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 <brian.e.carpenter@xxxxxxxxx> wrote:

Hannes,

On 23-Feb-21 22: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*.

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
>
> *: 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
>
> -----Original Message-----
> From: ietf <ietf-bounces@xxxxxxxx> On Behalf Of Fernando Gont
> Sent: Tuesday, February 23, 2021 1:07 AM
> To: 'ietf@xxxxxxxx' <ietf@xxxxxxxx>; GENDISPATCH List <gendispatch@xxxxxxxx>; Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx>
> 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:
> 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: fgont@xxxxxxxxxxxxxxx
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
> 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.
>

--
Gendispatch mailing list
Gendispatch@xxxxxxxx
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.