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

John C Klensin <john-ietf@jck.com> Fri, 11 July 2008 14:16 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 00D063A6B61; Fri, 11 Jul 2008 07:16:12 -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 8B41E3A6B61; Fri, 11 Jul 2008 07:16:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.546
X-Spam-Level:
X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.053, 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 MUU9rmJTWUYo; Fri, 11 Jul 2008 07:16:06 -0700 (PDT)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 53D0C3A6B3D; Fri, 11 Jul 2008 07:15:43 -0700 (PDT)
Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1KHJPZ-000LHu-DJ; Fri, 11 Jul 2008 10:15:49 -0400
Date: Fri, 11 Jul 2008 10:15:48 -0400
From: John C Klensin <john-ietf@jck.com>
To: Keith Moore <moore@network-heretics.com>, Eliot Lear <lear@cisco.com>
Subject: Re: Call for review of proposed update to ID-Checklist
Message-ID: <A21314578D199229A87950E6@p3.JCK.COM>
In-Reply-To: <487764A9.9050309@network-heretics.com>
References: <200807101550.IAA16153@gra.isi.edu> <4877628D.9020200@cisco.com> <487764A9.9050309@network-heretics.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Disposition: inline
Cc: Bob Braden <braden@ISI.EDU>, 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 Friday, 11 July, 2008 09:48 -0400 Keith Moore
<moore@network-heretics.com> wrote:

> 
> 
> Eliot Lear wrote:
>> Bob,
>>> This contradicts Section 2.1 of RFDC 1123, which says an
>>> application SHOULD support literal addresses (and of course
>>> DNS support is a MUST) -- Section 6.1.1.)
>>>    
>> 
>> Within the application space, which is what we were talking
>> about with  RFC 1123, I'd have to say that the times have
>> changed.  Back in 1989 DNS  was still relatively unproven,
>> failures were common, and there was a  need to be able to get
>> around DNS.  
> 
> In my experience, DNS failures are still common.  Most of
> those failures are probably due to misconfiguration of some
> sort or another (e.g. failure to decrease TTLs in advance of
> an address change, particularly when that address is in an NS
> record).  But to the application, it still looks like a DNS
> failure.

This is an important consideration.  But it is an important
consideration in designing protocols and table formats and for
configuring systems.  As Eliot points out (and as I tried to
point out to Bob earlier) no one is suggesting (at least in this
Checklist context) prohibiting a protocol specification from
supporting literals -- this is just about choices of examples.
Even the question of describing the tradeoffs between the use of
domain names versus literals in a particular protocol, while
important, has little to do with the examples in most cases.

>...
>> I'm not saying that DNS is perfect by any stretch, but the
>> alternative is  worse.
>> 
>> Still, I don't think John is suggesting that we prohibit
>> applications  from supporting literals.  I personally just
>> think we shouldn't  highlight such examples.
> 
> I think examples involving literals are fine, as long as we
> state that they're expected to be used only in exceptional
> cases.

But that is exactly what the proposed text (in its virtual
revised form) would require, e.g. (illustrative, not a proposal
for final text),

	One SHOULD avoid use of literals in examples.  In the
	exception cases, one should note why they were used so
	that reviewers can understand the reasoning.  "The DNS
	is too unstable or otherwise inappropriate for many of
	the real-world cases so it was important to illustrate
	the syntax when a literal is used as the common case"
	would be, IMO, a perfectly good statement of a reason. 

Whether or not the community would accept that as a reason
would, I assume depend on the case-by-case specifics of the
protocol or context involved.  That is, IMO, as it should be.

    john


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf