GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5111

Network Working Group B. Aboba Request for Comments: 5111 Microsoft Corporation Category: Experimental L. Dondeti

                                                        QUALCOMM, Inc.
                                                          January 2008
        Experiment in Exploratory Group Formation within the
              Internet Engineering Task Force (IETF)

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.

Abstract

 This document describes an RFC 3933 experiment in the Working Group
 formation process, known as the Exploratory Group.  Exploratory
 Groups may be created as the first step toward Working Group
 formation, or as an intermediate step between a Birds of a Feather
 (BOF) session and Working Group creation.  Exploratory Groups are
 focused on completion of prerequisites for Working Group formation,
 and as a result they have a short life-time, with limited
 opportunities for milestone extension.

Table of Contents

 1. Introduction ....................................................2
    1.1. Requirements ...............................................4
 2. Exploratory Group Formation .....................................4
 3. The Experiment ..................................................5
    3.1. Success Metrics ............................................5
 4. Security Considerations .........................................6
 5. Normative References ............................................6
 6. Acknowledgments .................................................6

Aboba & Dondeti Experimental [Page 1] RFC 5111 Exploratory Group Experiment January 2008

1. Introduction

 "IETF Working Group Guidelines and Procedures" [RFC2418] describes
 the Working Group formation process within the Internet Engineering
 Task Force (IETF).  As noted in RFC 2418 [RFC2418] Section 2.1:
    When determining whether it is appropriate to create a working
    group, the Area Director(s) and the IESG will consider several
    issues:
  1. Are the issues that the working group plans to address clear and

relevant to the Internet community?

  1. Are the goals specific and reasonably achievable, and achievable

within a reasonable time frame?

  1. What are the risks and urgency of the work, to determine the

level of effort required?

  1. Do the working group's activities overlap with those of another

working group?

      ...
  1. Is there sufficient interest within the IETF in the working

group's topic with enough people willing to expend the effort to

      produce the desired result (e.g., a protocol specification)?
      ...
  1. Is there enough expertise within the IETF in the working group's

topic, and are those people interested in contributing in the

      working group?
      ...
  1. Does a base of interested consumers (end-users) appear to exist

for the planned work?

      ...
  1. Does the IETF have a reasonable role to play in the

determination of the technology?

      ...
  1. Are all known intellectual property rights relevant to the

proposed working group's efforts issues understood?

  1. Is the proposed work plan an open IETF effort or is it an

attempt to "bless" non-IETF technology where the effect of input

      from IETF participants may be limited?

Aboba & Dondeti Experimental [Page 2] RFC 5111 Exploratory Group Experiment January 2008

  1. Is there a good understanding of any existing work that is

relevant to the topics that the proposed working group is to

      pursue?  This includes work within the IETF and elsewhere.
  1. Do the working group's goals overlap with known work in another

standards body, and if so is adequate liaison in place?

 In some situations, while interest on the part of IETF participants
 and end-users may be evident, and the relevance to the Internet
 community may be demonstrated, the answer to other questions (such as
 an understanding of existing work, clarity or achievability of goals,
 or overlap with existing working groups or standards bodies) may not
 be as clear.  In the past, the likely outcome in this circumstance
 has been to postpone Working Group formation or even Birds of a
 Feather (BOF) sessions until satisfactory answers are forthcoming.
 However, in practice this may leave the status of the potential
 Working Group officially undetermined for months or even years.
 While the Area Directors should provide potential Working Group
 participants timely updates on the status of the potential Working
 Group and insight into IESG or IAB concerns, currently there is no
 mechanism to track progress toward Working Group creation, and as a
 result, participants may not have a clear understanding of the status
 or the next steps.  Also, the lack of formal recognition may
 negatively affect the motivation of the participants, and may leave
 those who have not followed the effort closely with an impression
 that no work is going on.
 This document describes an RFC 3933 [RFC3933] experiment in the
 Working Group (WG) formation process, known as the Exploratory Group
 (EG).  Exploratory Group milestones are focused on completion of
 prerequisites for Working Group formation, and as a result they are
 expected to conclude within a short time frame, with limited
 opportunities for milestone extension.
 This Exploratory Group experiment does not alter the Working Group
 formation guidelines described in RFC 2418 [RFC2418] Section 2.1, or
 the Internet Standards Process described in RFC 2026 [RFC2026].
 Rather, it builds on these existing processes, introducing an element
 of formality which may be useful in clarifying IESG and/or IAB
 concerns relating to Working Group formation criteria and motivating
 more rapid progress toward their resolution.  Since Exploratory Group
 documents (including the EG Charter and potential WG Charter) are
 reviewed and comments are tracked using existing tools and processes,
 feedback is available to Exploratory Group chairs and authors,
 providing for transparency and accountability.

Aboba & Dondeti Experimental [Page 3] RFC 5111 Exploratory Group Experiment January 2008

1.1. Requirements

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 document are to be interpreted as described in [RFC2119].

2. Exploratory Group Formation

 If at any point during the Working Group formation process, relevance
 to the Internet community and interest within the IETF and end-user
 community has been demonstrated, but one or more Working Group
 formation criteria outlined in RFC 2418 [RFC2418] Section 2.1 has not
 yet been met, the IESG MAY propose that an Exploratory Group be
 formed.  Exploratory Groups MAY be created as the first step toward
 Working Group formation, or as an intermediate step between an
 initial Birds of a Feather (BOF) session and Working Group creation.
 The formation of an Exploratory Group after a second BOF is NOT
 RECOMMENDED.
 Since the goal of an Exploratory Group is to put in place the
 prerequisites for formation of a Working Group more rapidly than
 might otherwise be possible, Exploratory Groups SHOULD initially be
 chartered for a period of six months to twelve months, with six
 months being the default.  While the IESG MAY extend the initial
 Exploratory Group milestones by an additional six months, extensions
 beyond this are NOT RECOMMENDED.  The Exploratory Group Charter
 SHOULD include at least the following "basic milestones":
    o Development of a Working Group Charter.
    o Development of a document demonstrating fulfillment of the
      Working Group formation criteria described in RFC 2418 [RFC2418]
      Section 2.1.
 The IESG MAY also include additional milestones within an Exploratory
 Group charter (such as development of a problem statement or
 requirements document and/or completion of a review of the literature
 or current practices), as long as these additional milestones do not
 compromise the ability of the Exploratory Group to deliver on the
 basic milestones in a timely way.  A Exploratory Group charter MUST
 NOT include milestones relating to development of standards track
 documents or protocol specifications.
 Since the Exploratory Group experiment is not intended as a
 substitute for the existing Working Group formation process,
 Exploratory Groups SHOULD be formed only in situations where the
 prerequisites for formation of a WG are likely to be met if the EG
 successfully completes the basic milestones.

Aboba & Dondeti Experimental [Page 4] RFC 5111 Exploratory Group Experiment January 2008

3. The Experiment

 This experiment runs for a period of 18 months from IESG approval of
 the experiment.  During the period of the experiment, the IESG MAY
 approve formation of as many as three Exploratory Groups.  The IESG
 MUST inform the community in a public statement of any decisions for
 Exploratory Group formation approved under this experiment.  Such a
 statement SHOULD include a description of specific Exploratory Group
 that was formed.
 Given that this is an experiment, the intent is for Exploratory
 Groups to be handled identically to Working Groups in terms of IETF
 process, tools and infrastructure; no additional burden is to be
 imposed on the IETF Secretariat.  Other than the abbreviated
 Exploratory Group charter, the process for formation of an
 Exploratory Group is identical to that of a Working Group, including
 review by the IAB and IESG, announcement of the potential Exploratory
 Group, and request for review by the IETF community.  The operating
 rules of an Exploratory Group (openness, meeting requirements, etc.)
 are identical to Working Groups.  From the point of view of IETF
 infrastructure (tools, membership in the WGCHAIRS mailing list,
 process rules, Exploratory Group Charter pages, etc.)  Exploratory
 Groups are treated identically to Working Groups, with the exception
 that Exploratory Group names should include "EG" within the name
 (e.g. "EXAMPLEEG"), so as to clearly differentiate them from Working
 Groups.
 Review of Exploratory Group documents will utilize the same tracking
 tools and processes (including PROTO shepherding) as other IETF
 documents; this allows feedback to be viewed by Exploratory Group
 Chairs and participants, as well as providing additional clarity on
 next steps.  Formation of an Exploratory Group requires the
 appointment of an Exploratory Group Chair, and a well defined set of
 Working Group formation criteria (agreement on the Working Group
 Charter, review of the formation criteria, problem statement or
 requirements document, etc.).

3.1. Success Metrics

 Since one of the goals of this experiment is to enable the more rapid
 formation of Working Groups, the success of an individual Exploratory
 Group, as well as the experiment, can be measured based on the
 progress made toward Working Group formation.  Useful metrics
 include:

Aboba & Dondeti Experimental [Page 5] RFC 5111 Exploratory Group Experiment January 2008

 Progress on Basic Milestones
      A Exploratory Group that does not make progress on its basic
      milestones cannot be judged successful, regardless of its other
      achievements, such as progress on a literature review or
      requirements document.  Progress on the basic milestones is
      measured by whether they are completed within the time-frame
      specified in the initial Exploratory Group Charter, and whether
      feedback from the IESG, IAB and IETF community is positive,
      leading the IESG to vote to form a Working Group.
 Mailing List Activity
      Since one of the goals of the Exploratory Group experiment is to
      avoid a potential loss of interest among participants, evidence
      of continued engagement on the part of Exploratory Group
      participants based on mailing list activity is a potential
      success metric.  Conversely, an Exploratory Group whose mailing
      list shows minimal traffic would probably not be a good
      candidate for milestone extension.

4. Security Considerations

 This document describes an experiment in the formation of Exploratory
 Groups.  It has no security considerations.

5. Normative References

 [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
            3", BCP 9, RFC 2026, October 1996.
 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC2418]  Bradner, S., "IETF Working Group Guidelines and
            Procedures", BCP 25, RFC 2418, September 1998.
 [RFC3933]  Klensin, J. and S. Dawkins, "A Model for IETF Process
            Experiments", BCP 93, RFC 3933, November 2004.

6. Acknowledgments

 The authors would like to thank Jari Arkko, Brian Carpenter, Thomas
 Narten, Lars Eggert, Eric Rescorla, Sam Hartman, and John Klensin for
 valuable input.

Aboba & Dondeti Experimental [Page 6] RFC 5111 Exploratory Group Experiment January 2008

Authors' Addresses

 Bernard Aboba
 Microsoft Corporation
 One Microsoft Way
 Redmond, WA 98052
 EMail: bernarda@microsoft.com
 Phone: +1 425 706 6605
 Fax:   +1 425 936 7329
 Lakshminath Dondeti
 QUALCOMM, Inc.
 5775 Morehouse Dr
 San Diego, CA
 USA
 EMail: ldondeti@qualcomm.com
 Phone: +1 858-845-1267

Aboba & Dondeti Experimental [Page 7] RFC 5111 Exploratory Group Experiment January 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.

Aboba & Dondeti Experimental [Page 8]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5111.txt · Last modified: 2008/01/05 00:52 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki