Lakshminath, Let me be prefectly frank: if feedback were completely unverifiable as a result of rigid "confidentiality" requirements, there would be nothing to stop someone from making things up. Note that this is - absolutely - not the same thing as saying anyone in the IETF would actually take advantage of the opportunity. That would be similar to saying that - because we know a little about network protocols - we are all capable of being the worst sort of hackers. But there can be a lot of reasons why someone might take advantage of such an opportunity and - let's face it - at least part of the reason why people are inclined to verify what they hear is because there is that possibility. This may sound a little cynical, and maybe it is - but there are a few of us that feel that giving feedback based on poorly supported impressions is not a lot different from "making it up." -- Eric Gray Principal Engineer Ericsson > -----Original Message----- > From: Lakshminath Dondeti [mailto:ldondeti@xxxxxxxxxxxx] > Sent: Wednesday, March 19, 2008 6:17 PM > To: Eric Gray > Cc: Dave Crocker; IETF Discussion > Subject: Re: Nomcom process realities of "confidentiality" > Importance: High > > On 3/19/2008 11:12 AM, Eric Gray wrote: > > 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. > > Eric, > > May I assume you use the word "leaking" above in the context > of (d) and > (e) below and other similar contexts? Next, I wouldn't quite > say people > "make things up;" each person communicates their perceptions and the > nomcoms may then investigate how pervasive is the said feeling in the > community, if they don't already know from the feedback already > collected, balance all other view points and figure out what > is in the > best interests of the community. It is a subjective process > and that's > why we use humans to do it. > > thanks, > Lakshminath > > > > > 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 > > > _______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf