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

From: Paul A Vixie <[email-masked]>
Date: Tue, 26 Oct 1999 12:05:24 -0700

> > it's a vision thing.  (and btw, this is the reason i stopped pushing SRV.)
> 
> Do you have an alternative suggestion?

an alternative to the iesg?  no.

an alternative to srv?  no.

basically there are just whole kinds of things the ietf cannot do.  i think
a number of vendors here who have gone out on their own, know what i mean.
(and this is the reason i don't yell loudly or often at microsoft any more.)

---

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

>> 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: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Tue, 26 Oct 1999 22:05:31 -0400

It seems to me much better to have SRV on standards track with this
funny caveat imposed by the IESG than to let it sit as Experimental.

It's always possible that the "SHOULD NOT" can be removed later
as it goes to Draft or whatever based on experience or changes in 
the IESG.

Donald

From:  Jeffrey Altman <[email-masked]>
Date:  Tue, 26 Oct 99 14:59:02 EDT
Reply-To:  [email-masked]
To:  Paul A Vixie <[email-masked]>
Cc:  [email-masked]
In-Reply-To:  Your message of Tue, 26 Oct 1999 11:18:43 -0700
Message-ID:  <[email-masked]>

---

From: Michael Mealling <[email-masked]>
Date: Wed, 27 Oct 1999 11:12:12 -0400 (EDT)

> as it goes to Draft or whatever based on experience or changes in 

Umm... Once its out there we could also write new documents describing
how SRV is supposed to work with things like HTTP. I for one wouldn't
mind helping write "Using SRV with HTTP" if it'll break this 
document out of its rather peculiar situation....

The URN group has a HUGE dependency on SRV. Let's just let it go
and fix this by explicity defining it for other protocols as needed.

Remember, nothing we write is enforceable and users and implementors will
always do whatever the hell they want...

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | www.rwhois.net/michael
Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:         14198821
Network Solutions	|          www.lp.org          |  [email-masked]

---

From: Mats Dufberg <[email-masked]>
Date: Wed, 27 Oct 1999 21:07:10 +0200 (CEST)

> funny caveat imposed by the IESG than to let it sit as Experimental.

Being new to this business, I really don't understand all this fuss about
SRV. Isn't SRV the scalable and flexible solution that everyone should
want to have for all kind of service in the future, including replacing
MX?

Mats

-----------------------------------------------------------------
Mats Dufberg                                    [email-masked]
NIC-SE                                           +46-8-545 857 06
Box 5774                                    fax: +46-8-545 857 29
SE-114 87 Stockholm                         http://www.nic-se.se/

---

From: Paul A Vixie <[email-masked]>
Date: Wed, 27 Oct 1999 17:06:05 -0700

> want to have for all kind of service in the future, including replacing MX?

there is no reason to replace mx with srv.  mail is working fine, and the
features srv has that mx lacks have never been considered essential for mail.

similarly, there's no reason to replace ns with srv.

there is however a strong need to use srv rather than raw a rr's.

and there is a strong need to avoid reinventing mx for every new protocol.

---

From: Paul A Vixie <[email-masked]>
Date: Thu, 28 Oct 1999 15:19:17 -0700

> SRV has flexibility that MX lacks, for exampel the ability to choose a
> different port.
> ...
> If SRV becomes a hit, I see no reason why MX should not be replaced by
> _smtp._tcp SRV some time in the future.

we don't need a reason not to do this.  not doing it is the default condition.
not doing it is what will happen unless we can find a compelling reason to do
it.  i have seen no possible reason yet advanced whose author has labelled it
compelling, or, apart from such labelling, which i have found compelling.

---

From: Mats Dufberg <[email-masked]>
Date: Fri, 29 Oct 1999 00:09:32 +0200 (CEST)

> similarly, there's no reason to replace ns with srv.

MX could be seen as a special case of SRV, but NS is a different kind of
animal.

Mats