Internet DRAFT - draft-nottingham-wugh-services
draft-nottingham-wugh-services
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]
