IAB Thoughts on the Role of the Internet Research Task Force (IRTF)
draft-iab-irtf-02

Internet Engineering Task Force                                 S. Floyd
INTERNET-DRAFT                                                 V. Paxson
draft-iab-irtf-02.txt                                            A. Falk
Expires: June 2006                                               Editors
                                                        20 December 2005

      IAB Thoughts on the Role of the Internet Research Task Force
                                 (IRTF)

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 June 2006.

Abstract

    This document is an IAB (Internet Architecture Board) report on the
    role of the IRTF (Internet Research Task Force), both on its own and
    in relationship to the IETF.  This document evolved from a
    discussion within the IAB as part of a process of appointing a new
    chair of the IRTF.

Floyd et al.                                                    [Page 1]
INTERNET-DRAFT             Expires: June 2006              December 2005

    TO BE DELETED BY THE RFC EDITOR UPON PUBLICATION:
     Changes from draft-iab-irtf-01.txt:
       * Changes in response to feedback from Ran Atkinson:
           - NSRG requiring consensus decisions.
           - Updated list of IAB members.
           - Added a reference to RFC 3932.
       * Changes in responses to feedback from J.P. Martin-Flatin:
           - Clarified phrase about "IETF-related informational RFCs".
           - Clarified phrase about "gateways controlling the
               advancement of [...] RFCs in the IETF"
           - Clarified discussion in "Range of activities".
           - Moved section on "What's in a Name" to an earlier
               subsection.
           - Deleted sentence about where IRTF internet-drafts are
               listed on the internet-drafts web page.
       * Editing changes in response to feedback from Spencer Dawkins:
           - Clarified discussion of implications of IRTF members being
               volunteers.
           - Clarified that "new chair of the IRTF" referred to Aaron.
       * Changes for Aaron to make:
         - Addressing Ran's feedback about the IRTF publication process.
     Changes from draft-iab-irtf-00.txt:
       * Added the following sentence: "One of the goals of the IAB is
           to make more use of the IRTF in investigating
           architectural issues."
       * Added list of past IRTF chairs.
       * Revised Abstract and first paragraph of Introduction.
       * Corrected typos.
       * Added a section on "Relationships between the Research and
           Development Communities"
       * Topics suggested that have not been added to the document:
         - Adding a section about the IRTF and SDOs.
         - Non-ASCII formats for IRTF documents?
           More transitory communication?
           Is there a need for tools for the IRTF?
         - RGs such as MOBOPTS are becoming too much a part of the
           standardization process?
           (We say in this document that this shouldn't happen...)

Floyd et al.                                                    [Page 2]
INTERNET-DRAFT             Expires: June 2006              December 2005

                             Table of Contents

    1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . .   3
    2. The Relationship between the IRTF, the IAB, and
    the IETF . . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
       2.1. Differences between IRTF and IETF Groups . . . . . . . .   5
       2.2. Research Groups as Non-blocking Entities . . . . . . . .   5
    3. The Range of IRTF Groups. . . . . . . . . . . . . . . . . . .   5
    4. Issues for the Future . . . . . . . . . . . . . . . . . . . .   6
       4.1. IRTF Groups and Network Architecture . . . . . . . . . .   7
       4.2. The Relationship between the IETF and the
       IRTF. . . . . . . . . . . . . . . . . . . . . . . . . . . . .   8
       4.3. Relationships between the Research and
       Development Communities . . . . . . . . . . . . . . . . . . .  10
          4.3.1. What's in a Name:  on the Name
          `Research Group' . . . . . . . . . . . . . . . . . . . . .  10
       4.4. The RFC Track for IRTF Documents . . . . . . . . . . . .  10
    5. Security. . . . . . . . . . . . . . . . . . . . . . . . . . .  11
    6. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . .  11
    Normative References . . . . . . . . . . . . . . . . . . . . . .  11
    Informative References . . . . . . . . . . . . . . . . . . . . .  11
    IANA Considerations. . . . . . . . . . . . . . . . . . . . . . .  12
    AUTHORS' ADDRESSES . . . . . . . . . . . . . . . . . . . . . . .  12
    Full Copyright Statement . . . . . . . . . . . . . . . . . . . .  13
    Intellectual Property. . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

    As part of the process of appointing a new chair of the Internet
    Research Task Force (IRTF), the IAB considered the future role of
    the IRTF both on its own, and in relationship to the IETF.  The IAB
    has expanded this discussion into this IAB report on the role of the
    IRTF, and circulated this document for wider community review.  [As
    one result of this discussion, Aaron Falk was appointed the new
    chair of the IRTF in March 2005.]

2.  The Relationship between the IRTF, the IAB, and the IETF

    Before 1989, the IAB (then the Internet Activities Board, and now
    the Internet Architecture Board) oversaw a number of task forces.
    In 1989, organizational changes were made to coalesce these task
    forces into two groups, the IETF and the IRTF.  The IRTF was tasked
    to consider long-term research problems in the Internet, and the
    IETF was to concentrate on short-to-medium term engineering issues
    related to the Internet.  At this time, all of the task forces
    except the IETF were restructured as IRTF research groups.  For
    example, the End-to-End Task Force became the IRTF's End-to-End

Floyd et al.                                        Section 2.  [Page 3]
INTERNET-DRAFT             Expires: June 2006              December 2005

    Research Group (E2ERG) and the Privacy & Security Task Force became
    the IRTF's Privacy & Security Research Group (PSRG) [IAB Web Pages]
    [RFC 3160] [E2ERG].

    Much of the early participation in the IETF as well as in the IRTF
    was from the academic and research communities.  (We don't have a
    citation from this, but a look at the members of the IAB from the
    80's and early 90's shows IAB members from institutions such as MIT,
    UCLA, BBN, UCL, SDSC, and the like, while IAB members from the last
    few years were more likely to list their organizations at the time
    of service as Cisco, IBM, Microsoft, Nokia, Qualcomm, and Verisign
    [IAB Web Pages]. We expect that a study of authors of RFCs would
    show a similar trend over time, with fewer authors from the academic
    and research communities, and more authors from the commercial
    world.)  While the IRTF has continued to have significant
    participation from the academic and research communities, the IETF
    has focused on standards development, and has become dominated by
    the needs of the commercial sector.

    The IRTF has generally focused on investigation into areas that are
    not considered sufficiently mature for IETF standardization, as well
    as investigation of areas that are not specifically the subject of
    standardization, but could guide future standards efforts.

    The IRTF Research Groups guidelines and procedures are described in
    RFC 2014.  The IRTF Chair is appointed by the Internet Architecture
    Board (IAB), and charters IRTF Research Groups (RGs) in consultation
    with the Internet Research Steering Group (IRSG) and with approval
    of the IAB.  The chairs of the RGs comprise the main part of the
    Internet Research Steering Group (IRSG), although the IRTF Chair can
    also appoint at-large members to the IRSG.

    As RFC 2014 states, the IRTF does not set standards.  While
    technologies developed in a Research Group (RG) can be brought to
    the IETF for possible standardization, "Research Group input carries
    no more weight than other community input, and goes through the same
    standards setting process as any other proposal" [RFC 2014] (Section
    1.1). This is necessary to ensure that RGs don't become a part of
    the standards process itself.

    RFC 2014 continues to say that "since the products are research
    results, not Internet standards, consensus of the group is not
    required" [RFC 2014] (Section 3). However, the NameSpace Research
    Group was one RG that did require consensus decisions; this group
    was chartered exclusively to make a recommendation to the IETF.

    RFC 2014 goes on to describe Research Group operation, meeting
    management, staff roles, group documents, and the like.  This

Floyd et al.                                        Section 2.  [Page 4]
INTERNET-DRAFT             Expires: June 2006              December 2005

    document is not a revision of RFC 2014, but instead a more wide-
    ranging discussion of the possible roles of the IRTF.

    The past history of IRTF Chairs is as follows: Dave Clark
    (1989-1992); Jon Postel (1992-1995); Abel Weinrib (1995-1999); Erik
    Huizer (1999-2001); Vern Paxson (2001-2005).

2.1.  Differences between IRTF and IETF Groups

    A key difference between IRTF research groups and IETF working
    groups is that IRTF groups are not trying to produce standards of
    any kind, and that the output of IRTF groups does not require
    consensus within the RG, or broad consensus from the IETF.

    In some cases, IRTF groups have acted as research groups with
    minimal constraints, creating a community for discussing research
    proposals, with mature proposals "tossed over the fence" to an IETF
    group for standardization.  The RMRG (Reliable Multicast Research
    Group) was an example of such a group, with standardization efforts
    in RMT (the Reliable Multicast Transport working group).

2.2.  Research Groups as Non-blocking Entities

    As stated in RFC 2014, the IRTF does not set standards.  It is
    important that, unless clearly specified otherwise by the IESG,
    research groups do not act as gateways controlling the advancement
    of standards, experimental RFCs, or informational RFCs produced by
    working groups in the IETF.

    Similarly, as stated in RFC 2014, existing research groups also do
    not necessarily prevent the creation of new research groups in
    related areas.  Of course, when considering a proposal for a new
    research group, it is perfectly appropriate for the IRTF and the IAB
    to consider the relationship with existing research groups.
    However, "multiple Research Groups working in the same general area
    may be formed if appropriate" [RFC 2014] (Sections 1.1,2.1).

3.  The Range of IRTF Groups

    There is a wide range of ways that IRTF groups can currently be
    structured.  Some of the most significant are:

    * Membership:  Groups might be open or closed (in terms of
    membership).  The End-to-End Research Group and the NameSpace
    Research Group are both past examples of closed RGs.

Floyd et al.                                        Section 3.  [Page 5]
INTERNET-DRAFT             Expires: June 2006              December 2005

    * Time-scale:  While RGs are generally long-term, groups could be
    either long-term (on-going), or short-term with a specific goal; the
    NameSpace Research Group is an example of an RG that was chartered
    as a short-lived group [NSRG]. We note that RFC 2014, written in
    1996, assumed that RGs would be long-term: "Research Groups are
    expected to have the stable long term membership needed to promote
    the development of research collaboration and teamwork in exploring
    research issues" [RFC 2014] (Section 1).

    * Relationship to IETF:  Groups can include a goal of producing
    proposals to be considered in the IETF (e.g., the Anti-Spam Research
    Group), or can be independent of any current or proposed work in the
    IETF (e.g., the Delay-Tolerant Networking Research Group).

    * Range of activities:  IRTF activities could consist not only of
    research groups and their associated meetings, workshops, and other
    activities, but also of separate workshops or other one-time
    activities organized directly by the IRTF.  To date, however, the
    IRTF has not organized such activities other than in the form of
    BOFs at IETF meetings.

    * Both research and development: IRTF groups can focus on
    traditional research activities, but they could also focus on
    development, on tool-building, on operational testing or protocol
    interoperability testing, or on other activities that don't fit the
    framework of a Working Group (WG).  Instead of having a specific
    plan for the evolution of the IRTF, we think that this will have to
    be explored over time, with discussions between the IRTF Chair, the
    IRSG, and the IAB (and with the IESG as appropriate).

    As discussed above, the IAB believes that the range of research
    groups could be expanded further, in terms of timescale,
    relationship to the IETF, range of activities, and range between
    research and development.

4.  Issues for the Future

    This section discusses some of the issues in the future evolution of
    the IRTF.  A key issue, discussed in Section 4.1 below, concerns how
    the IRTF can best contribute on questions of network architecture.

    Similar issues could be raised in how the IRTF can best contribute
    to incubating technology for later development in the IETF.  We
    emphasize that we are not proposing that the IRTF should become a
    de-facto holding point for technologies that are not making clear
    progress in the WGs.  Some technologies might not make progress in
    WGs because of key open issues, making an RG an appropriate step.

Floyd et al.                                        Section 4.  [Page 6]
INTERNET-DRAFT             Expires: June 2006              December 2005

    Other technologies, however, might not make progress in WGs because
    of a lack of interest, inherent design weaknesses, or some other
    reason that does not justify moving it into an RG instead.

4.1.  IRTF Groups and Network Architecture

    One interest of the IAB is how progress is made on issues of network
    architecture.  This includes help in developing and evaluating new
    architectures, and in understanding the evolving architecture and
    architectural issues of the decentralized, deployed Internet
    infrastructure.  This also includes developing tools that could be
    used in the above tasks.

    The spectrum of potential activities for IRTF groups ranges from the
    visionary to the specific, including the following:

    * Architecture: where are we, and where do we go from here?

    * Incubation:  we think we know where to go, but we don't yet have
    the tools to get there.

    * Problem focus: We have some specific problems to solve or
    potential solutions to evaluate.

    Some RGs have addressed broad architectural issues, with a mixed set
    of results;  examples of such RGs include the End-to-End Research
    Group, the NameSpace Research group, and the Routing Research Group.
    For other RGs (e.g., the Host Identity Protocol Research Group), the
    focus of the group is to study a specific proposal, with wider
    architectural issues raised at workshops held by the RG.  Finally,
    some RGs are in specific areas with well-defined boundaries, with
    topics that don't have broad impact on the wider Internet
    architecture.

    Where an IRTF RG lies on the spectrum of possible activities depends
    in part on where the IETF and the field itself lies.  For example,
    in areas such as network management where the IETF community has
    doubts or concerns about where we should be going with management
    technology, it would be useful for the IETF to be able to look to
    the IRTF for architectural evaluation.  In contrast, in areas where
    the architectural approach is better established, an RG with an
    incubation approach might be more appropriate.  Finally, where many
    pieces of the puzzle are in place, but some significant problems
    remain, an RG with a problem focus might make sense.

    For those RGs with an architectural focus, it would not be
    appropriate for the IAB to charter an RG to come up with *the*

Floyd et al.                                      Section 4.1.  [Page 7]
INTERNET-DRAFT             Expires: June 2006              December 2005

    architectural perspective on some topic; any such result would
    necessarily have to pass through the wide feedback and consensus
    procedures of the IETF.  However, it is appropriate for the IAB to
    ask an RG for exploration and discussion of an architectural issue;
    e.g., the IAB has asked the Routing Research Group for feedback
    about research objectives for inter-domain routing improvements [IAB
    Minutes].  It is also possible for RGs to make recommendations on
    architectural or other issues, with or without the request of the
    IAB; e.g., the End-to-End Research Group [RFC 2309] and the Crypto
    Forum Research Group have both made recommendations to the general
    IETF community.  However, some RGs function better as a breeding
    ground for ideas, and not as a consensus-building community.  For
    example, while the NameSpace Research Group was "an invitational
    research group chartered exclusively to make a recommendation to the
    IETF" [NSRG], the group never achieved a clear consensus.

    While the IAB doesn't have clear answers on the evolving role of the
    IRTF in addressing and understanding open architectural issues, this
    is an area that will be explored in the upcoming years, in
    collaboration with the IRTF Chair.  One of the goals of the IAB is
    to make more use of the IRTF in investigating architectural issues.

4.2.  The Relationship between the IETF and the IRTF

    Another area that could use more attention is making the
    relationship between the IETF and the IRTF more productive.  For
    many (though not all) of the research groups in the IRTF, part of
    the power of the RG lies in its relationship to the IETF.  Of
    current and recent RGs, for example, this is true of the ASRG (Anti-
    Spam), the CFRG (Crypto Forum), HIP (Host Identity Protocol), and a
    number of others.

    The interchange between the IETF and the IRTF could be improved in
    both directions: from the IETF to the IRTF in terms of information
    about IETF problems that could be helped by further research and
    development, and IETF evaluation of RG efforts and direction; and
    from the IRTF to the IETF in terms of reports, documents, proposals,
    BOFs, and the like.  Current paths for this interchange include IRTF
    reports at IETF plenary meetings; RG meetings before or after the
    IETF, or in one of the scheduled sessions during the IETF;
    workshops; and IRTF documents.

    One possibility (for some research groups, not for all of them)
    could be for an RG to have a design-team-like relationship to the
    IETF or to an IETF working group, with an RG charter that includes
    an agreement of deliverables, with some notion of the timeframe for
    those deliverables.  An issue that would need to be resolved here is

Floyd et al.                                      Section 4.2.  [Page 8]
INTERNET-DRAFT             Expires: June 2006              December 2005

    when is it appropriate for an RG to undertake such a relationship
    vs. an IETF WG doing it directly, as is sometimes already done.

    We note that as in WGs, RGs are composed of volunteers who make
    their own choices of research and engineering topics.  RGs are
    usually started by a proposal from individuals who want to form the
    RG.  Thus, it is important to realize that IRTF activity often will
    not be viable in the absence of individuals who would like to take
    on the particular work, and this tempers the usefulness of IETF WGs
    providing input to the IRTF regarding desired IRTF directions or
    activities.  For example, while the IETF can request specific
    research activities from IRTF RGs, results will require individuals
    within the RGs willing to undertake this work.

    IRTF RGs have been of significant benefit to the IETF; a number of
    IETF proposals began as discussions in the End-to-End Research
    Group, for example.  At the same time, the interchange with RGs can
    take significant time and effort from WG chairs and from ADs,
    sometimes with little to show for it if the RG's direction is at
    odds with that desired by the WG chairs or ADs.  One task for the
    future is to improve the dialogue between the IETF and the IRTF
    while not increasing the load on WG chairs and ADs.

    One role of the IRTF could be to open some new communication paths
    between the research community and the IETF.  Over the last ten
    years, as the Internet has grown and matured, and the difficulties
    of making changes to the Internet architecture have increased, the
    research community's participation in the IETF has dropped.  We are
    not necessarily expecting to reverse this trend, but it would be
    good for the output of the research community to reach the IETF
    somewhat more than it does now, and for the research community to
    hear more from the IETF.

    We would like to shape an IRTF that meets the needs of researchers
    in this domain, providing interaction both with other researchers
    and with other industry technologists.  In this respect we would
    like to see an IRTF that has momentum that is self-sustaining from
    voluntary efforts, that undertakes (some) work on topics that align
    to the interests of the IETF, and in such a fashion continues to be
    of material assistance to the IETF standardization effort.  We would
    also like to see an IRTF that continues to give thoughtful
    consideration and input to the development of the Internet
    architecture.

Floyd et al.                                      Section 4.2.  [Page 9]
INTERNET-DRAFT             Expires: June 2006              December 2005

4.3.  Relationships between the Research and Development Communities

    One of the current and future roles played by the IRTF is that of a
    bridge between the research and development communities; the
    research community in general is less of an active force in the IETF
    than it was in the beginning of the IETF's history.  At the risk of
    resorting to stereotypes, IETFers sometimes view the network
    research community as irrelevant or disconnected from reality, while
    researchers sometimes view the IETF as insufficiently thoughtful or
    as an unproductive place for investing one's research energies.
    There is also a natural difference in time scales, with the IETF
    more focused on near-to-medium-term issues, and researchers often
    more focused on longer-term issues.

    Unfortunately, disconnections between the research and development
    communities can hurt both the research and the development.  Just as
    one example, from "Failure to Thrive: QoS and the Culture of
    Operational Networking" [B03] : "Remarkable intelligence and energy
    have been lavished upon the architectural design of QoS, but much
    less attention has been devoted to careful analysis of the relevant
    problem space from an operational or economic perspective. This
    discrepancy is symptomatic of a broken (or attenuated) feedback loop
    between network operations and research."  Thus one potential role
    of the IRTF is to help provide a productive forum that improves the
    communication in both directions between the two communities.

4.3.1.  What's in a Name:  on the Name `Research Group'

    There have been proposals that for some groups the name "Research
    Group" is incorrect or unnecessarily off-putting to some potential
    participants, and that other names such as "Architecture Group"
    might in some cases be more useful.  Such a terminology change is
    potentially quite significant, and needs to be evaluated in terms of
    the IAB's overall role and responsibility for guiding the
    development of architectural considerations within the IETF.
    Another issue is that different RGs have different mixes of people,
    in terms of researchers from academia, industry practitioners, and
    IETF WG participants; it is not clear how changing the names would
    affect this.

4.4.  The RFC Track for IRTF Documents

    Currently, RFCs produced by RGs are published as individual
    submissions, under the review of the RFC Editor [RFC 3932].  There
    is currently a discussion (and pending internet-draft) about the
    need for a venue for publishing RG output that is clearly marked as

Floyd et al.                                     Section 4.4.  [Page 10]
INTERNET-DRAFT             Expires: June 2006              December 2005

    research, as opposed to the output of an IETF WG.  This is both to
    more clearly distinguish RG output from standards documents of the
    IETF, and to give RG output more visibility than that of individual
    submissions.  Similarly, RG output might have different reviewing
    criteria from that of other documents considered as individual
    submissions.  This discussion is on-going.

    More visibility for RG internet drafts could increase the level of
    interchange between the RG and the rest of the community.

    It would also be helpful to decrease the delay in the publication
    time for IRTF RFCs.  Anything that *increased* the publication time
    would probably be counterproductive.

5.  Security

    There are no security considerations in this document.

6.  Acknowledgements

    This document comes out of discussions in the IAB.  Many thanks for
    Bob Braden, Aaron Falk, Rajeev Koodli, J.P. Martin-Flatin, and
    Gabriel Montenegro for feedback on this document.

Normative References

    [RFC 2014] A. Weinrib and J. Postel, IRTF Research Group Guidelines
    and Procedures, RFC 2014, October 1996.  Best Current Practice.

Informative References

    [B03] G. Bell, "Failure to Thrive: QoS and the Culture of
    Operational Networking", Proceedings of the ACM SIGCOMM Workshop on
    Revisiting IP QoS: What Have We Learned, Why Do We Care?, August
    2003.

    [E2ERG] B. Braden, "The End-to-end Research Group - Internet
    Philosophers and Physicists", Presentation to the IETF plenary,
    March 1998.

    [IAB Minutes] Minutes, IAB Teleconference -- June 12, 2001, URL
    "http://www.iab.org/documents/iabmins/IABmins.2001-06-12.html".

    [IAB Web Pages] A Brief History of the Internet Advisory /

Floyd et al.                                                   [Page 11]
INTERNET-DRAFT             Expires: June 2006              December 2005

    Activities / Architecture Board, URL
    "http://www.garykessler.net/library/ietf_hx.html".

    [NSRG] Web page, NameSpace Research Group (NSRG), URL
    "http://www.irtf.org/historical/namespace.html".

    [RFC 2309] B. Braden et al., Recommendations on Queue Management and
    Congestion Avoidance in the Internet, RFC 2309, April 1998.

    [RFC 3160] S. Harris, "The Tao of IETF - A Novice's Guide to the
    Internet Engineering Task Force", RFC 3160, August 2001.

    [RFC 3932] H. Alvestrand, The IESG and RFC Editor Documents:
    Procedures, RFC 3932, October 2004.

IANA Considerations

    There are no IANA considerations in this document.

AUTHORS' ADDRESSES

    Internet Architecture Board
    EMail:  [email protected]

    Internet Architecture Board Members
    at the time this document was published were:

    Bernard Aboba
    Loa Andersson
    Brian Carpenter (IETF Chair)
    Leslie Daigle (IAB Chair)
    Patrik Faltstrom
    Bob Hinden
    Kurtis Lindqvist
    David Meyer
    Pekka Nikander
    Eric Rescorla
    Pete Resnick
    Jonathan Rosenberg
    Lixia Zhang

    The IRTF Chair at the time this document was published was Aaron
    Falk.

    We note that when this document was begun, Sally Floyd was a member

Floyd et al.                                                   [Page 12]
INTERNET-DRAFT             Expires: June 2006              December 2005

    of the IAB, and Vern Paxson, as IRTF chair at the time, was an ex-
    officio member of the IAB.

Full Copyright Statement

    Copyright (C) The Internet Society (2005).  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 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-
    [email protected].

Floyd et al.                                                   [Page 13]