Re: [port-srv-reg] "xmp" service type and the unified IANA Service Name and Port Number Registry

Joe Touch <touch@isi.edu> Thu, 25 August 2011 18:05 UTC

Return-Path: <touch@isi.edu>
X-Original-To: port-srv-reg@ietfa.amsl.com
Delivered-To: port-srv-reg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D1EB21F8C8C for <port-srv-reg@ietfa.amsl.com>; Thu, 25 Aug 2011 11:05:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.256
X-Spam-Level:
X-Spam-Status: No, score=-103.256 tagged_above=-999 required=5 tests=[AWL=-0.657, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZf1NeXVY+K6 for <port-srv-reg@ietfa.amsl.com>; Thu, 25 Aug 2011 11:05:06 -0700 (PDT)
Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 7D1E021F8C8A for <port-srv-reg@ietf.org>; Thu, 25 Aug 2011 11:05:06 -0700 (PDT)
Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id p7PI67Ro026980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 25 Aug 2011 11:06:07 -0700 (PDT)
Message-ID: <4E568F0F.6050600@isi.edu>
Date: Thu, 25 Aug 2011 11:06:07 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: Stuart Cheshire <cheshire@apple.com>
References: <6BA107CB-7E6F-4720-ABDF-7B0D0733D607@apple.com> <4E53BF1F.5040708@krupczak.org> <9A7A3E75-3F30-4A39-8D35-94D3C2C9381B@apple.com> <20110824024614.GF29306@uncasville.krupczak.org> <6128495A-A51C-4259-A3B6-C8933B4BE564@apple.com> <4E5527CD.6050509@isi.edu> <5E527290-A04D-4773-9BB0-B41C04B189DA@apple.com>
In-Reply-To: <5E527290-A04D-4773-9BB0-B41C04B189DA@apple.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: port-srv-reg@ietf.org
Subject: Re: [port-srv-reg] "xmp" service type and the unified IANA Service Name and Port Number Registry
X-BeenThere: port-srv-reg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of updates to service name and transport protocol port registry <port-srv-reg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/port-srv-reg>, <mailto:port-srv-reg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/port-srv-reg>
List-Post: <mailto:port-srv-reg@ietf.org>
List-Help: <mailto:port-srv-reg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/port-srv-reg>, <mailto:port-srv-reg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Aug 2011 18:05:07 -0000

Hi, Stuart,

These may be yours and Apple's opinion, but they are not shared by the 
rest of the network community, which has been using /etc/services nearly 
since there have been assigned ports.



On 8/25/2011 10:20 AM, Stuart Cheshire wrote:
> On 24 Aug 2011, at 9:33, Joe Touch wrote:
>
>> My view is that getservbyname provides the same level of
>> indirection inside a host that SRV records provide between hosts.
>> In specific, modifications of the /etc/services tables does occur
>> and is valid. As a result, I would not suggest that you change to
>> using the port number directly.
>
> [Removing Bobby Krupczak from discussion]
>
> I do not agree with you Joe, and I don't think this is good advice.
>
> The difference is that SRV records are a good idea because the
> client queries the organisation providing the service to discover
> what port that service instance is listening on. This is broadly
> applicable on a worldwide Internet encompassing many administrative
> domains.

I don't debate the benefits of SRV records, and have recommended many 
use them, but they are not feasible in many cases.

Note however that if SRV records were used *today* for all services, it 
would be a requirement that the SRV tables on the local machine would 
need to include a copy of entries from the ports table - i.e., it would 
need to effectively replicate /etc/services anyway, or you would be 
cutting your node off from all clients that haven't yet converted to SRV 
lookups.

> The getservbyname() call queries the client's own local table, which
> has little if any relationship to to whatever port any given server
> instance may be listening on.

getservbyname() is used both by clients and servers. A server that 
doesn't consult a local /etc/services - or a copy thereof in its local 
DNS SRV entries - is basically saying it cannot be reached by legacy 
clients in the Internet.

Is that seriously Apple's position? That we should all move to SRVs and 
cut ourselves off from legacy clients?

> The notion that a network administrator
> can modify *all* the /etc/services tables on *all* machines only made
> sense in an earlier era of isolated islands of IP connectivity, before
> mobile devices like laptop computers became common (e.g. pre 1990s). The
> getservbyname() call is an API for the 1970s and 1980s, which makes
> little sense in today's world.

With the proliferation of firewalls and NATs it is also useful within 
enterprises. The NAT can convert from local values anyway, and this can 
provide centralized control over external access to various local services.

Further, ports considered 'risky' can (and often are) removed from these 
tables.

>> Stuart - perhaps you can encourage Apple to update their
>> /etc/services to track the IANA list more closely. Regardless of similar
>> flaws in other OSes, this list should be updated regularly.
>
> The reason we *stopped* updating /etc/services in 2002 is precisely
> ecause we *don't* believe that APIs like getservbyname() are useful any
> more, and encouraging developers to believe otherwise would not be
> helpful.

All that does is set your products apart as having out-of-date tables.

If you want to encourage users to use SRV records, that's fine - but 
forcing users to encode port numbers into their code as an alternative 
to updating /etc/services is short-sighted.

Joe