On Mon, Jun 29, 2020 at 05:11:00PM -0400, Andrew G. Malis wrote:
> Toerless,
>
> As Spencer says, the current rule (which is well documented in section 4.17
> of RFC 8713) is intended (for better or worse) to prevent NomCom from being
> made up of a small set of affiliations.
Sure, but but if some part of the IETF community comes
from an industry which for better or worse is structured into
fewer large companies than other parts of the community then it
puts this part of the community at a disadvantage.
I am looking at this in comparison with IMHO similar difficult
constructs. Aka: In ITU, each country has one vote. Is this fair
wrt. e.g.: USA/China with one vote each vs. E.g.: Europe or
Africa ? We are just seeing what this leads to. Even the electoral
college in the USA recognizes difference in size between states.
> I think that we're all in agreement that the more diversity in the I*, the
> better. Which implies that the more diversity on the NomCom, the better.
> However, there are very few levers that the IETF actually has to produce
> NomCom diversity other than affiliation.
How about we introduced a rule saying that there can be at most
two Nomcom people from one country ? That would create a lot more
diversity. Huh ? Unfair ? Why ? Because it affects more candidates than
the vendor role ? How is that a good argument if we are after diversity ?
I could equally say that the NomCom procedures suppress the diversity
from all the different voices just because they work for one company
instead of oh, for example a loyalty group built as a franchise
around a popular business model.
> If you have a better idea, propose an update to RFC 8713.
The first thing is for IETF attendants to even start thinking about
whether the current scheme is fair. I think most do. I don't. I also
said that the first stage of updating RFC8713 would be to consider
better acknowledging this fact and wondering if this is still appropriate
under the evolution in the community. I for once don't think it is
anywhere as useful as it might have been in the past. Definitely not
by itself as a one-off it is right now.
Cheers
Toerless
>
> Cheers,
> Andy
>
>
> On Mon, Jun 29, 2020 at 3:13 PM Toerless Eckert <tte@xxxxxxxxx> wrote:
>
> > [rant]
> >
> > The long time NOMCOM scheme we have, strongly punishes direct
> > employment by single big entities over other forms of loyalty
> > and ecosystem structures. I think this is a historic artefact
> > and lazyness in thinking about better solution, and it does IMHO
> > not well take into account the evolution we had in the IETF
> > over the last 20 years or so.
> >
> > How about all those one or two people (consulting) companies that
> > all have loyalty to a single undisclosed larger employer, like various
> > agencies of a single government ? AFAIK we do not ask, but
> > would we even consider different agencies of a single government
> > to be a single entity wrt. NOMCOM ? I don't think we have
> > done so when it comes to direct employment by them.
> >
> > I can attest that the interests and loyalties of different groups in
> > large vendors wrt. IETF leadership can easily be more diverse than
> > i would expect the goals of different agencies in a some governments
> > are.
> >
> > Not to speak of individuals who have a lot more loyalty to
> > the IETF purely from the self serving perspective that their
> > career in IETF may be longer than that in any individual employer
> > and behave accordingly. Wait. are we not all well advised to
> > all behave like that ? But we're obviously not trusted to do so
> > when working for a large employer.
> >
> > How about many small companies whose loyalties lie with the
> > specific business models such as those of OTTs/cloud-based ?
> >
> > How about the most likely subconcious "i have no idea on most
> > IETF area candidates, but in doubt i will vote for someone with
> > my own country/geo-area or cultural background" ?
> >
> > Why are big vendors the only aspect we try to protect NOMCOM
> > against ?
> >
> > Of course, i do not expect anything to improve, but at least
> > we could be more open about the fact how the NOMCOM scheme
> > is traditionally discriminatory in this respect. Because i don't
> > think people would even agree with this classiciation (discrimination).
> >
> > Having worked for 20 years for big vendors, i at least feld
> > this rule to be discrimination after having served once in
> > Nomcom and came out of it thinking that my specific vendor
> > association had no impact on my Nomcom choices. Sure, i can be
> > lying to myself. Who knows.
> >
> > Of course, i do favour for IAB and all IETF areas those candidates
> > who do not think the Internet infrastructure can be ignored
> > or commoditized because it just needs to macially come out
> > a wifi thingy into a notebook or cloud server and one just needs
> > to build applications on top of it.
> >
> > And exactly that candidate selection bias would likely be most
> > dominant in those nomcom candidates to which the discrimination
> > rule is applied, and if one wonders why the Internet infrastructure
> > standards evolution is (at least IMHO) so ossified where as the
> > applications running on top of it are not, then one has to wonder.
> >
> > Even if we cannot figure out how to improve the actual process,
> > it would be fairer to the IETF members working for large
> > employers if the Nomcom procedures would more explicitly
> > highlight the discrimination introduced to acknowledge this
> > unfairness. And write something like
> >
> > "we don't know how to do better, but if you have an
> > idea, please bring it forward".
> >
> > Just saying.
> >
> > [/rant]
> >
> > Cheers
> > Toerless
> >
> > On Mon, Jun 29, 2020 at 01:52:49AM +0000, Salz, Rich wrote:
> > > * It's a mechanism for mitigating the efforts of a few companies to
> > stuff the Nomcom and get their employees on the I*. I'm not sure it's the
> > best way, or sufficient, to assure the independence of leadership bodies
> > but I don't think it's unreasonable.
> > >
> > > Strong agreement.
> >
> > --
> > ---
> > tte@xxxxxxxxx
> >
> >
--
---
tte@xxxxxxxxx
