Subject: please post updated draft

From: "Levon Esibov (Exchange)" <[email-masked]>
Date: Thu, 14 Oct 1999 18:00:26 -0700

Please post the attached updated draft-ietf-dnsind-rfc2052bis-03.txt
(supercedes the -02 version).

Thank you!
Levon.

 <<draft-ietf-dnsind-rfc2052bis-03.txt>>

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 18 Oct 1999 17:52:39 -0700 (PDT)

I have a question on the intent of our old friend the weight field.
The draft says:
							Each time a
	target is needed, the client orders the remaining (not
	previously used) SRV RRs at the current priority in any order,
	except that all those with weight 0 are placed at the beginning
	of the list. 

If an RRset contain two records: one with weight 10 and one with weight 90
isn't the intend that about 90% of the load we directed at the latter?

The "remaining (not previously used)" seems to make a single client
talking to the service do a 50/50 load split:
1. The first request will have the 90/10 split. Suppose it picks the 90%
record. 2. The next request will only consider the weight 10 record.
3. The 3rd request will what? fail since there are no more records to
   consider?

Puzzled.

Also in section "Usage rules" it says:
             For each distinct priority level
                  While there are still elements left at this priority
                  level
                       Select an element randomly, with probability
                       Weight, as specified above, and move it to the
                       tail of the new list
Should it be "... with probability Weight/(sum of Wights at this priority 
level)"?

  Erik

---

From: David Shaw <[email-masked]>
Date: Wed, 20 Oct 1999 22:41:31 -0400

I wonder if someone could clarify how these two statements in
draft-ietf-dnsind-rfc2052bis-03.txt work together?

>    Service
>         The symbolic name of the desired service, as defined in Assigned
>         Numbers [STD 2] or locally.  An underscore (_) is prepended to
>         the service identifier to avoid collisions with DNS labels that
>         occur in nature.
> 
>         Some widely used services, notably POP, don't have a single
>         universal name.  If Assigned Numbers names the service
>         indicated, that name is the only name which is legal for SRV
>         lookups.  Only locally defined services may be named locally.
>         The Service is case insensitive.

Here the service can be defined officially (via STD 2) or "locally",
which to my eye means "anything I make up as long as I don't expect
anyone else to support it in any way whatsoever".

> Applicability Statement
> 
>    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. Such specification MUST
>    define the symbolic name to be used in Service field of the SRV
>    record as described above. It also MUST include security
>    considerations. Service SRV records SHOULD NOT be used in the absence
>    of such specification.

The last sentence says that SRV records should only be used if there
is a specification on how they are supposed to be used.  (That seems
rather intuitive to me - without any specification, how could you use
them anyway?)

Or is this meant to refer to a *public* specification?  If so, then
how does that jibe with the "locally defined" services mentioned
earlier?

David

-- 
   David Shaw  |  [email-masked]  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson