Re: [eppext] Recharter Milestones discussion

Antoin Verschuren <> Fri, 04 December 2015 14:17 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B5FCF1A0031 for <>; Fri, 4 Dec 2015 06:17:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.083
X-Spam-Status: No, score=0.083 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id E5qbUgL1PruF for <>; Fri, 4 Dec 2015 06:17:21 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id E988D1A00E9 for <>; Fri, 4 Dec 2015 06:17:17 -0800 (PST)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id 32BA1280318 for <>; Fri, 4 Dec 2015 15:17:17 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=walhalla; t=1449238637; bh=qNgIkBTbAu0dv9bTJpSzx73dEtXxTsa961N8XVlfMyE=; h=Subject:From:In-Reply-To:Date:References:To:From; b=JMg4kXYM9mx9FV+8YJgmofI02IgRzIhs5R7U/hA/jyCLv1mSQez2izIca/3eTTl3y nxGdUfg6TrnIikt28rvd/YkR74Q87WMNiMIBJihoLFGSVmV9gWAqvm0TEZSxwTHK/B BUup5aGOxZCjbioL9HOhZ89z6TzbIoT55rUKUgUQ=
Content-Type: multipart/signed; boundary="Apple-Mail=_B29A7A1A-C780-4490-B31B-F2813B2C69E7"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Pgp-Agent: GPGMail 2.5.2
From: Antoin Verschuren <>
In-Reply-To: <>
Date: Fri, 04 Dec 2015 15:17:10 +0100
Message-Id: <>
References: <> <>
To: eppext <>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <>
Subject: Re: [eppext] Recharter Milestones discussion
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: EPPEXT <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 04 Dec 2015 14:17:27 -0000

Op 4 dec. 2015, om 13:22 heeft Rik Ribbers <> het volgende geschreven:

> All,
> General feedback: I don’t have a very strong opinion about priorities and order. If a document is ready for submission let’s just submit it and move on.

Hi all,

Some clarification on grouping of the milestones again then.
We need milestones in our charter. We cannot be a working group if we just say we will do some work but we don’t know what and when we will be finished.
We need deadlines on our documents so we can see if progress is as we want.
The chairs will use these deadlines to give guidance to the working group on priorities and things to work on.
We realize that we cannot work on 10 documents at the same time and demand they will all be done in Februari.
We simply don’t have the resources for that.

That does not mean we cannot work on documents in group 3 before the deadline.
If we’re done earlier with documents in group 3 because there happens to be momentum for one of the drafts that’s fine too.
But we cannot demand all the documents to be worked on at the same time.
That’s why we need to set reasonable deadlines on the milestones in our charter.

The only question we have now is if this is the set of documents we agree to work on, and if the milestones dates give a reasonable priority on what we want to work on first.

>> Group 1
>> -epp-rdap mapping (draft-gould-epp-rdap-status-mapping)
>> -verification code (draft-gould-eppext-verificationcode)
>> -nv mapping (draft-xie-eppext-nv-mapping)(Remains as Informational, but reviewed by WG)
> I  have a question about the verification drafts. During the Yokohama meeting someone (James Gould?) stated that the verification drafts should have the highest priority over others and somehow they ended up in group 1. What I missed is the reasoning why. There are other drafts that are longer part of this working group and deserve higher priority in my opinion (like resellers and change poll en the fees drafts). Can somebody explain the reasoning why these are (so) important.

[hat on]
The list of priorities only reflects what the working group suggested at the Yokohama meeting.
There was no objection during the meeting, but we said we would take the discussion to the list.
[/hat on]

[hat off]
I originally had the reseller draft in group 1 and the rdap mapping in group 2.
My reasoning being that the reseller draft is indeed more mature and has had more review, and more importantly, the rdap mapping seems to have been pushed in based on timelines set by ICANN more than by maturity or demand of the document in the IETF. I wonder if this will improve the quality of the document. We still have the tmch/launchphase/tmch-func-spec documents as leftovers to work on from our current charter, and looking at the IESG and IANA feedback on the tmch document, there is still quite some work to be done there which is also heavily reliant on ICANN staff. Perhaps the authors of these drafts can explain if there’s going to be extra resources from ICANN allocated to these drafts to have them all done within a month. But in my opinion it is more reasonable to work on the documents in an order that will allow for better review to improve the quality of the documents.
[/hat off]

>> -Relay (no draft yet, split from keyrelay)
> There is no document so there is no need to add it to the milestones. The charter is explicit enough to add any document if the WG thinks it is of value. Personally I don’t see this document happening very soon.

Note taken.

> Furthermore
> Will there be an individual call-for-adoption per document or if the document is on the charter it is adopted?

All the documents in the milestones will be adopted by the WG. So this is a call for adoption of all 10 documents.
Unless you state now that you don’t want to adopt document x in this list.

> In the last case. How are we going to make sure the documents get enough review before submission?

Most of the documents have already been discussed on the list.
For additional documents to be added to the milestones we will always ask for reviewers before we adopt a document as WG item.

> In the first case. Can we explicitly ask for reviewers and people willing to work on the document during the adoption?

A document can still fail after we decided to work on it.
Once we reach the deadline, we will ask the working group to review and comment, or remove the item from our milestones if it has failed.
We will always ask for explicit review before a document is last called, and we will ask for explicit comments if the chairs feel the document does not have enough support.

So let me ask differently: Which documents on the list do you want to work on or review?

- --
Antoin Verschuren

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