Subject: Re: DNS SRV question (was Re: please post updated draft)

From: Jeffrey Altman <[email-masked]>
Date: Tue, 26 Oct 99 14:09:29 EDT

> The real issue, of course, is the wording in the SRV document.  Why
> can't it just be accepted that people are going to use SRVs for stuff
> that simply has no relevance to the Internet at large, but may be very
> relevant/useful/necessary for the local site that is using it?

Someone on the IESG would have to answer this one.  We at Columbia
University use DNS SRV records with "telnet" protocol against the
wishes of the IESG.  We have an old telnet client that we can't
replace that is hardcoded to port 23 and which explodes if it receives
a telnet option above 34 (LINEMODE).  

For implementing secure telnet we use a non-standard port number and a
client that uses DNS SRV to find out the port to use for telnet.  When
we are able to abandon the broken client and move secure telnet to
port 23 we will redirect the DNS SRV records to point to port 23.

I really don't understand the IESG's problem with using DNS SRV to
specify port numbers, priorities, and weights for IETF protocols that
do not make it a requirement.  

    Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
                 The Kermit Project * Columbia University
              612 West 115th St #716 * New York, NY * 10025
  http://www.kermit-project.org/k95.html * [email-masked]

---

From: Paul A Vixie <[email-masked]>
Date: Tue, 26 Oct 1999 11:18:43 -0700

> do not make it a requirement.  

it's a vision thing.  (and btw, this is the reason i stopped pushing SRV.)

---

From: David Shaw <[email-masked]>
Date: Wed, 27 Oct 1999 11:44:48 -0400

> do not make it a requirement.  

I don't understand the IESG's problem with using SRV with *NON*-IETF
protocols.  If I want to invent the new-and-improved "David protocol",
and use SRV to specify ports, priorities, and weights, according to
that draft I can't.  Even if it is being used on my own network, and
never used elsewhere, somehow it's a no-no.

It makes no sense at all.

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

---

From: Thomas Narten <[email-masked]>
Date: Wed, 27 Oct 1999 15:28:02 -0400

> never used elsewhere, somehow it's a no-no.

I don't believe it is the intent to disallow the use of SRV with
non-ietf protocols. The intent is to disallow it in general in the
absence of a specific document describing how a specific
application/protocol is to use SRV. If one wants to invent a new
protocol, documenting it is to use SRV at that point would of course
be the logical thing to do.

Thomas

---

From: David Shaw <[email-masked]>
Date: Thu, 28 Oct 1999 00:29:07 -0400

> be the logical thing to do.

Okay, that was my main concern.  So if I understand things correctly
now, the Applicability Statement is intended to say "any protocol that
someone is going to use SRV for, should be a protocol that is
documented to use SRV".  I don't necessarily agree with it, but at
least I understand it.

I also think Michael Mealling's point about just writing a series of
"Using SRV with (insert name here)" documents is a good one.  My main
concern is to clarify the usage of SRV with non-IETF protocols.

Using my example from before, if I create the "David protocol", how do
I "document" it to use the SRV protocol?  Is it enough to say that
since I invented it, I can make SRV a part of it?  I guess I'm asking
what sort of documentation is necessary here.

The Applicability Statement also says "Such specification MUST define
the symbolic name to be used in Service field of the SRV record as
described above."  This can be a real problem: If I create my own
protocol, and "define the symbolic name", how do I prevent my symbolic
name from colliding with an IETF-assigned STD 2 symbolic name?
(i.e. what stops me from deciding to give my new protocol the symbolic
name "http"?)

I'd like to suggest a small change to say that if a non-STD 2 symbolic
name is created, it should be prefixed with an "x-".  That will
accomplish two things: one, it addresses the possible name collision
between a local and STD 2 symbolic name, and two, it makes it clear
that such local usage for non-IETF protocols is permissible.  Using an
"x-" is a natural choice from many other naming conflict issues.

Incidental typo: "Such specification MUST define the symbolic name to
be used in Service field of the SRV record as described above." is
missing the word "the" before the word "Service"

David