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

[Peter Saint-Andre <[e-mail]>]

[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/>