IETF Logo Mail Archive

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

Barry Leiba <barryleiba@computer.org> Thu, 18 December 2014 21:09 UTC

Return-Path: <barryleiba@gmail.com>
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 AB19D1A1B94 for <weirds@ietfa.amsl.com>; Thu, 18 Dec 2014 13:09:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 nZa190vGZOzP for <weirds@ietfa.amsl.com>; Thu, 18 Dec 2014 13:09:27 -0800 (PST)
Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BD571A1B71 for <weirds@ietf.org>; Thu, 18 Dec 2014 13:09:26 -0800 (PST)
Received: by mail-la0-f50.google.com with SMTP id pn19so1763938lab.9 for <weirds@ietf.org>; Thu, 18 Dec 2014 13:09:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=MTvpQLBRRXZIsfqaWZ2g9gJwDFke8L6ehEkpcUasudo=; b=0V5ELBz84QXDNbABM5vJUkkndfsNjixhby4juD0slAcbBDAJu2egpYIoU3I3KBaNjc Wn7Z0sfBVrd6jsfvJdbdrSgsQ1zmYP7hnzRRJFmlw2TnDOVxUI4COWESLDP5L7xktsSW TIHvuICuEpvLQyGpgZ48jJTiHHGG79lEnelVZb1RFjndU8HWQmh4Hm1KEyqzm1GyoYrR KxHmgKv5OpIglnmEK1t6PZjA9FYtUF0WzJ+O72x9UpJOixmqRIea88nFLjPCvNb6WPrk UUgldvX7F8p6/Sj6Luiv4kQVbxrcxdUWWM25b+ggYWExtgfbRqKn+XjxyKu+MhHUCq85 VONA==
MIME-Version: 1.0
X-Received: by 10.112.41.168 with SMTP id g8mr4260758lbl.59.1418936965053; Thu, 18 Dec 2014 13:09:25 -0800 (PST)
Sender: barryleiba@gmail.com
Received: by 10.152.127.168 with HTTP; Thu, 18 Dec 2014 13:09:24 -0800 (PST)
In-Reply-To: <20141218205850.GH28899@x28.adm.denic.de>
References: <20141218193248.30639.20974.idtracker@ietfa.amsl.com> <0F70F800-D7F1-49AF-97D3-34568DFA3C9C@viagenie.ca> <20141218205850.GH28899@x28.adm.denic.de>
Date: Thu, 18 Dec 2014 16:09:25 -0500
X-Google-Sender-Auth: kF9mZcfM-3tXX5KfcAFlzOMkjCw
Message-ID: <CALaySJJ2FkkOE0L8EBbKmUnX5ukDN3RVpykC7XiT0wisP52dqg@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: Marc Blanchet <marc.blanchet@viagenie.ca>, Barry Leiba <barryleiba@computer.org>, 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>
Content-Type: text/plain; charset="ISO-8859-1"
Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/TUoxU6lvfmDwgolt1j1DHth1Aak
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:09:27 -0000

> to be established here is not even a registry, it is operational data
> (fed from existing registries coming from different, non-IETF IANA pillars).
> more like the DNS root zone than an IETF protocol parameters registry.
>
> Therefore what the IETF should do is specify the format only and let
> "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
it's important for this document (along with its normative references)
to provide the complete information necessary to create
implementations.

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

Barry

v2.23.0 | Report a Bug | By Email