--On Friday, 11 July, 2008 09:48 -0400 Keith Moore
<moore@xxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf