[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Re: Ruminations on Arch Desiderata

From: Paul Snively
Subject: Re: [Gnu-arch-users] Re: Ruminations on Arch Desiderata
Date: Sat, 20 Sep 2003 01:23:39 -0700

Hash: SHA1

Hi Stephen!

On Saturday, September 20, 2003, at 12:05 AM, Stephen J. Turnbull wrote:

You're missing the point.  DNS is designed (except for zone transfers)
to return _all_ necessary information in _one_ packet.  That's a
minimum of the DNS overhead, a SRV record, and an A or AAAA record,
say 128 bytes.  But RFC 2782 gives a simple example (one service, two
primary hosts, two backup hosts) which adds up to 365 bytes already.
So you're down to about 140 bytes to share among several DNS TXT
records.  This is starting to look tight:


is 113 bytes right there, plus string overhead, even compressing the
host out (ie, by referring to the query section of the reply).  Note
that (at least at some point in history) you could not check out a
full copy of the current arch without access to both archives.

Note that Cheshire et al recommend keeping a DNS TXT record to _less
than 100 bytes_!  So my example, although obviously incoherent because
it comes from a somewhat different problem, is not at all inconsistent
with what the authors are thinking themselves.

As an ideal, sure. But:

"In cases where more data is justified (e.g. LPR printing), keeping the total size under 400 bytes should allow it to fit in a single standard 512-byte DNS message. (This standard DNS message size is defined in RFC 1035.)

In extreme cases where even this is not enough, keeping the size of the TXT record under 1300 bytes should allow it to fit in a single 1500-byte Ethernet packet.

Using TXT records larger than 1300 bytes is NOT RECOMMENDED at this time."

I quoted the section earlier on file servers and HTTP servers because those are precisely the kinds of mechanisms you'd use to make an arch archive available publicly and because they are clearly, deliberately, and explicitly within the domain of services that DNS-SD is intended to address, even if that means that TXT records get up into the 1K range.

Don't tell me, tell Cheshire et al.  The words SHOULD NOT when
capitalized in an RFC have specific meaning.  I didn't introduce them;
Cheshire et al did.

Where? I see three instances of the phrase: in section 2, which defines its use; in section 6.2, "Ideally it SHOULD NOT be necessary for a client to retrieve this additional information before it can usefully establish a connection to the service;" and section 6.5, "Authors defining DNS-SD profiles SHOULD NOT convert binary attribute data types into printable text (e.g. using hexadecimal, Base64 or UU encoding) merely for the sake of making the data be printable text when seen in a generic debugging tool."

Those are different in kind from arch.  It is possible to get that
information without use of DNS-SD.  Without that information you
cannot find an arch archive, but Cheshire et al specifically say a
discovery protocol SHOULD NOT depend on that information.

"Ideally it SHOULD NOT be necessary." Well, arch isn't a service running on a port, so it doesn't fit the ideal case. But the FTP/HTTP/whatever service hosting your public archive does. Add a URL and you're done, and that's absolutely within not only what Cheshire et al contemplate, but how DNS-SD is being used today.

What's wrong with the suggestion I made, of standardizing on a
directory service which is pointed out by the SRV record for arch?

What's the configurationless version of that? I don't have a problem with LDAP for configurationfull installations, but that's not the only case I'm interested in addressing.

You're all hung up on this exciting proprietary technology which may
or may not be standardized and whose current formulation specifically
deprecates the elegant approach you suggest.

Once again, I think you underestimate the progress on ZeroConf as an emerging standard; take some time to follow the IETF ZeroConf Working Group's efforts. Whatever else it may be, it is certainly not proprietary: <>, <>, <>, <>, <>, <>, < multicastDnsServiceDiscoverForPython.html>, <>, and <> are all open source, and several are Free-as-in-FSF software.

As for "specifically deprecates," I've quoted whole sections of the spec that contradict your interpretation, neglecting to leave out such crucial words as "Ideally" and "In extreme cases where even this is not enough... 1300 bytes." Note that your example was 113 bytes plus string overhead. So you could double that, add your 128 bytes for "a minimum of the DNS overhead, a SRV record, and an A or AAAA record," and still be within the 512-byte range. In short, with your failure to quote the spec, argument from the worst-case and assertion that it's the only case supported by the spec, and mischaracterization of this open-source technology as "proprietary," it's clear that your argument is political rather than technical.

On the other hand, if we use my suggestion, then (a) we conform to
current RFCs and drafts and can implement _and deploy_ _now_

Using DNS-SD (and, optionally, mDNS), we also conform to current RFCs and drafts (since they are drafts) and can implement _and deploy_ _now_ (since DNS-SD and mDNS implementations are available for all popular platforms).

and (b)
since DNS TXT records are proposed as an auxiliary discovery method,
there is nothing to prevent us from adding them immediately on an
experimental basis for those who want them, and then later deprecate
the original method when DNS TXT records are promoted to Best Current
Practice.  Finally, if the auxiliary service is well-known (such as
LDAP), then it can be easily deployed at sites that don't implement
DNS SRV records yet.

Again, if you wish to limit yourself to installations that require configuration, I think this is fine. Such a limitation is an anti-goal for me. I've indicated not merely a willingness, but a desire, to discuss DNS-SD distinctly from mDNS, but you seem to wish to continue conflating them. I've even mentioned alternative no-configuration technology such as Ensemble and Spread, to which there's been no reply. So I have to conclude that it is not I who am "hung up on this... technology" at all, but rather that you are being selectively perceptive. I'll say it one more time: if anyone knows of a good _configurationless_ alternative to DNS-SD + mDNS, I'm all ears. It could be DNS-SD and something other than mDNS or it could be neither; I really don't care (cf. Ensemble and Spread). But neither Ensemble nor Spread are IETF standards-tracked; neither have multiple implementations; neither are provided with any popular computing platform or supported by any OS vendor. So I suspect that the resistance to those alternatives would be even greater than the resistance to ZeroConf. Nevertheless, I remain open to substantive feedback about the available alternatives to DNS-SD and mDNS, particularly since I've now spent approximately half an hour of my life that I can never get back writing trivial rebuttals to selective, out-of-context, unrealistically pessimistic, and in one case merely false, "information" about DNS-SD.

Institute of Policy and Planning Sciences University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.

Best regards,

Version: GnuPG v1.2.3 (Darwin)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]