Subject: draft-ietf-dnsind-rfc2052bis-02.txt

From: Thomas Narten <[email-masked]>
Date: Fri, 26 Feb 1999 07:14:51 -0500

This document did not clear the IESG yesterday. The APPs ADs raised
four issues (appended).  Point 2 is a nit that I doubt would have been
raised in the absence of the other issues. Point 3 will make life
easier for authors of future documents that specfy SRV be used, so I
have to agree that this one makes sense. In any case, since text has
been provided, this hopefully won't pose a significant burden.

Points 1 & 4 may be more contentious.  Do you have thoughts on how
best to proceed here? My concern is having the document stall for an
extended period of time.

These were the only issues raised. Modulo these comments, the document
would have been approved.

Thomas

Reasons:

1. Despite the applicability statement, the example of using a SRV
   record to look up an HTTP URL is just too prominent and too
   likely to be misinterpreted.  SRV is not defined for use with HTTP,
   and it's not clear that SRV alone will be used with HTTP.
   (though SRV might be used in conjunction with NAPTR)
   
   The easiest thing to do is to remove the introductory example.
   Or it could cite SIP, since the behavior of SIP and SRV is
   already defined.

2. In Definitions, the reference to BCP 14 should cite RFC 2119 
   as a reference.  (the reader is far more likely to understand
   how to find RFCs than BCPs)

3. There needs to be a template that is used to define 
   application use of SRV.  I suggest adding a section:

----------------------------------------------------------------------
Use of SRV records by applications.

   The specific usage of SRV records may vary from one application 
   to another.  SRV records SHOULD NOT be used with any particular
   protocol until the specifics of such usage are published in an RFC.
   Specific instructions for use of SRV for any protocol MUST include 
   the following: 

   a) The DNS label to be used for SRV queries associated with this
      protocol.  

   b) If the protocol can be used over both udp and tcp, the rules
      by which the application decides how to choose between them.

   c) The interaction or precedence between SRV and any other 
      resource discovery mechanisms which are defined for applications
      using this protocol, including fallback behavior when SRV
      records are not present.

   d) Recommendations for whether the 'Weight' field of the response
      should be used or ignored, and if used, how the Weight field
      should be employed.  Such recommendations may simply refer
      to the algorithm supplied in draft-ietf-dnsind-rfc2052bis-*
      or they may supply a different algorithm entirely.
----------------------------------------------------------------------
   
4. Use of the weight feature should be defined on a per-application basis.
   Some applications may need to define their own weighting or load-
   balancing schemes, which might either use the Weight field in a
   protocol-specific way or ignore it entirely.  Even the authors of SRV 
   admit that DNS is not a good place to put weighting, so the weighting 
   scheme recommended in SRV should not be assumed to be universally 
   applied.  

suggested replacement for the definition:

   (bottom of page 3, after Priority)

----------------------------------------------------------------------
   Weight
	This field is intended for use by protocols which wish to
	implement a DNS-based load-balancing mechanism.  The Weight
        field contains an integer in the range 0-65535.  

	Weight is intended to allow selection from among several records
	of equal Priority.  Beyond that, the specific interpretation 
	of the Weight field is defined by each protocol that wishes to 
	use it, though it is expected that a record with a smaller Weight 
	has a lower priority of being selected than a record with a larger 
	Weight.  A sample algorithm for use of Weight in record selection 
	is given below.

        For protocols that do not employ the Weight field, or in cases
        where no load-balancing is needed, domain administrators are 
        urged to supply a Weight of 0.  This will make the RR easier for 
        humans to read (less noisy).  
----------------------------------------------------------------------

suggested replacement for the section:
----------------------------------------------------------------------
The "Weight" field

   The Weight field is intended to facilitate load balancing between
   serves for an application.  However, because the actual load on
   typical servers may change too quickly relative to the amount
   of time that the SRV records are cached, and because some applications
   may define their own load balancing schemes which do not use SRV,
   the use of the Weight field is protocol-specific.  (i.e. not all
   protocols will use Weight but any given protocol which defines a
   use of SRV may recommend or require that Weight be used in some 
   particular way)

   The following algorithm MAY be employed by protocols which wish
   to employ the Weight field in selection of a server.  The algorithm
   assumes that a client may potentially need to attempt to contact 
   several target servers until it finds one which is able (reachable,
   not too busy, etc) to serve its request.

   Each time a target is needed, the client should order the remaining 
   (not previously used) SRV RRs at the current priority in any random 
   fashion, except placing all those with weight 0 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 random number (not necessarily of integral value)
   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.
----------------------------------------------------------------------

Thomas