Re: [regext] WGLC redux: REGEXT working group charter

"Gould, James" <jgould@verisign.com> Fri, 14 September 2018 15:57 UTC

Return-Path: <jgould@verisign.com>
X-Original-To: regext@ietfa.amsl.com
Delivered-To: regext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F02CA1200D6 for <regext@ietfa.amsl.com>; Fri, 14 Sep 2018 08:57:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.com
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 6Ac75x5pHvwx for <regext@ietfa.amsl.com>; Fri, 14 Sep 2018 08:57:23 -0700 (PDT)
Received: from mail6.verisign.com (mail6.verisign.com [69.58.187.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 259C1128CB7 for <regext@ietf.org>; Fri, 14 Sep 2018 08:57:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=38420; q=dns/txt; s=VRSN; t=1536940643; h=from:to:date:message-id:mime-version:subject; bh=y1tyEhglY//KkLBArNiU4jju2syKinaeGLuORcB8WYE=; b=kui1kVjEvo/zn4U58GB+iUdctHb+laPpAUOY+oXsTaDhJHUImhmNzenc 6KPj0B1VPuxMkemvPnOvIRJdb+ddTCMpZbJMb9H2i64Dxx9pw/uxk4IGW 8EHpQkNXMg1oPJPhiRCwSOH7lmE1lxgGPOuLQ+m2lx0vYAZVXWHGuQH6O 3lAWGDrm4/pEJcWVjuwTQWvzk/pBOoqm9OfiJ4JOdukfgRC4AkW4f5z1j Tqu7ak69LwLg+xxCMp1T9WEEN75y6CjJn46CUv56RmGdPdh3xyPW+aB9M w0CIeBlS5pdaOU5XSHoQNU6i8X2rOA9Xu0wkRoM2kleZQV7t9VUwuw+Yc A==;
X-IronPort-AV: E=Sophos;i="5.53,373,1531800000"; d="png'150?scan'150,208,217,150";a="5691045"
IronPort-PHdr: 9a23:M/NvUxH2p8bJzX2jduGmdZ1GYnF86YWxBRYc798ds5kLTJ76p8S+bnLW6fgltlLVR4KTs6sC17KJ9fi4EUU7or+5+EgYd5JNUxJXwe43pCcHRPC/NEvgMfTxZDY7FskRHHVs/nW8LFQHUJ2mPw6arXK99yMdFQviPgRpOOv1BpTSj8Oq3Oyu5pHfeQpFiCa/bL9oMBm6sRjau9ULj4dlNqs/0AbCrGFSe+RRy2NoJFaTkAj568yt4pNt8Dletuw4+cJYXqr0Y6o3TbpDDDQ7KG81/9HktQPCTQSU+HQRVHgdnwdSDAjE6BH6WYrxsjf/u+Fg1iSWIdH6QLYpUjmk8qxlSgLniD0fOjA57m/Zl9BwgqxYrh2vphxw34HbbZqPNPZie6PQZ88WSHBDU8tXSidPApm8b4wKD+cZM+pWro79p0YKrRSjHQWnGefhxSVNhnDoxq023fkqHAbE3AwvGNIOrXDUo8juOacMT++11qjIzS7Cb/NZ3zfx8pTHchckofyVW797bMTfyU4qFwzfj1WQr5ToPy2L2eQXsmib9OtgVe2pi2I9tw5xpT2vyt8yiobXnIIVy0vE9SR2wIYzJN24TlJ0bcS4H5tXsiGWL4p2Td0+Q2Fmoio6zacGuZG9cSMXy5on3wbSZ+Gbf4SS/x7uVuicLS1liH9ldr+znRm//Ey4xuHhSsW4yktGoyhZntXWq3wA2B/e5tKaRvZ+5kuh1yiA2gPP5uxBJE07j6nWJpo6zbM1mJcfr1nMEy7zlUrtiKKbd0cp9+2m5unpYLjpu5mRPJJuhA7kKKQhgMm/DPw9MggJQmeU5/yx1Kbm/U3lWLVKieA2krXBvJDaO8sboqm5DhdI34g/8xizEjep3swXk3YGMF5JZgiLj5b1NFHJOvD4Fe2zjE6xnztx2fDGJKbhApPXInffl7fheK5x609ayAUt0dBS/49YBq0bLP7uWEL8usbUAgI5PgG62erqB9Fw2psbWW2VA6+ZNK3SsUWP5uIqO+SMZoAVuDHgK/gh+vHjlmE5lkEHfamoxpsXaX+4HvJ8L0qFZnrsh88NEX0WsQomUOzqlFqCXCZRZ3axWKI84jI7B5y8DYrYSYCth6GO0z2mEZJLZmFKEEyDEXDtd4+cQfcDdDqSItN9kjwDTbWhSpEu1Q2gtALh0bVnKPbU+ioZtZLlztR14enTnwko9TNoF8Sdz32NT2Zsk2MSWTA2075woENhylqY0Kh3neBYFdJJ6/NOSAc6Os2U8+svQdLxXQbCc82hR1GqS9mqEHc6Sdd7i4sMYEF5GNi4ph/E0yOmD65TnLuOUth8uKPRw3bZLsBhzHfAkq8lxRFyQ8ZTO0WvgLJ49g6VAYqf1w3TjauleLQA9C/A6GnFynCB9gkMSgN/XLXZdXESekWQqs72sBDsVbirXP4INRZFxYrKCKJPZ8ajxQFES/D+PNj2fW+rmnyxChDOzbSJOtm5M14B1TnQXRBX2zsY+myLYFAz
X-IPAS-Result: A2FMAQC52Ztb/zGZrQpYAxwBAQEEAQEKAQGBUYEQSIEUgScKg2iWS4MAhV6NY4E/Fx0DBAgBAhgBCguDeEYCF4NpNRcBAwEBAQEBAQIBAQKBBQyCNSIRLxwvCQEFAQEBAQEBJwEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQgCCAc1EgEBGAEBAQEDAQEDAR0CAgYBQB0BCBEDAQEBBgEBARgHAwIEBRABCQUBCxQJCgQBEQEGCIMTAYFpAySkenszhycNgkAPin+BQj6BEicfgkyCVkUBAYE6PgkBFRGCOjGCJgKNQYVng0yBP4NVLAMGAoVfAVqGQYMugguMeocHhE0Da4dbAgQCBAUCFIFEA4IJcBU7KgGCQQmCHBeDRYUUhT5vAQwki32BLoEeAQE
Received: from BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) by BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1531.3; Fri, 14 Sep 2018 11:57:18 -0400
Received: from BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d]) by BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d%5]) with mapi id 15.01.1531.003; Fri, 14 Sep 2018 11:57:18 -0400
From: "Gould, James" <jgould@verisign.com>
To: "jkolker@godaddy.com" <jkolker@godaddy.com>, "ietf@antoin.nl" <ietf@antoin.nl>, "regext@ietf.org" <regext@ietf.org>
Thread-Topic: [EXTERNAL] Re: [regext] WGLC redux: REGEXT working group charter
Thread-Index: AQHUTEOd+UwepmTTEUWcYJb5piUdig==
Date: Fri, 14 Sep 2018 15:57:18 +0000
Message-ID: <4D69E480-428E-41E4-AF03-8EC298E023FD@verisign.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.f.0.180709
x-originating-ip: [10.170.148.18]
Content-Type: multipart/related; boundary="_004_4D69E480428E41E4AF038EC298E023FDverisigncom_"; type="multipart/alternative"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/WXbfhT-upcdTTX2T8XRQIsSQFlc>
Subject: Re: [regext] WGLC redux: REGEXT working group charter
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Registration Protocols Extensions <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>, <mailto:regext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext/>
List-Post: <mailto:regext@ietf.org>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>, <mailto:regext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Sep 2018 15:57:26 -0000

Related to bullet #2, I’m hoping that it addresses file formats such as:


  1.  Data Escrow File Format (draft-arias-noguchi-registry-data-escrow and draft-arias-noguchi-dnrd-objects-mapping)
     *   This format is associated with data escrow deposits from registration entities (registry, registrar, privacy and proxy services) to data escrow providers.  Can a data escrow provider be considered a registration entity?
  2.  Data Set File Format (draft-gould-regext-dataset)
     *   This format is primarily meant to be between registrar and registry; although a 3rd party can generate a signed data set.

—

JG

[cid:image001.png@01D255E2.EB933A30]

James Gould
Distinguished Engineer
jgould@Verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com<http://verisigninc.com/>

From: regext <regext-bounces@ietf.org> on behalf of Jody Kolker <jkolker@godaddy.com>
Date: Friday, September 14, 2018 at 11:15 AM
To: Antoin Verschuren <ietf@antoin.nl>, Registration Protocols Extensions <regext@ietf.org>
Subject: [EXTERNAL] Re: [regext] WGLC redux: REGEXT working group charter

Since EPP and RDAP is included in this paragraph:

<<
The working group may also take on work to develop specifications that
describe the following types of information exchanged between entities
involved in Internet identifier registration that are using the RDAP or
EPP protocols:
>>

Can this paragraph be updated to:
<<
*Uniform representation formats for publishing local policy or
 configuration options between registration entities.
*Data formats for files exchanged between registration entities.
*Technical guidance for registration processes between registration entities.

>>

The reason for changing the 2nd bullet “*Data formats for files exchanged between registration entities that
 need insertion in or extraction from EPP or RDAP.”  Is that the data reports are not downloaded via EPP or RDAP.

Thanks,
Jody Kolker

From: regext <regext-bounces@ietf.org> On Behalf Of Antoin Verschuren
Sent: Friday, September 7, 2018 9:20 AM
To: Registration Protocols Extensions <regext@ietf.org>
Subject: Re: [regext] WGLC redux: REGEXT working group charter

Alex,Patrick,

Thank you for your comments. You made some good suggestions.
I agree the scope of the bulletpoints are not that clear and not scoped narrow enough for people not in this working group and not knowing which documents we discussed.
How about changing the last paragraph with bulletpoints to this:

---
The working group may also take on work to develop specifications that
describe the following types of information exchanged between entities
involved in Internet identifier registration that are using the RDAP or
EPP protocols:

*Uniform representation formats for publishing local policy or
 configuration options regarding EPP and RDAP use.
*Data formats for files exchanged between registration entities that
 need insertion in or extraction from EPP or RDAP.
*Technical guidance for registration processes that are supported by
 EPP or RDAP.
—

To explain out thinking:
The “registry mapping” and similar documents will fall under bulletpoint 1
The draft-gould-regext-dataset and similar documents will fall under bulletpoint 2
The “dnsoperator-to-rrr-protocol” and similar documents will fall under bulletpoint 3

If you agree to this text, than we will change that in the version we resend to the IESG for reconsideration.

- --
Antoin Verschuren

Tweevoren 6, 5672 SB Nuenen, NL
M: +31 6 37682392






Op 3 sep. 2018, om 17:31 heeft Alexander Mayrhofer <alex.mayrhofer.ietf@gmail.com<mailto:alex.mayrhofer.ietf@gmail.com>> het volgende geschreven:

Hello everyone,

tl;dr - i do agree with all what Patrick said - more inline

On Fri, Aug 31, 2018 at 10:46 PM Patrick Mevzek <pm@dotandco.com<mailto:pm@dotandco.com>> wrote:


And I still think it is too broad, especially "Data formats for files"
(which files? what data? why the format needs a specification and a working group?).
"Registry mapping" and "Registry transition" will probably seem obscure to anyone
outside of the working group. I am myself not even sure what it covers or not.

I do agree to these points. For a charter, i think the functional area
would be required, and if there wasn't a draft names "registry
mapping", i wouldn't know what it meant (quite blunt: would this
covering the creation of a geographic map of all EPP/RDAP accessible
registries? ;)

Some (hopefully more productive) thoughts:

"Data format for files" -> Data format, yes, but only in the scope of
EPP/RDAP registries and between the involved parties. Limited to
frequent cases of such data exchange.

"Registry mapping" -> Representation of configuration options for
EPP/RDAP registries.

"Registry transition" -> not sure what we should standardize here... a
process? Data beyond escrow?

I understand the intention behind all these, but it seems to me those
reflect milestones rather than an abstract charter strategy.

best,
Alex

_______________________________________________
regext mailing list
regext@ietf.org<mailto:regext@ietf.org>
https://www.ietf.org/mailman/listinfo/regext