Re: [DNSOP] Minor editorial change to draft-ietf-dnsop-sutld-ps
Warren Kumari <warren@kumari.net> Wed, 05 July 2017 12:55 UTC
Return-Path: <warren@kumari.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1A55131CE9 for <ietf@ietfa.amsl.com>; Wed, 5 Jul 2017 05:55:30 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] 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 xpFXWnqo_-Ip for <ietf@ietfa.amsl.com>; Wed, 5 Jul 2017 05:55:28 -0700 (PDT)
Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (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 A2D42131CE0 for <ietf@ietf.org>; Wed, 5 Jul 2017 05:55:28 -0700 (PDT)
Received: by mail-ua0-x22a.google.com with SMTP id z22so142508459uah.1 for <ietf@ietf.org>; Wed, 05 Jul 2017 05:55:28 -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=JcK5DwVaN8MW5LeAtVce4f8DXWrqzgokZ1RVG96mwGA=; b=Shh1G92JEHwQ0i/6ggXzvC/ompL1F8BJhrJJYaTP7ZdUGdX8+dsyiqMvK4U39hJLuP gdfgB8aJ6hD1ae++zJIOnx23etT3Hwyk5zbXt0XquYCyHEv3Ivj+S/U1weH6+yckuOuO 8l6AKKQmWf34rMJOgAMEifqtuYnAGleKxmqBKQlJ7S9pz1itFw3DtbKT2PFdNjGkEEIx 4AXLUZBVlk8M70/eym4pvinx2B9C8B1HY/mgWsLEbdrp2WqMgzbAe/0yRG0UGdNLA4Jz K6hORs5SxIIweeOLSNtlQi/qZ0IvryVj6i/mvQ+FeeVg0AmuxfS4avUIYFnWSrX5W2QJ oNIQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JcK5DwVaN8MW5LeAtVce4f8DXWrqzgokZ1RVG96mwGA=; b=ojbAO0DKZv1Bad64cYT/bkGO/nbmd2lenX5eQbQMu8joC1FHmje8XOwJqlZkvZ2Yb9 GwJGiAQ4KNB4odmkIvezJkygoH0YFliBJoyV8SWv4Ec7JL3poxQhKfT8F8bCYO+N5xJC jYGLW3Syff2+VA1cNHJvM6TW0OR1brrtj35YrUoARxnwzfu3pxlCW8jyyAngOou6mx+P VBOdV7gPDDxtJzhFmk3Sxn7fXGx6onH/vf4IZj0O0pYdAvd9D8cc1v1Zfqk2JjFdotqm SqOY4bBo8wGjjP4cDmYqEGP5v2rf+G9UlQPYgFmadHKvfBktSYGUnEFQtuMwxZq+e2M1 zR/w==
X-Gm-Message-State: AIVw111T+W0Vxabu9bOv/IId7MnW6omZlOHVY+f0Bo5VlYS/vfVj1uTi TDL9wTy/UjtmZ4BtfCVA6cX8kEupuzYQ
X-Received: by 10.159.58.97 with SMTP id r33mr17831231uag.110.1499259327583; Wed, 05 Jul 2017 05:55:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.159.39.165 with HTTP; Wed, 5 Jul 2017 05:54:47 -0700 (PDT)
In-Reply-To: <CACfw2hjahuUH=xnBPpP80NteEjyBB1aWp4hk_xpoQ6Vw12TWhA@mail.gmail.com>
References: <CAHw9_iJQ31wqLavOhtMpPOBhGP4j6CLk45KHGdX5vOA+qj4nQA@mail.gmail.com> <m2a84kzm4y.wl-randy@psg.com> <F98FEA1C-3F3F-4344-8B07-996AAD899CC2@fugue.com> <m2shicxr0h.wl-randy@psg.com> <A70FD34B-000A-4748-B1B2-BF6DF66C7D6C@fugue.com> <m2podgxq97.wl-randy@psg.com> <5F120298-CD66-4CB6-9DC5-0C5DF6F02CC7@fugue.com> <CACfw2hhx+-Z=7ZnnaOkToc+Bd7aKDpBFt+nFUxkt9sKqLn4D8Q@mail.gmail.com> <2DF1AFC7-643B-4610-8EB8-0616D3D0B024@fugue.com> <20170705000229.5918D7D8457F@rock.dv.isc.org> <CACweHNCAi7JcOW9CX=6FViv1wUoe5fhn7deJ2eieP2-D_FhaSA@mail.gmail.com> <CACfw2hjahuUH=xnBPpP80NteEjyBB1aWp4hk_xpoQ6Vw12TWhA@mail.gmail.com>
From: Warren Kumari <warren@kumari.net>
Date: Wed, 05 Jul 2017 08:54:47 -0400
Message-ID: <CAHw9_iJSWQNotk1hO8WY6SA99NgZHj290G9q2XyQwfaqOtp3gg@mail.gmail.com>
Subject: Re: [DNSOP] Minor editorial change to draft-ietf-dnsop-sutld-ps
To: william manning <chinese.apricot@gmail.com>
Cc: Matthew Kerwin <matthew@kerwin.net.au>, dnsop <dnsop@ietf.org>, IETF Rinse Repeat <ietf@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/cDs8gE1SaA3gYkVXKtbhcQIH7fQ>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Jul 2017 12:55:31 -0000
Been trying to figure out where to insert this. https://tools.ietf.org/html/draft-sullivan-dns-class-useless-03 Abstract Domain Name System Resource Records are identified in part by their class. The class field is not effective, and it is not used the way it appears to have been intended. This memo suspends additions to the DNS class registry pending greater clarity on how classes might be used, and until such clarification requires those defining new RRTYPEs to define them for all classes. Answer wrote a draft about this a few months / years ago. W On Tue, Jul 4, 2017 at 10:36 PM, william manning <chinese.apricot@gmail.com> wrote: > Most of the other application (besides dns) presume a single class, IN, > hence the URL presumption of "DNS name" will -always- be in the IN class. > Technically imprecise and sloppy, but pragmatically it works... until some > loons come along and do something creative with classes. Then all bets are > off. > RFC 1034 also uses IN in its examples and most folks forget inheritence > rules. > > /Wm > > On Tue, Jul 4, 2017 at 7:23 PM, Matthew Kerwin <matthew@kerwin.net.au> > wrote: >> >> On 5 July 2017 at 10:02, Mark Andrews <marka@isc.org> wrote: >> > >> > Who owns a name is a different question to what machines serve the >> > <name,type,class> tuple and how do you reach those machines. There >> > is absolutely no reason why the zones <name,IN> and <name,CLASS56> >> > need to be served by the same machines. There is a argument for >> > them both being under control of the same people. >> > >> > Mark >> > >> >> Hi, I'm jumping in at a random time with a possibly dumb question, but >> the talk of <name,type> and <name,type,class> tuples got me wondering >> about representation in general, and URLs in particular. >> >> RFCs 3986 and 7230 say[*] that every 'host' in a HTTP URL that looks >> like a DNS name is a DNS name, and that they have to be resolved to IP >> addresses if you want to fetch them, but they don't talk meaningfully >> about how to do that resolution. Given that we always assume class=IN >> (not to mention type=A|AAAA via happy eyeballs), how would we go about >> practically presenting an alternative class in things like URLs? >> (Registering a new "alt-http" URL scheme doesn't strike me as a great >> idea.) >> >> Because it's all well and good setting up your own .org hierarchy >> under class=FOO or whatever, but there's not much point if you can't >> send people to www.not-icann.org using it. Unless you don't want to >> expose your new hierarchy to the web ...? >> >> Cheers >> >> >> [*] https://tools.ietf.org/html/rfc3986#section-3.2.2 : >> >> """A registered name intended for lookup in the DNS uses the syntax >> defined in Section 3.5 of [RFC1034] and Section 2.1 of [RFC1123].""" >> >> I read that as: "if it matches RFC1034 (and isn't overridden by the >> specific URI scheme's rules) it's a DNS name." It could be read the >> other way, but that just adds more assumptions. >> >> -- >> Matthew Kerwin >> http://matthew.kerwin.net.au/ >> >> _______________________________________________ >> 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
- Minor editorial change to draft-ietf-dnsop-sutld-… Warren Kumari
- Re: Minor editorial change to draft-ietf-dnsop-su… Randy Bush
- Re: Minor editorial change to draft-ietf-dnsop-su… Ralph Droms
- Re: Minor editorial change to draft-ietf-dnsop-su… Randy Bush
- Re: Minor editorial change to draft-ietf-dnsop-su… Ted Lemon
- Re: Minor editorial change to draft-ietf-dnsop-su… Randy Bush
- Re: Minor editorial change to draft-ietf-dnsop-su… Ted Lemon
- Re: Minor editorial change to draft-ietf-dnsop-su… Randy Bush
- Re: Minor editorial change to draft-ietf-dnsop-su… Ted Lemon
- Re: Minor editorial change to draft-ietf-dnsop-su… Randy Bush
- Re: Minor editorial change to draft-ietf-dnsop-su… Ted Lemon
- Re: Minor philosophical update to draft-ietf-dnso… John Levine
- Re: [DNSOP] Minor editorial change to draft-ietf-… william manning
- Re: [DNSOP] Minor editorial change to draft-ietf-… Ted Lemon
- Re: [DNSOP] Minor editorial change to draft-ietf-… Paul Vixie
- new DNS classes Jim Reid
- Re: new DNS classes Ted Lemon
- Re: [DNSOP] new DNS classes Paul Vixie
- Re: [DNSOP] new DNS classes David Conrad
- Re: new DNS classes John C Klensin
- Re: new DNS classes Paul Vixie
- Re: new DNS classes Mark Andrews
- Re: [DNSOP] Minor editorial change to draft-ietf-… Mark Andrews
- Re: new DNS classes or anything else John Levine
- Re: new DNS classes or anything else George Michaelson
- Re: [DNSOP] Minor editorial change to draft-ietf-… Matthew Kerwin
- Re: [DNSOP] Minor editorial change to draft-ietf-… william manning
- Re: [DNSOP] Minor editorial change to draft-ietf-… Mark Andrews
- Re: [DNSOP] Minor editorial change to draft-ietf-… Matthew Kerwin
- Re: new DNS classes Randy Bush
- Re: new DNS classes or anything else Randy Bush
- Re: Minor editorial change to draft-ietf-dnsop-su… Suzanne Woolf
- Re: new DNS classes or anything else John C Klensin
- Re: Minor editorial change to draft-ietf-dnsop-su… John C Klensin
- Re: [DNSOP] Minor editorial change to draft-ietf-… Warren Kumari
- Re: [DNSOP] Minor editorial change to draft-ietf-… Ted Lemon
- Re: Minor philosophical update to draft-ietf-dnso… Ted Lemon
- Re: Minor philosophical update to draft-ietf-dnso… John R Levine
- Re: [DNSOP] Minor editorial change to draft-ietf-… Roy T. Fielding
- Re: new DNS classes John Levine
- Re: Minor philosophical update to draft-ietf-dnso… Ted Lemon
- Re: [DNSOP] Minor editorial change to draft-ietf-… Mark Andrews
- Re: new DNS classes Phillip Hallam-Baker
- Re: new DNS classes John C Klensin
- Re: new DNS classes Nico Williams
- Re: new DNS classes Randy Bush
- Re: new DNS classes shogunx
- Re: [DNSOP] Minor editorial change to draft-ietf-… John C Klensin
- Re: [DNSOP] Minor editorial change to draft-ietf-… Martin Rex
- Re: new DNS classes Mark Andrews
- Re: new DNS classes Mark Andrews
- Re: [DNSOP] Minor editorial change to draft-ietf-… Mark Andrews
- Re: [DNSOP] Minor editorial change to draft-ietf-… John C Klensin
- Re: new DNS classes Nico Williams
- Re: new DNS classes Mark Andrews
- Re: [DNSOP] new DNS classes David Cake
- Re: new DNS classes Paul Vixie
- Re: new DNS classes Nico Williams
- Re: new DNS classes Nico Williams
- Re: new DNS classes Nico Williams
- Re: [DNSOP] new DNS classes Nico Williams
- Re: [DNSOP] new DNS classes David Conrad
- Re: new DNS classes william manning
- Re: new DNS classes Pete Resnick
- Re: new DNS classes Nico Williams
- Re: new DNS classes Mark Andrews
- Re: new DNS classes Phillip Hallam-Baker
- Re: new DNS classes Pete Resnick
- Re: new DNS classes Mark Andrews
- Re: new DNS classes Nico Williams
- Re: new DNS classes Pete Resnick
- Re: new DNS classes Randy Bush
- Re: new DNS classes Mark Andrews
- Re: new DNS classes John Levine
- Re: [DNSOP] new DNS classes Andrew Sullivan
- Re: new DNS classes John Levine
- Re: new DNS classes Phillip Hallam-Baker