<pre>Network Working Group                                          T. Hardie
Request for Comments: 3929                                Qualcomm, Inc.
Category: Experimental                                      October 2004


                 <span class="h1">Alternative Decision Making Processes</span>
              <span class="h1">for Consensus-Blocked Decisions in the IETF</span>

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2004).

Abstract

   This document proposes an experimental set of alternative decision-
   making processes for use in IETF working groups.  There are a small
   number of cases in IETF working groups in which the group has come to
   consensus that a particular decision must be made but cannot agree on
   the decision itself.  This document describes alternative mechanisms
   for reaching a decision in those cases.  This is not meant to provide
   an exhaustive list, but to provide a known set of tools that can be
   used when needed.

<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>

   Dave Clark's much-quoted credo for the IETF describes "rough
   consensus and running code" as the key criteria for decision making
   in the IETF.  Aside from a pleasing alliteration, these two
   touchstones provide a concise summary of the ideals that guide the
   IETF's decision making.  The first implies an open process in which
   any technical opinion will be heard and any participant's concerns
   addressed; the second implies a recognition that any decision must be
   grounded in solid engineering and the known characteristics of the
   network and its uses.  The aim of the IETF is to make the best
   possible engineering choices and protocol standards for the Internet
   as a whole, and these two principles guide it in making its choices
   and standards.

   In a small number of cases, working groups within the IETF cannot
   reach consensus on a technical decision that must be made in order to
   ensure that an interoperable mechanism or set of standards is



<span class="grey">Hardie                        Experimental                      [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc3929">RFC 3929</a>        Consensus-Blocked Decisions in the IETF     October 2004</span>


   available in some sphere.  In most of these cases, there are two or
   more competing proposals at approximately the same level of technical
   maturity, deployment, and specification.  In some cases, working
   groups can achieve consensus to advance multiple proposals and either
   to revisit the question with experience or to build the required
   mechanisms to handle multiple options for the life of the protocol.
   In other cases, however, a working group decides that it must advance
   a single proposal.

   Choosing among proposals can be difficult especially when each is
   optimized for slightly different use cases, as this implies that the
   working group's best choice depends on the participants' views of
   likely future use.  Further problems arise when different proposals
   assign costs in implementation, deployment, or use to different
   groups, as it is a normal human reaction to seek to prevent one's own
   ox from being gored.

   This document proposes a set of experimental mechanisms for use in
   such cases.  To gauge the results of the use of these mechanisms, the
   Last Call issued to the IETF community should note such a mechanism
   is being used and which proposal among the set was chosen.  If and
   when the community becomes satisfied that one or more of these
   methods is useful, it should be documented in a BCP.

   In no way should this experiment or any future BCP for this small
   number of cases take precedence over the IETF's normal mode of
   operation.

<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  Rough Consensus as a baseline approach</span>

   The Conflict Research Consortium at the University of Colorado
   outlines the pros and cons of consensus as follows:

      The advantage of consensus processes is that the resulting
      decision is one that meets the interests of all the parties and
      that everyone can support.  The disadvantage is that developing
      such a decision can be a very slow process, involving many people
      over a long period of time.  There is also a relatively high
      probability of failure.  If a quick decision is needed, the
      consensus approach may not work.  Consensus rule processes also
      tend to favor those that oppose change and want to preserve the
      status quo.  All these people have to do is refuse to support any
      consensus compromises and they will win (at least as long as they
      can delay change) [<a href="#ref-CONFLICT" title="&quot;Consensus Rule Processes&quot;">CONFLICT</a>].







<span class="grey">Hardie                        Experimental                      [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc3929">RFC 3929</a>        Consensus-Blocked Decisions in the IETF     October 2004</span>


   Using "rough consensus" as a guideline limits some of the
   disadvantages of consensus processes by ensuring that individuals or
   small factions cannot easily block a decision that otherwise has
   general support.  The touchstone of "running code" can also limit the
   disadvantages of consensus processes by requiring that statements
   opposing particular proposals be technically grounded.

   These limitations do not change the core mechanisms of consensus-
   building, however, and the IETF process continues to require
   individual participants both to use their best engineering judgment
   to select among proposals and to balance their own interests with
   those of the Internet as a whole.  Active participation and a
   willingness to compromise, possibly on key points, are needed.
   Historically, this has worked because a large majority of
   participants have recognized that the Internet's growth and
   enhancement are more important overall than any specific short-term
   advantage.

   In other words, "rough consensus" is sufficient in most cases in the
   IETF to ensure not only that individuals or small groups are heard
   when they raise technical objections, but also that they cannot block
   progress when general agreement has been reached.  This document does
   not suggest changing the usual mechanisms for achieving progress; it
   proposes mechanisms for use when a working group has consensus that
   it must make a decision but cannot make that decision by the usual
   rules.

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  Conditions for use</span>

   In general, working groups should consider using alternate decision-
   making processes when it is clear both that a choice must be made and
   that the choice cannot be made with continued discussion, refinement
   of specifications, and implementation experience.  A guideline for
   determining whether these conditions have been met is included below.

<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>.  There is a clear decision to be reached</span>

   There must be a clear statement of the decision to be reached.  This
   may be in the working group's charter, in requirements documents, or
   in other documents developed by the working group.  Prior to any
   invocation of an alternate decision making process, the Chair(s)
   should confirm with the working group that there is general agreement
   on the decision to be reached.  This should include a specific
   consensus call on whether the working group can advance multiple
   proposals or must select a single proposal for the work item.






<span class="grey">Hardie                        Experimental                      [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc3929">RFC 3929</a>        Consensus-Blocked Decisions in the IETF     October 2004</span>


<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>.  Proposals are available in Draft form</span>

   Proposed solutions must be available as Internet-Drafts and must be
   sufficiently specified so that the Chair(s) believe they could be
   published as an IETF specification, possibly with further refinement.
   If the Chair indicates that a proposed solution is insufficiently
   specified, concrete problems must be identified, and a reasonable
   amount of time provided to resolve those problems must be provided.
   Note that if one of the proposed solutions is "do nothing", an
   explicit Draft to that effect must be available; it may, however, be
   produced when the group invokes an alternate decision-making process.

<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>.  The working group has discussed the issue without reaching</span>
<span class="h3">      resolution</span>

   Consensus-building requires significant amounts of discussion, and
   there is no general rule for indicating how much discussion a
   technical issue requires before a group should reach consensus.  If
   there is any question about whether the discussion has been
   sufficient, the working group chair(s) should always err on the side
   of allowing discussion to continue.  Before using an alternate
   decision making process, the working group chair(s) should also make
   an explicit call for consensus, summarizing the technical issues and
   the choice to be made.  If new technical points are made during the
   call for consensus, discussion should continue.  If no new points are
   raised, but the group cannot come to consensus, the working group may
   consider using an alternate decision making process.  Under no
   circumstances is the working group required to use an alternate
   decision-making process.

<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>.  There is an explicit working group last call to use an alternate</span>
<span class="h3">      method</span>

   In item 3.3 above, it is noted that the Chair(s) should make an
   explicit call for consensus on the technical issues and should
   proceed only after that call has yielded no forward progress.  A
   different Last Call on whether to use an alternate decision-making
   method is required, with a stated period for comments by working
   group members.  This is to indicate that the decision to use an
   alternate method should be taken at least as seriously as the
   decision to advance a document on the standards track.  It also
   provides a clear signal that this is a last moment for participants
   to reconsider their positions.  The decision to use an alternate
   decision making process requires the rough consensus of the working
   group, as determined by the Chair(s).  The choice of which process to
   use may be made in the Last Call or may be the subject of separate
   discussions within the working group.  If the group comes to




<span class="grey">Hardie                        Experimental                      [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc3929">RFC 3929</a>        Consensus-Blocked Decisions in the IETF     October 2004</span>


   consensus that an alternative method is required but does not come to
   consensus on the method to use, an external review team (c.f. <a href="#section-4.1">section</a>
   <a href="#section-4.1">4.1</a>, below) will be formed.

   In discussions regarding this document, several points have been
   raised about the viability of any mechanism that requires consensus
   to use an alternative to consensus-based decision making.  Some
   individuals have pointed out that groups having trouble achieving
   consensus on a technical matter may have similar problems achieving
   consensus on a procedural matter.  Others have been concerned that
   this will be used as an attempt to end-run around rough consensus.
   These are valid concerns, and they point both to the need to retain
   rough consensus as the baseline mechanism and the need to exercise
   caution when using these alternate methods.  More importantly though,
   they highlight the nature  of these alternatives.  They are primarily
   mechanisms that allow people to recognize the need for compromise in
   a new way, by backing away from entrenched technical positions and by
   putting the technical choice in the hands of the broader community.
   They highlight that the choice for each participant is now between
   achieving a result and failure.

   There is a fundamental tension between the IETF community's desire to
   get the best decision for a particular technical problem and its
   desire to get a decision that has community buy-in in the form of
   rough consensus.  These mechanisms cannot resolve that fundamental
   tension.  They may, however, provide a way forward in some situations
   that might otherwise end in a deadlock or stagnation.


<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  Alternate Methods</span>

   In setting up an alternate method, care must be taken that the
   process by which the decision is reached remains open and focused on
   the best technical choice for the Internet as a whole.  The steps set
   out below provide a straw proposal for four such mechanisms.  These
   systems are relatively heavyweight, partially to highlight the
   gravity of invoking these methods and partially to ensure that the
   IETF community as a whole is alerted to and kept informed of the
   process.  Note that alternate procedures have been used in the past;
   see [<a href="./rfc3127" title="&quot;Authentication, Authorization, and Accounting: Protocol Evaluation&quot;">RFC3127</a>] for a description of that used in the decision between
   two competing candidate protocols for Authentication, Authorization,
   and Accounting.  By setting out these proposals, this document does
   not intend to limit working group choice but intends to provide a set
   of well-defined processes that obviate the need for reinvention in
   most cases.






<span class="grey">Hardie                        Experimental                      [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc3929">RFC 3929</a>        Consensus-Blocked Decisions in the IETF     October 2004</span>


<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>.  Alternate Method One: External Review Team Formation</span>

   The working group notifies the IETF community that it intends to form
   an external review team by making a public announcement on the IETF-
   announce mailing list.  That announcement should include a summary of
   the issue to be decided and a list of the Internet-Drafts containing
   the alternate proposals.  It should also include the name and
   location of an archived mailing list for the external review team's
   deliberations.

<span class="h4"><a class="selflink" id="section-4.1.1" href="#section-4.1.1">4.1.1</a>.  External Review Team Membership</span>

   External review teams have five members who must meet the same
   eligibility requirements as those set out for a voting member of the
   NomCom [<a href="./rfc3777" title="&quot;IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees&quot;">RFC3777</a>].  Explicitly excluded from participation in external
   review teams are all those who have contributed to the relevant
   working group mailing list within the previous twelve months, the
   IESG, the IAB, and the members of an active NomCom.

   Volunteers to serve on the review team send their names to the IETF
   executive director.  Should more than five volunteer, five are
   selected according to the process outlined in [<a href="./rfc3797" title="&quot;Publicly Verifiable Nomination Committee (NomCom) Random Selection&quot;">RFC3797</a>].  Note that
   the same rules on affiliation apply here as to the NomCom, to reduce
   the burden on any one organization and to remove any implication of
   "packing" the review team.

   Participants in the working group may actively solicit others to
   volunteer to serve on the review team but, as noted above, they may
   not serve themselves if they have commented on the list within the
   previous twelve months.

<span class="h4"><a class="selflink" id="section-4.1.2" href="#section-4.1.2">4.1.2</a>.  External Review Team Deliberation</span>

   The external review team is alloted one month for deliberations.  Any
   member of the team may extend this allotment by two weeks by
   notifying the relevant working group Chair(s) that the extension will
   be required.

   The team commits to reading the summary provided during the IETF
   announcement and all of the relevant Internet-Drafts.  Members may
   also read the archived mailing list of the working group and may
   solicit clarifications from the document authors, the working group
   chairs, or any other technical experts they choose.  All such
   solicitations and all deliberations among the review team of the
   proposals should take place on the archived mailing list mentioned in
   the IETF announcement.  The team members may, of course, have one-
   on-one discussions with relevant individuals by phone, email, or in
   person, but group deliberations should be on the archived list.



<span class="grey">Hardie                        Experimental                      [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc3929">RFC 3929</a>        Consensus-Blocked Decisions in the IETF     October 2004</span>


<span class="h4"><a class="selflink" id="section-4.1.3" href="#section-4.1.3">4.1.3</a>.  Decision Statements</span>

   Each member of the external review team writes a short decision
   statement, limited to one page.  That decision statement contains a
   list of the proposals in preference order.  It may also contain a
   summary of the review team member's analysis of the problem and
   proposed solutions, but this is not required.  These decision
   statements are sent to the archived mailing list, the relevant
   working group chair(s), and the IESG.

<span class="h4"><a class="selflink" id="section-4.1.4" href="#section-4.1.4">4.1.4</a>.  Decision Statement Processing</span>

   The decision statements will be tallied according to "instant-runoff
   voting" rules, also known as "preference voting" rules [<a href="#ref-VOTE" title="&quot;Frequently Asked Questions about IRV&quot;">VOTE</a>].

<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>.  Alternate Method Two: Mixed Review Team</span>

   This mechanism allows the working group to designate a review team
   that involves those outside the working group and those who have been
   involved in the process within the working group.  Although it may
   appear that having a single representative of each proposal will have
   a null effect on the outcome, this is unlikely, except when there is
   a binary choice, because of the rules for decision-statement
   processing (c.f. 4.1.4.).  As in 4.1, the working group notifies the
   IETF community that it intends to form a mixed review team by making
   a public announcement on the IETF-announce mailing list.  That
   announcement should include a summary of the issue to be decided and
   a list of the Internet-Drafts containing the alternate proposals.  It
   should also include the name and location of an archived mailing list
   for the external review team's deliberations.

<span class="h4"><a class="selflink" id="section-4.2.1" href="#section-4.2.1">4.2.1</a>.  Mixed Review Team Membership</span>

   Mixed review teams are composed of one designated representative of
   each of the proposals, typically the Internet-Draft's principal
   author, and six external members.  Five of the external members are
   selected per 4.1.1. above.  The sixth is designated by the IESG as a
   chair of the group.  Though the primary role of the chair is to
   ensure that the process is followed, she or he may vote and engage in
   the deliberations.

<span class="h4"><a class="selflink" id="section-4.2.2" href="#section-4.2.2">4.2.2</a>.  Mixed Review Team Deliberation</span>

   The review team is alloted one month for its deliberations, and any
   member of the team may extend that allotment by two weeks by
   notifying the review team Chair this the extension will be required.





<span class="grey">Hardie                        Experimental                      [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc3929">RFC 3929</a>        Consensus-Blocked Decisions in the IETF     October 2004</span>


   The review team commits to reading the summary provided during the
   IETF announcement and all of the relevant Internet-Drafts.  Members
   may also read the archived mailing list of the working group, and of
   any other technical experts as they see fit.  All such solicitations
   and all deliberations among the review team of the proposals should
   take place on the archived mailing list mentioned in the IETF
   announcement.

<span class="h4"><a class="selflink" id="section-4.2.3" href="#section-4.2.3">4.2.3</a>.  Decision Statements</span>

   As in 4.1.3, above.

<span class="h4"><a class="selflink" id="section-4.2.4" href="#section-4.2.4">4.2.4</a>.  Decision Statement Processing</span>

   As in 4.1.4, above.

<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>.  Alternate Method Three: Qualified Short-Straw Selection</span>

   As in 4.1 and 4.2, the working group notifies the IETF community that
   it plans to use an alternate decision mechanism by making a public
   announcement on the IETF-announce mailing list.  That announcement
   should include a summary of the issue to be decided and a list of the
   Internet-Drafts containing the alternate proposals.

   In this method, a single working group participant is selected to
   make the decision.  Any individual who has contributed to the working
   group in the twelve months prior to the working group Last Call on
   the technical question (c.f. 3.3, above) may volunteer to serve as
   the decision maker.  Individuals may qualify as participants by
   having made a public statement on the working group mailing list, by
   serving as an author for an Internet-Draft under consideration by the
   working group, or by making a minuted comment in a public meeting of
   the working group.  The Chair(s) may not volunteer. Each qualified
   volunteer sends her or his name to the working group chair and the
   IETF Executive Director within three weeks of the announcement sent
   to the IETF-announce mailing list.  The IETF Executive Director then
   uses the selection procedures described in [<a href="./rfc3797" title="&quot;Publicly Verifiable Nomination Committee (NomCom) Random Selection&quot;">RFC3797</a>] to select a
   single volunteer from the list.  That volunteer decides the issue by
   naming the Internet-Draft containing the selected proposal in an
   email to the relevant working group chair, the working mailing list,
   and the IESG.

<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>.  Alternate Method Four: Random Assignment</span>

   Among the small number of cases for which consensus is not an
   appropriate method of decision-making are an even smaller number for
   which the decision involves no technical points at all and a need to
   select among options randomly.  The IDN working group, as an example,



<span class="grey">Hardie                        Experimental                      [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc3929">RFC 3929</a>        Consensus-Blocked Decisions in the IETF     October 2004</span>


   needed to designate a specific DNS prefix.  As the decision involved
   early access to a scarce resource, a random selection was required.
   In such cases, a working group may ask IANA to make a random
   assignment from among a set of clearly delineated values.  Under such
   circumstances, IANA will be guided by [<a href="./rfc3797" title="&quot;Publicly Verifiable Nomination Committee (NomCom) Random Selection&quot;">RFC3797</a>] in its selection
   procedures.  Under extraordinary circumstances, the working group
   may, with the approval of the IESG, ask IANA to select among a pool
   of Internet-Drafts in this way.

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  Appeals</span>

   The technical decisions made by these processes may be appealed
   according to the same rules as any other working group decision, with
   the explicit caveat that the working group's consensus to use an
   alternate method stands in for the working group's consensus on the
   technical issue.

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  Security Considerations</span>

   The risk in moving to a system such as this is that it shifts the
   basis of decision making within the IETF.  In providing these
   mechanisms, it is hoped that certain decisions that may be
   intractable under consensus rules may be reached under the rules set
   out here.  The risk, of course, is that forcing the evaluation to
   occur under these rules may allow individuals to game the system.

<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  IANA Considerations</span>

   <a href="#section-4.3">Section 4.3</a> may require the IANA to make random selections among a
   known set of alternates.

<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>.  References</span>

<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>.  Normative References</span>

   [<a id="ref-RFC3797">RFC3797</a>]  Eastlake, D., "Publicly Verifiable Nomination Committee
              (NomCom) Random Selection", <a href="./rfc3797">RFC 3797</a>, June 2004.

   [<a id="ref-RFC3777">RFC3777</a>]  Galvin, J., Ed. "IAB and IESG Selection, Confirmation, and
              Recall Process: Operation of the Nominating and Recall
              Committees", <a href="https://www.rfc-editor.org/bcp/bcp10">BCP 10</a>, <a href="./rfc3777">RFC 3777</a>, June 2004.

<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>.  Informative References</span>

   [<a id="ref-RFC3127">RFC3127</a>]  Mitton, D., StJohns, M., Barkley, S., Nelson, D., Patil,
              B., Stevens, M., and B. Wolff, "Authentication,
              Authorization, and Accounting: Protocol Evaluation", <a href="./rfc3127">RFC</a>
              <a href="./rfc3127">3127</a>, June 2001.



<span class="grey">Hardie                        Experimental                      [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc3929">RFC 3929</a>        Consensus-Blocked Decisions in the IETF     October 2004</span>


   [<a id="ref-VOTE">VOTE</a>]     Center for Democracy and Voting. "Frequently Asked
              Questions about IRV", <a href="http://www.fairvote.org/irv/faq.htm">http://www.fairvote.org/irv/faq.htm</a>.

   [<a id="ref-CONFLICT">CONFLICT</a>] International Online Training Program on Intractable
              Conflict,"Consensus Rule Processes", Conflict Research
              Consortium, University of Colorado, USA.
              <a href="http://www.colorado.edu/conflict/peace/treatment/consenpr.htm">http://www.colorado.edu/conflict/peace/treatment/</a>
              <a href="http://www.colorado.edu/conflict/peace/treatment/consenpr.htm">consenpr.htm</a>

<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>.  Acknowledgements</span>

   The author would like to acknowledge the contributions and
   challenging exchanges of those who reviewed this document, among them
   John Klensin, Dave Crocker, Pete Resnick, Spencer Dawkins, Scott
   Bradner, Joel Halpern, Avri Dora, Melinda Shore, Harald Alvestrand,
   Alex Simonelis, Keith Moore, Brian Carpenter, and Alex Rousskov.

<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>.  Author's Address</span>

   Ted Hardie
   Qualcomm, Inc.
   675 Campbell Technology Parkway
   Suite 200
   Campbell, CA U.S.A.

   EMail: hardie@qualcomm.com

























<span class="grey">Hardie                        Experimental                     [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc3929">RFC 3929</a>        Consensus-Blocked Decisions in the IETF     October 2004</span>


Full Copyright Statement

   Copyright (C) The Internet Society (2004).

   This document is subject to the rights, licenses and restrictions
   contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, 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 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 IETF's procedures with respect to rights in IETF Documents can
   be found in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.

   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
   <a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.

   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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.







Hardie                        Experimental                     [Page 11]
</pre>