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

[Paul Snively]

-----BEGIN PGP SIGNED MESSAGE-----
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:
>
> ARCHIVE-URL=http://@/~lord/{archives}/address@hidden
> ARCHIVE-URL=http://@/~lord/{archives}/address@hidden
>
> 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: <http://developer.apple.com/darwin/projects/rendezvous>,  
<http://www.swampwolf.com/products>, <http://zeroconf.sourceforge.net>,  
<http://dotlocal.org/mdnsd>, <http://www.acm.uiuc.edu/signet/liaison>,  
<http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/zeroconf/tmdns>,  
<http://radio.weblogs.com/0105002/stories/2003/01/06/ 
multicastDnsServiceDiscoverForPython.html>,  
<http://www.strangeberry.com/java_rendevous.htm>, and  
<http://www.neato.org/%7Efemur/iu> 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      
> http://turnbull.sk.tsukuba.ac.jp
> 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,
Paul

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)

iEYEARECAAYFAj9sDpQACgkQugPBK9DetepInQCgo8Uc83obu9iDpkpVsytm3XZv
QnEAoJPgl7lPjnsjcYAlLHB4aTIZ9x2T
=75JQ
-----END PGP SIGNATURE-----