Re: [port-srv-reg] "assigned" ( vs. "registered"), and related issues

Olafur Gudmundsson <ogud@ogud.com> Fri, 15 January 2010 14:39 UTC

Return-Path: <ogud@ogud.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3C3D3A6AC1; Fri, 15 Jan 2010 06:39:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.662
X-Spam-Level:
X-Spam-Status: No, score=-2.662 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1NuLDF3V8gTo; Fri, 15 Jan 2010 06:39:30 -0800 (PST)
Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 5B48D28C0F7; Fri, 15 Jan 2010 06:39:30 -0800 (PST)
Received: from valholl.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o0FEdOYi085542; Fri, 15 Jan 2010 09:39:24 -0500 (EST) (envelope-from ogud@ogud.com)
Message-Id: <201001151439.o0FEdOYi085542@stora.ogud.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 15 Jan 2010 09:39:02 -0500
To: Magnus Westerlund <magnus.westerlund@ericsson.com>, Olafur Gudmundsson <ogud@ogud.com>
From: Olafur Gudmundsson <ogud@ogud.com>
Subject: Re: [port-srv-reg] "assigned" ( vs. "registered"), and related issues
In-Reply-To: <4B503CFA.4010107@ericsson.com>
References: <201001111508.QAA08192@TR-Sys.de> <54E3D339-1E62-4BD1-9AA0-80F3C348724F@nokia.com> <201001141413.o0EEDBDD076210@stora.ogud.com> <4B503CFA.4010107@ericsson.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Scanned-By: MIMEDefang 2.67 on 66.92.146.20
Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org>, "port-srv-reg@ietf.org" <port-srv-reg@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Jan 2010 14:39:30 -0000

At 05:01 15/01/2010, Magnus Westerlund wrote:
>Olafur Gudmundsson skrev 2010-01-14 15:13:
> > At 03:39 13/01/2010, Lars Eggert wrote:
> >
> >> > IMO, this basically treats SRV names as old port numbers were treated -
> >> > i.e., ask for a name, get ALL transports. That's how port number
> >> > assignments were done until recently, where now only the needed
> >> > transport is assigned.
> >> >
> >> > So IMO a service means something only relative to a transport. However,
> >> > it'd be useful to require the transport be specified only if the same
> >> > name would mean different things for different transports. Do we ever
> >> > see that happening?
> >>
> >> Right. Or, in other words, if you have a service name, it's yours for
> >> all transports, just as ports used to be. (There are so many service
> >> names that we can burn combinations that aren't used, and limit
> >> interactions with IANA.)
> >>
> >> Lars
> >
> > The important point is:
> > Each service is going to have one or more transports that are "preferred",
> > these preferences need to be noted in the registry.
> > (this point applies both to port allocations and service names).
> >
> > See section 5.1 of
> > http://tools.ietf.org/html/draft-gudmundsson-dnsext-srv-clarify-00
> >
> > for proposed search order when priority order is not known.
> >
>
>I thought this was going to be covered in the reference that explains
>how the SRV is used with service X. I think that is the most appropriate
>place to indicate which protocols are expected to be supported and for
>which usages which is the most appropriate.
>
> >From the Service name registry point of view this is not needed
>information. However, I agree that for the user of the service name it
>is clearly of interest. But as I said before, it is service specific.
>
>Cheers
>
>Magnus Westerlund


What Alfred and I envision (and apps people correct me if I'm wrong):
The SRV update document specifies a default order of transports to use,
the registry in the Notes field[1] stores transports in priority order
for a service if different from default.
If a service does not envision using SRV then that should be noted.

The document/application for service lists the priority order when
different from the default.

[1] We can add a special column to the Service registry for transport list.

         Olafur