Re: [Dime] NAPTR fix for 3588bis

[jouni korhonen <[e-mail]>]

Hi,


On Mar 31, 2010, at 9:32 PM, Mark Jones wrote:

> Thanks for the feedback, Jouni. Responses inline.
> 
>> -----Original Message-----
>> From: jouni korhonen [mailto:[e-mail]]
>> Sent: March 31, 2010 12:20 PM
>> To: Mark Jones
>> Cc: [e-mail]
>> Subject: Re: [Dime] NAPTR fix for 3588bis
>> 
>> Hi,
>> 
>> Thanks Mark for initiating the discussion and proposing text. My
>> initial comments inline.
>> 
>> On Mar 31, 2010, at 4:48 PM, Mark Jones wrote:
>> 
>>> Here are the proposed changes to 3588bis to implement the fix for the
>> NAPTR issues discussed at IETF#77 (see
>> http://www.ietf.org/proceedings/10mar/slides/dime-5.pdf)
>>> 
>>> Comments appreciated.
>>> 
>>> There was some discussion at the meeting of creating S-NAPTR
>> Application Service Tag entries for the unregistered NAPTR values in
>> RFC3588 ("AAA+D2x"). No consensus was reached but my impression was
>> that we were leaning towards NOT creating these entries. That would be
>> my preference too but are there any objections on the list?
>> 
>> Would be ok I think.. However, I really would like to see even some
>> discussion related to them _somewhere_. Any ideas? Would an errata be
>> enough to cover that?
>> 
> 
> I do agree this change needs to be discussed but I assumed we were going to have that discussion _here_ on this list. If the errata review procedure is likely to generate more discussion then I'm all for it.

Right. I have no idea how the errata stuff actually works in practice but we should, of course, first have a common agreement on the list.



> 
>> 
>>> 
>>> Regards
>>> Mark
>>> 
>>> ************************* FIRST CHANGE *************************
>>> 
>>> Section 5.2 Diameter Peer Discovery
>>> 
>>> => Replace step 2 with the following text:
>>> 
>>>  2.  The Diameter implementation performs a NAPTR query for a server
>>>      in a particular realm.  The Diameter implementation has to know
>>>      in advance which realm to look for a Diameter agent in.  This
>>>      could be deduced, for example, from the 'realm' in a NAI that a
>>>      Diameter implementation needed to perform a Diameter operation
>>>      on.
>>> 
>>>      The NAPTR usage in Diameter follows the S-NAPTR DDDS
>> application
>>>      [RFC3958] which means that the SERVICE field includes tags for
>> the
>>>      desired application and supported application protocol.
>>>      The application service tag for a Diameter application is 'aaa'
>> and
>>>      the supported  application protocol tags are 'diameter.tcp',
>>>      'diameter.sctp' or 'diameter.tls'.
>> 
>> RFC3958 ABNF does not allow "." in iana-registered-protocol, so the
>> application protocol has to be changed, like "diametertcp" or "dtcp"
>> etc..
>> 
> 
> Lucky for us that IANA is ignoring the RFC3958 ABNF then :)
> 
> http://www.iana.org/assignments/s-naptr-parameters/s-naptr-parameters.xhtml
> 
> Another errata perhaps?
> 
>   iana-registered-protocol  = ALPHA *31ALPHANUMSYM

Great to see even RFC3958 authors do not follow the ABNF they created in later RFCs. RFC3958 already has an errata that says the ALPHANUM definition for iana-registered-protocol is missing and proposes one as a solution. Maybe we just have to carry on the  tradition of dodgy IANA DNS definitions in Diameter ;)

- Jouni

> 
>>> 
>>>      The client follows the resolution process defined by the S-
>> NAPTR
>>>      DDDS [RFC3958] application to find a matching SRV or A record
>> of
>>>      a suitable peer.  The domain suffixes in the NAPTR replacement
>> field
>>>      SHOULD match the domain of the original query.
>>> 
>>> 
>>> ************************* SECOND CHANGE *************************
>>> 
>>> Section 11.6 NAPTR Service Fields
>>> 
>>> => Rename this section to S-NAPTR Parameters and replace content
>> with:
>>> 
>>> This document registers a S-NAPTR Application Service Tag value of
>> "aaa".
>>> 
>>> This document also registers the following S-NAPTR Application
>> Protocol Tags:
>>> 
>>>  Tag            | Protocol
>>>  ---------------|---------
>>>  diameter.tcp   | TCP
>>>  diameter.sctp  | SCTP
>>>  diameter.tls   | TLS
>> 
>> See my note above regarding the application protocol.
>> 
>> 
>>> 
>>> ************************* THIRD CHANGE **************************
>>> 
>>> Appendix B.  NAPTR Example
>>> 
>>> => Rename section to S-NAPTR Example and modify as follows.
>>> 
>>>  As an example, consider a client that wishes to resolve aaa:
>>>  example.com.  The client performs a NAPTR query for that domain,
>> and
>>>  the following NAPTR records are returned:
>>> 
>>> ;;        order pref flags service             regexp replacement
>>> IN NAPTR  50    50   "s"   "aaa:diameter.tls"  ""
>> _diameter._tls.example.com
>>> IN NAPTR  100   50   "s"   "aaa:diameter.tcp"  ""
>> _aaa._tcp.example.com
>>> IN NAPTR  150   50   "s"   "aaa:diameter.sctp" ""
>> _diameter._sctp.example.com
>> 
>> And lets have an example of "a" flag as well:
>> 
>> IN NAPTR  150   50   "a"   "aaa:diametertls" ""     server1.example.com
>> IN NAPTR  150   50   "a"   "aaa:diametertls" ""     server2.example.com
>> 
> 
> Fine by me.
> 
>> 
>>> 
>>>  This indicates that the server supports TLS, TCP and SCTP in that
>>>  order.  If the client supports TLS, TLS will be used, targeted to a
>>>  host determined by an SRV lookup of _diameter._tls.example.com.
>> That
>>>  lookup would return:
>>> 
>>>   ;;       Priority  Weight  Port    Target
>>>   IN SRV   0         1       5060    server1.example.com
>>>   IN SRV   0         2       5060    server2.example.com
>>> 
>>> 
>>> ************************* FOURTH CHANGE **************************
>>> 
>>> 14.1.  Normative References
>>> 
>>> => Add new reference to S-NAPTR DDDS RFC3958.
>>> 
>>> ************************* END OF CHANGES ***********************
>> 
>> - Jouni
>> 
>> 
>> 
>>> 
>>> _______________________________________________
>>> DiME mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dime
>