Dave, I think I disagree with you on several of the details in your discussion without necessarily disagreeing with where you are going with it. First of all, I think that the realistic view of the possibility of something leaking is enough to ensure that people do not make things up when giving feedback. The fact that what a person says may eventually get back to the one they said it about tends to make people stick to facts. That is useful. But the possibility needs to be very small. However important people may feel it is to verify what they hear, it is not a good idea to turn everything you hear into some sort of juicy gossip to be handed around like used needles. That is not only not useful, it leads to potentially seriously disruptive emotional reactions to what may very well have been meant as consturctive criticism. In addition, I think that someone who cannot deal with the possibility that they may hear things that they have to either keep entirely to themselves, or exercise a very high degree of discretion about, should be straight-forward about that at some point before they are exposed to that kind of information. If that means they have to step down from a liaison role, or some other role in the NomCom process, then that is what they need to do. However, I think this is buried in your comments under what I think you're identifying as the "human factor" - and it is true that the degree of discretion that applies is a very hard fence to walk. Never-the-less, some very simple guide-lines do exist. For example, consider the following: In a private NomCom discussion Sigfreed tells Signund that she heard that the candidate Borg has a reputation for being excessively stubborn. Signund happens to know Borg very well and they have been friends for many years. The possible choices for Signund range across (at least) the following possibilities - a) ignore the comment because it is clearly already second hand information, b) explore the comment further with Sigfreed to see if there is anything she knows from first hand, c) accept the comment as one data point but otherwise keep it to themselves, d) check with a number of other people to see if they have gotten a similar impression, but without referring to any specific source(s), e) check with Borg to see if there is any reason why anyone might have gotten the impression that Borg is stubborn (again being careful not to offer names), f) ask a few people where Sigfreed might have gotten such an impression about Borg, g) tell Borg that Sigfreed is saying that Borg is a stubborn person. Assuming that we all have pretty much the same ideas about what "confidentiality" means, I think it is fairly obvious that most people would agree that either a), b) or c) would be correct behaviors, and that d) and (possibly) e) might be okay under some circumstances but f) and g) are definitely out of line. I suspect that d) and e) are in the area in which leaking of confidential information is most likely to occur. Sure, it is possible that someone has decided to ignore a more conventional meaning of the word confidential to suit a personal agenda. Or it is possible that they are operating with a different understanding of what most people mean by "confidential." But - for the most part - indiscretion in this context is a result of simply sharing more information than intended while trying to verify something we need to be certain about. On the whole, I think most people understand that is something that can happen. I also think that what people are really concerned about is that confidentiality is not being observed as a convention, and as promised during the process. That must remain a legitimate concern. And the reason why that is the case is that it is necessary in getting honest and unambiguous feedback about people that the people being asked _believe_ that they're comments will be kep confidential. -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On > Behalf Of Dave Crocker > Sent: Wednesday, March 19, 2008 1:11 PM > To: IETF Discussion > Subject: Nomcom process realities of "confidentiality" > > G'day, > > The current discussion about Nomcom activities has been sufficiently > professional and constructive in tone to prompt me to raise a > particularly > delicate point: > > Just how realistic is our belief in confidentiality for > the process? > > It will be trivial to turn my query into an unintended attack > on personal > integrity. That's not what I intend and I hope it is not > what anyone does. > Indeed, I won't participate in any exchanges that are of that type. > > My view is that any problems are with unrealistic > expectations, rather than > personal failings. (Or rather, that personal failings occur > in all of us and we > need to make sure our institutional processes factor them in > realistically.) > > Assumptions about confidentiality are at the core of many > difficulties > surrounding the Nomcom process. They restrict what > information Nomcom gets and > they restrict what information it gives. They also seem to > introduce distortions > in decision-making, as well as tensions. > > That makes it worth ensuring that our expectations for > confidentiality along the > process match the reality. > > For example, > > I was on a Nomcom that considered whether to renew > someone and chose not to. > Input to Nomcom was extensive as was Nomcom's > consideration. The two Nomcom's > I've been on included a wide range of equally-experienced and > assertive IETF > folk. The affected person later communicated to me that they > had been told that > I directed the outcome. > > Someone within the committee talked to them about details > of internal Nomcom > discussions. That they got the information seriously wrong > merely underscores > the danger of inaccurate assumptions about confidentiality. > (Factor in whatever > assessment might be made of my range of behaviors and one > still has to be left > with the view that the idea of my controlling any outcome of > either Nomcom is > simply silly.) > > Were things more open, the person might have had access > to more than one > channel of description and might have been able to get a more > accurate sense of > what took place. Were things less open, then some sources of > distortion might > have been eliminated. > > To be clear, as a non-Nomcom community participant, I > have at various other > times interacted with Nomcom members who drew very, very > strict lines around > information they would (not) share with me. Indeed my sense > over the years is > that everyone takes the requirement extremely seriously. But > taking the > requirement seriously is different from never violating it. > > This was merely an example that I have first-hand knowledge about. > > To have a realistic model of confidentiality, we need a > realistic model of IETF > social processes. > > For example, many of the people in the IETF management pool > are at least very > close friends. Liaisons are present during all Nomcom > discussions. The strain > on a liaison who is party to highly critical discussions > about a very close > friend strikes me as excessive: It is not reasonable to > expect them to maintain > confidentiality. And I repeat that I am offering this merely > as an example. And > note that the challenge is not only present for liaisons. > > Add to this the fact that a) we have no detailed rules for > confidentiality but > rather treat the word as having implicit-but-total effect on > behavior, b) we > have no enforcement powers over violations, and c) Nomcom > members, IAB members, > IESG members and ISOC members typically do not have any background in > maintaining confidentialities of these types. > > (On item c), if you think that there is no need for training > or experience, > please think again. Organization personnel matters are > peculiar processes.) > > The concept of Nomcom was a creative solution to the > challenge of making formal > community decisions in the absence of formal community > membership. That said, > the conduct of Nomcom processes tends towards pretty classic > personnel > assessment, but with people typically lacking classic > personnel training or > experience. Coupled with a lack of institutional > specification for the > construct or enforcement against "violations" and we are > certain to get > distorted processes. > > I've been taught that any good security structure begins by > limiting what needs > to be secure and who security is expected from. > > We ought to consider extremely carefully exactly what > confidentialities are > essential and exactly who needs to maintain them. > > By way of example, I'll raise a question about Harald's > proposal to make > nominations for Nomcom consideration public but not who > agrees to be considered. > In the current IETF and Nomcom reality, I've offered a +1 > for the proposal. > This note does not change my support of it. Rather, it's > helped me to reflect > on the larger issues. > > In terms of overall process effectiveness and > confidentiality, is the proposal > realistic? The idea behind the proposal's distinction is > that keeping the exact > set of interested nominees confidential will protect a > nominee from, for > example, concerns that a competing candidate who is already > holding the position > will find out. > > Does anyone seriously believe that someone sitting within > IETF management will > not know who is running against them? Please consider just > how tightly-knit the > IETF management community is. (And again, that's not a > complaint; it's a > reality, and I don't see that it can, or maybe even should, change.) > > In the face of sensitivities, it is convenient to seek to > avoid them. Invoking > "confidentiality" can be the convenient mechanism for this > convenient avoidance. > > But convenience is not the same as utility. > > Let me suggest that we at least discuss a model that begins > by allowing > everything to be open, and then imposes restrictions only > when there is > agreement on a compelling need for it, and that the > restriction be defined on > the smallest possible group of people. > > d/ > -- > > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > IETF mailing list > IETF@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf > _______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf