Re: [port-srv-reg] Peter Saint-Andre's Discuss on draft-ietf-dime-rfc3588bis-29: (withDISCUSS and COMMENT)
Peter Saint-Andre <stpeter@stpeter.im> Tue, 15 November 2011 04:53 UTC
Return-Path: <stpeter@stpeter.im>
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 E52131F0C4F; Mon, 14 Nov 2011 20:53:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.893
X-Spam-Level:
X-Spam-Status: No, score=-102.893 tagged_above=-999 required=5 tests=[AWL=-0.294, 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 JOSZGNfh6uFl; Mon, 14 Nov 2011 20:53:28 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 4865E1F0C72; Mon, 14 Nov 2011 20:53:27 -0800 (PST)
Received: from dhcp-15ab.meeting.ietf.org (unknown [64.104.46.217]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E3CC04216E; Mon, 14 Nov 2011 21:59:37 -0700 (MST)
Message-ID: <4EC1F043.9020201@stpeter.im>
Date: Tue, 15 Nov 2011 12:53:23 +0800
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Joe Touch <touch@isi.edu>
References: <20110922020938.20266.40068.idtracker@ietfa.amsl.com> <63F5863A798FF74A8817FB17814063DD67AF16@FIESEXC035.nsn-intra.net> <4E7B38C3.2050406@stpeter.im> <4E7B5EE6.1060907@stpeter.im> <5B0CB394-6313-45A1-AA0A-EC6C130BFCC9@isi.edu> <4EC1EE3C.8050301@stpeter.im> <4EC1EF7F.8010000@isi.edu>
In-Reply-To: <4EC1EF7F.8010000@isi.edu>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "Korhonen, Jouni (NSN - FI/Espoo)" <jouni.korhonen@nsn.com>, draft-ietf-dime-rfc3588bis@tools.ietf.org, "port-srv-reg@ietf.org" <port-srv-reg@ietf.org>, The IESG <iesg@ietf.org>, dime-chairs@tools.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 04:53:30 -0000
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 >>> >> >> -- Peter Saint-Andre https://stpeter.im/
- Re: [port-srv-reg] Peter Saint-Andre's Discuss on… Peter Saint-Andre
- Re: [port-srv-reg] Peter Saint-Andre's Discuss on… Joe Touch
- Re: [port-srv-reg] Peter Saint-Andre's Discuss on… Peter Saint-Andre
- Re: [port-srv-reg] Peter Saint-Andre's Discuss on… Joe Touch
- Re: [port-srv-reg] Peter Saint-Andre's Discuss on… Peter Saint-Andre
- Re: [port-srv-reg] Peter Saint-Andre's Discuss on… Joe Touch
- Re: [port-srv-reg] Peter Saint-Andre's Discuss on… Stuart Cheshire
- Re: [port-srv-reg] Peter Saint-Andre's Discuss on… Joe Touch
- Re: [port-srv-reg] Peter Saint-Andre's Discuss on… Jouni Korhonen
- Re: [port-srv-reg] Peter Saint-Andre's Discuss on… Jouni Korhonen
- Re: [port-srv-reg] Peter Saint-Andre's Discuss on… Korhonen, Jouni (NSN - FI/Espoo)