Re: [Dime] [dime] #4: Review from Sebastien Decugis

["dime issue tracker" <[e-mail]>]

#4: Review from Sebastien Decugis


Comment (by lionel.morand@…):

 >> 1) (3.1.1) second list item (editorial):
 >> =======================================
 >>
 >> Furthermore, the redirect agent MUST a Redirect-Realm AVP
 >>
 >>     missing word?
 >>
 >> Response:
 >>
 >> Text in -05 version now reads:
 >>
 >>       The server MUST include the Result-Code AVP set to
 >>       DIAMETER_REALM_REDIRECT_INDICATION.  The server MUST also include
 >>       the alternate realm identifiers with which it has been
 configured,
 >>       each in a separate Redirect-Realm AVP instance.
 >>
 >> (Note that the redirect agent has been replaced by a server, at least
 >> until the WG debates the issue in Vancouver.)
 >
 > [SD] Sounds good to me, thanks.
 >
 >
 >> 2) (3.1.1) What if the the other peer advertised the Relay application?
 >> =====================================================================
 >> ===
 >>
 >> ==> Should the redirect agent consider that it supports the
 >> Redirect-Realm application?
 >>
 >> Response:
 >>
 >> Text in -05 version no longer discusses applications supported by the
 >> upstream peer. New section 3.2.2 specifies rerouting by a conforming
 >> proxy, but I think a relay would just have to pass the answer back
 >> upstream because rerouting requires changes to the request. Should
 >> that be stated explicitly?
 >
 > [SD] Indeed you are right, since the proxy has to change the
 > Destination-Realm AVP, it is not a simple relay anymore. I guess this
 > does not require a clarification in the document, the new text is
 > clear enough.
 >
 >
 >>  3) (3.1.1) "the message MUST include the Error- Reporting-Host AVP
 >> if the host setting the Result-Code AVP is different from the
 >> identity encoded in the Origin-Host AVP,"
 >> =====================================================================
 >> =
 >>
 >> ==> IIUC this is an impossible situation, since the Redirect Agent
 >> did not forward the Request. I believe this text could be removed for
 >> clarity.
 >>
 >> Response:
 >>
 >> Done.
 >
 > [SD] Thanks
 >
 >
 >>
 >>  4) (3.1.2)
 >> ===========
 >>
 >> ==> What if the original request contains a Destination-Host AVP? In
 >> that case, should a UNABLE_TO_DELIVER error be returned? There is
 >> probably no point in sending to the alternate realm with a
 >> Destination-Host in the previous realm, right? Unless maybe if the
 >> Destination-Realm of the request message does not match the
 >> Origin-Realm of the Redirect indication (change of broker for
 >> example). Any opinion?
 >>
 >> Response:
 >>
 >> Text is currently written as follows:
 >>
 >>   o  If the request contains a Destination-Host AVP, the server MUST
 >>       set the 'E' bit in the answer and set the Result-Code AVP to
 >>       DIAMETER_UNABLE_TO_DELIVER.
 >>
 >> However, I don't really like that -- important information is not
 >> getting back upstream. Rereading your comment, I'm thinking the
 >> appropriate behaviour is to set DIAMETER_REALM_REDIRECT_INDICATION in
 >> this case, too. The proxy is told (in new section 3.2.2):
 >>
 >>        B.  Remove the Destination-Host (if present) and Destination-
 >>            Realm AVPs from the original request and add a new
 >>            Destination-Realm AVP containing the realm selected in the
 >>            initial step.
 >>
 >> So this case is taken care of properly and the server bullet quoted
 >> above should be deleted. I had meant to bring this up for discussion
 >> in Vancouver, but at this point the proper behaviour seems obvious.
 >
 > [SD] I am not quite clear on which one is the proper behavior to adopt
 > (reply an error or redirect to the realm in any case) and I'll let the
 > WG status on this. I am fine with both choices, as long as they are
 > clear in the document. Note that I guess the debate is really to know
 > how the Destination-Host AVP is used. If you consider for example the
 > Diameter EAP application, this AVP is used to ensure that further
 > messages in a session will reach the same Diameter server as the
 > initial message. Redirecting such middle-session messages would not
 > have any meaning. I guess this might be left as a choice for the
 > applications implementing this RFC...
 >
 >
 >>  5) (3.2)
 >> =========
 >>
 >> ==> This section does not give the value of the M flag for the new
 >> AVP. By the semantics of the application, I believe the M flag should
 >> be set, right?
 >>
 >> Response:
 >>
 >> Relevant text is now in section 3.3. Last sentence reads:
 >>
 >>    The M flag for the Redirect-Realm AVP MUST be set, and the V flag
 >>    MUST NOT be set.
 >
 > [SD] Perfect :)

-- 
----------------------------------+------------------
 Reporter:  lionel.morand@…       |       Owner:
     Type:  enhancement           |      Status:  new
 Priority:  major                 |   Milestone:
Component:  realm-based-redirect  |     Version:
 Severity:  In WG Last Call       |  Resolution:
 Keywords:                        |
----------------------------------+------------------

Ticket URL: <http://wiki.tools.ietf.org/wg/dime/trac/ticket/4#comment:1>
dime <http://tools.ietf.org/wg/dime/>