Re: [Dime] NAPTR fix for 3588bis

[jouni korhonen <[e-mail]>]

[snip]

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

More on this topic.. RFC3958 itself contain examples that go against the ABNF. So, I _guess_ it is ok for us to assume that

"iana-registered-protocol  = ALPHA *31ALPHANUM"

is actually

"iana-registered-protocol  = ALPHA *31ALPHANUMSYM"

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