Re: [weirds] Fwd: I-D Action: draft-ietf-weirds-bootstrap-11.txt

Peter Koch <pk@DENIC.DE> Thu, 18 December 2014 21:36 UTC

Return-Path: <peter@denic.de>
X-Original-To: weirds@ietfa.amsl.com
Delivered-To: weirds@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FD9A1A879B for <weirds@ietfa.amsl.com>; Thu, 18 Dec 2014 13:36:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level:
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 0JhMvUnvwC2Q for <weirds@ietfa.amsl.com>; Thu, 18 Dec 2014 13:36:43 -0800 (PST)
Received: from office.denic.de (office.denic.de [81.91.160.182]) (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 3A4921A879D for <weirds@ietf.org>; Thu, 18 Dec 2014 13:36:43 -0800 (PST)
Received: from office.denic.de (mailout1.denic.de [10.122.34.3]) by office.denic.de (Postfix) with ESMTPS id AB3A4240021; Thu, 18 Dec 2014 22:36:30 +0100 (CET)
Received: from x27.adm.denic.de (x28.fra2.if.denic.de [10.122.64.17]) by office.denic.de with esmtps (TLSv1:AES256-SHA:256) id 1Y1ikI-0000Tm-GB; Thu, 18 Dec 2014 22:36:30 +0100
Received: from localhost by x27.adm.denic.de with local id 1Y1ikF-0003PC-AH; Thu, 18 Dec 2014 22:36:27 +0100
Date: Thu, 18 Dec 2014 22:36:27 +0100
From: Peter Koch <pk@DENIC.DE>
To: Barry Leiba <barryleiba@computer.org>
Message-ID: <20141218213627.GI28899@x28.adm.denic.de>
Mail-Followup-To: Barry Leiba <barryleiba@computer.org>, Marc Blanchet <marc.blanchet@viagenie.ca>, Pete Resnick <presnick@qti.qualcomm.com>, "Murray S. Kucherawy" <superuser@gmail.com>, Michael Szucs <mszucs@afilias.info>, "draft-ietf-weirds-bootstrap.all@tools.ietf.org" <draft-ietf-weirds-bootstrap.all@tools.ietf.org>, "<weirds@ietf.org>" <weirds@ietf.org>
References: <20141218193248.30639.20974.idtracker@ietfa.amsl.com> <0F70F800-D7F1-49AF-97D3-34568DFA3C9C@viagenie.ca> <20141218205850.GH28899@x28.adm.denic.de> <CALaySJJ2FkkOE0L8EBbKmUnX5ukDN3RVpykC7XiT0wisP52dqg@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CALaySJJ2FkkOE0L8EBbKmUnX5ukDN3RVpykC7XiT0wisP52dqg@mail.gmail.com>
User-Agent: Mutt/1.4.2.3i
Sender: Peter Koch <peter@denic.de>
Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/_ra6JXf_O9S6-gaAnI-RztJj5vk
Cc: Pete Resnick <presnick@qti.qualcomm.com>, "<weirds@ietf.org>" <weirds@ietf.org>, "draft-ietf-weirds-bootstrap.all@tools.ietf.org" <draft-ietf-weirds-bootstrap.all@tools.ietf.org>
Subject: Re: [weirds] Fwd: I-D Action: draft-ietf-weirds-bootstrap-11.txt
X-BeenThere: weirds@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" <weirds.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/weirds>, <mailto:weirds-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/weirds/>
List-Post: <mailto:weirds@ietf.org>
List-Help: <mailto:weirds-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/weirds>, <mailto:weirds-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Dec 2014 21:36:49 -0000

On Thu, Dec 18, 2014 at 04:09:25PM -0500, Barry Leiba wrote:

> > "the other entity" (aka ICANN) describe (in an RFC, independent submission stream)
> > the operational details of the initial "hook".
> 
> I would be happy with that alternative, as long as it's a normative
> reference, which this document would then have to wait for.  I think

while processing them in prallel at the RFC Editor is a good idea,
I think not only should there be no normative reference (downref to Informational,
not necessary to understand the protocol spec, not even to implement it because what's
provided in the "companion" RFC is config data) but probably none
at all, simply because the IETF might not need to take a position here _and_
the protocol work is done by specifying the format.  But I could understand
the desire to provide some guidance in an appendix _with_ a pointer to the 2nd RFC.

> I'm not sure we want to delay things for that, but you're welcome to argue it.

I'd not argue in favor of delay, but definitely for said separation.
I can't write the second document because "I'm not ICANN" ...

-Peter