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@cridland.net - xmpp:dwd@dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf