On Tue, Aug 23, 2022 at 3:57 PM, Donald Eastlake <d3e3e3@xxxxxxxxx> wrote:
Hi Warren,On Tue, Aug 23, 2022 at 2:45 PM Warren Kumari <warren@kumari. > wrote:net On Tue, Aug 23, 2022 at 12:24 PM, Phillip Hallam-Baker <phill@hallambaker. > wrote:com On Tue, Aug 23, 2022 at 10:35 AM Salz, Rich <rsalz=40akamai.com@ > wrote:dmarc. ietf. org If the rules say one thing, and literally everyone else does something else, who is at fault? It seems that a case can be made for three possibilities:- Those who didn't follow the rules- The rules are wrong- The rules were not clear enoughDoes it matter? The only thing that we have left to do now are:* Decide if we want to fix the issue for the future* If so, decide how to fix it* Try to work out some general principles on how to design such systems.Hi all,I'm assuming that I missed some discussions, but assuming that we end up changing the process **for future nomcoms**, why wouldn't we just select an additional 0.5*NOMCOM backup members, according to the normal rules, including no more than N from a company, etc.E.g: if we need 4 people (limiting it to 4 for simplicity and so I don't need to make up more names) we select:Appointes:-----1: Lucija Steffie - Acme Tool and Die2: Hunter Nikomedes - Techfluent3: Sandra Jarah - Techgenics4: Hana Luke - Acme Tool and DieBackups:---------5: Vilmos Ida - Ratchet Technologies6: Lawali Dudley - Networks-R-Us(when running the algorithm, it also selected Wilma Flintstone, but we discarded Wikma because she also works for "Acme Tool and Die").Now, if we are unable to reach Hunter Nikomedes (or there is some other reason that Hunter cannot serve, like we discover that Techfluent is actually a wholly owned subsidiary of Acme Tool and Die[0]) the nomcom simply slots in Vilmos instead.We already have an "unconflicted" list, and companies (easily) cannot game this by having one of their employees not participate so that another one can, etc..I really feel like I must be missing something super obvious here - please point out where :-)What you are suggesting is how it was done in 1998 and how it has been done every year since then.
Ah — RFC3797 S5.1: "If someone in the pool is later selected by
the algorithm and random input but it has been determined they are
ineligible, they can be skipped and the algorithm run further to make
an additional selection." — somehow I'd parsed "run further" as "you can run it again". Clearly I didn't actually read the example (S.6) which says: "Should one of the above turn out to be ineligible or decline to serve, the next would be Sloth, number 22."
But recently there have been fears that if the 11th (or whatever) person is from sponsor X and someone (or two) from sponsor X is in the first 10, if sponsor X thinks this 11th person would be better on the nomcom they might pressure the selected person to refuse to serve. Or if the 11th person is from a customer of Sponsor X a sponsor X selected person could refuse to serve so as to give this customer a voting nomcom membership. Etc.
This could be mitigated by having "any sponsor who has a slot in the first tranche cannot have anyone in the backup." rule. So, Acme Tool and Die could have either one or two people in the first / primary set — but they cannot have anyone in the backup set. This way there is no way for someone to decline and have someone else from their company appointed… but, yes, it doesn't solve the "the 11th person is from a customer of Sponsor X", or Pete's "Rich (who is number 11 on the list) will stand up to mean Warren, so I'll step down"...
Anyway, while how it is done has to be carefully specified in detail, it has been suggested that this should be solved by keeping all of the initial selected 10 that want to serve and then selecting from the top of the remainder of the list after re-randoming its order.
…but… but.. if Acme Tool… um.. er, what about it… um… yeah, I got nothing.
I suspect that my initial hesitation about this is it feels somewhat disruptive to not know ahead of time who might be next - serving on the nomcom is a significant time and effort investment, and knowing that you are in the backup set allows you to plan ahead e.g not schedule vacation, set aside extra time, etc…
… but it turns out that not knowing ahead of time who might be next is actually the exact feature that we are looking for, and not a bug.
It still feels like there is a tiny tweak that can be made that somehow magically solves this without having to rerun the algorithm (minus the selected people), but everything I think of is either wildly baroque, or relies on secrecy, or similar… I have a horrible feeling I'm going to wake up at 3AM with the perfect solution, just to realize once I'm fully awake that it is completely, obviously and hilariously wrong.
W
Thanks,
Donald
===============================
Donald E. Eastlake 3rd +1-508-333-2270 (cell)
2386 Panoramic Circle, Apopka, FL 32703 USA
d3e3e3@gmail. com I also wonder if we may be going slightly overboard here: we are choosing a nomcom to appoint Area Directors, not elect the next pope.Although ADs *are* often mistaken for gods, in actual fact that are only very minor deities - demi-gods at best, and often just satyrs. This is backed up by the fact that we often have a hard time finding candidates willing to be apotheosized; often this is because they simply don't have support from their employers. If companies cared enough to try and stack the nomcom process through complex trickery like the above, surely we'd also be seeing them fighting to propose and support AD candidates, and gain influence in other ways (like trying to poach ADs and WG chairs and similar)?Yes, we should *clearly* make the process clear and transparent and deterministic and minimize opportunities for gaming (it's also a fun technical challenge), but we should also (IMO) keep in mind what it is that we are trying to accomplish.I'm slightly worried about some of the tone in parts of this thread — if we end up creating an absolutely perfect nomcom selection process, but end up losing our culture (and friends) in the process, have we really won? Perhaps I'm naive (and again, we should make the process as perfect as we can), but I also don't think that it is necessarily true that there are great forces stacked against us, waiting to swoop in and try and get their favorite candidate appointed — let's save some of this energy and passion and use it to move document along, etc…WP.S: Hmmm… I'm starting to have a horrible suspicion that I may have accidentally climbed onto a soap-box…..[0]: Clearly, getting people onto the NOMCOM is worth creating many many shell companies in order to stack the deck…. or something…The only one that interests me here is the last because I think NOMCONs smack of the sort of schemes Trotskyites used to engineer to ensure they maintained control over organizations. The real function of the scheme is to insulate the appointees from accountability by making it impossible to know who they will end up being accountable to.The general principle I learn from this is that if you want a system to be unambiguous, reduce as much of the system as possible to code. Introducing ceremony is one way of doing that. It isn't an accident that there is a shinto ceremony for making sword steel, the ceremony is the embodiment of the knowledge of how to make a particular quality of steel in a repeatable fashion.One of the main reasons security policy schemes fail in deployment is that you cannot apply security policy effectively unless the policy data itself is reliable. And that is only possible if the generation of that policy is automated.
