Subject: Issues with 2052bis (SRV)

From: Robert Elz <[email-masked]>
Date: Thu, 15 Jul 1999 15:12:53 +0200

Areas of concern with rfc2052bis (SRV records)

The following have been identified as things that need to be fixed in the
current version of 2052bis.   Some of these date back to when this was
discussed in February, but since there hasn't been a new draft since then
they are repeated here (even where the WG has already agreed on a course of
action, months ago).

The summaries below take into account the reactions of the attendees
at the DNSIND/DNSSEC meeting in Oslo, and are offered to the list as
potential solutions.   In some cases the suggestions here have been
influenced by more discussions since the WG meeting.

If the WG as a whole can agree on these modifications, or something
similar, then it ought to be possible to get 2052bis agreed as a PS
and published as an RFC relatively soon (nb: relatively...)

Issue 1:

The biggest concern is still what to do with the examples.  Of those there
are two types of immediate concern.

First, there's the introductory example right at the start of the doc,
which serves to introduce the concept.

Second, there are the worked examples later in the draft (how one actually
moves from a desire to connect to an address).

There seem to be 4 options for handling those two (and no need to select
the same option for each).

	a. Simply delete all the examples
	b. Leave the examples as they are, and just make it clearer
		that the protocols used are merely for explanation.
	c. Use fictitious protocols (the example protocol, or the foobar
		protocol)
	d. Use examples from protocols that really are using SRV

No-one has suggested (a), or not seriously, examples seem necessary to
this document, so it is suggested tat be ruled out as an option.

(b) has been suggested, but my impression is that the doc will not
succeed if we continue down that route (it might be possible, but it
will be harder).

(c) has the advantage that no-one can rationally be confused into simply
blindly copying the examples, and even if they do the worst possible harm
is some wasted space in their DNS servers.   It has the disadvantage that
it is harder to get a grasp on what is really being done for some protocol
about which no details at all are known, other than its supposed name.

(d) has the advantage that there are real protocols, with real uses.  It
has the disadvantage that many of the SRV protocols are not widely known,
and there is no guarantee at all that when they're finished being defined
they will still be using SRV, or perhaps worse, still be using it the way
2052bis would document it (perhaps the name associated with the port number
for the protocol might be altered, or something).

The suggestions are to go with (d) using ldap for the introductory example.
This has the advantage that it is a real protocol, not totally obscure,
and is apparently already being deployed by Microsoft as documented in the
draft draft-armijo-ldap-locate-00.txt so it is not likely to change.

Then, go with (c) for the worked example (whether it is the "example"
protocol, or the "foobar" protocol, or something else doesn't seem to
matter).   That means that this draft won't be subject to the whims
of anyone else when it gets down to the details of exactly how the
application performs the lookups.

Issue 2:

It has been suggested that the following two paragraphs be added to the
draft.  The attendees in Oslo had no problems doing this ...

    Note: There are currently various experiments at providing relative
    network proximity estimation, available bandwidth estimation, and
    similar services.  Use of the SRV record with such facilities, and in
    particular the interpretation of the Weight field when these
    facilities are used, is for further study.

and

    Weight is only intended for static, not dynamic, load balancing.
    Using SRV weight for dynamic load balancing would require
    assigning unreasonably short TTLs to the SRV RRs, which would 
    limit the usefulness of the DNS caching mechanism, thus increasing
    overall network load and decreasing overall reliability, and
    generally creating a public menace.  Load balancing via SRV is
    only intended to express static information such as "this server
    has a faster CPU than that one" or "this server has a much better
    network connection than that one".

Issue 3:

This paragraph (currently in the draft) ...

    In general, it is expected that SRV records will be used by clients
    for applications where the relevant protocol specification indicates
    that clients should use the SRV record.   The examples in this
    document use familiar protocols as an aid in understanding.  It is
    not intended that those protocols will necessarily use SRV records.

is considered inadequate.

That is actually attempting to do two things.   First, it is indicating that
SRV should only be used when a spec says to use it for some protocol.
That's the first sentence.   The latter two sentences are the "let out"
for using examples in the draft which use existing protocols that don't
really use SRV.

Now, if we assume that the examples are to be changed (issue 1), then the
last two sentences are not needed, though a brief intro to the worked
examples indicating that a fictitious protocol is being used would be needed.

In place of the first sentence, the following s suggested:

    In general, it is expected that SRV records will be used by clients
    for applications where the relevant protocol specification indicates
    that clients should use the SRV record.  SRV records SHOULD NOT be
    used in the absence of such a specification.

Note that of all the issues covered in Oslo, this was the only one that
received anything noticeable in terms of dissent.   Some felt that anyone
should be free to use SRV for anything they like, and indicated that was
what they are already doing.   It is unlikely that that approach will pass
the IESG though.   It is also true that nothing in any RFC can force
or prohibit any behaviour on your own network - everyone is free to do
what they like there.  In general you're free to do what you like
over the Internet too - the issue is whether you can expect anyone else
to understand, and co-operate.   Overall the WG meeting attendees
seemed content to include this text.

Issue 4:

There is text in the draft, concerning the weight algorithm, which
suggests that the algorithm SHOULD be used.   That is what has been
agreed by the WG previously.   There is also a sentence which says...

    A client MAY use means other than Weight to choose among target
    hosts with equal Priority.

There is some concern that this is contradictory, likely to lead
to confusion, and not in accordance with the 2119 definition of MAY
in any case.   The suggestion is that this sentence simply be
deleted from the draft.

Issue 5:

The text about the weight algorithm begins ..

    A load balancing mechanism.  When selecting a target host among
    the those that have the same priority, the chance of trying this
    ....

It was suggested in the WG meeting that some of the problems with
2052bis come from exactly this, and that it would be a good idea to
replace "load balancing" there (and I assume anywhere else it happens
to occur" with "server selection".

Issue 6:

It has been suggested that the actual description of the weight
algorithm is unclear.   The suggestion was (originally) that it
be replaced by the following text.

    A load balancing mechanism.  The weight field specifies a relative
    weight for entries with the same priority. Larger weights SHOULD be
    given a proportionately higher probability of being selected. The range
    of this number is 0-65535.  This is a 16 bit binary integer in network
    byte order.  Domain administrators SHOULD use Weight 0 when there
    isn't any load balancing to do, to make the RR easier to read for
    humans (less noisy).  In the presence records containing weights
    greater than 0, records with weight 0 have a very small chance of
    being selected.

    In the absence of a protocol whose specification calls for the use
    of other weighting information, implementations SHOULD implement the
    effect of the following algorithm:  Each time a target is needed, the
    client orders the remaining (not previously used) SRV RRs at the
    current priority in any random fashion, 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. Note that the random numbers used
    here MUST NOT be restricted to integer values if this algorithm is to
    work properly.

It was later pointed out that this seems to suggest that floating point
must be used, which would make implementation difficult on systems with
no floating point capabilities (no hardware, no software either).   Since
it is entirely possible to implement a suitable algorithm, entirely in
integer arithmetic (hardware integer arithmetic) - typically using some
fixed point scheme, it has ben suggested that this should be reworded
yet again to avoid the floating point suggestion.   Text is welcome...

Issue 7:

It has been suggested (requested, required, whatever you like) that the
section giving the changes from 202 be expanded a little, and in particular
that it indicate that it note that the weight field is now much more
clearly defined.

Issue 8:

It has been requested (required, ...) that a template be provided showing
what is required of authors of specs which are to use SRV records.  That is
it needs to set out what such a spec needs to define in order to correctly
specify the use of SRV records.   This is one of the old issues that the
WG agreed to proceed on months ago.

Issue 9:

The sentence ...

    else if the service desired is SMTP (and SMTP has been defined
    elsewhere to expect SRV lookups)

	    skip to RFC 974 (MX).

has been read two different ways.  One as "if A and B", and the
other as "if (A)" (and by the way, SMTP has been defined...)

It was generally agreed that the way to fix this one is to simply delete
all references to SMTP and MX records from the draft.  This is a side
effect of replacing the examples to remove protocols which don't use
SRV records, but this one was generally agreed should be removed, whatever
was done with the other examples.

Issue 10:

Typos...

The reference to BCP 14 should be [BCP 14] so it is clear it is a reference.
And
	s/the authors believes/the authors believe/

The first of those is also old, and was agreed months ago, the second
I cannot imagine is going to cause us a problem..

All of these are open to discussion on the list.   For any where there
is no discussion, it will be assumed that the suggestion in this message
(where one exists) is agreed, and will be implemented in the draft.

After discussions with the ADs, the milestone on getting this doc done
has been modified from April 2013, to April 2038 ...   But it would be
kind of nice to surprise everyone and actually finish it this century
(though I am not going to enter the debate about which year that means).

kre