Re: [Dime] Diameter Group: Type?

Hi,

On Jan 25, 2011, at 2:02 PM, Erez Nassimi wrote:

> Hi Avi & Sebastian - and thank you David for the support :-)
>  
> A few comments and clarifications:
>  
> 1.       I don't think it's too late to add a "G"rouped bit in flags. Adding a "G" bit, should not revoke / replace Groups as type. It could be an additional feature.

If it is not broken or severely confusing, then adding a new optional feature would just add new code and for no proper reason.

> 2.       By saying "Group may be basic", I mean it may be a basic concept, but not a basic type.
> 3.       Syntax parsing the inside level of AVP's might be very useful, when there is a need to filter out irrelevant / incorrect messages as quick as possible.

If you do not understand the grouped AVP, then depending on the M bit, I either do not care the whole grouped AVP or return an error pointing to the grouped APV, not the contents of it.

> 4.       I think you would agree with me, that when syntax parsing a Diameter message (for example to verify validity of the message), it would be faster to identify a Group, without accessing any other data structure. That's what I mean by performance improvement.

I agree that it could be a performance enhancement. However, you would need to access the dictionary for the AVPs inside the group anyway. Depending how your per application dictionaries are handled, the performance gain might be subtle.

> 5.       It's clear that when reaching a semantic analysis phase of the Diameter message, one needs ALL necessary info. Group or not Group, this is just a small part of the info in that phase.
> 6.       In any case, an additional "G" bit cannot harm anything; since in the worst case the Group type info still exists. So the "G" bit can be ignored.

It can make stupid parsers to break who expect to receive a 0 in place of G bit..

> 7.       Also "calculating" the "G" bit when creating a message should not be a burden, since the info has to be there anyway.

Right.

- Jouni

>  
> I hope I'm more clear now.
>  
> Regards,
> Erez Nassimi
> This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement,
> you may review at 
> http://www.amdocs.com/email_disclaimer.asp
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime