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

[Jouni Korhonen <[e-mail]>]

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