Re: Last Call: draft-cheshire-dnsext-dns-sd (DNS-Based Service Discovery) to Informational RFC

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

 



On Tue Nov  4 14:28:19 2008, The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:

- 'DNS-Based Service Discovery '
   <draft-cheshire-dnsext-dns-sd-05.txt> as an Informational RFC

I note that this document is Informational, yet forms the basis for standards track documents both in the IETF and other SDOs. It would be, therefore, more useful to tidy up this document and move it to the standards track rather than short-cutting it to an Informational.

In the course of reviewing XEP-0174 changes for the XSF, I reviewed this document in detail, particularly on the subject of record formatting. The following are my own views, however, not those of the XSF.

I believe the document is exceedingly unclear, and as such unsuitable for publication in its present form. It is badly laid out, and contains a mixture of specification, rationale, marketing, and confusing reiteration of other documents, making the document much harder to extract useful information from than it needs to be.

I'm also unconvinced that this represents the state of the protocol as deployed by various Apple devices anyway. If this is to be a serious attempt to document a working protocol, it must reflect reality.

Section by Section:

1) The last two paragraphs of the Introduction can largely be snipped.

2) Use of RFC 2119 language in an Informational document is a curious one - I'm not against its use, but in general terms, the document does not appear to use these terms in quite the way I'd expect. In particular, the terms appear to be used to express designer's preferences rather than actual interoperability requirements.

3) Seems okay.

4) Okay.

4.1) The parenthesis in the second paragraph is superfluous - one expects that any reader would surely understand DNS to this level.

From about the top of page 6, however, it gets really bad. Only the top paragraph, diagram, and first two sentences of the subsequent paragraph are needed here. The rest of the page is waffle and repetition.

Page 7 is mostly okay - it could probably be condensed.

I'd question the purpose of Punycode here, though, if the records are already usefully deployed in UTF-8, since the records are only to be found by querying in the first place. Is this actually supported in the field? (As in, do clients try punycode?)

4.2) I'm always a little wary of UI detail in IETF documents, but the suggestions seem reasonable.

4.3) As near as I can tell, the backslah-escaping of DNS-SD instance names is done externally as well as internally, so this section is exceedingly misleading.

4.4) Appears to be largely marketing, or rationale, and is confusing in this section.

4.5) Appears to be largely rationale.

5) Reiterates SRV

6) Okay, although I don't understand the point of mandating an empty TXT record, it being about the only portion of the document not backed up by twenty-five pages of rationale including words like "compelling". I'm guessing it might be to avoid negative caching, thus placing the statement "This service has no parameters" under the control of normal TTL, etc. That would, naturally, be a compelling reason.

It's a shame that several TXT records for services are absent on dns-sd.org, then, but "it's only a SHOULD" - ho, ho.

6.1) Massively confusing, since it reiterates RFC 1035 in such a way that without referring to RFC 1035 to gain the context, one is led to believe that the actual strings must follow this format, instead of it merely being wire format.

6.2) All jolly good, although I note that several Apple devices appear to use a single TXT string containing a comma seperated list of values, that is, if you forgive my pseudo-ABNF:

txt_value = txt_record
txt_record = keypair ["," keypair]

Instead of the apparent specification:

txt_value = "" / (1*txt_record)
txt_record = keypair

I wonder whether this is an earlier version of the specification, or a non-standard usage of a non-standard, or whether even Apple people can't glean the single useful fact from this entire page of prose.

6.3) Astonishingly, this section is reasonably concise, and contains information which is, dare I say it, useful. Thankfully it, too, appears to be ignored by various Apple devices.

6.4) This section could usefully be folded into 6.2, and the resultant prose condensed into perhaps a paragraph or two, and potentially use ABNF for clarity:

keypair = key ["=" value]
key = 1*key_char
key_char = %x20-%x3C / %x3E-%x7E
value = *OCTET

6.5) I seem to have inadvertantly included much of this in my ABNF above in 6 characters. The last two paragraphs seem superfluous - specifications for debugging tools?

6.6) Describes the wire format, which strikes me as very much less than useful. Again, I've seen serious confusion result from this. Zone file format records would be much more useful to most people.

6.7) It's deeply unclear, to me, whether the txtvers= relates to this specification, or the specification for interpretation of the key names and values. It's very clear to me that this is the wrong approach if the latter is desired, which is perhaps why I've not seen this used anywhere in the field. (The correct approach is to rename those keys for which the definition has changed, thus allowing services to advertise both old and new formats if appropriate, and minimize actual code change).

7) Isn't nearly all of this reiterating RFC 2782?

And is it pure coincidence that Apple-based browsers are listed first?

7.1) An example (by which I mean example zone files, etc, not examples that require buying an Apple computer) would be much more useful here.

I believe this means that:

_printer._sub._http._tcp.example.com IN PTR A\032Printer._http._tcp.example.com
_http._tcp.example.com IN PTR A\032Printer._http._tcp.example.com
_http._tcp.example.com IN PTR A\032Web\032Page._http._tcp.example.com

However, whether or not "A Printer" remains a service instance enumerated by a discovery for "plain http" is unclear.

The section appears to be about a page too long.

7.2) Again, I feel sure this could be expressed in fewer paragraphs.

8) "Compelling" again. This time in a discussion of printer protocols. I'm pretty sure this is useless waflle.

The actual content - that is, the requirement to specify a particular service as the master, or reference, service for each service class seems unfortunate, but I can't immediately think of anything better. Perhaps more frustratingly, there seems no obvious way of multilaterally agreeing on such a thing - ie, no IANA consideration for such registration.

9) This is quite a good section; reasonably concise with no mentions of round, pomaceous fruit. Note that the recommendation would yield something of the form:

_services._dns-sd._udp.example.org. 3600 IN PTR _afpovertcp._tcp.

Rather than:

;; QUESTION SECTION:
;_services._dns-sd._udp.dns-sd.org. IN	PTR

;; ANSWER SECTION:
_services._dns-sd._udp.dns-sd.org. 3600 IN PTR _afpovertcp._tcp.dns-sd.org.
_services._dns-sd._udp.dns-sd.org. 3600	IN PTR	_ftp._tcp.dns-sd.org.
_services._dns-sd._udp.dns-sd.org. 3600	IN PTR	_http._tcp.dns-sd.org.
_services._dns-sd._udp.dns-sd.org. 3600	IN PTR	_ipp._tcp.dns-sd.org.
_services._dns-sd._udp.dns-sd.org. 3600 IN PTR _pdl-datastream._tcp.dns-sd.org. _services._dns-sd._udp.dns-sd.org. 3600 IN PTR _printer._tcp.dns-sd.org.
_services._dns-sd._udp.dns-sd.org. 3600	IN PTR	_ssh._tcp.dns-sd.org.

Which makes me wonder if I've misread the specification. Or maybe the dns-sd.org administrators haven't read it.

10) Aside from the almost obligatory mentions of Malus domestica, this seems reasonably good and useful.

11) I'm deeply suspicious that this is only one paragraph. Perhaps there are several pages missing in my copy?

12) It might be better to refer to the "all-zero" address, or "network address", rather than "base address".

13) Reasonable. I'm not sure it's quite within the scope of this document to specify additional records when using SRV.

14) Marketing material?

15) Mostly quite useful, although if the examples showed the output of dig, it'd be better, and if they showed the output of a query with multiple keys, etc, this would be better still.

16) The section (and subsections) has some useful material, but a lot of waffle, and descends into outright marketing at the end. In my more cynical moments - and it may astonish you all to discover I have them - I wonder if the penultimate paragraph of Section 16.2 exists to name-check any Apple trademarks previously unmentioned.

17) Again, I'm distressed by the lack of a further page and a half explaining in detail why Apple's use of IPV6 is "compelling", or some such rubbish.

18) Short, and this time it needs to be longer.

By suggesting that DNS servers ought to be including more data in the additional section, it's beholden on clients to ensure that the server is providing data it is authoritative for. The particular risk is that I might configure my local DNS server to give out different SRV records, A records, etc. than I ought to, and thereby potentially poison your cache. I'm sure this is documented elsewhere, but I certainly don't see it in the references.

19) A secret registry. Right.

20) Not acknowledging Apple?!?

21) Oh, yes, we are.

In summary, I think there's a valuable and useful 10 pages of document here, carefully contained within 40 pages of namechecks, marketing, and other gratuitous waffle. Please consider rewriting this document prior to publication.

Dave.
--
Dave Cridland - mailto:dave@xxxxxxxxxxxx - xmpp:dwd@xxxxxxxxxxxxxxxxx
 - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
 - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]