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

[Paul Snively]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Stephen!

On Friday, September 19, 2003, at 12:40  AM, Stephen J. Turnbull wrote:

> Just that protocols that browse for distributed resources can be hell
> on a network.  One has to be very careful.
Agreed that the designers of such protocols need to be careful.

> Hehe.  (1) This isn't an RFC, even, yet.

Time will resolve that issue, such as it is.

>   (2) My guess is that the DNS
> TXT record is just plain dead in the water.  Why?  Because many DNS
> implementations are restricted to 512 (yep, you can count 'em on your
> fingers if you're a centipede) _bytes_ of returned data.  So what
> you're suggesting surely requires multiple trips to the well.

This is addressed in section 6.2 of 
<http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt>. Certainly 
most URLs fit nicely in 512 bytes or less.

>   (3)
> That's on a datagram service.

It's unclear to me what the significance of this is.

>   (4) And it's deprecated by the authors
> anyway.  The lpd example is about _backward compatibility_.  New
> protocols SHOULD NOT depend on it.
This is far too strong. It's true that they use the word "legacy" to 
talk about services that don't do feature negotiation on their host and 
port, but earlier, in section 6. we find:

"Similarly, a file server may have multiple volumes, each identified by 
its own volume name. A Web server typically has multiple pages, each 
identified by its own URL. In these cases, the necessary additional 
data is stored in a TXT record with the same name as the SRV record."

These examples demonstrate that use of DNS-SD for precisely the type of 
service that a public arch archive represents has been contemplated and 
is supported by the DNS-SD authors. The use of the TXT record in such 
cases is not at all deprecated; section 6. and its subsections are 
precisely about defining how the TXT record can be used to provide 
necessary additional information, such as a URL, to make effective use 
of a service.

> This is _definitely_ going to be hell on the conference network at
> registration hour.  Not to mention abuse of the whole DNS idea.  The
> DNS was never intended to be a directory for arbitrary text.
And no one's asking for it to be; it's being asked to be a directory 
for arbitrary services. And it's going to be no more hell on the 
network at registration hour than a bunch of people hitting the same 
HTTP server or Wiki server at the same time would be (keep in mind that 
we're talking about DNS-SD, not mDNS; that's a separate discussion).

> My guess is that the IETF will say: if you want to use SRV records to
> discover lpd queues, rewrite the lpd protocol spec.
No one's talking about lpd except as an example of how DNS-SD can even 
support services that weren't designed with it in mind.

> tla grab is technologically trivial, and it's a social solution.
Yeah, and so far in my investigation it doesn't seem relevant at all.

> mDNS amounts to walking into a crowded room and yelling, "Yo, is Paul
> Snively here?"

No; it amounts to having my machine say "Yo, public arch archive here!" 
every five minutes.

>   That's social behavior; you're talking to a specific
> group, the ones in front of you, and who knows if anyone will bother
> to answer?

They don't have to answer. The information will get to them with a high 
degree of probability of success. Certainly higher than with word of 
mouth.

>   And sure, humans are more fallible than machines, but UDP
> is pretty fallible as mechanical technologies go.  Especially in the
> packet storm that is likely to characterize registration hour at a
> conference.
I think you may wish to read the mDNS docs and follow the IETF ZeroConf 
working group discussions at 
<http://www.merit.edu/mail.archives/zeroconf>. I think you'll be 
pleasantly surprised to find that these issues are receiving the 
attention that they deserve. But once again, at the moment, I'm more 
interested in concentrating on service discovery (DNS-SD or otherwise) 
apart from mDNS considerations.

> DNS-SD as written in that draft looks to me to suffer from severe lack
> of the kinds of experience that informs the Gulbrandsen, Vixie, Esibov
> RFC for SRV records.

From <http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt>:

"We would like to thank (in alphabetical order) Richard Brown, Josh 
Graessley, Erik Guttman, Paul Vixie, and Bill Woodcock, for their 
contributions."

From 
<http://files.multicastdns.org/draft-cheshire-dnsext-multicastdns.txt>:

"The concepts described in this document have been explored and 
developed with help from Erik Guttman, Paul Vixie, Bill Woodcock, and 
others."

>   I think it's years from acceptance, and two of
> the features that arch might want to depend on (DNS TXT records and
> multilevel protocol discovery, cf the _anon._ftp._tcp example) are
> likely to be extremely controversial.

It seems that TXT records of 512 bytes or less are comparatively safe. 
I don't see the connection between arch and multilevel protocol 
discovery. Nevertheless, it's also not clear to me why multilevel 
protocol discovery should be controversial.

>   IMO YMMV IANAL etc. but I think
> we're better off looking for a solution we can implement today in
> conformance with the existing RFCs.
Too late, in a few important senses: there aren't any competing service 
discovery systems that have any wider acceptance; ZeroConf is in the 
IETF working group phase and is being standardized; and it's already 
shipping on the 2nd most popular consumer platform in the world. If 
someone can challenge me on the first point, I'd be thrilled--I'm 
always interested in good technology 
(<http://www.cs.cornell.edu/Info/Projects/Ensemble> and 
<http://www.spread.org>, for example). There are no factual challenges 
to the latter two points.

A major aspect of my point is precisely that this _can_ be implemented 
today, and in fact the ZeroConf RFC drafts _are_ in conformance with 
the existing RFCs ("This document describes a convention for naming and 
structuring DNS resource records. Given a type of service that a client 
is looking for, and a domain in which the client is looking for that 
service, this convention allows clients to discover a list of named 
instances of that desired service, using only standard DNS queries" and 
"This document proposes no change to the structure of DNS messages, and 
no new operation codes, response codes, or resource record types. This 
document simply discusses what needs to happen if DNS clients start 
sending DNS queries to a multicast address, and how a collection of 
hosts can cooperate to collectively answer those queries in a useful 
manner.")

From your previous message, it's clear that you understand the value 
proposition. Unfortunately, from this response, it's far from clear 
that you understand who is behind DNS-SD and mDNS, the level of design 
effort that's been put into it, or its adoption rate. Still, fine: if 
you have an alternative suggestion that addresses the process that you 
described so well, I absolutely want to know about it. In the meantime, 
I'll continue working with David on the spaces-in-filenames and 
AppleSingle support and revisit service discovery after that.

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

iEYEARECAAYFAj9rr8AACgkQugPBK9DetersbgCfR/5gN/XoIIg96yANkcTBn0W0
6T4AoIJOJz4Qy08WhTj8H2QKSHxHWi5V
=ROoO
-----END PGP SIGNATURE-----