I believe this response (I hope inadvertently) appears to remove a valuable
principle by which the IESG acted on appeals.
I urge the IESG to reconsider the formulation of its response to the appeal
to clarify the issues raised below.
At 2:01 PM -0400 9/20/07, The IESG wrote:
>IESG Response to the Appeal Against the Removal of the Co-chairs of the
>GEOPRIV Working Group
>
>
>Introduction
>
> This is the IESG response to the appeal by Randall Gellens, Allison
> Mankin, and Andy Newton posted at:
>
> http://www.ietf.org/IESG/APPEALS/IESG_Appeal_20070622-final.pdf
>
> Cullen Jennings recused from all discussion of this appeal.
>
> The appeal raises three major points for the IESG to address:
>
> 1. The removal of the WG Chairs violates IETF process;
>
> 2. The actions taken interfered with the consensus process; and
>
> 3. There is a conflict of interest.
>
> The appeal also proposes a remedy. This response includes some
> comments about the proposed remedy.
>
>1. The removal of the WG Chairs violates IETF process
>
> RFC 2418 says:
>
> Working groups require considerable care and feeding. In addition
>to
> general participation, successful working groups benefit from the
> efforts of participants filling specific functional roles. The Area
>
> Director must agree to the specific people performing the WG Chair,
>
> and Working Group Consultant roles, and they serve at the
>discretion
> of the Area Director.
>
> Since all WG chairs "serve at the discretion of the Area Director,"
> they can be replaced at any time. The previous GEOPRIV WG co-chairs
> were told about their removal in private before the public
> announcement. This action was not required, but it is the most
> polite way to handle the situation. Perhaps the public announcement
> could have provided some rationale, but the authority to remove a WG
> chair is clear.
In this response, the IESG appears to have read the appeal to state that the
removal of the chairs was not within the authority of the Area Director.
The appeal statement:
http://www3.ietf.org/IESG/APPEALS/IESG_Appeal_20070622-final.pdf
does not support this reading. It does not say that Area Directors
do not have the right to remove chairs, it says that the manner
and timing by which this was done interfered with the consensus process
inappropriately. The remainder of the IESG statement below appears
to attempt to address the interference issue. But in choosing to highlight
that all "WG chairs serve at the discretion of the Area Director",
the IESG appears to be saying that the personnel decisions of
an Area Director or the IESG are not subject to appeal.
During the time I served on the IESG, it was a general guideline that
*any decision* of an Area Director or the IESG was subject to appeal
to the IESG. While this is a broad reading of RFC 2026, Section 6.5,
I think it is an important point and a principle worth retaining. The
appeals process in the IETF is not simply a mechanism for establishing
who has what rights; it is a mechanism for conflict resolution. By
making all decisions subject to it, we ensure that conflicts which arise
are dealt with as early as possible and with as little process as possible.
If members of the community believe that a personnel decision
was made in a way the interfered with the proper operation of the
IETF, I believe asking the IESG to attempt to resolve the conflict is
an appropriate thing to do. This appeal response, which re-asserts the
authority of the AD to make the original decision, does not seem
to support this use of the IETF's normal conflict resolution mechanism.
Further, this appeal response appears to say that the only conflict resolution
mechanism open to those who disagree with a personnel decision
is to invoke one of the removal mechanisms for those who made it.
I hope that the IESG will re-structure its response to this appeal
to re-affirm that the conflict resolution mechanisms of the IETF are
available for this purpose. I also encourage the IESG (and, frankly,
the IETF community as a whole) to try to see the appeals process
as a way of resolving conflict, rather than a quasi-legal process for
determining
whether a remedy will be granted. I understand how previous appeals
have pushed everyone in that direction, but it is something we must
continue to resist. I have worked with Allison, Andy, and Randy for
many years, as well as Cullen and Jon. They are all experienced
IETF folks who have toiled for years to make things work; forcing them
into even more adversarial positions when conflicts do need resolution
is a mistake, at least I see it.
My thanks for your attention,
regards,
Ted
>2. The actions taken interfered with the consensus process
>
> The appeal claims that a sequence of events, including the
> replacement of the GEOPRIV WG chairs, interfered with the consensus
> process. From the wording of the appeal, it is not clear which items
> in the sequence are offered as background. It is clear that removal
> of the GEOPRIV WG chairs is claimed to have interfered. Some of the
> events in the sequence occurred more than two months prior to the
> submission of the appeal, and it is recognized that these events are
> not subject to appeal. Each of the items in the sequence is
> addressed for completeness.
>
>2.1. Changing of GEOPRIV WG session time at IETF 68
>
> It appears that many events lead to the unfortunate rescheduling the
> GEOPRIV session at IETF 68. Andy's broken arm, schedule conflicts, a
> wedding, and airlines schedules impacted by bad weather on the East
> Coast of the United States were all contributing factors. As a
> result, only one of the GEOPRIV co-chairs (Randy) was at the IETF 68
> meeting in Prague. The RAI ADs were faced with a situation where
> either the SPEERMINT WG or the GEOPRIV WG was going to meet without
> any of their chairs present in the session. With little time to make
> a decision, the RAI ADs chose to adjust the schedule so that
> SPEERMINT, the younger of the two WGs, would have a session where a
> WG chair could attend.
>
> Due to the schedule change, Randy was no longer able to attend the
> session. The change created a conflict with LEMONADE, and Randy
> needed to be in the LEMONADE session. However, the GEOPRIV WG co-
> chairs had already selected Henning Schulzrinne (the author of RELO),
> to co-chair the session with Randy. The decision was made that Jon
> Peterson (one of the RAI ADs) would co-chair the session with
> Henning.
>
> Scheduling is a problem that faces all ADs. This was a choice of the
> lesser of two evils. In hindsight, it may not have been the best
> possible choice. However, a reasonable decision was made.
>
>2.2. Changing of the GEOPRIV WG session agenda at IETF 68
>
> Discussion of Layer 7 Location Configuration Protocol (L7-LCP) was
> planned, but it is not clear from the agenda that a decision between
> HELD and RELO was planned. As usual, the first agenda item was an
> agenda bash. There was an agenda change that moved the discussion of
> location signing to the end of the session, but this change is not
> relevant to the appeal.
>
> The original agenda is available at:
>
> http://www3.ietf.org/proceedings/07mar/agenda/geopriv.txt.
>
> The minutes summarize the agenda as:
>
> A. Agenda Bashing
> B. Document Status
> C. Future Directions
> D. L7-LCP Problem Statement & Requirements
> E. L7-LCP Protocol Selection
> F. Geo URI
>
> The agenda that was published prior to the meeting does not indicate
> that RELO would be discussed, and it does not include the "L7-LCP
> Protocol Selection" agenda item. A participant could easily have
> been surprised when these topics were added during agenda bashing.
>
> Review of the audio stream of the agenda basing portion of the
> GEOPRIV WG session at IETF 68 makes it clear that all of the
> participants were made aware of the push for a decision. No one
> spoke against this proposed change to the agenda, and no one hummed
> against the revised agenda when asked.
>
>2.3. Assessing the opinion at the GEOPRIV WG session at IETF 68
>
> Discussing the L7-LCP problem statement and HELD were clearly on the
> agenda that was posted prior to the meeting. It is clear that people
> following the GEOPRIV WG knew HELD and RELO were the two HTTP L7-LCP
> candidates. The appeal asserts that no decision should have been
> made at the WG session at IETF 68. However, it was made clear
> through hums, that the people in the room felt they needed to make a
> protocol selection. They clearly indicated that waiting for
> consensus on the requirements document was not needed.
>
> It was recognized that location signing was still a topic of active
> discussion. However, the still-under-discussion problem statement
> document no longer included location signing as a requirement. The
> GEOPRIV WG chose to remove it from the requirements between the -00
> and -01 drafts. Draft -02 was available prior to this WG session.
>
> The appeal takes issue with the participation of Cullen Jennings in
> the counting of hands. Ted Hardie and Cullen both helped the Acting
> GEOPRIV WG Session Chairs count hands. RELO and HELD each got 22
> hands. Yet, hums indicated that the people in the room wanted a
> decision. They were faced with a tie. To break the tie, Cullen cast
> a vote for RELO. Rohan Mahy stated during the session that Cullen
> had previously indicated no technical preference between RELO and
> HELD. However, Cullen did indicate that he believed that a decision
> had to be made. In hindsight, Cullen regrets casting a vote. In the
> end, Cullen's vote made no difference since votes from the Jabber
> room were used to break the tie. By totaling the hands in the room
> and the Jabber room votes, HELD was declared the winner.
>
> The appeal questions the integrity of the Jabber process. The belief
> is that most Jabber participants were listening to the real-time
> audio feed; therefore, they were not asked different questions.
> Rather, they were prompted to organize their responses. The Acting
> GEOPRIV WG Session Chairs were satisfied that a plurality of opinion
> had emerged, and no one has challenged their assessment of the
> outcome.
>
> The appeal raises questions regarding RFC 3929. However, RFC 3929
> was not employed. Ted Hardie, the author of RFC 3929, explained
> during the session how the process used was not compatible with RFC
> 3929. Ted spoke quite clearly about the process that was proposed
> for selecting the protocol, and based on review of the audio stream
> the people in the room were in agreement with using the proposed
> process.
>
>2.4. Interfering with the GEOPRIV WG chairs' processes after IETF 68
>
> It is clear that Cullen Jennings was pushing the GEOPRIV WG to make
> progress. Over the years, the GEOPRIV WG became a divisive group.
> Cullen was looking for closure on long-standing unresolved issues
> that were preventing the GEOPRIV WG from fulfilling their charter.
> Nearly every AD finds themselves in this situation at one time or
> another.
>
> On March 30, after the IETF 68 meeting in Prague, Cullen told the
> GEOPRIV WG co-chairs that he planned to relieve them of their
> positions. The appeal states that a reason given for this decision
> was that the chairs should "never have allowed the HELD proposal to
> remain viable." Cullen denies saying such a thing. He also said,
> "I'm not sure what I said that could have been misinterpreted as
> meaning this."
>
> (Note: The IESG has no way to determine what was actually said during
> this discussion between Cullen, Randy, Allison, and Andy.)
>
> Cullen did not dictate the choice of document editor to the new
> GEOPRIV WG chair. However, he readily admits that it was "obvious"
> to him that a good editor would be required. According to Cullen, he
> asked the previous GEOPRIV WG co-chairs if they had any suggestions.
> They had none. Therefore, they engaged in a discussion of the
> qualities to look for in an editor. Cullen suggested they consider
> Mary Barnes. In a previous conversation with Mary, Cullen had asked
> her if she would be willing to be editor if the chairs asked her to
> do so, and she had indicated that she probably had time to take on
> the job. Mary is not strongly connected to either of the proposals,
> is very organized, and is experienced at working as an editor on
> highly controversial proposals. Cullen reports that the previous
> GEOPRIV WG co-chairs seemed to think Mary sounded like a good choice.
> The current GEOPRIV WG chair ended up choosing Mary, and he believes
> that Mary is the best person for the job.
>
> After IETF 68, the previous GEOPRIV WG co-chairs began the process to
> confirm the direction that was set during the GEOPRIV WG session.
> They used a series of questions, giving mail list members a certain
> period of time to respond. The previous GEOPRIV WG co-chairs were
> replaced with the current GEOPRIV WG chair before this process was
> complete. However, the current GEOPRIV WG chair continued the
> process. At the end of the allotted time, the current GEOPRIV WG
> chair assessed the mail list traffic, and determined the consensus.
> No one, including the three appellants, has approached the current
> GEOPRIV WG chair to indicate disagreement with the recorded
> consensus. Any disagreement with this consensus call should begin
> with the current GEOPRIV WG Chair, and then work its way up the chain
> if satisfaction is not found. There is no evidence that the change
> of WG chairs during the consensus call had any impact on its outcome.
>
>3. There is a conflict of interest
>
> When dealing with conflict of interest, perception is just as
> important as reality.
>
> It seems that everyone agrees that the GEOPRIV WG has become divided
> into at least two camps on the HTTP L7-LCP issue. The appeal refers
> to "the Cisco camp," and claims that Cullen used his IETF leadership
> position to support that camp.
>
> The appeal suggests that Cisco favors a particular L7-LCP solution.
> From the GEOPRIV WG history it is clear that participants from Cisco
> have advocated lower layer LCP approaches (such as DHCP), and
> therefore it is quite difficult to understand how Cullen's effort to
> force a choice between HELD and RELO supports the inferred Cisco
> agenda. Since the core DHCP documents had long since been completed
> (RFC 3825 was published in July 2004), it is the opinion of the IESG
> that these actions by Cullen did not further any Cisco agenda and
> were instead targeted at timely completion of the GEOPRIV WG charter.
>
> The agenda that was posted prior to IETF 68 and the minutes reflect a
> time slot for Cullen Jennings to discuss "Future Directions." The
> appeal says that Cullen used this time to seek acceptance of a DHCP
> extension. This extension had not been previously discussed in the
> GEOPRIV WG and at the time had no associated Internet-Draft.
> However, review of the audio stream from the GEOPRIV WG session shows
> that very little time was spent discussing any aspect of DHCP. After
> the meeting, James Polk wrote an individual submission which the
> GEOPRIV WG may or may not adopt to fill the identified hole. This
> draft is not a subject of this appeal.
>
> The appeal states that the agenda slot was given to Cullen for
> validation of the current milestones. Milestones were certainly not
> the focus of any discussion during the GEOPRIV WG session. When
> asked about updates to GEOPRIV WG milestones, Cullen indicated that
> he was not prepared to address new milestones until outstanding
> critical work is complete. There seems to be a serious
> miscommunication on this point. The message referenced in the appeal
> is about updates to the milestones in the existing GEOPRIV WG
> charter. The previous GEOPRIV WG co-chairs were not proposing new
> work items. The proposed milestones can be found at:
>
> http://www.ietf.org/mail-archive/web/geopriv/current/msg02571.html
>
> The IESG believes that Cullen's actions are consistent with an AD
> that is pushing a divisive WG toward closure on chartered work. The
> IESG also believes that the GEOPRIV WG milestones are seriously out
> of date, and they should be updated promptly.
>
>4. Proposed Remedy
>
> The proposed remedy is not appropriate. Appeals are designed to
> allow the IETF to reconsider a decision and to correct a mistake.
> The remedy proposed in the appeal is to move the GEOPRIV WG from the
> RAI Area to another area. This recommendation does not correct any
> mistakes that may have been made, nor does it consider the technical
> needs of the GEOPRIV WG. Rather, it is an attempt to move the
> GEOPRIV WG to a place in the IETF organization where Cullen Jennings
> will have less influence.
>
> By the way, the question of transferring the GEOPRIV WG to the
> Applications Area has been discussed on at least one previous
> occasion. The proposal was discussed by the RAI and Applications
> ADs, and they decided that the GEOPRIV WG fits well in the RAI Area.
> They recognized that the GEOPRIV WG has implications for things other
> than SIP and that it makes use of protocols developed in the
> Applications Area. As a result of these discussions, Lisa Dusseault,
> one of the Applications ADs, agreed to be a technical advisor to the
> GEOPRIV WG.
>
> The IETF has at least two mechanisms to address concerns about
> recurring biased behavior of an AD. While such concerns might be
> offered as rationale in an appeal, an appeal is not the best
> mechanism for addressing long-standing AD behavior concerns. In the
> future, if anyone has such concerns, the IESG believes that these
> other mechanisms ought to be used to address them. The first and
> least disruptive mechanism is input to the Nominations Committee
> (NomCom) when the offending AD is being considered for a subsequent
> term. The second and much more radical mechanism is the recall
> process as described in RFC 3777.
>
>5. Conclusion
>
> For the reasons provided above, the appeal is denied.
>
> The IESG observes that the GEOPRIV WG milestones are out of date. We
> encourage the RAI ADs to work with the current GEOPRIV WG chair to
> update them.
>
>
>
>_______________________________________________
>Geopriv mailing list
>[EMAIL PROTECTED]
>https://www1.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
