I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-cheshire-dnsext-dns-sd-05
Reviewer: Ben Campbell
Review Date: 2008-11-13
IETF LC End Date: 2008-12-02
IESG Telechat date: (if known)
Summary:
This draft is on the right track, but there are open issues that
should be considered prior to publication.
General Comments:
-- Intended Status
I am not sure I understand the intent of this draft. It has an
intended status of "informational", but it defines protocol of a sort,
or at least conventions that would benefit from standardization. I
don't think that is necessarily a problem per se, if the intent is
something along the lines of "here's a protocol used by certain
deployed products, and if you want to interoperate with them you can
follow this" If that is the case, it would help to be explicit about
it in the first few paragraphs of the intro, and perhaps even the
abstract. Or maybe a "Scope of Applicability" section.
I further note that there are multiple last call comments that suggest
this should be a proposed standard, and that there are proposed
standard efforts that would like to use it.
[I fully admit to not knowing the history that led to this work being
"informational", so there may be very good reasons I don't know about.]
-- Relationship to existing work
On a shallow review, certain aspects of this draft seem to compete
with some of the DDDS/NAPTR work, for example, RFC 4848 and 3958. I am
curious what how this draft relates to that, and what benefits the
author's believe DNS-SD has over, say, U-NAPTR. (This comment is
somewhat dependent on the above comment about intended status--if this
is truly informational, then it's probably not a problem if it
competes with existing work. But if it became a proposed standard, it
would be useful for it to contrast itself to RFC 4848 and/or RFC 3958)
-- User Interface recommendations:
While there is good information here, I wonder why it belongs in this
draft, rather than in a separate paper. While most of the draft
describes how to implement DNS-SD, The user interface considerations
sections really serve to evangelize subjective viewpoints (most of
which I agree with, btw) on UI design. UI design is not something the
IETF tends to take on in general. Again, this interacts a bit with my
"informational" vs "proposed standard" comments above. While most of
the draft could conceivably appropriate for a standards track RFC, the
UI considerations section is truly "informational" or possibly BCP
material.
Also, I assume the UI guidance would apply to other service discovery
mechanisms as well. If so, that further supports separating it out.
-- Tone
Several parts of this draft have a strong marketing tone. An RFC
should take more of an objective engineering tone. I will point out
some specific (but non-exhaustive) examples in the detailed comments
below.
Specific Comments:
--Section 3, 4th paragraph: "... so simple to implement..."
This is a very vague test. How do you define "simple to implement"? I
personally know of implementors and operators that struggle getting
basic DNS right.
-- 5th paragraph:
Does this draft purport to meet the requirements in [ATalk]?
-- Section 4.2, example 3 paragraphs from end:
The"XXX Floor.apple.com" examples should use example.com
-- 2nd from end: "... this document recommends..."
Since you are using 2119 normative language elsewhere, I suspect this
should have been a normative statement. (that is, s/recommends/
RECOMMENDS)
-- Last paragraph: "... MAY choose to retry the query using Punycode"
Did you really intend that to be a MAY? This seems to imply that it is
possible to have records that you cannot successful query without
using Punycode--which would seem to support making this at least a
SHOULD.
-- Section 4.5.3, 2nd paragraph:
nit - it might be better to avoid the term "machine" and instead use
"name server" or maybe even "zone", since these do not necessarily map
to a single piece of hardware.
-- Section 5, last paragraph:
This effectively says that SRV clients SHOULD do SRV correctly. That
seems a little weak--but since this paragraph really only restates
requirements from the SRV RFC, you can probably drop in entirely, or
if you want it for background purposes, restate it descriptively
rather than normatively.
-- Section 6.7, paragraph 1
Is this recommendation intended to be normative?
Also, in the last sentence, do you want to encourage clients to ignore
_lower_ version numbers? Doesn't that hurt backward compatibility?
-- Section 8
This entire section seems to assume that devices are creating their
own SRV records. You mention elsewhere that this is not a requirement,
and that manual administration is a valid approach. It might help to
also describe the things in this section from an administrator's
viewpoint.
-- Paragraph 6 : "Typically the flagship protocol is the oldest and/or
best-known protocol of the set"
That surprises me--I would have guessed the flagship to be the one
that best met the needs of the application--which is unfortunately
subjective. On the other hand, if devices create their own "flagship"
entries, then this only seems to work if the flagship is the lowest
common denominator. This would almost seem to imply a normative
statement that the flagship MUST or SHOULD be the lowest common
denominator, or you are going to have devices disagreeing on what the
flagship should be.
-- 2nd to last paragraph:
This seems to address my previous comment somewhat--but who decides
the flagship for a given class? Should their be a registry?
-- Section 12, first paragraph after bullet list: "These domains are
purely advisory."
Is it safe to assume that, while it is optional to use these domains
for the purposes listed, they MUST NOT be used for other purposes?
-- Section 13.1:
For the record, this is counter to the existing guidance for PTR,
which says that no additional section processing is needed. Do you
expect DNS servers to be aware that DNS-SD PTR records are different
than other PTR records and treat them differently?
-- 13.2
Is this advice any different than that for SRV in general? If so, then
my same comment from 13.1 applies. If not, then there is no need to
restate it normatively here.
-- Section 14:
You compare DNS-SD against non-DNS methods, but you do not compare it
against things like DDDS/NAPTR, etc. That comparison would be helpful.
-- Section 16.1, numbered list:
It is not clear to me if this section talks about what to provision
into DNS records, or what clients should display if they notice
conflicts. I _think_ you are talking about the first. Are you assuming
automatic generation of the DNS records (e.g. via DDNS)? If so, it is
probably worth discussing this from a manual provisioning perspective
as well.
-- Section 16.1, list of printer names:
I would suggest hypothetical names, rather than real products. Also,
you suggest that printer makers email the authors to get added to the
list--you realize that this can't happen once this becomes an RFC,
right?
-- Section 16.2
This whole section seems full of stealth marketing. You describe UI
mistakes, all of most of which can be attributed to a particular
vendor I won't name, then you describe "better ways", most or all of
which can be attributed to a certain competing vendor. It would help
to restate these from a more objective viewpoint--or at least don't
make the identity of the guilty so obvious
For example:
OLD:
(b) display some animation like a searchlight
sweeping back and forth for ten seconds, and then
(c) at the end of the ten-second search, display
a static list showing what was discovered.
NEW:
(b) display an indication that the
host is searching for the resources, and then
(c) after a predetermined time period, display a static list
showing what was discovered so far.
-- Section 18
Single paragraph security considerations sections make me nervous.
Have you thought about whether the advertising of services in DNS
increases the impact of DNS attacks over and above simple name
translation? That is, is it more important to use DNSSEC for DNS-SD
than for conventional DNS usages? Is it okay for clients to simply
accept services as valid because they discovered then via DNS-SD, or
should they apply additional authentication?
-- Section 19, paragraph 1:
The fact that RFC2782 did not create a application id registry does
not close the door on having one. I don't know if this draft is the
right place to do it--but if one is needed one should be created. I
note at least one other draft (draft-gudmundsson-dns-srv-iana-
registry-00) that is attempting to do so--perhaps this section could
be used as input to that, or some other effort.
-- paragraphs 2 and 3:
That's a lot of rules for IANA to enforce. You would probably be
better off making the registry "expert review" from day one, and let
the reviewers enforce the rules. Also, since I assume this would be a
general registry of SRV application identifiers, are these rules
general, or specific to DNS-SD? If the second, then an expert review
would probably be even more important.
Also, shouldn't the application IDs for SRV start with an underscore?
-- 5th paragraph:
I think the risk of collision is higher than you suggest. Names are
not chosen randomly, and it is likely that many implementors would
naturally choose the same name for similar services. For example, I
could see a bunch of implementers jumping on generic names like
"print", "printer", "conference", "storage", etc. I think it would be
better to encourage implementors to register names as early as possible.
-- 2nd to last paragraph: "... applications to remain secret"
I don't think you will find much IETF support for secret IANA
registries. But even if I am wrong, if we have a need for secret
entries here, we are likely to need them for many other things that
IANA manages. If you really want to take up that fight, it might be
better to do it in a separate draft.
-- Final paragraph:
Will this paragraph go away when the RFC is published? How do you plan
to get the existing registered names into an IANA registry?
-- Section 21:
This entire section has a strong "marketing" tone. It's goal is not
clear to me. If it is really needed, can it be de-hyped somewhat? A
few sentences listing products that use DNS-SD and operating systems
for which it is available might be sufficient.
--the IDNITS tool reports the following. I think it is confused about
the weird spacing issue, but probably correct on the domain name and
IP address examples.
Checking boilerplate required by RFC 3978 and 3979, updated by RFC
4748:
----------------------------------------------------------------------------
== It looks like you're using RFC 3978 boilerplate. You should
update
this, as the boilerplate described in the IETF Trust License
Policy
document (see http://trustee.ietf.org/license-info) is accepted
from 10
November 2008, and will be required from 16 December 2008,
01:00 UTC.
Version 1.34 of xml2rfc can be used to produce documents with
boilerplate
according to the mentioned Trust License Policy document.
Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt
:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to http://www.ietf.org/ID-Checklist.html:
----------------------------------------------------------------------------
** There are 9 instances of lines with non-RFC2606-compliant FQDNs
in the
document.
== There are 3 instances of lines with non-RFC3330-compliant IPv4
addresses
in the document. If these are example addresses, they should
be changed.
== There are 1 instance of lines with private range IPv4 addresses
in the
document. If these are generic example addresses, they should
be changed
to use the 192.0.2.x range defined in RFC 3330.
Miscellaneous warnings:
----------------------------------------------------------------------------
== Line 1431 has weird spacing: '...olo.net inte...'
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Missing Reference: 'RFC 3492' is mentioned on line 324, but not
defined
-- Obsolete informational reference (is this intentional?): RFC 2434
(Obsoleted by RFC 5226)
-- Obsolete informational reference (is this intentional?): RFC 2535
(Obsoleted by RFC 4033, RFC 4034, RFC 4035)
Summary: 1 error (**), 5 warnings (==), 2 comments (--).
Thanks!
Ben.
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf