Clarifications on the Routing of Diameter Requests Based on the Username and the Realm
draft-ietf-dime-nai-routing-04

[Ballot comment]
I support Jari's DISCUSS on i18n (issue 6).


4.2.  Ensuring Backwards Compatibility

  Implementations compliant to this specification MUST define a new
  Diameter application.  This requirement is set to guarantee backwards
  compatibility with existing Diameter implementations, applications
  and deployments.  Diameter agents not compliant with this
  specification will not advertise support for these new applications
  that implement the enhanced routing solution based on Decorated NAIs
  and will therefore be bypassed.

Excuse my ignorance, but how can this be achived?

[Ballot discuss]
This document should move forward, but I have a couple of concerns:

1. History

> At the time of publication of the Diameter Base Protocol [RFC3588],
> the NAI definition was based on [RFC2486] in which a NAI could only
> contain a single realm.  The NAI definition has since been updated in
> [RFC4282] to define Decorated NAIs that contain multiple realms.

As far as I can remember, this was not the exact history. First of
all, RFC 2486 had examples employing the bang notation, and there
were several implementations and proposals that took benefit of
schemes like this. RFC 4282 expanded and clarified this usage, and
was published at the same time as RFC 4284 came out, which was
a very specific usage of the bang syntax and other things.

I would suggest a rewrite: "While the use multiple realms is
generally discouraged, RFC 4282 does allow multiple realms.
The use of this facility appears in, for instance, RFC 4284.

2. RFC 4284

And add RC 4284 as an informational reference.

3. Use of example domain names

> decorate its NAI as Realm-H!username@Realm-X.  The roaming terminal

I understand that you've used Realm-X in the sense of a variable here,
but the realm parts are supposed to be DNS names. I'd like to see
these examples reverted to (a) the use of example.com domain names
or (b) use some syntactic notation that makes it clear that Realm-X is
not a domain name but a conceptual variable.

4. Interoperability

> Implementations compliant to this specification MUST define a new
> Diameter application.

While this is a theoretically a nice way to avoid a problem, it also
seems at odds with real world deployment. Diameter applications
already exists and implementations already use decoration. I don't
understand how this requirement improves the situation. It may hurt,
in fact, if the result is further proliferation of separate diameter
applications, reducing the likelihood of interoperability in a
situation where both endpoints would like to use the same conceptual
application (but different App IDs) and both are decoration capable.

5. Track

Finally, we need to understand that NAI decoration has throughout
its history been frowned upon. RFC 4282 documented its use as a part
of known industry designs and RFC 4284. However, as pointed out in
RFC 5113, it is not believed to be a long term solution, and has a
number of issues. I'm uncomfortable with the idea publishing further
Standards Track specifications building additional features around
it. However, Informational seems like an appropriate classification,
and I support the publication of this document as such.

6. There has been some recent discussion in RADEXT WG about i18n
NAIs. This document takes no position on the matter, but the
decoration is probably the most difficult part to handle in an i18n
solution. Shouldn't the document say something about this?

[Ballot discuss]
This Discuss is to raise an issue with the IESG during the telechat. I will clear the Discuss during the telechat and no action is required form the authors.

Every time I see an I-D with "routing" in the title my nerves get even further shattered! Is there an easy way we can introduce some differentiation between routing as seen in the Routing Area, and the selection of a sequence of domains or servers that we see in other Areas? (Or am I just being too nervous?)

[Ballot discuss]
This document should move forward, but I have a couple of concerns:

1. History

> At the time of publication of the Diameter Base Protocol [RFC3588],
> the NAI definition was based on [RFC2486] in which a NAI could only
> contain a single realm.  The NAI definition has since been updated in
> [RFC4282] to define Decorated NAIs that contain multiple realms.

As far as I can remember, this was not the exact history. First of
all, RFC 2486 had examples employing the bang notation, and there
were several implementations and proposals that took benefit of
schemes like this. RFC 4282 expanded and clarified this usage, and
was published at the same time as RFC 4284 came out, which was
a very specific usage of the bang syntax and other things.

I would suggest a rewrite: "While the use multiple realms is
generally discouraged, RFC 4282 does allow multiple realms.
The use of this facility appears in, for instance, RFC 4284.

2. RFC 4284

And add RC 4284 as an informational reference.

3. Use of example domain names

> decorate its NAI as Realm-H!username@Realm-X.  The roaming terminal

I understand that you've used Realm-X in the sense of a variable here,
but the realm parts are supposed to be DNS names. I'd like to see
these examples reverted to (a) the use of example.com domain names
or (b) use some syntactic notation that makes it clear that Realm-X is
not a domain name but a conceptual variable.

4. Interoperability

> Implementations compliant to this specification MUST define a new
> Diameter application.

While this is a theoretically a nice way to avoid a problem, it also
seems at odds with real world deployment. Diameter applications
already exists and implementations already use decoration. I don't
understand how this requirement improves the situation. It may hurt,
in fact, if the result is further proliferation of separate diameter
applications, reducing the likelihood of interoperability in a
situation where both endpoints would like to use the same conceptual
application (but different App IDs) and both are decoration capable.

5. Track

Finally, we need to understand that NAI decoration has throughout
its history been frowned upon. RFC 4282 documented its use as a part
of known industry designs and RFC 4284. However, as pointed out in
RFC 5113, it is not believed to be a long term solution, and has a
number of issues. I'm uncomfortable with the idea publishing further
Standards Track specifications building additional features around
it. However, Informational seems like an appropriate classification,
and I support the publication of this document as such.

[Ballot discuss]
> At the time of publication of the Diameter Base Protocol [RFC3588],
> the NAI definition was based on [RFC2486] in which a NAI could only
> contain a single realm.  The NAI definition has since been updated in
> [RFC4282] to define Decorated NAIs that contain multiple realms.

As far as I can remember, this was not the exact history. First of
all, RFC 2486 had examples employing the bang notation, and there
were several implementations and proposals that took benefit of
schemes like this. RFC 4282 expanded and clarified this usage, and
was published at the same time as RFC 4284 came out, which was
a very specific usage of the bang syntax and other things.

I would suggest a rewrite: "While the use multiple realms is
generally discouraged, RFC 4282 does allow multiple realms.
The use of this facility appears in, for instance, RFC 4284.

And add RC 4284 as an informational reference.

> decorate its NAI as Realm-H!username@Realm-X.  The roaming terminal

I understand that you've used Realm-X in the sense of a variable here,
but the realm parts are supposed to be DNS names. I'd like to see
these examples reverted to (a) the use of example.com domain names
or (b) use some syntactic notation that makes it clear that Realm-X is
not a domain name but a conceptual variable.

> Implementations compliant to this specification MUST define a new
> Diameter application.

While this is a theoretically a nice way to avoid a problem, it also
seems at odds with real world deployment. Diameter applications
already exists and implementations already use decoration. I don't
understand how this requirement improves the situation. It may hurt,
in fact, if the result is further proliferation of separate diameter
applications, reducing the likelihood of interoperability in a
situation where both endpoints would like to use the same conceptual
application (but different App IDs) and both are decoration capable.

Finally, we need to understand that NAI decoration has throughout
its history been frowned upon. RFC 4282 documented its use as a part
of known industry designs and RFC 4284. However, as pointed out in
RFC 5113, it is not believed to be a long term solution, and has a
number of issues. I'm uncomfortable with the idea publishing further
Standards Track specifications building additional features around
it. However, Informational seems like an appropriate classification,
and I support the publication of this document as such.

[Ballot comment]
4.2.  Ensuring Backwards Compatibility

  Implementations compliant to this specification MUST define a new
  Diameter application.  This requirement is set to guarantee backwards
  compatibility with existing Diameter implementations, applications
  and deployments.  Diameter agents not compliant with this
  specification will not advertise support for these new applications
  that implement the enhanced routing solution based on Decorated NAIs
  and will therefore be bypassed.

Excuse my ignorance, but how can this be achived?

[Ballot comment]
The header of the document says:
Updates: 3588, 3588bis

What is 3588bis and why is it not listed in the list of references?


4.2.  Ensuring Backwards Compatibility

  Implementations compliant to this specification MUST define a new
  Diameter application.  This requirement is set to guarantee backwards
  compatibility with existing Diameter implementations, applications
  and deployments.  Diameter agents not compliant with this
  specification will not advertise support for these new applications
  that implement the enhanced routing solution based on Decorated NAIs
  and will therefore be bypassed.

Excuse my ignorance, but how can this be achived?

PROTO Writeup for draft-ietf-dime-nai-routing
=============================================

http://tools.ietf.org/html/draft-ietf-dime-nai-routing-02

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

Hannes Tschofenig is the document shepherd.
The document is ready for publication.

Dan Romascanu is the responsible AD.

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

The document was reviewed within the DIME working group.

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

There are no concerns regarding the amount of review.
The document will also be reviewed by the AAA doctors group in a later
publication phase.

(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 interested community has discussed those issues and has
indicated that it still wishes to advance the document, detail
those concerns here.

There are no concerns with the document.

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

There is consensus within the DIME WG to publish the document.
The members of the group had some discussions regarding procedural
aspects, namely whether to progress this document independently or
as part of RFC3588bis. The decision was made to progress it
independently.

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

Nobody stated extreme discontent.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html 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?

The nits have been checked.


(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 in the document have been split into normative and
informative.


(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 suggested a reasonable name for the new registry? See
[I-D.narten-iana-considerations-rfc2434bis]. 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?

This document does not require actions by IANA.

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

There is no formal language in the document.

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

Technical Summary

This specification defines the behavior required of Diameter agents
to route requests when the User-Name Attribute Value Pair contains a
Network Access Identifier formatted with multiple realms. These
multi-realm or "Decorated" Network Access Identifiers are used in
order to force the routing of request messages through a predefined
list of mediating realms.


Working Group Summary

The document fixes a small technical aspect and hence it sailed
smoothly through the DIME group.

Document Quality

This document is the product of the DIME working group.
The current implementation status of this specification is, however,
unknown. We expect implementations to arrive when larger Diameter
deployments utilize the RFC 4282 based NAI format.

Personnel

Hannes Tschofenig is the document shepherd for this document.
Dan Romascanu is the responsible AD.