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

[Tom Taylor <[e-mail]>]

Thanks for your solid review. I'm moving slowly on my post-meeting obligations, 
as the result of catching a nasty cold on the way back from Japan. I left the 
"non-functional misery" stage somewhere around last Tuesday, but I'm still 
looking forward to leaving the "functional misery" stage.

Yeah, I'm feeling sorry for myself.

Sebastien Decugis wrote:
> 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.
>