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

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 15 Nov 2011 12:44:44 +0800

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 [email-masked] 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:[email-masked]] Sent: Thursday, September 22, 2011 5:10
>>>> AM To: The IESG Cc: [email-masked];
>>>> [email-masked] 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
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/port-srv-reg
>

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Joe Touch <[email-masked]>
Date: Mon, 14 Nov 2011 20:50:07 -0800

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:
>> 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.
>>
>> 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
>>

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 15 Nov 2011 12:53:23 +0800

Thanks, Joe. Let's see if our DIME friends are available. :)

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Joe Touch <[email-masked]>
Date: Tue, 15 Nov 2011 01:06:01 -0800

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"<[email-masked]>  wrote:
>

---

From: Stuart Cheshire <[email-masked]>
Date: Tue, 15 Nov 2011 15:11:26 -0800

On 14 Nov 2011, at 20:44, Peter Saint-Andre wrote:

> My DISCUSS is still unresolved. Would it be productive to chat face-to-face in Taipei this week?

I do (unsurprisingly) have some thoughts on service naming.

Here's my availability:

Wednesday:
1510-1610  Afternoon Session II
1610-1630  Beverage and Snack Break I - Common Area

Thursday:
0900-1130  Morning Session I
1130-1300  Lunch break
1500-1520  Beverage Break - Common Area
1720-1740  Beverage and Snack Break II - Common Area
1740-1940  Afternoon Session III

I can also do breakfast Thursday or Friday.

Stuart Cheshire <[email-masked]>
* Wizard Without Portfolio, Apple Inc.
* www.stuartcheshire.org

---

From: Joe Touch <[email-masked]>
Date: Tue, 15 Nov 2011 15:15:24 -0800

I think we're meeting at the message board today at 3pm

Joe

On 11/15/2011 3:11 PM, Stuart Cheshire wrote:
> ngly) have some thoughts on service naming.
>
> Here's my availability:

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 15 Nov 2011 10:58:01 +0200

- Jouni

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 15 Nov 2011 11:27:50 +0200

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

- Jouni

---

From: "Korhonen, Jouni (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 16 Nov 2011 01:56:09 +0200

ok. i'll show up.

- jouni

-----Original Message-----
From: ext Joe Touch [mailto:[email-masked]]
Sent: Wed 11/16/2011 1:15 AM
To: Stuart Cheshire
Cc: Peter Saint-Andre; The IESG; Korhonen, Jouni (NSN - FI/Espoo); [email-masked]; [email-masked]; [email-masked]
Subject: Re: [port-srv-reg] Peter Saint-Andre's Discuss on draft-ietf-dime-rfc3588bis-29: (withDISCUSS and COMMENT)

Joe