Subject: [dnsext] [Technical Errata Reported] RFC2782 (2984)

From: RFC Errata System <[email-masked]>
Date: Tue, 4 Oct 2011 13:39:00 -0700 (PDT)

The following errata report has been submitted for RFC2782,
"A DNS RR for specifying the location of services (DNS SRV)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=2782&eid=2984

--------------------------------------
Type: Technical
Reported by: Jordan Brown <[email-masked]>

Section: Weight

Original Text
-------------
        To select a target to be contacted next, arrange all SRV RRs
        (that have not been ordered yet) in any order, except that all
        those with weight 0 are placed at the beginning of the list.

        Compute the sum of the weights of those RRs, and with each RR
        associate the running sum in the selected order. Then choose a
        uniform random number between 0 and the sum computed
        (inclusive), and select the RR whose running sum value is the
        first in the selected order which is greater than or equal to
        the random number selected. The target host specified in the
        selected SRV RR is the next one to be contacted by the client.
        Remove this SRV RR from the set of the unordered SRV RRs and
        apply the described algorithm to the unordered SRV RRs to select
        the next target host.  Continue the ordering process until there
        are no unordered SRV RRs.  This process is repeated for each
        Priority.

Corrected Text
--------------
Correcting the text requires agreement on what to do with entries with
weight=0, so I don't want to try to craft text until we have agreement there.

Notes
-----
The problem with this algorithm is that for a total weight T, it generates a random number 0..T and so allocates T+1 shares and gives the extra share to the first entry.  Thus with weights {1, 1}, the first entry is selected 2/3 of the time while the second entry is selected 1/3 of the time.

I suspect that this is an attempt to do *something* with entries with weight=0, but yields unobvious results there:  for {0, 1, 1}, the three entries are each selected 1/3 of the time.

I suggest:

- Ordering weight=0 entries to the end.
- Generating random numbers 0..(T-1).
- Using a "greater" test rather than "greater or equal".
- Selecting weight=0 entries in any order when all of the weight!=0 entries have been selected.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC2782 (draft-ietf-dnsind-rfc2052bis-05)
--------------------------------------
Title               : A DNS RR for specifying the location of services (DNS SRV)
Publication Date    : February 2000
Author(s)           : A. Gulbrandsen, P. Vixie, L. Esibov
Category            : PROPOSED STANDARD
Source              : DNS Extensions
Area                : Internet
Stream              : IETF
Verifying Party     : IESG
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 05 Oct 2011 08:00:36 +0900

>From examples of the RFC:

      ; NO other services are supported
      *._tcp          SRV  0 0 0 .
      *._udp          SRV  0 0 0 .

it is obvious that weight=0 means that the RR must not be
selected.

> - Using a "greater" test rather than "greater or equal".

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 05 Oct 2011 09:22:31 +0900

Jordan Brown wrote:

> Perhaps, but on the other hand it also says:
> 
> Domain
> administrators SHOULD use Weight 0 when there isn't any server
> selection to do, to make the RR easier to read for humans (less
> noisy). In the presence of records containing weights greater
> than 0, records with weight 0 should have a very small chance of
> being selected.

Hmmmm, as the RFC says:

	Domain
        administrators SHOULD use Weight 0 when there isn't any server
        selection to do, to make the RR easier to read for humans (less
        noisy).

        A Target of "." means that the service is decidedly not
        available at this domain.

weight=0 in the examples I showed should not be significant, sorry.

Then, I agree with you, except that

	- Selecting weight=0 entries in any order when all of
	the weight!=0 entries have been selected.

should be:

	- Selecting weight=0 entries in random order when all
	of the weight!=0 entries have been selected.

						Masataka Ohta

---

From: Douglas Otis <[email-masked]>
Date: Tue, 04 Oct 2011 18:21:21 -0700

> 	of the weight!=0 entries have been selected.
Even use of "." as a null target is problematic when this convention is 
ignored.

What problem does a "." (null) service reference improve over simply not 
having an entry?  The use of wildcards for _label._label services seems 
rather limited.

-Doug

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 05 Oct 2011 10:28:57 +0900

Douglas Otis wrote:

> Even use of "." as a null target is problematic when this
> convention is ignored.

Agreed.

> What problem does a "." (null) service reference improve
> over simply not having an entry?

Not having an entry might mean Name is the Target.

At least, I specified so in draft-ohta-urlsrv-00.txt.

						Masataka Ohta

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 05 Oct 2011 07:20:55 -0700

The algorithm described in RFC 2782 is what it is, and people know how to
configure the values in an SRV RR to achieve what they want.  If some disagree
with this algorithm, they should work on a rfc2782bis document, but not try to
change the meaning of RFC 2782 in an errata.

> "A DNS RR for specifying the location of services (DNS SRV)".

- -- 
Marc Petit-Huguenin
Personal email: [email-masked]
Professional email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 05 Oct 2011 08:46:42 -0700

On 10/05/2011 08:40 AM, Jordan Brown wrote:
> On 10/05/11 06:03, Marc Petit-Huguenin wrote:
>> Could be.  I just wanted to point out the inconsistency in the specification;
>> some parts say to choose proportionally (note the example that says that {1,3}
>> yields {1/4, 3/4}, when it actually yields either {2/5, 3/5} or {1/5, 4/5}
>> depending on the order reported) but the algorithm doesn't quite do that.
> 
>> For small weights the difference is significant.  For large weights it's not.

Yes, so perhaps the errata should be to say something like "Try to use weights
as high as possible, unless you use the value 0".

- -- 
Marc Petit-Huguenin

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 05 Oct 2011 09:11:21 -0700

>> depending on the order reported) but the algorithm doesn't quite do that.

Well, { 3/10, 7/10 } if each client randomizes the order each time and restarts
with a new list after each successful connection (which is another
underspecification in RFC 2782 that IMO would justify an rfc2782bis).

- -- 
Marc Petit-Huguenin

---

From: Jordan Brown <[email-masked]>
Date: Tue, 04 Oct 2011 16:21:57 -0700

Domain

---

From: Jordan Brown <[email-masked]>
Date: Wed, 05 Oct 2011 08:40:30 -0700

On 10/05/11 06:03, Marc Petit-Huguenin wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>

Could be.  I just wanted to point out the inconsistency in the 
specification; some parts say to choose proportionally (note the example 
that says that {1,3} yields {1/4, 3/4}, when it actually yields either 
{2/5, 3/5} or {1/5, 4/5} depending on the order reported) but the algorithm 
doesn't quite do that.

>> Reported by: Jordan Brown<[email-masked]>
>>
>> Section: Weight
>>
>> Original Text
>> -------------
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> iEYEARECAAYFAk6MVboACgkQ9RoMZyVa61fVRwCeKycrXn6Ceqfq9fczvT4jzRBb
> grAAmwdkJqmDrBTOdEZ1hS0O7IyMd9bR
> =cOUW
> -----END PGP SIGNATURE-----

---

From: Jordan Brown <[email-masked]>
Date: Wed, 05 Oct 2011 08:48:19 -0700

> as high as possible, unless you use the value 0".

Yes, that would be a reasonable response.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 06 Oct 2011 08:58:50 +0900

Marc Petit-Huguenin wrote:

> configure the values in an SRV RR to achieve what they want.

Not at all.

As the specification is on implementation details, logically
inconsistent to the rest of the RFC, people should have no
idea how to use weight=0.

> If some disagree

The problem is that RFC2782 has internal inconsistency because
of overspecification on implementation details.

						Masataka Ohta