Network Working Group S. Dawkins, Ed.
Internet-Draft Huawei (USA)
Intended status: Informational D. McPherson
Expires: January 8, 2009 Arbor Networks
July 7, 2008
Nominating Committee Process: Issues since RFC 3777
draft-dawkins-nomcom-3777-issues-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 8, 2009.
Abstract
This document describes issues with the current IETF Nominating
Committee process that have arisen in practice.
Dawkins & McPherson Expires January 8, 2009 [Page 1]
Internet-Draft NomCom Issues July 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Background of this document . . . . . . . . . . . . . . . . . 3
3. Issues that Affect NomCom Participation . . . . . . . . . . . 4
3.1. Shortening the NomCom Epoch . . . . . . . . . . . . . . . 4
3.2. Random Selection of NomCom Membership . . . . . . . . . . 4
3.3. Gaming NomCom Participation . . . . . . . . . . . . . . . 4
3.4. Affiliation and Related Issues . . . . . . . . . . . . . . 5
4. Issues Affecting NomCom Operation . . . . . . . . . . . . . . 6
4.1. Model for Candidate Evaluation . . . . . . . . . . . . . . 6
4.2. One NomCom for All Positions . . . . . . . . . . . . . . . 6
5. Candidate Issues . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Candidates Who Are Not Selected . . . . . . . . . . . . . 7
5.2. Running Against an Incumbent . . . . . . . . . . . . . . . 7
5.3. Soliciting Feedback on Non-Incumbent Candidates . . . . . 8
5.4. Interaction between Affiliation and Willingness to be
Considered . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Confirming Body Issues . . . . . . . . . . . . . . . . . . . . 9
6.1. Role of the Confirming Body . . . . . . . . . . . . . . . 9
6.2. Confirming Body Liaisons . . . . . . . . . . . . . . . . . 10
6.3. What a Confirming Body Actually Confirms . . . . . . . . . 11
6.4. 2007-2008 Dispute Resolution Process Experience . . . . . 12
6.4.1. Selecting an Arbiter . . . . . . . . . . . . . . . . . 12
6.4.2. Scope of Dispute Resolution Process . . . . . . . . . 12
6.4.3. Constitutional Crisis . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
Dawkins & McPherson Expires January 8, 2009 [Page 2]
Internet-Draft NomCom Issues July 2008
1. Introduction
The Internet Engineering Steering Group (IESG), the Internet
Architecture Board (IAB), and at-large IETF representatives to the
IETF Administrative Oversight Committee (IAOC) are selected by a
"Nominating and Recall Committee" (universally abbreviated as
"NomCom"). [RFC3777] defines how the NomCom is selected, and the
processes it follows as it selects candidates for these positions.
This document describes issues with the current NomCom process that
have arisen in practice. It does not propose ways to resolve those
issues - that will potentially be the role of one or more follow-on
documents and/or IETF work items.
2. Background of this document
[RFC3777] is the latest in a series of revisions to the NomCom
process, which dates back to [RFC2027] in 1996. [RFC3777] has been
updated once since 2004, but this update ([RFC5078] did not change
normative text (it replaced a sample timeline, allowing more time for
required tasks and identifying a small number of tasks that are
performed every year but were not included in the sample timeline).
Although NomCom deliberations are held to a high level of
confidentiality, three recent NomCom chairs {Danny McPherson {2004-
2005}, Ralph Droms {2005-2006}, and Andrew Lange {2006-2007}) have
reported a variety of issues at IETF Plenaries. They reported
several issues (that arise across NomCom cycles), including
experience that NomComs seem to consistently "run out of time" at the
end of the process, a small number of candidates for at least some
positions, confusion with confirming bodies, and a tension between
confidentiality and an open request for feedback on candidates.
This document is a compilation of discussions among a number of
recent NomCom chairs (named in Section 9) who acted as a design team,
at the IETF Chair's request. In addition, we used Lakshminath
Dondeti's IETF 71 Plenary NomCom report, and subsequent on-list and
off-list discussions, as input, but Lakshminath was not included in
the design team because he was currently serving as NomCom chair.
This document is closer to being a union of views than a consensus of
views. Given that each NomCom operates behind a wall of
confidentiality, with the past NomCom chair as the only "common"
participant, it's difficult even for a group of former NomCom chairs
to agree on "what the problems common to all NomComs are".
Dawkins & McPherson Expires January 8, 2009 [Page 3]
Internet-Draft NomCom Issues July 2008
3. Issues that Affect NomCom Participation
3.1. Shortening the NomCom Epoch
We struggled with several aspects of the length of the NomCom cycle.
Using the schedule suggested in ([RFC5078], the 2008-2009 NomCom will
be budgeting for a 43-week NomCom cycle. There are several concerns
that go along with a very long NomCom cycle:
o We have a sense that a longer NomCom commitment reduces the number
of NomCom volunteers who are willing to serve.
o A longer NomCom cycle can also affect the continued willingness of
candidates to be considered - candidates are contacted immediately
to see if they are willing to serve, and then immediately before
their names are sent forward - and there can be a 5-6 month delay
between these events, so candidates may lose enthusiasm, or may
experience personal/professional changes that prevent them from
serving, between the two contact points.
o A smaller number of NomCom volunteers raises concerns about large
"IETF sponsors" "gaming" the system.
o In a small minority of cases - IAB or IESG members who are serving
in a one-year term - the NomCom cycle starts almost immedately
after the member is seated (52 weeks in a year - 43 weeks in a
NomCom cycle = 9 weeks of experience when the process begins).
3.2. Random Selection of NomCom Membership
NomCom membership is selected randomly from a set of qualified
volunteers. This means that NomCom members are probably not
personally familiar with all of the candidates, and may not be
familiar with the required skillset for specific positions. This has
implications for the amount of time needed for NomCom to collect
inputs from the community.
We also discussed concerns about the level of awareness of IETF
culture for a randomly-selected NomCom - since an IETF attendee can
become NomCom-eligible in one year.
3.3. Gaming NomCom Participation
We have a sense that there are a small number of large sponsors for
IETF participants who provide a disproportionate number of NomCom
volunteers.
The issue isn't that a single sponsor can "pack" a NomCom - current
[RFC3777] rules limit that effect - but that large sponsors can be
almost assured of at least one participant being selected for NomCom,
year after year. We note that for several years, 50-60 percent of
Dawkins & McPherson Expires January 8, 2009 [Page 4]
Internet-Draft NomCom Issues July 2008
NomCom participants have come from four large sponsors. We aren't
saying this is a problem, only that it's a trend worth noticing.
3.4. Affiliation and Related Issues
As described in [RFC3777], the term "primary affiliation" is used in
the following ways:
o A nomcom volunteer's "primary affiliation" is used in determining
whether a volunteer is eligible for membership on the nominating
committee (Section 4, point 17)
o Within the recall process, a signatory's primary affiliation is
used to determine whether a signature on a recall petition is
valid (Section 7).
Despite the importance of "primary affiliation" in determining
eligibility for the nominating committee and the validity of a
signature on a recall petition, the term is never defined within RFC
3777.
While a potential nominating committee member or signatory with a
single employer may not have difficulty in determining their "primary
affiliation", the "primary affiliation" of an individual with
multiple consulting clients or part-time employers may be less clear.
Such ambiguities can make it difficult to determine whether the RFC
3777 requirements for nominating committee balance are being
followed, and may even affect the ability of the nomcom to accurately
assess the "primary affiliation" of the candidates for the positions
that the nomcom is attempting to fill.
For its definition of "affiliation", IEEE has come up with the
following:
"An individual is deemed 'affiliated' with any individual or
entity that has been, or will be, financially or materially
supporting that individual's participation in a particular IEEE
standards activity. This includes, but is not limited to, his or
her employer and any individual or entity that has or will have,
either directly or indirectly, requested, paid for, or otherwise
sponsored his or her participation."
It should not noted that the above definition focuses on support for
a particular activity, and therefore it is possible for a participant
to have different "affiliations" while developing a standards
submission, participating in an chair position, or serving on one or
more committees.
There are plenty of corner cases here - "do a UCLA professor and UC-
Dawkins & McPherson Expires January 8, 2009 [Page 5]
Internet-Draft NomCom Issues July 2008
Irvine grad student have the same affiliation?" - so what's needed is
guidance, judgement, and flexibility.
4. Issues Affecting NomCom Operation
4.1. Model for Candidate Evaluation
We discussed two models - a Personal Experience (PE) model, and a
Consultive (C) model.
Under the PE model, a NomCom member would use personal experience to
determine positions on candidates where the NomCom member has enough
background to support those positions, and would rely on candidate
feedback only for the positions where the NomCom member cannot
support a position based on personal experience.
Under the C model, a NomCom member would base candidate positions
almost exclusively on candidate feedback for all positions under
consideration.
We recognized that there's a tension in both directions - "personal
experience" can become "personal bias", while "consultive" can become
a popularity contest.
One former chair pointed out that the NomCom moved pretty quickly
from a model where a random sample of the community selects
leadership based on personal experience to a model where the random
sample of the IETF is expected to survey a large and increasing
percentage of the total community in order to select leadership. If
we expect NomCom to act as a PE group, the process would be less
intrusive to the rest of the community and would require less time
for NomCom deliberations.
We also noted that since NomCom voting members are unlikely to have
personal experience with all candidates in all areas, there's a
tendency for NomCom voting members to rely on other NomCom members
when considering an unfamiliar candidates in an unfamiliar area.
4.2. One NomCom for All Positions
We discussed whether having a single group of randomly-selected IETF
attendees working to fill all positions under consideration was the
right model. For example, one former NomCom chair noted that the
IAB's responsibilities have changed dramatically since the NomCom
structure was put in place, and a considerable amount of IAB time has
been spent on administrative restructuring, hearing appeals, and
representing the IETF in liaisons with other SDOs. Is the NomCom the
Dawkins & McPherson Expires January 8, 2009 [Page 6]
Internet-Draft NomCom Issues July 2008
best way way to choose people with the required skillset to carry out
these tasks?
5. Candidate Issues
We had some discussions about a relatively shallow candidate pool for
some positions. We noted that it's not unusual for recent NomComs to
reopen specific positions for late nominations (an indicator that the
first round didn't generate enough candidates who were both qualified
and willing to serve) - this happened in both 2005-2006 and in 2006-
2007.
5.1. Candidates Who Are Not Selected
We noted that candidates must obtain confirmation of support from
employers for a multi-year commitment, including commitments to fund
travel for IETF meetings and workshops. There are IETF participants
who are willing to obtain these commitments every year, but other
participants are not willing to be considered every year when they
must obtain high-level approval to be considered, and then must
notify the same high approval levels that they weren't selected -
especially if business plans were adjusted to accommodate the
candidate serving and must now be adjusted again to accommodate the
candidate not serving.
Even if a candidate is willing to be considered every year, the
current NomCom cycle length requires serious candidates to "put their
lives on hold" for up to six months between first being approached/
volunteering and ultimately being selected. Being in limbo for this
period of time may be a negative factor with respect to possible job
actions, especially new employment and promotions.
Potential candidates may be unwilling to be considered for leadership
positions, or may simply be unwilling to be considered during a
specific NomCom cycle (given a choice between standing for a position
against an incumbent finishing a first term and an incumbent
finishing a third or fourth term, a candidate may "lay out" for a
year to be considered against the long-time incumbent).
5.2. Running Against an Incumbent
For a variety of reasons, mostly good reasons, a NomCom may be
influenced by a candidate being an incumbent.
Rules we've heard discussed by various NomComs include:
Dawkins & McPherson Expires January 8, 2009 [Page 7]
Internet-Draft NomCom Issues July 2008
o always return a first term incumbent unless there is a problem
(assume the first term was training),
o always return an incumbent unless there is a problem (keep good
incumbents until they are no longer willing or able to serve, or
until they are no longer good incumbents),
o apply term limits in some form, and
o "shoot them all" (never actually done to our knowledge, but
expressed in NomCom discussions)
Given the confidentiality requirements of [RFC3777], potential
candidates do not know what the informal rules a NomCom may choose to
follow. [RFC3777] encourages candidates to be considered, anyway,
but candidates may choose to "be conservative in when you are
considered", and may decline to be considered even if the NomCom
would like to replace an incumbent.
Recent experience seems to show that a higher number of candidates
emerge when incombents publicly state they are unavailable to return
for another term than when incumbents publicly state that they are
available to return for another term, although this is only an
impression.
Note that this effect exists today, before any proposed changes to
NomCom confidentiality rules are considered. We expect that the
effect would be more pronounced if candidate lists are made public
(more about this in Section 5.3).
When potential candidates refuse to be considered, this complicates
life for a NomCom evaluating an incumbent who is willing to serve
again, but really needs to be replaced.
We see no way for a NomCom to signal that a slot is "REALLY open"
under the current rules of engagement.
We note that spending effort on NomCom questionnaires when a NomCom
is ready to reappoint an incumbent wastes valuable IETF participant
time, and this is doubly wasteful when a NomCom requests input on a
"ringer" who was not under consideration, and was only added to the
list to obscure which candidates WERE under consideration.
5.3. Soliciting Feedback on Non-Incumbent Candidates
NomCom announces the slots being considered in each NomCom cycle, so
incumbents being considered are known publicly, but other candidates
are not made public. This complicates the decision to provide input
to NomCom, because community members may provide information about a
"candidate" who isn't being considered, or who isn't willing to serve
- or, equally likely, they may simply choose not to provide input
Dawkins & McPherson Expires January 8, 2009 [Page 8]
Internet-Draft NomCom Issues July 2008
about non-incumbent candidates without being solicited to do so.
There isn't any formal guidance to NomComs about how to solicit
input, so each NomCom tends to use a modified version of what the
previous NomCom used to solicit input. Current NomCom practice is to
request feedback on lists of candidates from a large "private"
population - existing working group chairs, RFC authors in an area,
current document authors in an area, and the entire IESG and/or IAB
likely to see candidate lists which, although the lists contain
"ringers", necessarily expose the names of all candidates for a
position to a large and relevant portion of the IETF community.
Even with solicitation of feedback on large "private" distributions,
non-incumbents are at a disadvantage because the NomCom announcement
names the incumbents, but does not name the non-incumbents - who may
be tempted to do something that starts to look like campaigning, to
make sure that people who honestly believe they would be the best
candidate do provide input.
5.4. Interaction between Affiliation and Willingness to be Considered
We noted that there are unwritten rules about affiliation that affect
a candidate's willingness to be considered. For example, apparent
NomCom practice is that two area directors in the same area should
not have the same affiliation. If an area director is from company
X, possible candidates from company X may be less willing to be
considered for the second area director slot, assuming they will be
summarily rejected because of this affiliation.
Potential candidates for IAB slots may have similar concerns, and may
not be willing to be considered, if there are already two IAB members
with the same affiliation serving.
6. Confirming Body Issues
6.1. Role of the Confirming Body
In an e-mail on 2008/03/17, the IETF Chair asked the design team "to
propose a definition for the role of the confirming body. The
discussion in plenary indicates that this is a place where RFC 3777
is lacking. In part, this discussion has already taken place on the
IETF mail list, with members of the design team taking radically
different views. Please review the archives of the nomcom WG when
they are available."
We gave that our best shot.
Dawkins & McPherson Expires January 8, 2009 [Page 9]
Internet-Draft NomCom Issues July 2008
We recognized a tension between a confirming body that is expected to
"rubber-stamp" a candidate slate, and a confirming body that expects
to "re-run the NomCom process" - ("show us the information the NomCom
used to select this candidate slate, and we'll see if you picked the
right candidates"). Conversations at IETF 71 frequently used these
terms. We don't think either extreme is desirable. In subsequent
discussions we noted that there is a middle ground - a confirming
body would use information forwarded by the NomCom as part of its
"sanity check" diligence.
We haven't agreed on a proposed definition of the role of the
confirming body (yet). This is where the editor thinks we are, as of
00 I-D submission cutoff for IETF 72 (and the editor apologizes in
advance if he has been unable to capture the group's consensus on
what we didn't have consensus about)...
o The role of the confirming body is the acceptance or rejection of
proposed candidates.
o The confirming body should confirm candidates it believes are
qualified for the nominated position AND whose selection would not
be disruptive to the IETF process by whatever measure the
confirming body chooses to use. Conversely, the confirming body
should reject candidates who do not meet these conditions.
o Although [RFC3777] states that confirming body deliberations are
under the same requirements for confidentiality as the NomCom
itself, recent experience shows that NomComs and confirming bodies
can, and do, disagree on how much information the NomCom should
share with confirming bodies.
o Although [RFC3777] assigns process guardianship roles to
confirming body liaisons (as well as to the past NomCom chair),
the confirming body itself must rely on confirming body liaisons
for its view into the NomCom, and the liaisons are often reluctant
to share information with the rest of the confirming body, citing
confidentiality concerns.
6.2. Confirming Body Liaisons
Two sets of concerns were expressed about liaisons:
1. Concerns relating to affiliation and diversity imbalances created
by liaisons;
2. Concerns relating to undue influence of liaisons on the nomcom
process.
Since [RFC3777] places no restrictions on the "primary affiliation"
of liaisons, it is possible for more than two NomCom members to share
the same primary affiliation. One example is the 2006-2007 NomCom,
where two voting members, the past NomCom chair, the ISOC Liaison and
Dawkins & McPherson Expires January 8, 2009 [Page 10]
Internet-Draft NomCom Issues July 2008
the IESG liaison all shared a single primary affiliation.
In addition to affiliation imbalances, there is the issue of
diversity in liaison participation. While IESG and IAB liaisons
cannot serve in successive years (since IESG and IAB terms are two
years and a candidate whose position is being considered is not
eligible to serve as a liaison), no such restriction exists for other
liaisons and it has become common for other liaisons to return in
successive years.
While liaisons are non-voting, concerns were raised about the
influence that liaisons may have on NomCom voting members. Some
confirming bodies have explicitly instructed liaisons not to provide
any information unless the NomCom asks for the information directly,
and some NomCom chairs have set similar rules for liaisons. However,
there is a tension between being told "say nothing unless you are
asked directly", and participating in conference calls unable to say
anything when incorrect or incomplete factual statements are made.
We discussed how best to limit liaison participation in NomCom.
Currently, an important role of the liaisons is to monitor the nomcom
process and raise potential concerns about process violations.
However, currently [RFC3777] does not provide guidance on what a
liaison should do in the situation where a process violation occurs,
and it is not clear that this responsibility primarily resides with
the liaisons or with the past nomcom chair. If the primarily
responsibility for process monitoring is assumed to reside with the
past nomcom chair, then the role of the liaisons may be reduced or
eliminated, or the role may be restricted to those activities
required to supplement the past nomcom chair's responsibilities.
6.3. What a Confirming Body Actually Confirms
The 2006-2007 NomCom encountered a situation where they moved one
Area Director to IETF Chair and reopened nominations for the vacated
position - at this point, they had a complete slate, except for the
vacant slot, but IAB wasn't sure they could confirm a slate with one
vacancy or not.
Two considerations apply here.
1. Moving an incument, especially to IETF Chair, is "worst-case" -
it would be helpful to know that the incumbent will be seated in
the new position, before declaring the old position open.
2. Confirming bodies don't just consider each candidate in isolation
- there is also a sense that the confirming body ought to look at
the proposed slate, together with incumbents whose positions were
not considered during this NomCom cycle, as a group, to ensure
Dawkins & McPherson Expires January 8, 2009 [Page 11]
Internet-Draft NomCom Issues July 2008
that the group will work well together.
While it would simplify the confirmation process if confirming bodies
were willing to confirm partial slates or complete slates with
problematic candidates and "fill in" the remaining slots later, the
design team members were aware of several cases where the confirming
bodies identified concerns about two candidates serving together. In
some cases, both candidates were asked if this was really a concern
("can you let bygones be bygones?"). In other cases, the NomCom
provided a slate with a different candidate, to address the
confirming body's concern.
6.4. 2007-2008 Dispute Resolution Process Experience
The 2007-2008 NomCom exercised a new code path - for the first time,
a NomCom chair invoked the RFC 3777 dispute resolution process. This
means that a third-party arbiter is selected to investigate and
resolve the issue under dispute.
6.4.1. Selecting an Arbiter
The arbiter is selected by the ISOC President - but the ISOC
President has no way to know whether a proposed arbiter is also a
current "willing candidate" being considered by the same NomCom
committee.
6.4.2. Scope of Dispute Resolution Process
[RFC3777] names four cases where the dispute resolution process
should be invoked. None of the cases cover disputes between the
NomCom and a confirming body.
6.4.3. Constitutional Crisis
It is possible for either the Nomcom or a CB to wedge the process in
a way where it cannot proceed. The Nomcom can refuse to select a
candidate. A CB can refuse to either confirm or reject a proposed
candidate. It's unlikely that it would make sense to provide an
arbiter the powers to override either of these decisions.
Ultimately, we're dependent on the good will of both the Nomcom and
CB in the completion of the nominations process, and such good will
should be encouraged. The maxim is that "good fences make good
neighbors" - in this case, a better delineation of expectations
between the Nomcom and the CB is probably the best defense against a
future "Constitutional Crisis".
Dawkins & McPherson Expires January 8, 2009 [Page 12]
Internet-Draft NomCom Issues July 2008
7. Security Considerations
This specification describes issues with the current IETF Nominating
Committee process ([RFC3777]). No security considerations apply
beyond those discussions regarding confidentiality of NomCom
deliberations.
8. IANA Considerations
No IANA actions are requested in this specification.
9. Contributing Authors
o 2006-2007 Andrew Lange
o 2005-2006 Ralph Droms
o 2004-2005 Danny McPherson
o 2003-2004 Richard Draves
o 2002-2003 Phil Roberts
o 2001-2002 Theodore Ts'o
o 2000-2001 Bernard Aboba
o 1999-2000 Avri Doria
o 1998-1999 Donald Eastlake 3rd
o 1997-1998 Michael St. Johns
o 1996-1997 Geoff Huston
o 1993-1994 Fred Baker
10. References
10.1. Normative References
[RFC3777] Galvin, J., "IAB and IESG Selection, Confirmation, and
Recall Process: Operation of the Nominating and Recall
Committees", BCP 10, RFC 3777, June 2004.
10.2. Informative References
[RFC2027] Galvin, J., "IAB and IESG Selection, Confirmation, and
Recall Process: Operation of the Nominating and Recall
Committees", BCP 10, RFC 2027, October 1996.
[RFC5078] Dawkins, S., "IAB and IESG Selection, Confirmation, and
Recall Process: Revision of the Nominating and Recall
Committees Timeline", RFC 5078, October 2007.
Dawkins & McPherson Expires January 8, 2009 [Page 13]
Internet-Draft NomCom Issues July 2008
Authors' Addresses
Spencer Dawkins (editor)
Huawei Technologies (USA)
Phone: +1 214 755 3870
Email: spencer@wonderhamster.org
Danny McPherson
Arbor Networks, Inc.
Email: danny@arbor.net
Dawkins & McPherson Expires January 8, 2009 [Page 14]
Internet-Draft NomCom Issues July 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Dawkins & McPherson Expires January 8, 2009 [Page 15]