Re: [eppext] final charter description

James Galvin <galvin@elistx.com> Thu, 05 November 2015 01:44 UTC

Return-Path: <galvin@elistx.com>
X-Original-To: eppext@ietfa.amsl.com
Delivered-To: eppext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 252F11B363D for <eppext@ietfa.amsl.com>; Wed, 4 Nov 2015 17:44:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level:
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XOr5UGqeI9AQ for <eppext@ietfa.amsl.com>; Wed, 4 Nov 2015 17:44:37 -0800 (PST)
Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) (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 F38E71B3624 for <eppext@ietf.org>; Wed, 4 Nov 2015 17:44:36 -0800 (PST)
Received: by qgbb65 with SMTP id b65so55581712qgb.2 for <eppext@ietf.org>; Wed, 04 Nov 2015 17:44:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=elistx_com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=rOXh+A8mlI/ridTR62YxK8u9fFX7vpvjSK0V9wM/y9I=; b=TAKj0ZyWHfYr6hcWdT0grgY2tHqC1KVqtA1kt+2xHurj58Gm4PZqfK+FSw+N6CjzEI kbj/FewbuZYnoFxm+9n8T94OHtU5XRhGwMbT2vF3jnH4pkxtcRN9/fPL/Ao5Wsbyq7uz AyKL8wxDogdmwLdfn+8DcAMAPLqYA46uF0QpRtPqQ7i3dZKmK7FQK7j6YQ/9mHis0bPI o0JHAm2Vqj+mnMdjrEPRF2oXXzgPs+NtWMNaj7UXIVKpXI9+vdLqydv5j3OspToLcdus htQDCl+EadyAM6RhhIlRl3P4tXypUMTVGPjg06G9fwpOyRyiFU5RAY8FEgW0uSRfGFx6 iNFg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=rOXh+A8mlI/ridTR62YxK8u9fFX7vpvjSK0V9wM/y9I=; b=GymNZy21PPptMQDU60q6w0Aksqmu8neZlzNOv4IqRy+GAGSG/xa7mx8maIKLswTo9t iOZMqf4hfBRtB5TNLWxeVy0/Przo762ocDG9jm32RB6+CbVDeTZexiEaKlvSOT3cQxPn mFI4L7ANMP+gXhHltt7aWqVTZcpXY1YO4bJV7Tr7JZYDIMsZxwN1YSQZDqrs4CSHTIsm jTp1hyKFBPqCNH6Wt3zCTg0McaQiBCTaSUVqVRUdmoXO/Xcw3V+C7tv/vWE44gWdzsPG EdCYGH6431zqpBPOoTApr6lfHbZ2yXDhtkueZBArmp267ddE9h9yWbk1D/4SWQAca148 +y1w==
X-Gm-Message-State: ALoCoQlvkLGcMjaS/FUUti4KWAX/Wu297f0ysHE6EkxNOBuIHejalrICnQvtK1KGvaDPF/XIKn+G
X-Received: by 10.140.43.183 with SMTP id e52mr4930968qga.38.1446687876191; Wed, 04 Nov 2015 17:44:36 -0800 (PST)
Received: from jgalvin-lt.local (c-73-133-108-218.hsd1.md.comcast.net. [73.133.108.218]) by smtp.googlemail.com with ESMTPSA id m23sm1066126qkh.46.2015.11.04.17.44.30 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Nov 2015 17:44:35 -0800 (PST)
To: Marc Blanchet <marc.blanchet@viagenie.ca>
References: <563AAC4F.6050907@elistx.com> <A4E1F844-9D5E-43CD-B886-F5CB94809768@viagenie.ca> <1E948341-BA56-498F-8AF9-6382856B8265@viagenie.ca>
From: James Galvin <galvin@elistx.com>
Message-ID: <563AB498.7050203@elistx.com>
Date: Wed, 04 Nov 2015 20:44:56 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <1E948341-BA56-498F-8AF9-6382856B8265@viagenie.ca>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/eppext/GuexfDCaWI22blOf2qLeRtSsNQ8>
Cc: eppext <eppext@ietf.org>
Subject: Re: [eppext] final charter description
X-BeenThere: eppext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: EPPEXT <eppext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/eppext>, <mailto:eppext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/eppext/>
List-Post: <mailto:eppext@ietf.org>
List-Help: <mailto:eppext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/eppext>, <mailto:eppext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Nov 2015 01:44:39 -0000

For right now, I would say no.  This charter has been agreed to by the 
working group and is waiting for milestones to move forward.

Changing the scope would change the charter and I would recommend 
against this.

That's a process argument against.

Separately, I think this topic is different enough from "extensions" 
that it should itself be separate from this working group.  Just my 
opinion of course.  Would like to hear from others.

Jim



On 11/4/15 8:28 PM, Marc Blanchet wrote:
> have another comment about charter: should topics like this
> (draft-latour-dnsoperator-to-rrr-protocol-00) be in scope of the new wg?
> if yes, then we may want to make it so.
>
> Marc.
>
> On 5 Nov 2015, at 10:21, Marc Blanchet wrote:
>
>     few comments on the proposed charter:
>
>     Proposed Charter
>     Registration Protocols Extensions (REGEXT) Working Group
>
>     The Extensible Provisioning Protocol (EPP, Standard 69) is the
>     standard domain name provisioning protocol for top-level domain name
>     registries, and the Internet Corporation for Assigned Names and
>     Numbers (ICANN) requires all new generic top-level domain registries
>     to implement EPP. To avoid many separate EPP extensions that provide
>     the same functions, it's important to coordinate and standardize EPP
>     extensions.
>
>     <MB>I would be more happy to not specifically talk about ICANN
>     requirements for gTLD, but more in general for any registries,
>     including cctlds. I would just remove « and the Internet Corporation
>     … to implement EPP ».
>     </MB>
>
>     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.
>
>     The Registration Data Access Protocol (RDAP, RFCs 7480-7484) is the
>     proposed standard for retrieving registration metadata from both
>     domain name and Regional Internet Registries. Some registries are
>     using it now and many more are expected as ICANN moves towards
>     requiring it of generic top-level domain registries.
>
>     <MB>same comment here. More over, timing data such as « using it
>     now » does not survive well over time. Suggested change is to remove
>     the last sentence.
>     </MB>
>
>     To ensure
>     interoperable implementations it's important to coordinate and
>     standardize extensions and profiles to be used by registries.
>
>     Extensions in both cases 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 related extensions,
>     especially EPP extensions listed on the EPP extension registry, for
>     which it would makes sense to merge them into a single standard
>     extension everybody agrees on.
>
>     The REGEXT working group is the home of the coordination effort for
>     standards track extensions. The selection of extensions for standards
>     track shall incorporate the following guidelines.
>
>      1.
>
>         Proprietary documented extensions and individual submissions of
>         informational or experimental EPP extensions will follow the expert
>         review process as described in RFC7451 for inclusion in the EPP
>         extensions registry. These documents will not be part of the REGEXT
>         working group work or milestones. The working group may discuss or
>         advise on these documents.
>
>      2.
>
>         Extensions that seek standards track status can be suggested for WG
>         adoption. If accepted by the working group then the development of
>         the standard may proceed.
>
>      3.
>
>         The working group will exist as long as there is an extension
>         seeking standards track status. When there are no more proposals
>         for a standards track extension the 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 as
>         described in
>         RFC7451.
>
>     The working group will focus initially on the backlog of EPP extensions.
>
>     <MB>The last paragraphs are really EPP focused. We already know that
>     they are some RDAP extensions that need to be standardized. I think
>     the text should reflect that.
>     </MB>
>
>     On 5 Nov 2015, at 10:09, James Galvin wrote:
>
>         Included in this message is the final charter description that
>         has been previously agreed to by this working group.
>
>         What is missing are the milestones. A follow up message will
>         propose a draft set of milestones for discussion in the working
>         group meeting (and here on the list of course).
>
>         I'm separating these parts so we focus discussion.
>
>         Jim
>
>         ------------------------------------------------------------------------
>
>         EppExt mailing list
>         EppExt@ietf.org <mailto:EppExt@ietf.org>
>         https://www.ietf.org/mailman/listinfo/eppext
>
>     ------------------------------------------------------------------------
>
>     EppExt mailing list
>     EppExt@ietf.org <mailto:EppExt@ietf.org>
>     https://www.ietf.org/mailman/listinfo/eppext
>