Re: [DNSOP] New Version Notification for draft-ietf-dnsop-attrleaf-03.txt
"John R. Levine" <johnl@iecc.com> Tue, 20 March 2018 18:11 UTC
Return-Path: <johnl@iecc.com>
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 86057127201 for <dnsop@ietfa.amsl.com>; Tue, 20 Mar 2018 11:11:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level:
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.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 m0UxbkrOgEnQ for <dnsop@ietfa.amsl.com>; Tue, 20 Mar 2018 11:11:12 -0700 (PDT)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 40FDE127978 for <dnsop@ietf.org>; Tue, 20 Mar 2018 11:11:12 -0700 (PDT)
Received: (qmail 50657 invoked from network); 20 Mar 2018 18:11:10 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type:user-agent; s=c5df.5ab14ebe.k1803; bh=W7XX7HJdhehSTBzWFX58hBqJTv2Q1gCVTxqdrEOPSEU=; b=moz6hM3pgbahJvx96apG/FsmLZetN7iWTUVLTWWpQOkMhIG+wx4lrKum1bRbdeAdkJMIe42OlZlybZNOE/vK35bqKREVFEH2IiE/2nSLku/VhEkrag0mTo8m6B1I48Ue2f4fuh6Ue5jYHql9A/8yLepx4kHPj1SqBljklSCtMM/gM0+CJAnsvKSdJnTpe1G+RSIvg8GZLda0xrCpCVgXtOk/MkyrYpxCnRvBMCFi9X39ALrxZBl3xz0M479yB36O
Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 20 Mar 2018 18:11:10 -0000
Date: Tue, 20 Mar 2018 18:11:08 +0000
Message-ID: <alpine.OSX.2.21.1803201804440.8940@dhcp-8344.meeting.ietf.org>
From: "John R. Levine" <johnl@iecc.com>
To: Applications and Real-Time Area Discussion <art@ietf.org>, dnsop@ietf.org
In-Reply-To: <e1f41670-ada8-eaac-468c-c712b338a10b@dcrocker.net>
References: <f7b85bac-b050-5003-2df0-a48b1ef2f929@dcrocker.net> <e1f41670-ada8-eaac-468c-c712b338a10b@dcrocker.net>
User-Agent: Alpine 2.21 (OSX 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/ar_FsIdGexYiPjNnQg7kozXVspI>
Subject: Re: [DNSOP] New Version Notification for draft-ietf-dnsop-attrleaf-03.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 20 Mar 2018 18:11:15 -0000
After some back and forth with Dave, I realized I missed what seems to be to be a large change: this draft redefines the naming rules for SRV and URI. The current rule is that SRV is _service._protocol where the protocol is from a short list including _tcp and _udp and the service is from the IANA Service Name and Transport Protocol Port Number Registry most recently defined by RFC 6335. This draft proposes that the service names now come from a newly defined second-level name registry in the draft. The URI record uses the same namespace, but nobody believes it's widely used so it's less of an issue. This seems to be a large change for very little benefit, and unlikely to be backward compatible unless we can identify every service name now in use with SRV which seems unlikely. R's, John > G'day. This concerns an activity in dnsop, but the wg chair has quite > reasonably suggested running a significant, proposed change past apps folk, > since the work affects a number of existing and future apps efforts. (In > fact, the effort was first triggered by the DKIM work, more than 12 years > ago...) > > The domain of discourse is _underscore domain names, used for defining a > special place to use some DNS resource records, such as TXT and SRV. > > There are quite a few, existing documents that define such use, all without > the benefit of a common registry. Hence the danger of name collision. The > attrleaf effort is seeking to define a registry for holding existing > _underscore names and defining new ones. > > Besides defining the registry, the task requires updating existing > specifications to use it. The attrleaf draft has attempted to perform both > tasks in a single document, but this has made for a confused and confusing > document. (There's a larger lesson here, in spec writing...) > > More recent discussions (well, actually, last August) in dnsop, pointed > toward splitting registry definition from existing document updating, and the > note below points to a new draft that does the first. The note also charts > out the plan for the updating document. > > Comments? > > d/ > > -------- Forwarded Message -------- > Subject: [DNSOP] Fwd: New Version Notification for > draft-ietf-dnsop-attrleaf-03.txt > Date: Mon, 19 Mar 2018 17:35:29 -0700 > From: Dave Crocker <dhc2@dcrocker.net> > Reply-To: dcrocker@bbiw.net > Organization: Brandenburg InternetWorking > To: dnsop <dnsop@ietf.org> > > Folks, > > I'll limit what should be an extensive and elaborate apology to just this: > I'm sorry for the year of inactivity. > > The -03 version should provide some useful substance of progress. > > I've gone over last summer's comments and the -03 version should reflect what > the wg agreed to. Basically, it has been significantly streamlined, > essentially to reflect a clean-sheet model of the world. That is, it doesn't > deal with the ugliness that SRV, et al, created. It merely establishes the > two registries we need, long term, and populates them. This document should > have continuing utility. > > -03 defines two registries, 'global' and 'second-level'. I'm suspicious of > how short the global one is, though it does make sense. > > As noted in the document, absent major concerns with the substance of the > document, please send me or the list s/old/new/ types of change suggestions, > and if the change is for a reference, I'd love the suggestion to be > <reference> xml... > > > A second document will attempt to fix up the uglinesses in some existing > documents, to get them to align with a world that has these registries. It > should be viewed as a transitional document, though we all know how glacial > 'transitions' are in the Internet... > > Deciding how to pursue that reasonably has been the effort. The changes this > 'fixes' document defines will be to documentation, but not to existing > operation. Existing uses in the field will be preserved. > > > Here's the approach I'm taking: > > > 1. Simple underscore usage > > For many/most specifications that use underscore naming, the text merely > says to use it. They are straightforward. > > These specifications need to be listed in this document, explicitly, so > that later updates to them will know to deal with the revisions called for by > this document. > > But this document doesn't really need s/old/new kinds of precise detail > for them. Rather than provide precise language for changing each of these, I > propose to provide some generic text, and generic IANA Considerations. This > will permit this Fixes document to be cited as Updating those RFCs. > > > 2. SRV and URI > > These need more detailed text, very much in the s/old/new style. > > The current text in them does a use-by-reference of existing tables > defined for other purposes. The Update text will, instead, specify a > requirement for adding entries in the Global or Common Second-Level > registries. > > > d/ > > > -------- Forwarded Message -------- > > Name: draft-ietf-dnsop-attrleaf > Revision: 03 > Title: DNS Scoped Data Through '_Underscore' Naming of Attribute > Leaves > Document date: 2018-03-19 > Group: dnsop > Pages: 14 > URL: https://www.ietf.org/internet-drafts/draft-ietf-dnsop-attrleaf-03.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf/ > Htmlized: https://tools.ietf.org/html/draft-ietf-dnsop-attrleaf-03 > Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-attrleaf > Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-attrleaf-03 > > Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
- [DNSOP] Fwd: New Version Notification for draft-i… Dave Crocker
- Re: [DNSOP] Fwd: New Version Notification for dra… tjw ietf
- Re: [DNSOP] Fwd: New Version Notification for dra… Dave Crocker
- Re: [DNSOP] Fwd: New Version Notification for dra… John R. Levine
- Re: [DNSOP] Fwd: New Version Notification for dra… Dave Crocker
- Re: [DNSOP] New Version Notification for draft-ie… John R. Levine
- Re: [DNSOP] New Version Notification for draft-ie… P Vix
- Re: [DNSOP] New Version Notification for draft-ie… Dave Crocker
- Re: [DNSOP] New Version Notification for draft-ie… John R. Levine
- Re: [DNSOP] [art] New Version Notification for dr… Dave Crocker
- Re: [DNSOP] [art] New Version Notification for dr… John C Klensin
- Re: [DNSOP] [art] New Version Notification for dr… Paul Vixie
- Re: [DNSOP] [art] New Version Notification for dr… Paul Vixie
- Re: [DNSOP] [art] redefining SRV, New Version Not… John R. Levine
- Re: [DNSOP] [art] redefining SRV, New Version Not… John R. Levine
- Re: [DNSOP] [art] New Version Notification for dr… Dave Crocker
- Re: [DNSOP] [art] New Version Notification for dr… John R. Levine
- Re: [DNSOP] [art] New Version Notification for dr… Dave Crocker
- Re: [DNSOP] [art] New Version Notification for dr… Alexey Melnikov
- Re: [DNSOP] [art] New Version Notification for dr… Dave Crocker
- Re: [DNSOP] [art] redefining SRV, New Version Not… Ray Bellis
- [DNSOP] Attrleaf _second-Level modifications (was… Dave Crocker
- Re: [DNSOP] Attrleaf _second-Level modifications Ray Bellis
- Re: [DNSOP] [art] New Version Notification for dr… John Levine
- Re: [DNSOP] [art] New Version Notification for dr… Andrew Sullivan
- Re: [DNSOP] [art] New Version Notification for dr… Dave Crocker
- Re: [DNSOP] [art] New Version Notification for dr… John R Levine
- Re: [DNSOP] [art] Attrleaf _second-Level modifica… John Levine
- [DNSOP] Another look - draft-ietf-dnsop-attrleaf-… John C Klensin
- Re: [DNSOP] Another look - draft-ietf-dnsop-attrl… Paul Vixie
- Re: [DNSOP] Another look - draft-ietf-dnsop-attrl… John C Klensin
- Re: [DNSOP] Another look - draft-ietf-dnsop-attrl… Paul Vixie
- Re: [DNSOP] Another look - draft-ietf-dnsop-attrl… John C Klensin
- Re: [DNSOP] Another look - draft-ietf-dnsop-attrl… John R. Levine
- Re: [DNSOP] Another look - draft-ietf-dnsop-attrl… John C Klensin
- Re: [DNSOP] Another look - draft-ietf-dnsop-attrl… Martin Hoffmann
- Re: [DNSOP] [art] Another look - draft-ietf-dnsop… Dave Crocker
- Re: [DNSOP] [art] Another look - draft-ietf-dnsop… Martin Hoffmann
- Re: [DNSOP] Another look - draft-ietf-dnsop-attrl… John C Klensin
- Re: [DNSOP] Another look - draft-ietf-dnsop-attrl… Dave Crocker
- Re: [DNSOP] [art] Another look - draft-ietf-dnsop… Kurt Andersen (b)
- Re: [DNSOP] [art] Another look - draft-ietf-dnsop… John R. Levine
- Re: [DNSOP] Another look - draft-ietf-dnsop-attrl… John C Klensin
- [DNSOP] _openpgpkey & _smimecert (was: Re: [art] … Dave Crocker
- Re: [DNSOP] [art] Another look - draft-ietf-dnsop… Paul Vixie
- [DNSOP] namespace and substring reservations (was… Dave Crocker
- Re: [DNSOP] [art] Another look - draft-ietf-dnsop… Ray Bellis
- Re: [DNSOP] [art] Another look - draft-ietf-dnsop… Dave Crocker
- [DNSOP] Additional uses of underscore labels (was… Martin Hoffmann
- Re: [DNSOP] Additional uses of underscore labels Dave Crocker
- [DNSOP] End-to-end _underscore arguments (was: Re… Dave Crocker
- Re: [DNSOP] Another look - draft-ietf-dnsop-attrl… Warren Kumari
- Re: [DNSOP] Another look - draft-ietf-dnsop-attrl… Dave Crocker
- Re: [DNSOP] Another look - draft-ietf-dnsop-attrl… Warren Kumari
- Re: [DNSOP] Another look - draft-ietf-dnsop-attrl… Paul Vixie
- Re: [DNSOP] [art] Another look - draft-ietf-dnsop… John C Klensin
- Re: [DNSOP] [art] Another look - draft-ietf-dnsop… Adam Roach
- Re: [DNSOP] [art] Another look - draft-ietf-dnsop… Dave Crocker
- Re: [DNSOP] [art] Another look - draft-ietf-dnsop… John R. Levine
- Re: [DNSOP] [art] Another look - draft-ietf-dnsop… Paul Vixie
- Re: [DNSOP] [art] Another look - draft-ietf-dnsop… John R. Levine