[weirds] combined rechartering text

Andrew Newton <andy@hxr.us> Tue, 28 July 2015 20:41 UTC

Return-Path: <andy@hxr.us>
X-Original-To: weirds@ietfa.amsl.com
Delivered-To: weirds@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 212961B305B for <weirds@ietfa.amsl.com>; Tue, 28 Jul 2015 13:41:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id aWN23GHbmtVn for <weirds@ietfa.amsl.com>; Tue, 28 Jul 2015 13:41:19 -0700 (PDT)
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13F4C1B3022 for <weirds@ietf.org>; Tue, 28 Jul 2015 13:41:15 -0700 (PDT)
Received: by wibud3 with SMTP id ud3so195764115wib.1 for <weirds@ietf.org>; Tue, 28 Jul 2015 13:41:13 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=XzQU8LgbGn1d7LCZTVtgCK8DtLhknWBkWqxkAasNrts=; b=h/hxytgqsREM7UFh0+vBXAtqNF4J+0SUdmcWqYpbvFKJ5E41AZoZ6WV69dKai3Anm9 K61Yt61sprXkCpPLWxs77jQIeV42IHCBS5iAspuN3H9fURnsNC7NKm2aeazBc0pUz1Sy yqsOsWjZauNNfAeqzse40HUJi5e1cClXtqwhN2MI+i0bSDPKZcQMju6kEIoEJ46YAEYg visDziOcewHane1qbIY7DYNCYASpL51Bx9HfV9QlXwWkPwVpccxZLYrd+NKZstvSMpn3 FnIZ54Y16AzV62n2HdMtfsxb9PFG0h7O4gqKCSpe4jrQc5xPhB514uaI6UjeGiaG3NJ4 iDKA==
X-Gm-Message-State: ALoCoQkau2HeYxCky3nCKuWHYKAm8LA2Ct3OkJd0sliAwiYSfHTepYyp6sJLAqltVJ6zcPzo9WWA
MIME-Version: 1.0
X-Received: by with SMTP id he8mr69525264wjc.11.1438116073802; Tue, 28 Jul 2015 13:41:13 -0700 (PDT)
Received: by with HTTP; Tue, 28 Jul 2015 13:41:13 -0700 (PDT)
X-Originating-IP: []
Date: Tue, 28 Jul 2015 16:41:13 -0400
Message-ID: <CAAQiQRdD+LwYZNYBC2Mj7Es-oM2piygoM-rhT94pc1UA-y8U-A@mail.gmail.com>
From: Andrew Newton <andy@hxr.us>
To: eppext@ietf.org, "weirds@ietf.org" <weirds@ietf.org>
Content-Type: text/plain; charset=UTF-8
Archived-At: <http://mailarchive.ietf.org/arch/msg/weirds/jjVAzkdIeuUHRhWGA4513dZL2dE>
Subject: [weirds] combined rechartering text
X-BeenThere: weirds@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" <weirds.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/weirds>, <mailto:weirds-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/weirds/>
List-Post: <mailto:weirds@ietf.org>
List-Help: <mailto:weirds-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/weirds>, <mailto:weirds-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Jul 2015 20:41:21 -0000

Here is some proposed text for a rechartering focused on both EPP and RDAP.

It is based on the text James Galvin sent on July 23. However, there
are two things to note:

1. It broadens the allowable set of work items to also include
informational and BCP documents seeking IETF consensus.

2. States that EPP will be the initial focus of work items since it
has the greater backlog.



Draft Proposed Charter EPP/RDAP Extensions Working Group

The Extensible Provisioning Protocol (EPP, Standard 69) is the
standard domain name provisioning protocol for top-level domain name
registries, and the Registration Data Access Protocol (RDAP) is a
public-facing data access protocol used by domain name and Internet
number registries. As adoption of these protocols progresses by new
registries and registrars, it is important to coordinate and
standardize extensions when necessary.

The EPP Extensions (EPPEXT) working group completed its first goal of
creating an IANA registry of EPP extensions.  The registration process
of the registry is documented in RFC7451.  Extensions may be
registered for informational purposes as long as there is a published
specification that has been reviewed by a designated expert.

RDAP, completed by the WEIRDS working group, has a similar extensions
mechanism and accompanying IANA registries, also governed by expert
review and requiring published specifications.

For both protocols, extensions that seek the status of Internet
standard are subject to more thorough review and open discussion
within the IETF. In addition, commonality may be discovered in
extensions listed for which it would makes sense to merge them into a
single standard extension everybody agrees on.

This working group will be the home of the coordination effort for
standards track extensions and informational or best practices
documents needing IETF consensus.  The selection for work items shall
incorporate the following guidelines.

1. Proprietary documented extensions and individual submissions of
informational or experimental extensions will follow the expert review
process as specified for EPP and RDAP. These documents will not be
part of this working groups work or milestones. The working group may
discuss or advise on these documents.

2. Extensions that seek standards track status and other documents in
need of IETF consensus  can be suggested for WG adoption, and, once
accepted, proceed to IETF consensus and RFC publication according to
IETF practices.

3. This working group will exist as long as there are relevant
document work items.  When there are no more document work items, this
working group will either close or go dormant according to IETF rules.
The mailing list will remain open and available for the use of the
expert review process.

4. Initial work and milestones for this working group will emphasize
standardization of EPP extensions over RDAP extensions, as EPP has a
larger backlog of documents seeking adoption at the time of chartering
for this working group.


TBD depending on the initial documents selected for standards track.