Re: [Gendispatch] Diversity and Inclusiveness in the IETF

[Mary Barnes <[e-mail]>]

On Wed, Feb 24, 2021 at 1:22 AM Hannes Tschofenig <[e-mail]>
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 <[e-mail]>
> *Sent:* Tuesday, February 23, 2021 11:26 PM
> *To:* Brian E Carpenter <[e-mail]>
> *Cc:* Hannes Tschofenig <[e-mail]>; Fernando Gont <
> [e-mail]>; [e-mail]; GENDISPATCH List <
> [e-mail]>; Keith Moore <[e-mail]>
> *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 <
> [e-mail]> 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 <[e-mail]> On Behalf Of Fernando Gont
> > Sent: Tuesday, February 23, 2021 1:07 AM
> > To: '[e-mail]' <[e-mail]>; GENDISPATCH List <
> [e-mail]>; Keith Moore <[e-mail]>
> > 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: [e-mail]
> > 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
> [e-mail]
> 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.
>