Re: [Dime] Would realm-based redirection be a protocol error or an application error?

DIAMETER_REALM_REDIRECT_INDICATION should be defined as an Application error.
I think the 5XXX class is appropriate.
The R-bit should be cleared (default for all Diameter answer messages) and E-bit should not be set.

Sent from my iPad

On Jan 9, 2012, at 5:57 PM, "Tom Taylor" <tom.taylor.stds@gmail.com> wrote:

> See below.
> 
> On 09/01/2012 2:00 AM, Glen Zorn wrote:
>> On 1/9/2012 3:20 AM, Tom Taylor wrote:
>> 
>>> I'm finally updating draft-ietf-dime-realm-based-redirect.
>>> 
>>> Given that realm-based redirection is defined at an application level,
>>> maybe the answer is obvious.
>> 
>> Section 7 of RFC 3588 says
>> 
>>    There are two different types of errors in Diameter; protocol and
>>    application errors.  A protocol error is one that occurs at the base
>>    protocol level, and MAY require per hop attention (e.g., message
>>    routing error).  Application errors, on the other hand, generally
>>    occur due to a problem with a function specified in a Diameter
>>    application (e.g., user authentication, Missing AVP).
>> 
>>> What I am concerned with is whether the
>>> redirect server should clear the 'R' bit in the header to ensure that
>>> the response goes all the way back to the original requesting host
>>> (i.e., following on Figure 8 in section 7 of RFC 3588).
>> 
>> I don't understand: as I understand it, the 'R' bit has nothing to do
>> with error type; if it is cleared that just signifies that the message
>> is an answer, rather than a request (which would presumably be true of
>> any error response).
> 
> [PTT] I don't think so. Section 7 makes a clear distinction between the routing for protocol error responses and application error responses (Figures 7 and 8 rtespectively) and ascribes the difference to the setting of the 'R' bit (text following Figure 8).
>> 
>>> The reason for
>>> doing this is the issue identified in the Security Considerations
>>> section of the realm-based-redirection I-D: a change of realm implies a
>>> change of business relationship
>> 
>> I think that this is not necessarily true.  For example, consider a
>> large ISP with international operations; such an entity might have
>> multiple Diameter realms (europe.bigisp.com, asia.bigisp.com, etc.), no?
>> 
>>> that should be noted by the requesting
>>> host before the request is rerouted.
> 
> [PTT] I think I've decided not to mention the 'R' bit. The result fits within the recommendations in the Security Considerations section.
> 
>>> 
>>> Tom Taylor
>>> _______________________________________________
>>> DiME mailing list
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
>> 
>> 
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime