Re: [regext] [Ext] AD review of draft-ietf-regext-tmch-func-spec-08

Gustavo Lozano <gustavo.lozano@icann.org> Thu, 23 July 2020 22:19 UTC

Return-Path: <gustavo.lozano@icann.org>
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 378BD3A077A; Thu, 23 Jul 2020 15:19:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 i5rcnPhE2wDd; Thu, 23 Jul 2020 15:19:32 -0700 (PDT)
Received: from ppa3.lax.icann.org (ppa3.lax.icann.org [192.0.33.78]) (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 D3EFC3A0772; Thu, 23 Jul 2020 15:19:32 -0700 (PDT)
Received: from MBX112-E2-CO-1.pexch112.icann.org (out.mail.icann.org [64.78.33.7]) by ppa3.lax.icann.org (8.16.0.42/8.16.0.42) with ESMTPS id 06NMJVRF003868 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 23 Jul 2020 22:19:31 GMT
Received: from MBX112-W2-CO-2.pexch112.icann.org (10.226.41.130) by MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.595.3; Thu, 23 Jul 2020 15:19:30 -0700
Received: from MBX112-W2-CO-2.pexch112.icann.org ([10.226.41.130]) by MBX112-W2-CO-2.pexch112.icann.org ([10.226.41.130]) with mapi id 15.02.0595.003; Thu, 23 Jul 2020 15:19:30 -0700
From: Gustavo Lozano <gustavo.lozano@icann.org>
To: Barry Leiba <barryleiba@computer.org>, "draft-ietf-regext-tmch-func-spec.all@ietf.org" <draft-ietf-regext-tmch-func-spec.all@ietf.org>
CC: regext <regext@ietf.org>
Thread-Topic: [Ext] [regext] AD review of draft-ietf-regext-tmch-func-spec-08
Thread-Index: AQHWYTI2sfJPeiaRUkSHXyOsOZ6cUqkVvEWA
Date: Thu, 23 Jul 2020 22:19:30 +0000
Message-ID: <C032D118-90D2-4437-901F-F283E749A117@icann.org>
References: <CALaySJKMQ9Ktg-voR-WDjRU+QvdSCS0GZ1C78+maMsYuWo4vbQ@mail.gmail.com>
In-Reply-To: <CALaySJKMQ9Ktg-voR-WDjRU+QvdSCS0GZ1C78+maMsYuWo4vbQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.38.20061401
x-originating-ip: [192.0.32.234]
x-source-routing-agent: Processed
Content-Type: text/plain; charset="utf-8"
Content-ID: <5037FF14133BF24E94E7FD613A084AA4@pexch112.icann.org>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-23_09:2020-07-23, 2020-07-23 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/ewEcvYl65OqqByf1BszVDaiouYw>
Subject: Re: [regext] [Ext] AD review of draft-ietf-regext-tmch-func-spec-08
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, 23 Jul 2020 22:19:34 -0000

Thank you Barry,

If memory serves, during a past REGEXT meeting about informational I-Ds and working groups, the conclusion was that a WG could adopt an I-D with an informational intended status. For this I-D, the idea is to get a stable reference. The specification described in this I-D was defined using an open process in which Registries (some of which continue to participate in this WG) provided feedback.

Certainly, changes to the specification are likely unfeasible to be implemented. If an Independent Submission is the appropriate path, I don't see any issues as long as an stable reference exists for the I-D.
 
To provide context, during the ICANN - new gTLD program, the operational guideline was that technical specifications linked from the registry agreement should be IETF I-Ds.

Regards,
Gustavo

On 7/23/20, 13:45, "regext on behalf of Barry Leiba" <regext-bounces@ietf.org on behalf of barryleiba@computer.org> wrote:

    First: Please accept my apology for the delay in handling this
    document.  It's been a particularly busy time for the ADs, and I've
    let this slip for a lot longer than I'd thought it would.

    My main comment about this document is that I find it odd as a working
    group document: it strikes me as something that ought to be published
    by ICANN as a policy document, not as something that should come out
    of an IETF working group.  An alternative path in the RFC series would
    be through the Independent Stream, which allows publication of
    Informational documents without getting IETF consensus.

    What, exactly, would IETF consensus mean for this document.  As it's
    describing an operational external system, we don't really have the
    ability to change it.  All we can do is decide to publish it... or
    not, yes?

    I think it will be very hard to sell this to the IESG.  Will the
    working group consider an alternative path for publishing this (ICANN
    or the ISE, or something else)?

    Barry

    _______________________________________________
    regext mailing list
    regext@ietf.org
    https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/regext__;!!PtGJab4!v1qV2GrUORtkAz_QQzBbUadAutB25cxVjbKnfDfWNJlaimu2Vk4BFU2dhV_3ECCMw-HJA4BfZDc$