[Dime] Review of draft-ietf-dime-realm-based-redirect-02

[Sebastien Decugis <[e-mail]>]

Hello all,

Here is my review for the realm-based redirect document. My main comment
is about the new application Id, I think the document needs more
clarification. I have several comments related to this point:
- first of all, the advertisement of the application id is a "one hop"
mechanism in Diameter, during CER/CEA exchange. It would be useful to
clarify if we are limiting the realm-redirect to a single hop. My
understanding of RFC3588 redirect is that it will go back to the source
of the request, unless some relay interprets the content of the error
message (since the E bit is set). I would have assumed the same for
realm redirections, but I know some people advocated for a separate
application id -- it is just that I don't really understand how it is used.
- a corollary of the previous comment is that the document does not
specify how the new Application Id is used. My understanding from the
abstract is that we advertise the new application id during CER/CEA
exchange, inside a Auth-Application-Id AVP (this is a wild guess from
me). What happens if the other peer does not advertize the same
application, are we still allowed to use the realm-based redirect
mechanism ? Do we default to a host-based redirect? What if the peer
advertized the relay application ? These questions should be answered by
the document.

Here is the remaining of my comments, mostly editorial, except for the
usage part:
In paragraph 2, I think "client" is not appropriate. What about "peer"
instead ?

In paragraph 3, I think the value of the error code will be allocated by
IANA right ? (RFC3588 says IETF consensus, I am not sure what it means).
I believe the text should simply contain something like "3xxx TBD".

In paragraph 3.1.1, the Redirect-Max-Cache-Time AVP is told to indicate
the "scope" and persistance of... but I don't understand the word
"scope" here, maybe a remain from previous version ?
In same paragraph, "the Result-Code AVP MUST include the
Error-Reporting-Host AVP" is erroneous, since Result-Code is not a
grouped AVP. I would rephrase to something like "The
Error-Reporting-Host AVP must be included in the message along the
Result-Code AVP... ".

In paragraph 3.1.2, the redirect usage of ALL_REALM. I think this
conflicts with the rationale for the document presented in the
introduction, where an operator would stop providing a service. In that
case, we would more likely need a redirect usage of
REALM_AND_APPLICATION or even maybe ALL_APPLICATION, right? So that
messages that belong to a different application are still routed to our
servers.

In paragraph 3.2, I believe the document should mention if several
instances of the Redirect-Realm AVP can be present in the same message,
and how this situation must be interpreted (probably the same as if
several Redirect-Host are present, I would assume...)

In paragraph 4, there is a small typo: "Because real-based..." should
read "Because realm-based..."

In paragraph 5, same comment as paragraph 3, I am not sure the document
should already provide some values for the IANA managed registries...

That's all I have :)

Best regards,
Sebastien.

-- 
Sebastien Decugis
Research fellow
Network Architecture Group
NICT (nict.go.jp)