



Network Working Group                                      M. Nottingham
Internet-Draft                                            March 10, 2017
Intended status: Best Current Practice
Expires: September 11, 2017


                Using Third Party Services for IETF Work
                   draft-nottingham-wugh-services-00

Abstract

   Some IETF Working Groups use third-party tools to manage their work,
   in addition to or instead of those that the Secretariat and Tools
   team provide.  This document specifies requirements regarding their
   use.

Note to Readers

   The issues list for this draft can be found at
   https://github.com/mnot/I-D/labels/wugh-services .

   The most recent (often, unpublished) draft is at
   https://mnot.github.io/I-D/wugh-services/ .

   Recent changes are listed at https://github.com/mnot/I-D/commits/gh-
   pages/wugh-services .

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on September 11, 2017.








Nottingham             Expires September 11, 2017               [Page 1]

Internet-Draft       3rd Party Services to the IETF           March 2017


Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Notational Conventions  . . . . . . . . . . . . . . . . .   3
   2.  Requirements for Third-Party Tools  . . . . . . . . . . . . .   3
     2.1.  Rough Consensus To Use  . . . . . . . . . . . . . . . . .   3
     2.2.  Equal Access  . . . . . . . . . . . . . . . . . . . . . .   3
     2.3.  Clear Procedure . . . . . . . . . . . . . . . . . . . . .   4
     2.4.  Notification  . . . . . . . . . . . . . . . . . . . . . .   5
     2.5.  Neutrality  . . . . . . . . . . . . . . . . . . . . . . .   5
     2.6.  Recoverability  . . . . . . . . . . . . . . . . . . . . .   5
     2.7.  Administrative Access . . . . . . . . . . . . . . . . . .   6
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   5.  Normative References  . . . . . . . . . . . . . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   Some IETF Working Groups use third-party tools to manage their work,
   in addition to or instead of those that the Secretariat and Tools
   team provide.

   For example, GitHub https://github.com/ is currently used by a number
   of active Working Groups to manage their drafts; as a distributed
   version control system, it has several attractive features, including
   broad understanding and use among developers, a refined user
   experience, and issue tracking facilities.

   Working Groups are encouraged to use the best tools that work for
   them, in a manner that best suits the work; the IETF does not benefit
   from locking its work practices into a one-size-fits-all set of
   tools.



Nottingham             Expires September 11, 2017               [Page 2]

Internet-Draft       3rd Party Services to the IETF           March 2017


   However, use of tools controlled by third parties can cause issues if
   not carefully considered.  To preserve the integrity of the IETF
   process when they are used, Section 2 outlines requirements for such
   uses.

1.1.  Notational Conventions

   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.  Requirements for Third-Party Tools

   Working Groups using third-party tools to manage an aspect of their
   work - for example, but not limited to, hosting and change control
   for adopted drafts, issue tracking, and discussion management - are
   expected to conform to the following requirements when doing so:

2.1.  Rough Consensus To Use

   The appropriate tools to use depends in large part on the community
   that will be using them; what works for some will be problematic for
   others.

   As a result, Working Groups using third-party tools MUST establish
   consensus to do so.  This consensus MAY be "rough", as any other
   decision in the IETF might be.  The Working Group's decision SHOULD
   be informed by the needs of those who will use the tools the most,
   such as document editors.

   The Working Group SHOULD establish alternative means of access to
   critical resources when there are participants "in the rough" on this
   decision.  For example, if a few participants object to using Github,
   issue activity can be mirrored to a mailing list, and they can
   subscribe to it.

2.2.  Equal Access

   One of the important properties of IETF work is that it is accessible
   to any who want to participate.

   Use of third-party tools MUST NOT require payment of a fee by
   participants.  However, if use of a tool requires payment and some
   party (e.g., the Working Group chair) is willing to cover all fees,
   such a tool MAY be used.  Note that this requirement does not
   preclude the use of services where "premium" features are available
   for a payment, as long as those features are not required to fully
   participate in the work.



Nottingham             Expires September 11, 2017               [Page 3]

Internet-Draft       3rd Party Services to the IETF           March 2017


   Use of third-party tools MUST NOT require legal agreements, beyond
   acceptance of reasonable "terms of service" and similar measures.  In
   particular, third-party services MUST NOT require assignment of
   intellectual property.

   When choosing a tool, a Working Group MUST consider the breadth of
   platform(s) it is available upon; tools that are platform-specific
   SHOULD NOT be chosen unless there is consensus in the Working Group
   that the benefits of using that tool outweigh this limitation, and no
   suitable alternative is available.  Tools that are specific to
   individual users (e.g., the Editors) MAY be exempted from this
   requirement, although the Working Group Chair(s) MUST approve of such
   choices.

   It is not a requirement that every third-party tool be accessible
   using every possible combination of technology.

2.3.  Clear Procedure

   IETF Working Groups using third-party tools MAY use them to host
   substantial technical discussions, in addition to or even instead of
   the traditional mailing list.

   When doing so, Working Groups MUST establish and document clear
   procedures about what the appropriate venue(s) for discussion are,
   and how consensus is established.

   In particular, even when consensus is allowed to be established in
   another medium, the Working Group mailing list MUST remain an
   acceptable form of input and participation; this assures that use of
   a third-party tool is not required for participation.

   Furthermore, when the Working Group does establish consensus in
   another medium, the mailing list MUST still be informed, and
   objections from those on the mailing list not using the third-party
   tool MUST be considered as new information by the Chairs, although
   the Chairs MAY determine that it is not sufficient to reopen an
   issue.

   For example, if a draft incorporates the resolutions of a number of
   issues discussed in Github, it is appropriate to notify the mailing
   list that those issues are believed to have consensus, giving people
   an opportunity to raise objections at that point.








Nottingham             Expires September 11, 2017               [Page 4]

Internet-Draft       3rd Party Services to the IETF           March 2017


2.4.  Notification

   When IETF work is hosted on a third-party tool, new participants
   might engage directly with the tool, rather than being first
   introduced to IETF processes.  In some cases, drawing such new, non-
   traditional participants into the work is an explicit goal of using a
   third-party service.

   Many of these participants will not be familiar with IETF processes -
   in particular, the NOTE WELL terms.  As a result, Working Groups
   using third-party tools:

   o  MUST prominently display the NOTE WELL terms and MUST state their
      applicability to that tool.

   o  SHOULD display links to introductory resources about the IETF;
      e.g., https://ietf.org/ and [RFC4677].

   The IESG MAY establish specific text to include in certain
   situations.

2.5.  Neutrality

   Because a tool often serves as a "source of truth" for Working Group
   activity, it is important that it be trustworthy.  Preferably, tools
   SHOULD be operated by a party that is not involved in the Working
   Group's activities directly; exceptions include cases where a tool
   has a very limited function (e.g., a script to post the results of
   one process to another service).

2.6.  Recoverability

   Third-party tools can and do go out of business, have disasters
   befall them, or change their terms of service in a way that is no
   longer acceptable for our purposes.  Additionally, after the work has
   completed, it is important that there is a stable archive of the work
   available, even when the relationship with the third party has
   terminated.

   Using a third-party tool is effectively taking a dependency against
   it, and so Working Groups that use them MUST take reasonable steps to
   assure that any state necessary to recover the work is available.

   This requirement could be met in a number of ways.  For example, some
   Working Groups using GitHub will check their issue lists into the
   repository, so that the issue state is recoverable; since there are
   multiple copies of the repository replicated (a minimum of one per
   editor), this state is recoverable.



Nottingham             Expires September 11, 2017               [Page 5]

Internet-Draft       3rd Party Services to the IETF           March 2017


   Ideally, such recovery mechanisms will enable a seamless transition
   to a different toolset in the event of an unforeseen (and hopefully
   rare) transition.  However, it is not a requirement that there be a
   "ready to go" fallback.  That said, backups SHOULD be in open formats
   (e.g., XML, JSON).

   The Secretariat and/or Tools team SHOULD provide backup mechanisms
   for commonly used third-party tools, as nominated by the IESG.  When
   available, such facilities MUST be used by Working Groups.

2.7.  Administrative Access

   Because Working Group personnel can change over time, both the
   Chair(s) and responsible Area Director SHOULD have administrative
   access to third-party tools, unless this is impractical.

3.  IANA Considerations

   This document does not require any action from IANA.

4.  Security Considerations

   This document does not introduce security considerations for
   protocols, but its application helps assure that the process that the
   IETF uses maintains its integrity.

5.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC4677]  Hoffman, P. and S. Harris, "The Tao of IETF - A Novice's
              Guide to the Internet Engineering Task Force", RFC 4677,
              DOI 10.17487/RFC4677, September 2006,
              <http://www.rfc-editor.org/info/rfc4677>.

Author's Address

   Mark Nottingham

   Email: mnot@mnot.net
   URI:   https://www.mnot.net/







Nottingham             Expires September 11, 2017               [Page 6]
