Re: [regext] DOODLE: select your documents

Tobias Sattler <sattler@united-domains.de> Thu, 03 January 2019 10:27 UTC

Return-Path: <sattler@united-domains.de>
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 D17A4130DD4 for <regext@ietfa.amsl.com>; Thu, 3 Jan 2019 02:27:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=united-domains.de
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 VxtfszuYEYxh for <regext@ietfa.amsl.com>; Thu, 3 Jan 2019 02:27:46 -0800 (PST)
Received: from falbalka.udag.de (falbalka.udag.de [82.135.96.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C04BD128D0C for <regext@ietf.org>; Thu, 3 Jan 2019 02:27:46 -0800 (PST)
Received: from ts-thunderbolt3-dock.starnberg.udag.de (TS-thunderbolt3-dock.starnberg.udag.de [10.30.1.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by falbalka.udag.de (Postfix) with ESMTPSA id 8132E1F600EB; Thu, 3 Jan 2019 11:27:44 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=united-domains.de; s=ud20150520; t=1546511264; bh=MtagL5djEKP/N/Zvzd/2/iD/t4+gdkm7BS/ugaQwnrE=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=p+1cysyCoHJX18QPD1RjBISoo49lAwGWMIoKADo4skCiBCjMDROLgb1aK+LaBzhvI w1rqDvXLkWzeH/WnqUqyzz1Ps6iQ3Y/Tbo++c2nc3kitWCLMhCFFltF3SAyz9+nf6P mlKdePyoeZTT8lQ5zBs/njrolr9JnvmI7nXZI42+mBONd0yAts+fipzh0elCiAx8Ht uTmjuvrqR7wBtJwkQjVBreCJLQnu2HdtaBbGO5/u7u9V+yVVuu4bTw/OXW4/k0sH71 iQTrPRc6/kS2VQVfB5WcpemfWIe/8JVIWqfiKx+bbrzxse/r4rvjIxWgCgJPQTom1W h3UpSSTVxIRyQ==
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
From: Tobias Sattler <sattler@united-domains.de>
In-Reply-To: <19F54F2956911544A32543B8A9BDE0759FB9D1CF@NICS-EXCH2.sbg.nic.at>
Date: Thu, 03 Jan 2019 11:27:44 +0100
Cc: Registration Protocols Extensions <regext@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <018CE7ED-7823-4D25-B82A-A86654B22EB4@united-domains.de>
References: <C95BDA53-5A54-42E0-A544-B6A061F073FB@elistx.com> <19F54F2956911544A32543B8A9BDE0759FB9D141@NICS-EXCH2.sbg.nic.at> <073466F0-ACF0-492A-87F9-D81577125314@united-domains.de> <19F54F2956911544A32543B8A9BDE0759FB9D1CF@NICS-EXCH2.sbg.nic.at>
To: Alexander Mayrhofer <alexander.mayrhofer@nic.at>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/niKPgq2MLp5igccuLBM4R3jymI4>
Subject: Re: [regext] DOODLE: select your documents
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: Thu, 03 Jan 2019 10:27:50 -0000

Hi Alex,

I think we're more or less on the same page.

Just so we don't misunderstand each other: It's not that we or I don't appreciate the work on policies or even want to deliberately avoid them.  However, they essentially refer to framework conditions only and not to explicit technical implementations. Btw. I don’t think it would be a great idea to create ICANN policies on how things have to be technical implemented in every detail. But you never know what's to come.

Of course, as a registrar you could also take the view that you are king as a customer. However, it is far from my intention to make demands based on a possible market position. That's not a good style. This is why the way via standardisation should be in the common interest, especially since all parties can participate in it.

Be that as it may, I think we could live without IETF standardization, but conversely it would not be fair if this were interpreted against us and an implementation will only rejected by registries because our proposals are not RFC’s. Funny enough that some registries are working with us on these drafts and are not implementing them yet due to the non-standardization.

For me, this is a bit like a vicious circle.

My two cents

Best,
Tobias

> On 3. Jan 2019, at 10:49, Alexander Mayrhofer <alexander.mayrhofer@nic.at> wrote:
> 
> Tobias,
> 
> Thanks for coming back to my "rant". A few observations inline: 
> 
>> However, nowadays most domain registries have withdrawn to the point of
>> implementing only their own ideas or approved RFCs. This inevitably leads to
>> the situation that proposals for improvement - whoever they come from -
>> either have to be solved via approved RFCs, in lengthy bilateral talks /
>> negotiations or through policy development.
> 
> [AM] You're unwittingly strengthening my arguments here. You're saying "we don't bother about what Standards Track implies. We just need that RFC number so that we can force the industry into doing what we want". Not because of the higher quality reviews involved in IETF work, the well established and accepted process to progress an Internet Standard, etc. It's just to "gold plate" a spec with a "label" that tricks people into believing it's actually important. 
> 
> And secondly, you're actually saying "we're doing this so that we can evade the policy development  and discussions around it". Wow. 
> 
>> The goal of the ICANN CPH TechOps Group was and is to address technical
>> and operational challenges and as there seems to be no other way we
>> decided to go for the standardized way. If the REGEXT Group thinks that an
>> individual submission with the status informational is sufficient and this is
>> fully supported by the domain registries, then I see no problem doing it this
>> way and we can save time and effort here.
> 
> [AM] I don't know what the group thinks, i'm speaking as an individual here, obviously. Escrow has been implemented widely, and never made it beyond an individual draft. So, it's possible without an RFC number. Yes, there was some force involved into that, obviously, but - on the contrary 
> 
>> Just let me know how you want to do it.
> 
> [AM] First, I'm not disregarding your (or someone else's) work. I have written enough specifications to understand the amount of work that goes into those documents. Ironing out the details once the first implementation is done, fixing contradictions with other specifications, ironing out late corner cases.. Tons of very very useful work.
> 
> [AM] Practically, CPH techops could perfectly publish all those file format specifications as their own documents (CPHT-001... CPHT-002... etc..).  If they are good and beneficial for both registrars and registries, implementation will follow. I'm the last one to oppose standardization in that area - quite the contrary, I can think of  (and I'm working on) standardization of more items (Registry Registrar Data Group, Registry Data Nerds, etc...) - but I wouldn't think of submitting the work there to the IETF. That's my only point.
> 
> Best,
> Alex
> 
> _______________________________________________
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext