Hi.
Since the Last Call ends tomorrow and much of what I have to say
about this draft is really more general observations about
architecture and IETF procedures about which the draft is either
the beneficiary or the victim, this is a short and focused note
for the Last Call and those who are not interested in my
(inevitably longer) musings and/or explanations of concerns.
We have dug ourselves into a bit of a hole (or more than one)
wrt mechanisms for resolving references and DNS entries that
reference other DNS entries, some of them with the potential for
triggering multiple trips to the DNS with intermediate
processing. Independent of that problem (see other note), I
believe this I-D should be approved, and approved as a Proposed
Standard, on the grounds that we (and the Internet) are better
off with it than we are with only the NAPTR record and its
S-NAPTR refinement.
I do note that having "priority" and "weight" separated is not
well-motivated (or even explained) in either this document or in
the original application. Certainly we have had sufficient
experience with confusion about MX and SRV priorities to be
cautious about adding another ranking field, especially one
whose values are interpreted as "largest integer has the highest
preference" while the more traditional priority is interpreted
as "smallest integer is highest preference". Because IANA
registered this RR four years ago, it is too late to change that
(see the forthcoming longer note) but somewhat more explanation
in this document would, IMO, be helpful and might even above
confusion-related problems in configuration and implementations.
Noting that none of the examples in -11 use Weight in a
substantive way, I would hope that explanation would include a
discussion of when one would use "Weight" as distinct from
finer-grained Priorities and what benefits would be associated
with using it.
john