Re: [eppext] final charter description
"Marc Blanchet" <marc.blanchet@viagenie.ca> Thu, 05 November 2015 01:28 UTC
Return-Path: <marc.blanchet@viagenie.ca>
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 5D31D1B3600 for <eppext@ietfa.amsl.com>; Wed, 4 Nov 2015 17:28:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 PfLuv9RNikzZ for <eppext@ietfa.amsl.com>; Wed, 4 Nov 2015 17:28:47 -0800 (PST)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8A6FB1B35FE for <eppext@ietf.org>; Wed, 4 Nov 2015 17:28:46 -0800 (PST)
Received: from [133.93.37.87] (dhcp-37-87.meeting.ietf94.jp [133.93.37.87]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 64CE5403A2; Wed, 4 Nov 2015 20:28:45 -0500 (EST)
From: Marc Blanchet <marc.blanchet@viagenie.ca>
To: James Galvin <galvin@elistx.com>
Date: Thu, 05 Nov 2015 10:28:43 +0900
Message-ID: <1E948341-BA56-498F-8AF9-6382856B8265@viagenie.ca>
In-Reply-To: <A4E1F844-9D5E-43CD-B886-F5CB94809768@viagenie.ca>
References: <563AAC4F.6050907@elistx.com> <A4E1F844-9D5E-43CD-B886-F5CB94809768@viagenie.ca>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_MailMate_01109772-5216-4903-91C2-2D81973BBD8B_="
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.2r5141)
Archived-At: <http://mailarchive.ietf.org/arch/msg/eppext/ouE4fgfXAUWJG96XvgqjDR9OfoQ>
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:28:49 -0000
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 >> https://www.ietf.org/mailman/listinfo/eppext > _______________________________________________ > EppExt mailing list > EppExt@ietf.org > https://www.ietf.org/mailman/listinfo/eppext
- [eppext] final charter description James Galvin
- Re: [eppext] final charter description Marc Blanchet
- Re: [eppext] final charter description Marc Blanchet
- Re: [eppext] final charter description James Galvin
- Re: [eppext] final charter description Rik Ribbers
- Re: [eppext] final charter description Hollenbeck, Scott
- Re: [eppext] final charter description Marc Blanchet
- Re: [eppext] final charter description James Galvin
- Re: [eppext] final charter description Marc Blanchet
- Re: [eppext] final charter description James Galvin
- Re: [eppext] final charter description James Galvin
- Re: [eppext] final charter description Patrick Mevzek
- Re: [eppext] final charter description Andrew Newton
- Re: [eppext] final charter description Jacques Latour