[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: Fri, 19 Sep 2003 18:39:04 -0700

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 <>. Certainly most URLs fit nicely in 512 bytes or less.

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

I think you may wish to read the mDNS docs and follow the IETF ZeroConf working group discussions at <>. 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 <>:

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

From <>:

"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 (<> and <>, 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 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]