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

From: Cyrus Daboo <[email-masked]>
Date: Tue, 04 Nov 2008 11:50:12 -0400

Hi,

--On November 4, 2008 6:28:19 AM -0800 The IESG <[email-masked]> 
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

The IANA section of the dns-sd draft describes a process for registration 
of SRV service identifiers, but there is another draft doing the same 
thing: 
<http://www.ietf.org/internet-drafts/draft-gudmundsson-dns-srv-iana-registry-00.txt>.

So which of these two drafts is meant to define the actual SRV service type 
registry?

-- 
Cyrus Daboo

_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 8 Nov 2008 08:57:27 -0700

Great document I really like it but I think there are a few things  
that need to be done to improve it on the administrative side  
(technically looks great)..

First of all, it seems to me that there are lots of standards track  
stuff that will want to use this, it is well defined, works, widely  
implemented, and does not cause harm to existing things - Why would we  
do this as informations? I think it should be PS.

Next, I think the IANA section needs some work. It seems that this  
specification needs to define a few registries. One for the  
application protocol names which needs to be somehow unified with  
ports, one for flagship names and another for the sub names. Perhaps  
there is a better way to organize these than 3 registries, I don't  
care how  it gets done but it seems all three of these things do need  
to be registered.

For the application protocol names, it seems wise for the registry to  
include things for each protocol such as 1) who registered it 2)  
optional associated specification such as RFC or URL 3) defined flags  
4) associated flagship protocol 5) associated subs 7) full name of  
protocol.

The IANA section should ideal provide a template used for new  
registrations.

The specification should also provide the initial values to put in the  
registry. I would recommend include the 400+ names that are currently  
on the external site (thank you for running that BTW) in an appendix  
so they can be regressed.

The IANA section should come into force on approval of draft, not on  
publication of RFC. This reduces the time of transition.

IANA time is better spend not doing things like checking the protocol  
names meant the rules defined here. I think an expert review will do a  
better job of that. I think the registry should be Expert review from  
the beginning and this specification should provide guidance to the  
review that basically any name should be given on FCFS type basis as  
long as it meant the rules in this specification and was not making  
unreasonable use of the registry. This also resolves the issue of who  
and when could change it from FCFS to Expert Review. Would you b  
willing to be an expert reviewer for this? If the volume is high, some  
registries, such as ports have a bunch of reviewers.

If we want to allow secret registrations, the exact details of that  
need to be provided here. I'm very against this as it would be an  
administrative nightmare to handle. Instead I would suggest a  
different process that achieves much the same effect. During secret  
product development, some random individual or even a agent who does  
not reveal who they are working for registers the protocol _dapp with  
no more information about that than who registered it. Later when the  
product is released, the agent or individual could transfer change  
control of the registration to apple and update the registration with  
all the other information including what dapp was an abbreviation for.

This leads to another area, what to do when the person registered to  
update a registration can no longer be contacted at the supplied email  
address or easily found. In this case, I believe the expert should be  
able to update the registration up to and including removing it if  
there is a clear need to do that.

Few other comments.

The rest of my comments are small nits with the document.

Some people may complain that you are using names other than example.*  
and use of such names in RFC may cause the internet to melt down.

In section 4.2 seems to be the first mention of PTR records with no  
introductory text on how they are used or what they do. Seem like a  
sentence or two here might help. The PTR come up again in last para of  
section 8 but are not really explained until the next section.

In section 6.5, I think you should soften the advice on using binary  
in the TXT records. Sure we need to keep record size in mind but for  
many cases, I can imagine an value containing an IP address to be much  
easier to work with in ascii than binary. [not to mention v6 address  
are sometimes smaller in binary than ascii]. I think the person  
defining the tags needs to carefully consider the representation  
keeping size limits in mind but ASCII is going to be easier to work  
with in many environments - particularly when using existing DNS  
servers and tools

In section 12, it was not clear to me why and when you needed this. I  
suspect a little more motivation is needed here about what types of  
applications need to use these and when.

Section 13.1 Given I would like this to wok with existing DNS servers,  
I think a MAY would  be better than a SHOULD here. Or if you want to  
leave it as a SHOULD, explain when it is OK not to do this.

Cullen in my individual contributor roll

On Nov 4, 2008, at 7:28 , The IESG wrote:

> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive comments to  
> the
> [email-masked] mailing lists by 2008-12-02. Exceptionally,
> comments may be sent to [email-masked] instead. In either case, please
> retain the beginning of the Subject line to allow automated sorting.
>
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-cheshire-dnsext-dns- 
> sd-05.txt
>
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=9784&rfc_flag=0
>
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce

---

From: Stuart Cheshire <[email-masked]>
Date: Mon, 10 Nov 2008 11:31:09 -0800

On 4 Nov, 2008, at 07:50, Cyrus Daboo wrote:

> Hi,
>
> --On November 4, 2008 6:28:19 AM -0800 The IESG <iesg- 
> [email-masked]> wrote:
>
> The IANA section of the dns-sd draft describes a process for  
> registration of SRV service identifiers, but there is another draft  
> doing the same thing: <http://www.ietf.org/internet-drafts/draft- 
> gudmundsson-dns-srv-iana-registry-00.txt>.
>
> So which of these two drafts is meant to define the actual SRV  
> service type registry?
>
> -- 
> Cyrus Daboo

That text has been in DNS-SD since the start, back in 2001 when it  
was called "Discovering Named Instances of Abstract Services using  
DNS" (draft-cheshire-dnsext-nias-00.txt).

I have absolutely no ego at stake over ownership of that issue -- I  
simply put it in because someone pointed out that RFC 2782 failed to  
define an IANA registry for its service names, and since DNS-SD/NIAS  
depends on SRV records and identifying service types by name instead  
of number, without an IANA registry the specification would be  
somewhat handicapped.

Stuart Cheshire <[email-masked]>
* Wizard Without Portfolio, Apple Inc.
* Internet Architecture Board
* www.stuartcheshire.org

---

From: Dave Cridland <[email-masked]>
Date: Tue, 11 Nov 2008 00:07:46 +0000

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

---

From: Mark Townsley <[email-masked]>
Date: Sun, 16 Nov 2008 00:54:33 +0100

Dave Cridland wrote:
> 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.
>
> 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:
>
> 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 
> paragraph are needed here. The rest of the page is waffle and repetition.
>
> 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 
> 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
> 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 
> 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:
>
> than useful. Again, I've seen serious confusion result from this. Zone 
> file format records would be much more useful to most people.
>
> 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.
>
> 8) "Compelling" again. This time in a discussion of printer protocols. 
> I'm pretty sure this is useless waflle.
>
> _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    
> _pdl-datastream._tcp.dns-sd.org.
> _services._dns-sd._udp.dns-sd.org. 3600    IN PTR    
> _printer._tcp.dns-sd.org.
> 10) Aside from the almost obligatory mentions of Malus domestica, this 
> seems reasonably good and useful.
>
> 12) It might be better to refer to the "all-zero" address, or "network 
> address", rather than "base address".
>
> 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 
> 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.
>
> 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 
> 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.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 16 Nov 2008 11:13:49 -0500

>>
> Thank you for your review. Can you point me to any standards track  
> IETF documents which might need normative reference to this document?

One example: draft-lee-sip-dns-sd-uri-03

Henning

---

From: Dave Cridland <[email-masked]>
Date: Mon, 17 Nov 2008 09:38:01 +0000

On Sat Nov 15 23:54:33 2008, Mark Townsley wrote:
>> I note that this document is Informational, yet forms the basis  
>> for standards track documents both in the IETF and other SDOs.

IETF: http://tools.ietf.org/html/draft-lee-sip-dns-sd-uri-03
IETF:  
http://tools.ietf.org/html/draft-garcia-p2psip-dns-sd-bootstrapping-00
XSF: http://xmpp.org/extensions/xep-0174.html

Both the IETF documents have a Normative Ref of dns-sd, the XSF  
document (also Standards Track, and Draft, hence roughly equivalent  
to PS) has a formal dependency on it.

A cursory web search for "dns-sd specification" finds published books  
under the impression that DNS-SD is standards track.

Finally, while looking about for other specifications, I noticed this  
discussion on the KDE list, dating from just over 4 years ago, which  
left me quite impressed.

http://lists.kde.org/?l=kde-devel&m=109916905222337&w=2

I was particularly impressed by the discussion of how DNS-SD and IDNA  
interact, especially if the resolver is designed to handle  
transparent IDNA.

Dave.

---

From: Chris Newman <[email-masked]>
Date: Wed, 19 Nov 2008 17:02:58 -0600

>    <draft-cheshire-dnsext-dns-sd-05.txt> as an Informational RFC

As a technical contributor and end user, I strongly support publication of 
this document, although I would prefer it was on the standards track.  I 
very much appreciate the text discussing why certain design decisions were 
made, as well as mentioning implementation/UI issues where people made 
mistakes in the past.

Other comments:

Section 4:

>   The <Instance> portion of the Service Instance Name is a single DNS
>   label, containing arbitrary precomposed (Unicode Normalization Form C
>   [UAX15]) UTF-8-encoded text [RFC 3629].

Have you considered referencing RFC 5198 instead?  It's based on the same 
normalization form, but has some minor restrictions/clarifications that are 
likely to improve interoperability.  As your current text allows line 
breaks (was that intentional?) it would be helpful to have a canonical form 
for line breaks that 5198 defines.  If you didn't intend to allow line 
breaks you might want to recommend against their use as well.

>   intended to ever be typed in by a user accessing a service; the user
>   accesses a service by selecting its name from a list of choices
>   presented on the screen.

Since this list may also be presented by a screen reader to the blind, and 
selection from the list is a mandatory part of the user experience, have 
you considered adding a way to include a language tag to assist screen 
readers in their translation to voice?  BCP 18 has some discussion of this. 
Is there implementation experience that a language tag is not necessary for 
this situation?

Section 19:

What is the title of the registry that will be listed on IANA's web page?

Do you believe it would be possible to merge the new service registry with 
this one:
  <http://www.iana.org/assignments/gssapi-service-names>
creating a single service-name registry shared by these protocols?

		Thanks,
		- Chris

---

From: Marc Manthey <[email-masked]>
Date: Tue, 25 Nov 2008 15:55:50 +0100

Am 20.11.2008 um 00:02 schrieb Chris Newman:

> --On November 4, 2008 6:28:19 -0800 The IESG <iesg- 
> end user, I strongly support publication of this document,

hello all,

if this is the  " question "  , i would recomend that  as an "end- 
user" too ,
just currious that mr. cheshire does not respond;)

> Do you believe it would be possible to merge the new service  
> registry with this one:

have a great  day

Marc

-- 
Marc Manthey
Hildeboldplatz 1a D - 50672 Köln - Germany
Tel.:0049-221-3558032
Mobil:0049-1577-3329231
web : http://www.let.de
PGP/GnuPG: 0x1ac02f3296b12b4d