Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)
draft-daigle-snaptr-01

[Ballot comment]
Nits/Editorial


  of a named application service.  The application client MUST select
  one protocol to choose The PREF field of the NAPTR RRs may be used by
  the domain administrator to The first DNS query is for the NAPTR RRs

Missing "."?

>    identify the server as being authoritative for the original taret

s/taret/target/

> 6.5.2 Application Protocols
>
>    The protocol identifiers that are valid for the "app-protocol"
>    production are any standard, registered protocols [IANA registry
>    again -- is this the list of well known/registered ports?].


It would be good to be more clar about what "registered protocols"
are. Can you name the "name space" within IANA that is meant here? Oh,
I guess you mean to refer to the  IANA registry that _this_ document
creates. Right? This could be made more clear (think about how you
want this worded in the final  RFC).

[Ballot discuss]
> 7.3 Registration Process

IANA considerations could be more clear here (in terms of RFC 2434 (or
similar) language). Just what the requirements are for a new
registration. I.e, what level of review is required, and who does the
review? (This is especially true now that there will be RFCs that are
essentially unreviewed by the IETF.)

[Ballot comment]
This document has some very long lines.  The author should come up with a
  presentation for this information that fits the line length limits.

[Ballot discuss]
The security considerations say:
  >
  > The security of this approach to application service location is only
  > as good as the security of the DNS servers along the way.  If any of
  > them is compromised, bogus NAPTR and SRV records could be inserted to
  > redirect clients to unintended destinations.  This problem is hardly
  > unique to S-NAPTR (or NAPTR in general).
  >
  From the client perspective, it acts in the information received in a
  response to a DNS query.  Without authentication, the response could
  be from a party other than the DNS server.  DNSSEC is one solution.

[Ballot discuss]
The IANA considerations don't say what sort of RFC is needed for new registrations.  Are the categories in 2434 sufficient?

The Security Considerations section needs some tweaking.  In particular, the 4-step algorithm probably needs to say something about setting up an integrity-protected channel.  Also, DNSsec should be mentioned as a counter to some of the attacks -- it's not just "the security of the DNS servers along the way" that can lead to trouble.  Perhaps cite the DNS Threats document we approved recently?

IANA Last Call comments:

We understand 2 registries to be set-up.

S-NAPTR Application Service Tags
S-NAPTR Application Protocol Tags

In sections 7.1 and 7.2, there are pointers to
the initial registrations.  However, we would like to
confirm that these are not to be registered until those
drafts are approved to become RFCs as the registration
rules indicate a RFC is needed for assignments to be
made.