Re: [port-srv-reg] Peter Saint-Andre's Discuss on draft-ietf-dime-rfc3588bis-29: (withDISCUSS and COMMENT)

Jouni Korhonen <jouni.korhonen@nsn.com> Tue, 15 November 2011 09:28 UTC

Return-Path: <jouni.korhonen@nsn.com>
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 EB2CC21F8FC4; Tue, 15 Nov 2011 01:28:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.449
X-Spam-Level:
X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 CKMUD9x7TKTE; Tue, 15 Nov 2011 01:28:06 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id A619921F8F4C; Tue, 15 Nov 2011 01:28:05 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id pAF9S2HK008853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 15 Nov 2011 10:28:03 +0100
Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id pAF9S0gk004414; Tue, 15 Nov 2011 10:28:02 +0100
Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Nov 2011 10:27:55 +0100
Received: from 10.144.248.248 ([10.144.248.248]) by FIESEXC035.nsn-intra.net ([10.159.0.182]) via Exchange Front-End Server demuexc023.nsn-intra.net ([10.150.128.36]) with Microsoft Exchange Server HTTP-DAV ; Tue, 15 Nov 2011 09:27:55 +0000
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Tue, 15 Nov 2011 11:27:50 +0200
From: Jouni Korhonen <jouni.korhonen@nsn.com>
To: ext Joe Touch <touch@isi.edu>
Message-ID: <CAE7FD36.105E0%jouni.korhonen@nsn.com>
Thread-Topic: [port-srv-reg] Peter Saint-Andre's Discuss on draft-ietf-dime-rfc3588bis-29: (withDISCUSS and COMMENT)
Thread-Index: AcyjeNfeklsGSidVI0G+VySyl5kyMQ==
In-Reply-To: <4EC22B79.9010608@isi.edu>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 15 Nov 2011 09:27:55.0784 (UTC) FILETIME=[DB514080:01CCA378]
X-Mailman-Approved-At: Tue, 15 Nov 2011 17:01:24 -0800
Cc: draft-ietf-dime-rfc3588bis@tools.ietf.org, dime-chairs@tools.ietf.org, ext Glen Zorn <gwz@net-zen.net>, The IESG <iesg@ietf.org>, "port-srv-reg@ietf.org" <port-srv-reg@ietf.org>
Subject: Re: [port-srv-reg] Peter Saint-Andre's Discuss on draft-ietf-dime-rfc3588bis-29: (withDISCUSS and COMMENT)
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: Tue, 15 Nov 2011 09:28:07 -0000

Tomorrow after 3pm works for me. Thursday first morning session is also
available.

- Jouni



On 11/15/11 11:06 AM, "ext Joe Touch" <touch@isi.edu> wrote:

> Tomorrow I'm open after 3pm.
> 
> Thurs I'm open *except* for lunch.
> 
> (I have sessions I want to attend, but this will take priority)
> 
> Let me know what works.
> 
> Joe
> 
> 
> On 11/15/2011 12:58 AM, Jouni Korhonen wrote:
>> 
>> I and Glen are around. Though it seems social is next on my agenda. Tomorrow
>> first morning session is the only one where I need to attend to.
>> 
>> - Jouni
>> 
>> 
>> 
>> On 11/15/11 6:53 AM, "ext Peter Saint-Andre"<stpeter@stpeter.im>  wrote:
>> 
>>> Thanks, Joe. Let's see if our DIME friends are available. :)
>>> 
>>> On 11/15/11 12:50 PM, Joe Touch wrote:
>>>> I'm here if it's useful to meet - today is wide open...
>>>> 
>>>> Joe
>>>> 
>>>> On 11/14/2011 8:44 PM, Peter Saint-Andre wrote:
>>>>> My DISCUSS is still unresolved. Would it be productive to chat
>>>>> face-to-face in Taipei this week?
>>>>> 
>>>>> On 9/25/11 1:47 AM, Joe Touch wrote:
>>>>>> Hi, all,
>>>>>> 
>>>>>> TLS and DTLS are not transport protocols. The SRV spec specifies only
>>>>>> the following syntax:
>>>>>> 
>>>>>> _sname._tname.example.net
>>>>>> 
>>>>>> sname is a service name
>>>>>> tname is a transport protocol
>>>>>> 
>>>>>> Service names currently define all protocols from L5-L7 as a single,
>>>>>> non-parseable name. E.g., HTTP, HTTPS, etc. There are variants for
>>>>>> application protocols over SOAP over HTML, etc. But there aren't dots
>>>>>> separating the names (dots aren't permitted in service names, nor are
>>>>>> underscores), and there's no structure to those names.
>>>>>> 
>>>>>> I'm not aware of any documents that use other syntax that ever
>>>>>> proposed to update RFC 2782. The few exceptions (e.g., of specifying
>>>>>> SRV entries with nonstandard syntax) we've found to date have not been
>>>>>> deployed, and we're expecting to issue an update to those docs to
>>>>>> correct or deprecate them.
>>>>>> 
>>>>>> In this case, the approach I would expect - which is used much more
>>>>>> commonly - is:
>>>>>> 
>>>>>> _diameter-s._tcp.example.net -- this means "diameter over TLS"
>>>>>> _diameter-s._udp.example.net -- this means "diameter over DTLS"
>>>>>> 
>>>>>> Diameter-s, diameters, or any such new service name would be used to
>>>>>> indicate the secure variant of diameter.
>>>>>> 
>>>>>> This differs from the recent NAPTR application protocol tag. The
>>>>>> following was the summary of updates from that discussion on
>>>>>> DIME-extended-naptr, FWIW:
>>>>>> 
>>>>>> (1) State that the S-NAPTR Service/Protocol tags are unrelated to the
>>>>>> IANA Service Name and Transport Protocol Port Number Registry.
>>>>>> 
>>>>>> (2) State that the Application Protocol tag must not be parsed in any
>>>>>> way by the querying application or resolver. The delimiter (".") is
>>>>>> present in the tag to improve readability and does not imply a
>>>>>> structure or namespace of any kind.
>>>>>> 
>>>>>> (3) State that the choice of delimiter (".") for the Application
>>>>>> Protocol tag follows the format of existing S-NAPTR registry entries
>>>>>> but this does not imply that that it shares semantics with any other
>>>>>> RFCs that have created registry entries using the same format.
>>>>>> 
>>>>>> Joe
>>>>>> 
>>>>>> On Sep 22, 2011, at 9:14 AM, Peter Saint-Andre wrote:
>>>>>> 
>>>>>>> [Adding port-srv-reg@ietf.org for expert insight...]
>>>>>>> 
>>>>>>> Context for the ports and services folks:
>>>>>>> 
>>>>>>> During IESG review of draft-ietf-dime-rfc3588bis-29, I discovered that
>>>>>>> this specification appears to be using 'tls' and 'dtls' as SRV Proto
>>>>>>> values (and that it does not add 'diameter' to the ports and services
>>>>>>> registry). This strikes me as problematic, but feedback from your team
>>>>>>> would be helpful.
>>>>>>> 
>>>>>>> Thanks!
>>>>>>> 
>>>>>>> On 9/22/11 7:31 AM, Peter Saint-Andre wrote:
>>>>>>>> On 9/22/11 2:43 AM, Korhonen, Jouni (NSN - FI/Espoo) wrote:
>>>>>>>>> Peter,
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> -----Original Message----- From: ext Peter Saint-Andre
>>>>>>>>> [mailto:stpeter@stpeter.im] Sent: Thursday, September 22, 2011 5:10
>>>>>>>>> AM To: The IESG Cc: dime-chairs@tools.ietf.org;
>>>>>>>>> draft-ietf-dime-rfc3588bis@tools.ietf.org Subject: Peter
>>>>>>>>> Saint-Andre's Discuss on draft-ietf-dime-rfc3588bis-29: (withDISCUSS
>>>>>>>>> and COMMENT)
>>>>>>>>> 
>>>>>>>>> Peter Saint-Andre has entered the following ballot position for
>>>>>>>>> draft-ietf-dime-rfc3588bis-29: Discuss
>>>>>>>>> 
>>>>>>>>> When responding, please keep the subject line intact and reply to
>>>>>>>>> all email addresses included in the To and CC lines. (Feel free to
>>>>>>>>> cut this introductory paragraph, however.)
>>>>>>>>> 
>>>>>>>>> Please refer to
>>>>>>>>> http://www.ietf.org/iesg/statement/discuss-criteria.html for more
>>>>>>>>> information about IESG DISCUSS and COMMENT positions.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> ----------------------------------------------------------------------
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> DISCUSS:
>>>>>>>>> ----------------------------------------------------------------------
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> RFC 3588 used DNS SRV Proto values of 'tcp' and 'sctp' for the SRV
>>>>>>>>> Service of 'diameter'. 3588bis seems to add two more Proto values:
>>>>>>>>> 'tls' and 'dtls'. However, RFC 6335, which defines updated rules for
>>>>>>>>> the ports and services registry, allows only TCP, UDP, SCTP, and DCCP
>>>>>>>>> as transport protocols. Furthermore, this specification does not
>>>>>>>>> register the 'diameter' SRV Service value in accordance with RFC
>>>>>>>>> 6335. Because these values were not defined or registered by
>>>>>>>>> draft-ietf-dime-extended-naptr, I think they need to be defined
>>>>>>>>> here.
>>>>>>>>> 
>>>>>>>>> [JiK]: In extended-naptr I-D we have a note we came up with a lengthy
>>>>>>>>> discussion (and eventually to an agreement) with Joe Touch. How would
>>>>>>>>> RFC3588bis be different from extended-naptr in this case regarding
>>>>>>>>> the use of "diameter" and "dtls"?
>>>>>>>>> 
>>>>>>>>> The S-NAPTR Application Service and Protocol tags defined by this
>>>>>>>>> specification are unrelated to the IANA Service Name and Transport
>>>>>>>>> Protocol Port Number Registry (see [I-D.ietf-tsvwg-iana-ports]).
>>>>>>>>> 
>>>>>>>>> [JiK]: RFC3588bis only introduces "diameter.dtls" in addition what is
>>>>>>>>> already in extended-naptr I-D.
>>>>>>>> 
>>>>>>>> That's not how I read it. 3588bis says:
>>>>>>>> 
>>>>>>>> 3. If no NAPTR records are found, the requester directly queries for
>>>>>>>> SRV records '_diameter._sctp'.realm, '_diameter._dtls'.realm,
>>>>>>>> '_diameter._tcp'.realm and '_diameter._tls'.realm depending on
>>>>>>>> the requesters network protocol capabilities.
>>>>>>>> 
>>>>>>>> Those are not S-NAPTR Application Service and Protocol tags, they are
>>>>>>>> SRV Service and Proto values.
>>>>>>>> 
>>>>>>>> We might need to follow up separately with the Port Expert Team.
>>>>>>> 
>>>>>>> <snip/>
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> Port-srv-reg mailing list
>>>>>>> Port-srv-reg@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/port-srv-reg
>>>>>> 
>>>>> 
>>>>> 
>>>