Re: [DNSOP] [art] New Version Notification for draft-ietf-dnsop-attrleaf-03.txt
John C Klensin <john-ietf@jck.com> Wed, 21 March 2018 14:31 UTC
Return-Path: <john-ietf@jck.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 1F44112DA3D; Wed, 21 Mar 2018 07:31:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 9jwBBHpJbi7E; Wed, 21 Mar 2018 07:31:05 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC2D612DA51; Wed, 21 Mar 2018 07:31:03 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1eyelW-000Oae-I5; Wed, 21 Mar 2018 10:30:58 -0400
Date: Wed, 21 Mar 2018 10:30:51 -0400
From: John C Klensin <john-ietf@jck.com>
To: dcrocker@bbiw.net, "John R. Levine" <johnl@iecc.com>
cc: art@ietf.org, dnsop@ietf.org
Message-ID: <5F44FA5B42805C52479DE491@PSB>
In-Reply-To: <5244d327-f8ea-1590-c663-1d92e0b194c4@dcrocker.net>
References: <f7b85bac-b050-5003-2df0-a48b1ef2f929@dcrocker.net> <e1f41670-ada8-eaac-468c-c712b338a10b@dcrocker.net> <alpine.OSX.2.21.1803201804440.8940@dhcp-8344.meeting.ietf.org> <A7711F58-5145-49E8-9158-B2F94D0EABBF@redbarn.org> <7c168dc1-2ea7-d47e-78b7-0380e5d0aa84@dcrocker.net> <alpine.OSX.2.21.1803211104210.9553@ary.local> <5244d327-f8ea-1590-c663-1d92e0b194c4@dcrocker.net>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/jKQ91ptqzfVJhdnpC3ki3ECMabk>
Subject: Re: [DNSOP] [art] 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: Wed, 21 Mar 2018 14:31:08 -0000
--On Wednesday, March 21, 2018 06:05 -0700 Dave Crocker <dhc@dcrocker.net> wrote: > On 3/21/2018 4:05 AM, John R. Levine wrote: > >>>> Harmonization for the sake of harmonization is bad, and >>>> very little Internet System technology gets it. Just do >>>> new stuff better. >> >>> I agree completely. So please forgive my not understanding >>> how your first and third comments are relevant to the >>> current topic, which pertains to ensuring that new >>> behaviors use the new model. > >> I'm not Paul, but I'm guessing that he is referring to >> retroactively changing the naming rules for SRV and other RRs, >> rather than documenting existing practice. > Your attempt at clarification is equally confusing to me, > since it, too, seems to have nothing to do with the current > effort. > > The effort is to create a registry -- which obviously differs > from existing practice -- and to have that registry be used, > going forward. Both the creation and the future use deviate > fundamentally from 'existing practice'. I have to agree with Dave. There is a strong case to be made that the introduction of the underscore convention was a kludge that violated fundamental design assumptions of the DNS and that it was added without considering, much less acting on, what other changes would be needed to support it smoothly. One can imagine other, better, ways to do the same thing. I did consider including it as another example in RFC 8324 but decided against it, which may not have been the right decision. While I think I understand at least some of the reasons why alternatives to the underscore convention were not considered seriously, much less adopted, it is much too late now to change things and this proposal, AFAICT, has absolutely nothing to do with that or any other change to existing protocol or operational practices anyway. Given that one is going to have a list of keywords that are expected to expand over time (or demonstrated to do so whether it was initially expected or not), the absolutely minimal thing that can be done in the interest of _future_ damage is to create a registry of the keywords that are being used in the hope of minimizing the risk of inadvertent use of the same string for different purposes. As Graham points out, we recognized that problem with mail header field names, but there are many other examples as well and I note that we've been gradually altering existing registry definitions to move toward "let's at least prevent conflicts" rather than "registration indicates the IETF needs has blessed this use" (media type and URN namespace registries come immediately to mind). AFAICT, the only change that is being made to existing specs is to provide that, if new keywords are used/added, they should probably be registered too. That is not either harmonization for its own sake or a protocol change; it is just an administrative adjustment in how new keywords or actions are documented. I think the observation that we are needing to do this again suggests something else that I hope the IESG can consider and adopt as part of its review procedures (e.g., maybe in the shepherd template questions). We probably need to be much more aggressive about asking whether new protocols or specs include, or are creating, lists of things that might be expanded in the future, identifying them, and just create the registries the first time around. If FCSF is the default (as Dave suggests here), such a requirement does not imply significant new work or long-term commitments or, e.g., designated experts. It seems to me that would be far preferable to having to go through these later exercises of registry creation (including gathering old data to seed them) that seem to almost always stir up controversies that have little or nothing to do with the registries themselves. However, that suggestion, which I trust the ART ADs are reading and able to share with their colleagues, is very much about doing things right in the future rather than about Dave's modest and focused proposal to, as far as I'm concerned, is just fixing an earlier omission and thereby lowering risk of name conflicts going forward. best, john
- [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