|
Re: Last Call: draft-cheshire-dnsext-dns-sd (DNS-Based Service Discovery) to Informational RFC
2008-11-15 23:45:47
Dave Cridland wrote:
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.
Thank you for your review. Can you point me to any standards track IETF
documents which might need normative reference to this document?
- Mark
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.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
|
|