[Dime] [dime] extended-naptr #15 (new): review of extended NAPTR draft

["dime issue tracker" <[e-mail]>]

#15: review of extended NAPTR draft

 As promised, here is my feedback based on the last version of the draft.
 Mainly, it is more a question of readability/clarification than technical
 comment. The only "issue" depending of the feeling of the WG would be
 about discussing "experimental" format in this specification, that should
 be just for information and not normative.

 BR,

 Lionel

 ******************
 Abstract

    The Diameter base protocol specifies mechanisms whereby a given realm
    may advertise Diameter nodes and the supported transport protocol.
    However, these mechanism do not reveal the Diameter applications that
    each node supports.  A peer outside the realm would have to perform a
    Diameter capability exchange with every node in order to discover
    which one supports a required application.  This document describes
    an improvement using an extended format for the Straightfoward-NAPTR
    (S-NAPTR) Application Service Tag that allows for discovery of the
    supported applications without doing Diameter capability exchange
    beforehand.


 [LM] the following sentence should be removed.

   "A peer outside the realm would have to perform a
    Diameter capability exchange with every node in order to discover
    which one supports a required application."

 CER/CEA exhange will not be performed with "every node". Such assertion is
 not required anyway. The only thing that we can say that there is no way
 for the peer to know the Diameter node to contact for a given application.
 Default behaviour is outside the current scope of RFC3588 and should be
 left outside. [LM]

 ******************

 3. Extended NAPTR Service Field Format

    The NAPTR Service Field format defined by the S-NAPTR DDDS
    application in [RFC3958] consists of a S-NAPTR Application Service
    tag and a S-NAPTR Application Protocol tag delimited by a single
    colon (":") character.

 [LM]
 In the RFC 3958, it is said:

    "the Service Parameters may consist of an empty string, an app-
    service, or an app-service with one or more app-protocol
    specifications separated by the ":" symbol."

 so, app-service + app-protocol is only one of the possible formats.
 Therefore, the wording should be:

    "The NAPTR Service Field format defined by the S-NAPTR DDDS in
    [RFC3958] may consists of a S-NAPTR Application Service tag and a
 S-NAPTR
    Application Protocol tag delimited by a single colon (":") character."

 For illustration, a copy/paste of the format given in RFC 3958 can also be
 added: "service-parms = [ [app-service] *(":" app-protocol)]"

 [LM]

 *******************

   " The S-NAPTR Application Service Tag ABNF specification for the
    discovery of Diameter agents supporting a specific Diameter
    application is shown below."

 [LM] s/application is shown below/application is defined below

 *****************************

        appln-svc-tag           = iana-appln-tag / experimental-appln-tag
        iana-appln-tag          = "aaa+ap" appln-id
        experimental-appln-tag  = "x-aaa+ap" appln-id
        appln-id                = *DIGIT
                                  ; Application identifier expressed as a
                                  ; decimal integer.

 [LM] Why this specific notation for appl-service? Why not reuse instead
 the same notation as in RFC 3958, that would mean:

        app-service             = iana-appln-tag / experimental-appln-tag
 [LM]

 **************************

    "As stated in [RFC3958], application service tags that start with "x-"
    are considered experimental, and no provision is made to prevent
    duplicate use of the same string.  Implementors use them at their own
    risk.

    The S-NAPTR Application Protocol Tag ABNF specification for the
    discovery of Diameter agents supporting a specific Diameter transport
    protocol is shown below."


 [LM] if something starting by "x-" is experimental, why do we have to
 indicate any specific format in this specification? At least, one example
 for illustration can be provided, as possible way to handle it (especially
 for other SDOs e.g. 3GPP), but there is no specific reason for further
 detailed info. [LM]

 ****************************************

        appln-protocol-tag  = "diameter." app-protocol
        app-protocol        = "tcp" / "sctp" / "tls.tcp"

 [LM] same comment applies but raises another comment: "app-protocol" is
 already used in RFC 3958 as component of the "service-parms":
 "service-parms = [ [app-service] *(":" app-protocol)]". So some people can
 get confuse when reading both RFC 3403 and this specification.

 ***********************************

    "The maximum length of the NAPTR service field is 256 octets including
    one octet length field (see Section 4.1 of RFC 3403 and Section 3.3
    of [RFC1035]).  DNS administrators SHOULD also provision legacy RFC
    3588 style NAPTR records [RFC2915] in order to guarantee backwards
    compatibility with legacy RFC 3588 compliant Diameter peers.  If the
    DNS administrator provisions both extended S-NAPTR records as defined
    in this specification and legacy RFC 3588 NAPTR records, then the
    extended S-NAPTR records MUST have higher priority (e.g. lower order
    and/or preference values) than legacy NAPTR records."

 [LM] the text related to support request from legacy nodes should be put
 in a separate section, just to highlight the specific content. There is
 nothing to do with S-NAPTR format. Moreover, even if obvious, a sentence
 should be added to detail the behaviour of leagcy nodes receiving DNS
 responses with both type of S-NATPT records, to show that there is no
 compatible issue. [LM]

 [LM] based on my previous comment, I would propose to modify the content
 of the section 3 as put at the end

 ***********************************************
 4. Extended NAPTR-based Diameter Peer Discovery


    The Diameter Peer Discovery principles are described in Section 5.2
    of [RFC3588].  This specification updates the NAPTR query procedure
    in the Diameter peer discovery mechanism by allowing the querying
    node to determine which applications are supported by resolved
    Diameter peers.

    The extended format NAPTR records provide a mapping from a domain, to

 [LM] s/a domain, to/a domain to [LM]

 ***********

    a. 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 and which
       Application Identifier it is interested in.  The realm could be
       deduced, for example, from the 'realm' in a NAI that a Diameter
       implementation needed to perform a Diameter operation on.

 [LM] I know that it is a copy/paste frm RFC3588 and maybe it is due to my
 poor english but i felt to undersand the last sentence [LM]

 **********************

 5. Usage Guidelines


    Diameter is a peer to peer protocol whereas most of the applications
    that extend the base protocol behave like client/server applications.
    The role of the peer is not advertised in the NAPTR tags and not even
    communicated during Diameter capability negotiation (CER/CEA).  For
    this reason, NAPTR-based Diameter peer discovery for an application
    defining client/server roles should only be used by a client to
    discover servers.

 [LM] Should we clarify that the DNS responses can provide records for a
 proxy and redirect agents and not only "servers", or it is too obvious?
 [LM]

 *******************

 6.1. IETF Diameter Application Service Tags


    IANA is requested to reserve the following S-NAPTR Application
    Service Tags for existing IETF Diameter applications:

              +------------------+----------------------------+
              | Tag              | Diameter Application       |
              +------------------+----------------------------+
              | aaa+ap1          | NASREQ [RFC3588]           |
              | aaa+ap2          | Mobile IPv4 [RFC4004]      |
              | aaa+ap3          | Base Accounting [RFC3588]  |
              | aaa+ap4          | Credit Control [RFC4006]   |
              | aaa+ap5          | EAP [RFC4072]              |
              | aaa+ap6          | SIP [RFC4740]              |
              | aaa+ap7          | Mobile IPv6 IKE [RFC5778]  |
              | aaa+ap8          | Mobile IPv6 Auth [RFC5778] |
              | aaa+ap9          | QoS [RFC5866]              |
              | aaa+ap4294967295 | Relay [RFC3588]            |
              +------------------+----------------------------+

    Future IETF Diameter applications MUST reserve the S-NAPTR
    Application Service Tag corresponding to the allocated Diameter
    Application ID.

 [LM] should indicate that the IANA registration process is defined in
 RFC3958 [LM]

 ************* proposal for section 3 *************************
 - begin -

 3.  Extended NAPTR Service Field Format

    As described in RFC 3958 [RFC3958], Service Parameters for S-NAPTR take
 the form of a
    string of characters that follow this ABNF:

       service-parms = [ [app-service] *(":" app-protocol)]
       app-service   = experimental-service  / iana-registered-service
       app-protocol  = experimental-protocol / iana-registered-protocol
       experimental-service      = "x-" 1*30ALPHANUMSYM
       experimental-protocol     = "x-" 1*30ALPHANUMSYM
       iana-registered-service   = ALPHA *31ALPHANUMSYM
       iana-registered-protocol  = ALPHA *31ALPHANUMSYM
       ALPHA         =  %x41-5A / %x61-7A   ; A-Z / a-z
       DIGIT         =  %x30-39 ; 0-9
       SYM           =  %x2B / %x2D / %x2E  ; "+" / "-" / "."
       ALPHANUMSYM   =  ALPHA / DIGIT / SYM
       ; The app-service and app-protocol tags are limited to 32
       ; characters and must start with an alphabetic character.
       ; The service-parms are considered case-insensitive.

    The maximum length of the NAPTR service field is 256 octets including
    one octet length field (see Section 4.1 of RFC 3403 and Section 3.3
    of [RFC1035]).

    Section 3.1 defines S-NAPTR Application Service and Application
 Procotol Tag values
    that permit the discovery of Diameter peers that support a standard-
 track Diameter
    application and transport protocol.

    Section 3.2 provides informational guidelines for the definition of
 S-NAPTR
    Application Service Tag values that permit the discovery of Diameter
 peers that
    support a standard-track Diameter application and transport protocol.

 3.1  New iana-registered Application service and application protocol
 values

    This specification defines a new iana-registered-service value for the
 "app-service" field:

        iana-registered-service = "aaa+ap" appln-id
        appln-id                = *DIGIT

    Expressed as a decimal integer, the "appln-id" is used here to identify
    a diameter application identifier as assigned by IANA.

    This specification defines a new iana-registered-protocol value for the
 "app-protocol" field:

        app-protocol   = "diameter." app-transport
        app-transport  = "tcp" / "sctp" / "tls.tcp"

 3.2 Use of Extended NAPTR Service Field Format for standard-track
 applications

    It MUST be possible to use extended S-NAPTR Application Service Tag for
 dynamic discovery of
    Diameter agent supporting standard-track applications. Therefore, every
 IETF Standard-track
    Diameter application MUST be associated with the iana-registered-
 service value defined in
    this specification.

    For example, a NAPTR service field value of:

        'aaa+ap6:diameter.sctp'

    will mean that the Diameter node in the SRV or A/AAAA record supports
    the Diameter Session Initiation Protocol (SIP) Application ('6')
    and SCTP as the transport protocol.

 3.3 Options for use of S-NAPTR Application Service Tag for vendor-specific
 applications

    S-NAPTR Application Service and Application Procotol Tag values can
    also be used to discover Diameter peers that support a vendor-specific
    Diameter application. In such a case, there are two alternatives when
    using the Application Service tag.

 3.3.1 Use of iana-registered-service value

    Vendor-specific Diameter applications MAY be associated
    with the iana-registered-service value defined in this specification.
    In such a case, extended NAPTR Application Service tag for
    vendor-specific application will have the same format than for
 standard-track application.

    For example, a NAPTR service field value of:

        'aaa+ap16777251:diameter.sctp'

    will mean that the Diameter node in the SRV or A/AAAA record supports
    the Diameter S6a Application ('16777251') and SCTP as the transport
    protocol.

    However, such use of iana-registered-service value would require the
    publication of an RFC (of any category) as mandated by the IANA policy
    defined in [RFC3958, and this may not be desired by vendors/SDOs.

 3.3.2 Use of experimental-service value

    Instead of resorting to the constraining iana-registrered Appication
 Service tag,
    vendors/SDOs may rather rely on the experimental-service value as
 authorized by
    the format of Application service field.

    In such a case, this specification recommends the following format for
 the "app-service" field:

        experimental-service = "x-aaa+ap" appln-id
        appln-id                = *DIGIT

        Expressed as a decimal integer, the "appln-id" is used here to
 identify
        a vendor-specific application identifier as assigned by IANA.

    As stated in [RFC3958], application service tags that start with "x-"
    are considered experimental, and no provision is made to prevent
    duplicate use of the same string.  Implementors use them at their own
    risk. It is therefore the responsability of each vendor/SDO to define
 the exact
    values of S-NAPTR Application Service Tags associated with vendor-
 specific
    Diameter applications.

    For example, a NAPTR service field value of:

        'aaa+ap16777251:diameter.sctp'

    would mean that the Diameter node in the SRV or A/AAAA record supports
    the 3GPP-specific Diameter S6a Application ('16777251') and SCTP as the
    transport protocol.

    The use of this experimental-service value is strongly discouraged when
    considering standard-track applications, as standard values are
 assigned
    by IANA.

 - end -

-- 
----------------------------------------------+-----------------------------
 Reporter:  lionel.morand@…                   |       Owner:  lionel.morand@…
     Type:  enhancement                       |      Status:  new           
 Priority:  major                             |   Milestone:                
Component:  extended-naptr                    |     Version:                
 Severity:  In WG Last Call                   |    Keywords:                
----------------------------------------------+-----------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/15>
dime <http://tools.ietf.org/wg/dime/>