Re: Call for review of proposed update to ID-Checklist
John C Klensin <john-ietf@jck.com> Wed, 09 July 2008 21:03 UTC
Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 912F528C214; Wed, 9 Jul 2008 14:03:21 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61A9A28C1B8; Wed, 9 Jul 2008 14:03:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.478
X-Spam-Level:
X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kRogE8cEqbqt; Wed, 9 Jul 2008 14:03:19 -0700 (PDT)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id EE05F3A699D; Wed, 9 Jul 2008 14:03:18 -0700 (PDT)
Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1KGgox-000MI6-5k; Wed, 09 Jul 2008 17:03:27 -0400
Date: Wed, 09 Jul 2008 17:03:25 -0400
From: John C Klensin <john-ietf@jck.com>
To: Thomas Narten <narten@us.ibm.com>
Subject: Re: Call for review of proposed update to ID-Checklist
Message-ID: <D8C00052ED1EE1FDAF109DC7@p3.JCK.COM>
In-Reply-To: <200807091419.m69EJ4TX025969@cichlid.raleigh.ibm.com>
References: <20080708184427.5D55F28C0EC@core3.amsl.com> <p06250117c4996966b0d4@[75.145.176.242]> <DA239261F08994CDC795CDD5@p3.JCK.COM> <200807091419.m69EJ4TX025969@cichlid.raleigh.ibm.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Disposition: inline
Cc: Pete Resnick <presnick@qualcomm.com>, IETF Chair <chair@ietf.org>, ietf@ietf.org, iesg@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org
--On Wednesday, 09 July, 2008 10:19 -0400 Thomas Narten <narten@us.ibm.com> wrote: > And on the particular question of example DNS names: > > >> 6. Addresses used in examples SHOULD use fully qualified >> domain names instead of literal IP addresses, and SHOULD use >> example fqdn's such as foo.example.com instead of >> real-world fqdn's. See [RFC2606] (Eastlake, D. and A. >> Panitz, "Reserved Top Level DNS Names," June 1999.) for >> example domain names that can be used. > > Why the SHOULD? Presumably, because you don't want naive folk > to take the examples in the RFC and use them in local config > files and such, causing problems or other undesirable effects > when they (unexpectedly) get used in the real world.. > > But in cases where this really is not a concern, there is also > presumably not a need to _require_ use of the example names. Well, I agree, but, based on the response to the 2821bis appeal and the proposed RFC Editor note on that document, the IESG apparently sees actual harm (rather than, e.g., impolite behavior) where some of the rest of us do not. In the interest of being constructive, reducing ambiguity, surprises and post-last-call quibbling, of focusing on the areas where I think there is consensus about harm, and of being specific, I propose the following as alternative text: "6. Addresses used in I-Ds SHOULD use fully qualified domain names (FQDNs) instead of literal IP addresses. Working Groups or authors seeing exemptions from that rule MUST supply the rationale for IP address use with inline comments (e.g., "Editor's note:" or "Note in Draft:" that can be evaluated by the IESG and the community along with the rest of the document. Domain names in pseudo-code, actual code segments, sample data structures and templates, specifically including MIB definitions and examples that could reasonably be expected to be partially or entirely copied into code, MUST be drawn from the list reserved for documentary use in BCP32 (RFC 2606 or its successors). It is generally desirable for domain names used in other I-D discussion contexts to be drawn from BCP32 as well, if only as an act of politeness toward those who might be using the domains for other purposes at the time of publication or subsequently. Working groups or editors who are convinced that different names are required MUST be prepared to explain and justify their choices and SHOULD do so with explicit inline comments such as those described above." Now, that is somewhat longer and more complicated, but it would seem to satisfy the criteria that have been discussed on the IETF list, not just since the ID-Checklist update draft was posted, but over the last six weeks or so. In particular: (i) I believe that there actually is consensus that use of non-2606 names in places where they are likely to be copied into production code (even if only by the lazy or careless) is likely to be harmful as well as a terrible idea. (ii) There is, at best, much less consensus that use of non-2606 names in narrative or illustrative examples is likely to be harmful. There may be consensus that it is impolite (or, to quote some recent IESG comments, "rude") but that is, IMO, a rather different matter. (iii) The IETF has indicated enough times that domain names, not literal addresses, should be used in both protocols and documents that doing anything else should reasonably require clear and strong justification. (iv) If someone wants to use non-2606 names, it is entirely reasonable to expect them to explain why and to do so in public. If that drives editors and WGs to take the path of least resistance and use the 2606 names, I think it should be fine with all of us. FWIW, please note the philosophical similarity between the above and RFC 4897. In both cases, we move away from incentives for elaborate procedures and private negotiations between the IESG and authors (and the consequent late-stage guessing about what is likely to happen). Instead, we get the issues and justifications up front as part of document processing or in the document itself so that the community can address them as part of Last Call. The IESG can then make decisions based on evidence of community consensus (or community indifference, as the case may be). I think that is supposed to be what we all want around here, isn't it? john _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
- Re: Call for review of proposed update to ID-Chec… Frank Ellermann
- Re: Call for review of proposed update to ID-Chec… Pete Resnick
- Call for review of proposed update to ID-Checklist IETF Chair
- Re: Call for review of proposed update to ID-Chec… Dave Crocker
- Re: Call for review of proposed update to ID-Chec… Pete Resnick
- Re: Call for review of proposed update to ID-Chec… Dave Crocker
- RE: Call for review of proposed update to ID-Chec… Bert Wijnen - IETF
- Re: Call for review of proposed update to ID-Chec… John C Klensin
- RE: Call for review of proposed update to ID-Chec… Bert Wijnen - IETF
- RE: Call for review of proposed update to ID-Chec… John C Klensin
- Re: Call for review of proposed update to ID-Chec… Theodore Tso
- Re: Call for review of proposed update to ID-Chec… Brian E Carpenter
- Re: Call for review of proposed update to ID-Chec… Frank Ellermann
- Re: Call for review of proposed update to ID-Chec… Thomas Narten
- Re: Call for review of proposed update to ID-Chec… Spencer Dawkins
- Re: Call for review of proposed update to ID-Chec… Bill McQuillan
- Re: Call for review of proposed update to ID-Chec… Paul Hoffman
- Re: Call for review of proposed update to ID-Chec… Spencer Dawkins
- More example TLDs in 2606bis? (was: Call for revi… Frank Ellermann
- Re: Call for review of proposed update to ID-Chec… Keith Moore
- Re: Call for review of proposed update to ID-Chec… John C Klensin
- Re: Call for review of proposed update to ID-Chec… Ted Hardie
- Re: Call for review of proposed update to ID-Chec… Keith Moore
- Re: Call for review of proposed update to ID-Chec… John C Klensin
- Re: Call for review of proposed update to ID-Chec… Frank Ellermann
- Re: Call for review of proposed update to ID-Chec… Bob Braden
- Re: Call for review of proposed update to ID-Chec… John C Klensin
- Re: Call for review of proposed update to ID-Chec… Eliot Lear
- Re: Call for review of proposed update to ID-Chec… Keith Moore
- Re: Call for review of proposed update to ID-Chec… John C Klensin
- Re: Call for review of proposed update to ID-Chec… Bert Wijnen (IETF)
- Re: Call for review of proposed update to ID-Chec… John C Klensin
- Re: Call for review of proposed update to ID-Chec… Bert Wijnen (IETF)
- Re: Call for review of proposed update to ID-Chec… Bert Wijnen (IETF)
- Re: Call for review of proposed update to ID-Chec… Dave Crocker
- Re: Call for review of proposed update to ID-Chec… John C Klensin
- Re: Call for review of proposed update to ID-Chec… Bert Wijnen (IETF)
- Re: Call for review of proposed update to ID-Chec… Bert Wijnen (IETF)
- Re: Call for review of proposed update to ID-Chec… Frank Ellermann
- Re: Call for review of proposed update to ID-Chec… Paul Hoffman
- Re: Call for review of proposed update to ID-Chec… Dave Crocker
- Re: Call for review of proposed update to ID-Chec… Julian Reschke
- Re: Call for review of proposed update to ID-Chec… Dave Crocker
- Re: Call for review of proposed update to ID-Chec… John C Klensin
- Re: Call for review of proposed update to ID-Chec… Henrik Levkowetz
- Re: Call for review of proposed update to ID-Chec… Brian E Carpenter
- Re: Call for review of proposed update to ID-Chec… John C Klensin
- Re: Call for review of proposed update to ID-Chec… John C Klensin
- Re: Call for review of proposed update to ID-Chec… John C Klensin
- Re: Call for review of proposed update to ID-Chec… Julian Reschke
- Re: Call for review of proposed update to ID-Chec… Lars Eggert
- Re: Call for review of proposed update to ID-Chec… Henrik Levkowetz
- ID desires and TOOLS stuff [was: Re: Call for rev… Bert Wijnen (IETF)
- Re: Call for review of proposed update to ID-Chec… Bert Wijnen (IETF)
- Re: Call for review of proposed update to ID-Chec… Julian Reschke
- Re: Call for review of proposed update to ID-Chec… Bert Wijnen (IETF)
- Re: Call for review of proposed update to ID-Chec… Dave Crocker
- Re: Call for review of proposed update to ID-Chec… Dave Crocker
- Re: Call for review of proposed update to ID-Chec… Henrik Levkowetz
- Re: Call for review of proposed update to ID-Chec… SM
- Re: Call for review of proposed update to ID-Chec… Bert Wijnen (IETF)
- Mixed case (was: Call for review of proposed upda… Frank Ellermann
- Re: Call for review of proposed update to ID-Chec… Russ Housley
- Re: Call for review of proposed update to ID-Chec… Frank Ellermann
- Re: Call for review of proposed update to ID-Chec… Harald Alvestrand
- Re: Call for review of proposed update to ID-Chec… Bert Wijnen (IETF)
- Re: Call for review of proposed update to ID-Chec… Dave Crocker
- Re: Call for review of proposed update to ID-Chec… Dave Crocker
- Re: Call for review of proposed update to ID-Chec… Spencer Dawkins
- Re: Call for review of proposed update to ID-Chec… Robert Elz