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.