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