Re: [DNSOP] I-D Action: draft-ietf-dnsop-alt-tld-05.txt

Warren Kumari <warren@kumari.net> Mon, 26 September 2016 20:19 UTC

Return-Path: <warren@kumari.net>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1212D12B026 for <dnsop@ietfa.amsl.com>; Mon, 26 Sep 2016 13:19:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com
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 DUpnPr56hKbg for <dnsop@ietfa.amsl.com>; Mon, 26 Sep 2016 13:19:04 -0700 (PDT)
Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BDA112B007 for <dnsop@ietf.org>; Mon, 26 Sep 2016 13:19:04 -0700 (PDT)
Received: by mail-qk0-x236.google.com with SMTP id g67so120313457qkd.0 for <dnsop@ietf.org>; Mon, 26 Sep 2016 13:19:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=223RZQsMVst9Mn8RaUmZcnW4OFsidMyp8UegpnSK7rI=; b=Jdbp4sn08/ASOnuIwk8g1/P9PzyrZoXyd+jlnFH65vlMAIE2MgUMrFco6Oe9Xvz2wJ 4z+QNHmxhfQcK7AWdh1UqCd3DQ+kaFh/bgi9btFNekgQIi9h6k33U4ZpoMG5q9U9uGZs LKNkj8/dDfLsAsolagT9vb2BKBoTJjPP/X6jfSqPd6WzXcSJGTJMVVJVh+W4IjdL7dqR vwAPKzLjKRXInMrksv3Dk5fYzE9henaY6DU5UcNu4SxgutA3Sx3hw+x/2Zzpl0d4aybx 65Q8q1N9pU7BLY+5J6rmoSJIqxymoszay8X2yt6DGt1+ec5W7lxCdiXaz//Mdg6HBA3d iNag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=223RZQsMVst9Mn8RaUmZcnW4OFsidMyp8UegpnSK7rI=; b=ECmjdodhqk5x+cufcM9EEeBtSF8ufaiRHg3olvdqbDTvlZ29otse1YVIRa56QxE6Dg Olcnj0DXAGpBk80Th/QKxKI4tGLHWWNit8QaSZnncgisN/qCXZ7IucpeRtGE0aqeqkIE WtJsbtVvVPJ5tOZAy/5UdUtMOsZH03NrGNZzunDk8aF45foBk5tAtndDTbB/YtO7N9no 45UcG20JWEcA5yix3N6HQrKZg9N2BE9MlM7P/SeO/eGdIBo+o3KKmY9l6Zjvj8K5xFVf rUW6uXk5q1LWUROFY/JtrZL5717tbrSj+WIwEbKkThjLZTbCEW8QpmlWYYU8NlYR7dQm 1JNg==
X-Gm-Message-State: AA6/9Rl5Yekcx73hXw7wSsL8BdoGhGPD12EdiT/NXbcjWlm+PIpPkjpaJiTpcfU1cV9cYUrAkTP68yKffOXRpLaz
X-Received: by 10.55.175.134 with SMTP id y128mr22565417qke.134.1474921143369; Mon, 26 Sep 2016 13:19:03 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.147.196 with HTTP; Mon, 26 Sep 2016 13:18:32 -0700 (PDT)
In-Reply-To: <20160925162537.GA14945@laperouse.bortzmeyer.org>
References: <147368142586.14471.16897934069436083953.idtracker@ietfa.amsl.com> <20160925162537.GA14945@laperouse.bortzmeyer.org>
From: Warren Kumari <warren@kumari.net>
Date: Mon, 26 Sep 2016 16:18:32 -0400
Message-ID: <CAHw9_iKopM+n2t2v2v98aoqDV6LGkVrou+jiBkyQj4ZcMmaYQA@mail.gmail.com>
To: Stephane Bortzmeyer <bortzmeyer@nic.fr>
Content-Type: text/plain; charset=UTF-8
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/LAj-YckYKFEhSvb7OsxtFiHn8T8>
Cc: dnsop <dnsop@ietf.org>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-alt-tld-05.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Sep 2016 20:19:08 -0000

On Sun, Sep 25, 2016 at 12:25 PM, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
> On Mon, Sep 12, 2016 at 04:57:05AM -0700,
>  internet-drafts@ietf.org <internet-drafts@ietf.org> wrote
>  a message of 48 lines which said:
>
>>         Title           : The ALT Special Use Top Level Domain
>>         Authors         : Warren Kumari
>>                           Andrew Sullivan
>>       Filename        : draft-ietf-dnsop-alt-tld-05.txt
>
> The previous versions were, and I think it was good, carefully
> non-normative. .ALT was presented (as it should) as a MAY, not a MUST
> or a SHOULD. Now, sentences like "This document provides a solution
> that may, in many cases, be more appropriate than [RFC6761]." are,
> IMHO, too much. I suggest "This document provides, in some cases, an
> alternative solution to [RFC6761]"

I'm fine with that[0]. Please keep in mind that this document has been
around since early 2014, and has gone through many revisions (11, 6 as
an individual, and 5 as a WG doc). Since 2015-11-17 it has been a
"Parked WG Document" ("Waiting for the 6761 design team to sort out
the bigger issues before moving this forward.").
It was started before there had been much discussion on the Special
Use Names problems (draft-adpkja-dnsop-special-names-problem and
draft-tldr-sutld-ps were not even twinkles in the author's eyes), and
so it contains much background and discussions which may no longer be
needed - I've been told that this will finally be unparked as soon as
a decision is made on the problem statement, and we'll be happy to
revise it then.

>
> Also, disparaging terms like "pseudo-TLD" should be avoided. "Non-DNS
> TLD" is sufficient.

"pseudo-TLD" was in no way intended to be disparaging -- we had
defined it as "A label that appears in a fully-qualified domain name
in the position of a TLD, but which is not registered in the global
DNS.". Again, this was started in 2014 - there hadn't been much
discussion at this point. I really don't like "Non-DNS TLD", but I
also don't really like "pseudo-TLD" -- once we are allowed to make
proper edits to it again we'll happily put in whatever the WG wants --
and, suggestions welcome....

>
>> This label is intended to be used as the final (rightmost) label
>
> No. It is rightmost only in LTR scripts. "final" is correct,
> "rightmost" isn't. Please delete it.
>
>> For example, a group wishing to create a namespace for Friends Of
>> Olaf might choose the string "foo"
>
> If this namespace uses a non-DNS protocol for resolution, it may be
> case-sensitive and therefore it should be "FoO". (Yes, this was a
> troll.)

... was it? It raises an interesting point - seeing as alternate
resolution contexts are likely to want to have their names be able to
be used anywhere where a "traditional" DNS names is used, they will
likely also be (ASCII) case insensitive, because some apps likely
flatten case before handing to a resolver system. But, this seems like
a decision that the resolution system designed could make - perhaps it
is worth mentioning (again, once unparked) in the doc.
foo.alt MAY be different to foO.alt... perhaps....

Anyway, I'm really trying to stay away from solution discussions until
a problem statement is adopted....

W
[0]: We had been asked to put in the original text, but we will (of
course) do whatever the WG wants.

>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf