On Mon, Feb 23, 2015 at 10:05:15AM -0500, John C Klensin wrote:
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.
This is simply carried over verbatim from SRV, where priorities
yield strict ordering, while weights (for entries with the same
priority) support weighted load-sharing. This draft does not appear
to differ from SRV except in replacing target+port with an URI.
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".
I see nothing new added here, it just carries over priority/weight
from SRV, and priority (which takes precedence over weight) is the
same as SRV and MX in as far as lowest number wins. Clearly with
load-sharing relative weights, highest weight gets the most traffic,
but only statistically, some fraction of the time lower-weight URIs
are (to be) used.
While I am here, a few quick (likely not comprehensive) spelling/wording
fixes:
Section 1:
s/For resolution the application need to/For resolution the
application needs to/
s/number of implications/number of limitations/
s/is not replacing/is not intended to replace/
Section 2:
s/repetitive queries/repeated queries/
End of Section 3:
s/stake holders/stakeholders/
Section 4.1:
s/DNS labels that occur in nature/regular DNS labels/
--
Viktor.