Subject: Re: RFC 2782 (SRV RRs) Interop testing report

From: Erik Nordmark <[email-masked]>
Date: Fri, 1 Jun 2001 18:00:33 +0200 (CEST)

> The only section that required the interoperability section is "The format of
> the SRV RR". The format of the records was verified by monitoring the network
> traffic and by performing the tests described below. Note: subsections >
"Priority" and "Weight" describe how application using SRV records to locate >
a server should treat Priority and Weight values specified in the SRV >
records. Interoperability testing of the implementations supporting service >
location mechanism based on the rules described in the "Priority" and >
"Weight" sub-sections should be conducted within the testing of the >
implementations supporting relevant protocol specification corresponding to a
> specific application, not the generic specification of the SRV records, >
rfc2782bis.

The comment about the priority and weight subsections seems a bit odd
given that the specification has MUST and SHOULD laguage for those two
fields in question.

Thus I think there needs to be enough interoperatbility testing
to verify that the language in those subsections is clear enough for
implementors.

So the tests need to take into account the actual software on the clients
which honor the priority and weight fields in the RR - if this isn't done
we have no idea whether the description in the specification is clear enough.

This means testing with different priority and weight fields.

   Erik

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Stuart Cheshire <[email-masked]>
Date: Fri, 15 Jun 2001 18:50:47 -0700

>The comment about the priority and weight subsections seems a bit
>odd given that the specification has MUST and SHOULD laguage for
>those two fields in question.
>
>Thus I think there needs to be enough interoperatbility testing to
>verify that the language in those subsections is clear enough for
>implementors.
>
>So the tests need to take into account the actual software on the
>clients which honor the priority and weight fields in the RR - if
>this isn't done we have no idea whether the description in the
>specification is clear enough.
>

I agree with Erik's comments here.

In addition, I'd prefer that the priority and weight fields have 
precisely defined semantics for all SRV records, without the escape 
clause the RFC currently has, "In the absence of a protocol whose 
specification calls for the use of other weighting information...".

It has previously been noted that, "some programs only try the first 
address they get back from e.g. gethostbyname() and we don't know how 
widespread this behavior is." For this reason, the "Open Transport" 
networking APIs on Mac OS provide a connect-by-name capability, where the 
application just calls "Connect("hostname") and it is the OS 
responsibility to handle multiple addresses, if present, and to try them 
all in order. This makes it much easier for a Mac application to "do the 
right thing" even when the application programmer is not necessarily a 
networking expert.

By the same token, we'd like to make the OS handle SRV records and 
weighted server selection automatically on behalf of the application, and 
that's much easier if the priority and weight fields always have the same 
meanings.

I'd like to remove the escape clause.

Stuart Cheshire <[email-masked]>
 * Wizard Without Portfolio, Apple Computer
 * Chairman, IETF ZEROCONF
 * www.stuartcheshire.org