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.
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.
If you have a better idea, propose an update to RFC 8713.
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
