RE: Issues with 2052bis (SRV)

["Levon Esibov (Exchange)" <levone@Exchange.Microsoft.com>]

It has been 6 weeks since Robert posted summary on work_items/solutions for
the rfc2052bis (SRV records). I assume that the workgroup agrees on the
suggestions, per Robert's message "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.".

At this moment I would like to encourage updating the draft based on the
suggestions listed in the original Robert's e-mail. Although most of changes
are straightforward, some issues (like 6-8 below) require new text. I am
ready to offer the authors assistance in updating the draft, if that would
be helpful. The updated draft will be presented to the workgroup for final
discussion as soon as it is ready.

Thanks,
Levon Esibov

> -----Original Message-----
> From: Robert Elz [mailto:kre@MUNNARI.OZ.AU]
> Sent: Thursday, July 15, 1999 6:13 AM
> To: namedroppers@internic.net
> Subject: Issues with 2052bis (SRV)
> 
> 
> 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
> 
>