Diameter Straightforward-Naming Authority Pointer (S-NAPTR) Usage
draft-ietf-dime-extended-naptr-09

[Ballot comment]
Since the numeric part of aaa+apNNNN is intended to be parsed and compared against application IDs:

1) your syntax allows for arbitrarily long digit strings after aaa+ap. You are expecting that
your registration rules will never let a name with a digit string that can't be parsed as a 32 bit unsigned
get registered, but that won't keep it from showing up on the wire. (For that matter, changing the
syntax wouldn't either). You might want to warn implementers that they could be handed something too large.
Similarly, someone could populate a DNS record with something looking like aaa+ap02, or aaa+ap002.
You probably don't want those to be parsed and treated the same as aaa+ap2, right?


2) This doesn't change the registration rules for 3958. Someone only needs an RFC (on any track) to register
an aaa+ap666 (or any other number that's not backed up by a corresponding codepoint in
at the Application IDs table.
You're counting, (I think), on pattern matching from whichever stream-editor/reviewer to recognize that such
a registration needs review against the registries created by 3588. Am I missing something else that would
make this unlikely to fail to happen?

[Ballot comment]
I've cleared my Discuss based on a review by Patrik Fältström.  Patrik made the following comments, which the authors should consider before the document is published:

  1. I also am a person that like examples, and the document doesn't
  have anything like that.

  2. I do not know diameter enough to say whether the RRSET will be
  huge, as I do not understand how many NAPTR RR one normally will
  have with the high number of options.

  3. If the number of options is high (and because of that the RRSET
  large) I think using URI RR Type with the aaa options as prefixes to
  the domain name is a better design choice -- but that is from a pure
  DNS perspective...

[Ballot comment]
I agree with Ralph that this should receive expert DNS review if it hasn't already. It's making heavy use of a mechanism that has been only lightly exercised so far.

Can the document say something about why the names have been encoded in the form of a numeric index into a (subset of an) IANA registry instead of using a descriptive form? Is there any intent to parse the number out of the names and use it in a bit-field in some diameter (or other IETF protocol) message? The values this document registers hint that someone might been thinking of 32bit fields :

aaa+ap4294967295 | Relay [RFC3588]  (2^32-1)

[Ballot comment]
You have the following two ABNF expressions:

      iana-registered-service  = aaa-service / ALPHA *31ALPHANUMSYM
      iana-registered-protocol = aaa-protocol / ALPHA *31ALPHANUMSYM
     
You could shorten them to:

      iana-registered-service  =/ aaa-service
      iana-registered-protocol =/ aaa-protocol

If you want to be precise, instead of:

      appln-id                  = 1*DIGIT

you should probably have:

      appln-id                  = 1*26DIGIT

For the record, I don't think it's worth addressing the ABNF issue that Stephen has in his comment, but if you insist on doing so, this would solve the problem:

      reg-prefix                = ("X" (ALPHA  / DIGIT / "+" / ".") ) /
                                  (("A" - "W" / "Y" / "Z") ALPHANUMSYM)
      iana-registered-service  = ALPHA / (reg-prefix *30ALPHANUMSYM)
      iana-registered-protocol  = ALPHA / (reg-prefix *30ALPHANUMSYM)

[Ballot comment]
You have the following two ABNF expressions:

      iana-registered-service  = aaa-service / ALPHA *31ALPHANUMSYM
      iana-registered-protocol = aaa-protocol / ALPHA *31ALPHANUMSYM
     
You could shorten them to:

      iana-registered-service  =/ aaa-service
      iana-registered-protocol =/ aaa-protocol

If you want to be precise, instead of:

      appln-id                  = 1*DIGIT

you should probably have:

      appln-id                  = 1*26DIGIT

For the record, I don't think it's worth addressing the ABNF issue that Stephen has in his comment, but if you insist on doing so, this would solve the problem:

      registered-prefix        = ("X" (ALPHA  / DIGIT / "+" / ".") ) /
                                  (("A" - "W" / "Y" / "Z") ALPHANUMSYM)
      iana-registered-service  = ALPHA / (registered-prefix *30ALPHANUMSYM)
      iana-registered-protocol  = ALPHA / (registered-prefix *30ALPHANUMSYM)

[Ballot discuss]
These are comments for discussion.

Some questions arose in TSVDIR review of this document, including:

- should this have "Updates: RFC 3958" added?

- should the ABNF for "aaa-transport" include an extension prototype?  It may not be clear how clients would handle a new transport being added at a latter time.

- and relayed from Joe Touch:
  - The suggested alternate NAPTR structure seems to imply two things:
    1 - more than just TCP and UDP as transport labels
    2 - a hierarchical structure of labels that includes intermediate encodings

    Neither of these are particularly consistent with the way in which SRV
    labels appear to be used, AFAICT - as per the IANA ports doc. Given that
    diameter is a service name (in IANA ports), I'm concerned that this
    proposal is creating a structure to the identifiers that would be
    inconsistent with other uses, e.g., in SRV records. I.e., I would expect:

    - either all transports are potential labels, or only TCP and UDP (the
      label being only how things are searched, not necessarily an indicator
      of what protocol is being used)

    - if TLS is included, that should be encoded in the service name part of
      the label (http vs. https), and meaningful only on a per-label basis
      (i.e., you can't assume that "ends with 's'" means TLS), rather than
      using the "." separator for an hierarchy

[Ballot discuss]
These are comments for discussion, that may (or may not) be clearable without document changes.

Some questions arose in TSVDIR review of this document, including:

- should this have "Updates: RFC 3958" added?

- should the ABNF for "aaa-transport" include an extension prototype?  It may not be clear how clients would handle a new transport being added at a latter time.

- and relayed from Joe Touch:
  - The suggested alternate NAPTR structure seems to imply two things:
    1 - more than just TCP and UDP as transport labels
    2 - a hierarchical structure of labels that includes intermediate encodings

    Neither of these are particularly consistent with the way in which SRV
    labels appear to be used, AFAICT - as per the IANA ports doc. Given that
    diameter is a service name (in IANA ports), I'm concerned that this
    proposal is creating a structure to the identifiers that would be
    inconsistent with other uses, e.g., in SRV records. I.e., I would expect:

    - either all transports are potential labels, or only TCP and UDP (the
      label being only how things are searched, not necessarily an indicator
      of what protocol is being used)

    - if TLS is included, that should be encoded in the service name part of
      the label (http vs. https), and meaningful only on a per-label basis
      (i.e., you can't assume that "ends with 's'" means TLS), rather than
      using the "." separator for an hierarchy

--- TSV-DIR review by Magnus Westerlund ----------------------------------

As I understand this document what it primarily does is to reserve a
certain range of application service identifier all stating with aaa+ap
to have a special meaning.

In addition within this reserved range it also changes the registration
rules and allows vendor specific registrations on a first come first
served based.

Based on that I have to ask myself if this document shouldn't in fact
have an "Updates: RFC 3958".

Secondly, I do wonder if the ABNF definition for the aaa-transport:

aaa-transport            = "tcp" / "sctp" / "tls.tcp"

Should include an extension prototype or simply assume that one fall
back on the high level syntax and defines a new one. It is clear what
the syntax rules for any new definition needs to be. What isn't clear is
how clients would handle such a new transport.

---- Comments from Joe Touch, from the Expert Review team for IANA ports registration ------

This seems a little strange. I'm not entirely sure how independent this
proposal is, e.g., from other strings used to indicate services over
transports (as per the IANA ports doc). Given that, see the comments below.

I'd be relieved if we could know that the proposed structure to service
strings wouldn't bleed into or interfere with the current structure.

The suggested alternate NAPTR structure seems to imply two things:

- more than just TCP and UDP as transport labels

- a hierarchical structure of labels that includes intermediate encodings

Neither of these are particularly consistent with the way in which SRV
labels appear to be used, AFAICT - as per the IANA ports doc. Given that
diameter is a service name (in IANA ports), I'm concerned that this
proposal is creating a structure to the identifiers that would be
inconsistent with other uses, e.g., in SRV records. I.e., I would expect:

- either all transports are potential labels, or only TCP and UDP (the
label being only how things are searched, not necessarily an indicator
of what protocol is being used)

- if TLS is included, that should be encoded in the service name part of
the label (http vs. https), and meaningful only on a per-label basis
(i.e., you can't assume that "ends with 's'" means TLS), rather than
using the "." separator for an hierarchy

[Ballot comment]
Can the different abnf productions here really be distinguished?

      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

Seems like ALPHA *31ALPHASYMNUM does allow starting with "x-"
so there's no way to know if an "x-foo" is iana-registered or not based
on the abnf above. (Or is there some 1st matching rule I don't know?)

Upon approval of this document, IANA understands that there are five
IANA Actions that must be completed.

First, in the S-NAPTR Application Service Tags subregistry of the
Straightforward-NAPTR (S-NAPTR) Parameters registry located at:

http://www.iana.org/assignments/s-naptr-parameters/s-naptr-parameters.xml

IANA will register the string "aaa" with a reference of the current,
approved document.

Second, in the S-NAPTR Application Service Tags subregistry of the
Straightforward-NAPTR (S-NAPTR) Parameters registry located at:

http://www.iana.org/assignments/s-naptr-parameters/s-naptr-parameters.xml

the following values will be added:

+------------------+----------------------------+
| Tag              | Reference                  |
+------------------+----------------------------+
| aaa+ap1          | [RFC3588]                  |
| aaa+ap2          | [RFC4004]                  |
| aaa+ap3          | [RFC3588]                  |
| aaa+ap4          | [RFC4006]                  |
| aaa+ap5          | [RFC4072]                  |
| aaa+ap6          | [RFC4740]                  |
| aaa+ap7          | [RFC5778]                  |
| aaa+ap8          | [RFC5778]                  |
| aaa+ap9          | [RFC5866]                  |
| aaa+ap4294967295 | [RFC3588]                  |
+------------------+----------------------------+

Third, in the S-NAPTR Application Service Tags subregistry of the
Straightforward-NAPTR (S-NAPTR) Parameters registry located at:

http://www.iana.org/assignments/s-naptr-parameters/s-naptr-parameters.xml

the following values will be added:

+----------------+----------------------+
| Tag            | Reference            |
+----------------+----------------------+
| aaa+ap16777250 | [TS29.273]          |
| aaa+ap16777251 | [TS29.272]          |
| aaa+ap16777264 | [TS29.273]          |
| aaa+ap16777267 | [TS29.215]          |
+----------------+----------------------+

Where the references are:
[TS29.215]
3rd Generation Partnership Project, "3GPP TS 29.215; Technical
Specification Group Core Network and Terminals; Policy and Charging
Control (PCC) over S9 reference point; Stage 3 (Release 8)",
http://www.3gpp.org/ftp/Specs/html-info/29215.htm

{TS29.272]
3rd Generation Partnership Project, "3GPP TS 29.272; Technical
Specification Group Core Network and Terminals; Evolved Packet System;
Mobility Management Entity (MME) and Serving GPRS Support Node (SGSN)
Related Interfaces Based on Diameter Protocol (Release 8)",
http://www.3gpp.org/ftp/Specs/html-info/29272.htm

[TS29.273]
3rd Generation Partnership Project, "3GPP TS 29.273; Technical
Specification Group Core Network and Terminals; Evolved Packet System;
3GPP EPS AAA interfaces (Release 8)",
http://www.3gpp.org/ftp/Specs/html-info/29273.htm

Fourth, in the S-NAPTR Application Service Tags subregistry of the
Straightforward-NAPTR (S-NAPTR) Parameters registry located at:

http://www.iana.org/assignments/s-naptr-parameters/s-naptr-parameters.xml

the following values will be added:

+----------------+--------------------------------------------------+
| Tag            | Reference                                        |
+----------------+--------------------------------------------------+
| aaa+ap16777281 | [WIMAX]                                          |
| aaa+ap16777282 | [WIMAX]                                          |
| aaa+ap16777283 | [WIMAX]                                          |
| aaa+ap16777284 | [WIMAX]                                          |
| aaa+ap16777285 | [WIMAX]                                          |
| aaa+ap16777286 | [WIMAX]                                          |
| aaa+ap16777287 | [WIMAX]                                          |
| aaa+ap16777288 | [WIMAX]                                          |
| aaa+ap16777289 | [WIMAX]                                          |
| aaa+ap16777290 | [WIMAX]                                          |
+----------------+--------------------------------------------------+

Reference:
[WiMAX]    WiMAX Forum, "WiMAX Release 1.5", 
http://www.wimaxforum.org/resources/documents/technical/T33.

Fifth, in the in the S-NAPTR Application Protocol Tags subregistry of
the Straightforward-NAPTR (S-NAPTR) Parameters registry located at:

http://www.iana.org/assignments/s-naptr-parameters/s-naptr-parameters.xml

the following values will be added: subregistry of the
Straightforward-NAPTR (S-NAPTR) Parameters registry located at:

http://www.iana.org/assignments/s-naptr-parameters/s-naptr-parameters.xml

the following values will be added:

+------------------+----------+
| Tag              | Reference|
+------------------+----------+
| diameter.tcp    | [RFC3958]|
| diameter.sctp    | [RFC3958]|
| diameter.tls.tcp | [RFC3958]|
+------------------+----------+

IANA understands that these are the only actions that need to be
completed upon approval of the document.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Diameter S-NAPTR Usage) to Proposed Standard


The IESG has received a request from the Diameter Maintenance and
Extensions WG (dime) to consider the following document:
- 'Diameter S-NAPTR Usage'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-04-20. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-dime-extended-naptr/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-dime-extended-naptr/

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

I, Sebastien Decugis (sdecugis@nict.go.jp), am the document shepherd,
appointed by DiME chairs. I have reviewed the document and I believe it
is ready to be forwarded to IESG for publication.


(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

The document has received several in-depth reviews by group members
and sufficient discussion inside the DIME working-group.

The document should still be reviewed by DNS experts.
These reviews can be done during the IETF LC.


(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

I don't have such concern.


(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

I don't have such concerns or issues.


(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

Since the WG consists of a few individuals, it is difficult to answer
this question. However, the document was taken as WG item with a strong
consensus on its usefulness, and received good contributions afterwards.


(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No, to the best of my knowledge.


(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See the Internet-Drafts Checklist
and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

I have checked the ID nits and checklist, and confirmed that
there is no issue with this document.


(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

The references are split.
There is a race condition with rfc3588bis draft, which is explicited
in Section 10 of this draft (Editor's Note).
There is no downward reference.


(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

I have verified the IANA consideration section.
The new entries to existing registries are correctly identified.
There is no new registry requested.


(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

The ABNF syntax is verified and correct. There is no other formal language
in the document.


(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary

This document describes an improvement to Diameter dynamic peers discovery
mechanism using an extended format for the Straightforward-NAPTR (S-NAPTR)
Application Service Tag that allows for discovery of the supported Diameter
applications without doing Diameter capability exchange beforehand.


Working Group Summary

The WG process went smoothly for this document.
The document is a result of collaborative WG work.


Document Quality

There is currently no publicly announced implementations of this mechanism,
but there is known on-going implementation effort.
S-NAPTR and Diameter are implemented protocols.