Re: : digest issue 11 closure (fwd)

Minimizing the "coding" or "mapping table construnction" is a valuable 
argument when it has an impact on the processing time. But as I said 
before, this time is negligible compared to the time the gateway will 
use to process a request, so I don't see the point in destroying the 
clear structure we have in the Diameter SIP app for no visible gain.

/Miguel

Jari Arkko wrote:

> 
> Let me expand on what I meant with "additional work" that
> a R/D gateway needs to do. As originally envisioned, the Diameter
> translation gateway was expected to be a mindless automaton,
> blindly copying attributes to slightly different format. This would
> be great, as the introduction of a new application or AVP would
> not impact a gateway, or would only have a small impact. But we have
> actually come quite far from this ideal, the current translation
> rules for applications contain a number of attribute specific
> processing rules.
> 
> I realize we have already started on this path, and there's no
> turning back. Nevertheless, minimizing the necessary "coding"
> or "mapping table construction" for translation gateways is
> still valuable, as the simpler they are the easier they are to
> implement.
> 
> I also realize that there are conflicting requirements. Ability
> to clearly associate a particular set of attributes to a group
> can be problematic (but doesn't that have to be solved for
> RADIUS SIP anyway?). And grouping things inside on Grouped
> AVP looks much nicer.
> 
> --Jari
> 
> Miguel Garcia wrote:
> 
>> I have filed his issue:
>>
>> http://danforsberg.info:8080/draft-ietf-aaa-diameter-sip/issue47
>>
>> Now, I asked sometime ago what would be the problem in having grouped 
>> AVPs that, in turn, contain Digest-* attributes imported from RADIUS. 
>> The answer I got (Jari), at that time, was, there shouldn't be a problem.
>>
>> I still belive that grouped AVPs constitute a powerful mechanism to 
>> avoid problems (such as sequencing, repetition, etc.). I think that 
>> Jari's argument is weak ("this will create some overload to the 
>> gateway"). The gateway will need to do a bunch of other functions to 
>> translate RADIUS to Diameter, so I am not for the idea of constraining 
>> the protocol (Diameter) just because the gateway (to RADIUS) will have 
>> some extra load. I believe this extra load is negligible compared to 
>> the rest of AVPs the gateway will need to rebuild.
>>
>> My opinion: I am in favor of leaving the grouped AVPs as they are.
>>
> 
> 

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Research Center      Helsinki, Finland