Re: [Dime] I-D Action:draft-ietf-dime-realm-based-redirect-01.txt

["Victor Fajardo" <vfajardo at research.telcordia.com>]

Hi Tom,

Any plans on submitting and update to the doc ?

Regards,
Victor
 
-----Original Message-----
From: dime-bounces at ietf.org [mailto:dime-bounces at ietf.org] On Behalf Of Tom
Taylor
Sent: Wednesday, October 07, 2009 3:50 PM
To: Mark Jones
Cc: dime at ietf.org
Subject: Re: [Dime] I-D Action:draft-ietf-dime-realm-based-redirect-01.txt

I'll take the second choice you offer.

Mark Jones wrote:
> Hi Tom, 
> 
>> -----Original Message-----
>> From: Tom Taylor [mailto:tom.taylor at rogers.com] 
>> Sent: October 6, 2009 10:09 PM
>> To: Mark Jones
>> Cc: dime at ietf.org
>> Subject: Re: [Dime] I-D 
>> Action:draft-ietf-dime-realm-based-redirect-01.txt
>>
>> What I'm worried about is whether this implies every 
>> application out there has 
>> to be redefined to make use of this feature.
>>
> 
> That is indeed the implication. Alternatively, you define a new
application id for the realm-based redirect functionality and it complements
the existing applications, i.e. if you need NASREQ with realm-based
redirect, the CER/CEA advertises the NASREQ Application Id and the
Realm-based Redirect Application ID.
> 
> Regards
> Mark
> 
> 
>> Mark Jones wrote:
>>> Hi Tom,
>>>
>>> I was expecting a stronger statement on advertisement at 
>> the application level, e.g.
>>> "Because realm-based redirection is not part of base 
>> Diameter behaviour, support for realm-based redirection by 
>> the peers MUST be advertised at the application level."
>>> I don't see how the feature works reliably otherwise and 
>> punting the risk evaluation to the service provider seems 
>> inappropriate for a feature likely to used on 
>> inter-service-provider interfaces.
>>> Regards
>>> Mark
>>>
>>>
_______________________________________________
DiME mailing list
DiME at ietf.org
https://www.ietf.org/mailman/listinfo/dime