Re: Call for review of proposed update to ID-Checklist

[John C Klensin <john-ietf at jck.com>]

--On Wednesday, 09 July, 2008 10:19 -0400 Thomas Narten
<narten at 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 From ietf-bounces at ietf.org  Wed Jul  9 14:03:21 2008
Return-Path: <ietf-bounces at ietf.org>
X-Original-To: ietf-archive at megatron.ietf.org
Delivered-To: ietfarch-ietf-archive at 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 at core3.amsl.com
Delivered-To: ietf at 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 at jck.com>
To: Thomas Narten <narten at us.ibm.com>
Subject: Re: Call for review of proposed update to ID-Checklist
Message-ID: <D8C00052ED1EE1FDAF109DC7 at p3.JCK.COM>
In-Reply-To: <200807091419.m69EJ4TX025969 at cichlid.raleigh.ibm.com>
References: <20080708184427.5D55F28C0EC at core3.amsl.com>
	<p06250117c4996966b0d4 at [75.145.176.242]>
	<DA239261F08994CDC795CDD5 at p3.JCK.COM>
	<200807091419.m69EJ4TX025969 at cichlid.raleigh.ibm.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Disposition: inline
Cc: Pete Resnick <presnick at qualcomm.com>, IETF Chair <chair at ietf.org>,
	ietf at ietf.org, iesg at ietf.org
X-BeenThere: ietf at 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 at ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf at ietf.org>
List-Help: <mailto:ietf-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces at ietf.org
Errors-To: ietf-bounces at ietf.org



--On Wednesday, 09 July, 2008 10:19 -0400 Thomas Narten
<narten at 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 evalube 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 at ietf.org
https://www.ietf.org/mailman/listinfo/ietf


ated 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 at ietf.org
https://www.ietf.org/mailman/listinfo/ietf