Re: [regext] DOODLE: select your documents

Alexander Mayrhofer <alexander.mayrhofer@nic.at> Thu, 03 January 2019 10:39 UTC

Return-Path: <alexander.mayrhofer@nic.at>
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 C991412D84D for <regext@ietfa.amsl.com>; Thu, 3 Jan 2019 02:39:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no
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 tgl5RBmYtvQA for <regext@ietfa.amsl.com>; Thu, 3 Jan 2019 02:39:48 -0800 (PST)
Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) (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 AC9D4128D0C for <regext@ietf.org>; Thu, 3 Jan 2019 02:39:47 -0800 (PST)
Received: from nics-exch2.sbg.nic.at ([10.17.175.6]) by mail.sbg.nic.at with XWall v3.53 ; Thu, 3 Jan 2019 11:39:44 +0100
Received: from NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57]) by NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57%12]) with mapi id 14.03.0415.000; Thu, 3 Jan 2019 11:39:42 +0100
From: Alexander Mayrhofer <alexander.mayrhofer@nic.at>
To: Tobias Sattler <sattler@united-domains.de>
CC: Registration Protocols Extensions <regext@ietf.org>
Thread-Topic: [regext] DOODLE: select your documents
Thread-Index: AQHUmUgpkh9yytrCLkqYAKEagX/Al6WdQQ0ggAABxwCAABmnkP///h4AgAARx5A=
Date: Thu, 03 Jan 2019 10:39:41 +0000
Message-ID: <19F54F2956911544A32543B8A9BDE0759FB9D251@NICS-EXCH2.sbg.nic.at>
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> <018CE7ED-7823-4D25-B82A-A86654B22EB4@united-domains.de>
In-Reply-To: <018CE7ED-7823-4D25-B82A-A86654B22EB4@united-domains.de>
Accept-Language: en-US, de-DE
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.10.0.110]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-XWALL-BCKS: auto
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/CnWRt0eklJxp-UCCMhnGfLlpO1M>
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:39:50 -0000

Hello Tobias,

trying to settle that with a few last words: 

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

[AM] Good to hear. I do agree that we have the same goal, only our paths differ :)
 
> 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.

[AM] I'm with you that some things (such as file formats) are not (much) related to policy, and can be agreed on the "more practical" layers.

> 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.

[AM] I do definitely agree. Policies should cover the high level requirements. Implementations are a different story, and happen on a different "layer".

> 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.

[AM] As i said, i do believe that if something is good, it will succeed naturally. Technical specifications can, of course, never overcome market considerations or practical considerations (such as available resources, or cost vs. effort considerations). No matter if they're an RFC or any other kind of specification. But that goes beyond the discussion on here.
 
> 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.

[AM] Maybe that's because now that's an internet draft (rather than an specification from somewhere else) the following text from RFC2026, page 7 applies?

      ********************************************************
      *                                                      *
      *   Under no circumstances should an Internet-Draft    *
      *   be referenced by any paper, report, or Request-    *
      *   for-Proposal, nor should a vendor claim compliance *
      *   with an Internet-Draft.                            *
      *                                                      *
      ********************************************************

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

[AM] Aiming at an RFC does not replace buy-in by the involved parties, i think that's what it boils down to... 

Best,
Alex