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

From: Bob Braden <[email-masked]>
Date: Thu, 10 Jul 2008 08:50:44 -0700 (PDT)

*> 
  *> John C Klensin wrote:
  *> 
  *> > 	(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.
  *> 

John,

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.)

Bob Braden

_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: John C Klensin <[email-masked]>
Date: Thu, 10 Jul 2008 12:16:44 -0400

> John,
> 
> 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.)

Yes.  Independent of the text in 1123, several others have
pointed out that as strong a rule as I suggested, worded that
way, would be a bad idea.  Several notes in this thread have
pointed that out, offered specific examples, and proposed text
that was better than mine. 

Of course, there has never been a requirement that a
specification exhibit every one of its capabilities in examples.
The examples should be chosen should, IMO, represent likely
common practice rather than obscure features.  Sometimes that
will point to the use of IP addresses (see a note from Ted
Hardie for an example) but often it will suggest DNS names
instead.

However, since IPv6 came over the horizon, there _have_ been a
number of statements made that prefer domain names over literal
addresses for reasons that were not relevant when 1123 was
written.  I think those arguments are strong enough that asking
an editor who chooses to use examples with address literals in
it to explain that choice is entirely in order.

Again, the goal of my proposal is to move the rationale for
decisions to use anything but 2606 names into the document flow
for consideration during discussions of the document and Last
Call, with the IESG interpreting community consensus (as with
everything else).  The alternative, it appears, is a guessing
game about IESG intentions and flexibility post-last-call and an
invitation to private negotiations between the IESG and authors.
We generally claim those are a bad idea even if we don't always
act consistently with that claim.

    john

---

From: Eliot Lear <[email-masked]>
Date: Fri, 11 Jul 2008 15:39:25 +0200

Bob,
> SHOULD support literal addresses (and of course DNS support is a MUST) --

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.  Remember that even as late as two 
years prior, one had to edit SunOS binaries to gain access to DNS.  
Worse, use of literals in applications leads to their being placed in 
configuration files, and that's just bad juju in a dynamic world.  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.

As I recall, John was in the room, by the way, when that text was discussed.

Eliot

---

From: Keith Moore <[email-masked]>
Date: Fri, 11 Jul 2008 09:48:25 -0400

Eliot Lear wrote:
> 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.

> configuration files, and that's just bad juju in a dynamic world. 

We're a LONG way from getting rid of literals in configuration files. 
We're a LONG way from a world where IP addresses can change at a whim.

> I'm not saying that DNS is perfect by any stretch, but the alternative is 
> worse.
> 

I think examples involving literals are fine, as long as we state that 
they're expected to be used only in exceptional cases.

Keith

---

From: John C Klensin <[email-masked]>
Date: Fri, 11 Jul 2008 10:15:48 -0400

--On Friday, 11 July, 2008 09:48 -0400 Keith Moore
<[email-masked]> wrote:

>> 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