Re: : digest issue 11 closure (fwd)
Jari Arkko <[email protected]>
| Newsgroups | gmane.ietf.aaa |
|---|---|
| Message-ID | <[email protected]> |
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.
>