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

Thanks for the comprehensive review, Lionel.
Comments/questions inline prefixed by [mj]

Regards
Mark

On Mon, Nov 15, 2010 at 6:45 PM, dime issue tracker <trac@tools.ietf.org> wrote:
> #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]
>

 [mj] Ok but a CER/CEA may be required with "every node" until the peer locates
 one supporting the required application. I would prefer to keep this sentence
 as it helps explain the benefit but reword as "A peer outside the realm would
 have to perform a Diameter capability exchange with each node until it
 discovers one that supports the required application."

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

[mj] Agreed but I'd prefer to keep the RFC3958 text that you quote.

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

[mj] Agreed.

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

[mj] Agreed

>  **************************
>
>    "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]
>

 [mj] After further consideration, I agree we can not indicate a specific format
for the experimental namespace. We have no idea what is out there already
in experimental land so can not guarantee that our recommendations are
unique. In addition, removing all references to the experimental-appln-tag
would simplify the draft (and remove the need for some of the subsections
you are proposing in the section 3 re-org). As you point out, there
are many possible ways to handle it and no real value is defining a
specific format.

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

mj] Agreed. I'll keep it consistent with the RFC3958 labels.

>  ***********************************
>
>    "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]
>

[mj] I will move to a new "Backwards  Compatibility" section. Legacy nodes
applying the RFC3588 query procedure are simply going to ignore the entries
formatted as "aaa+apX:Y". Is that the sentence that you think is missing?

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

[mj] Agreed

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

 [mj] I think I understand it but the whole paragraph is worded bizarrely.
 As it is just an example, the last sentence could be reworded as
 "For example, the realm could be deduced from the NAI in the User-Name
 AVP or extracted from the Destination-Realm AVP."

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

[mj] I originally considered this as obvious. To the client, an agent is still
acting in the server role.

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

[mj] Agreed. I'll add a reference to this section.

>  ************* proposal for section 3 *************************

 [mj] There are some good suggestions in this proposal. I have some
 questions/comments inline below.

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

 [mj] Agreed. It is useful to repeat the ABNF from RFC3958 because then
 it is more obvious what we are overriding.

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

 [mj] But this draft is only concerned with iana-registered values. If
 SDOs/vendors want to play in the x- namespace then it is out of scope.

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

[mj] Can you clarify what "MUST be possible" means here?

>  Therefore, every IETF Standard-track
>    Diameter application MUST be associated with the iana-registered-
>  service value defined in
>    this specification.
>

[mj] Agreed. This is a missing requirement in RFC3588 and why this
draft is needed to update it.

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

[mj] Only one alternative is in scope of this draft if we are only concerned
with iana-registered service values.

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

 [mj] Earlier in the review, you'd questioned the addition of  recommendations
 on the usage of the experimental namespace. Why did you change your mind?

>    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/>
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>