Subject: Re: [Dime] Diameter Group: Type?

From: Erez Nassimi <[email-masked]>
Date: Fri, 28 Jan 2011 02:20:27 +0200

Guys,

Thank you for the comments. I think everyone agrees there is a bug in RFC. But this can lead us to 2 different interpretations:

1.  Based on "an unrecognized bit SHOULD be considered an error", we could assume that "subsequent Diameter applications MAY define additional bits within the AVP Header", should have read "subsequent Diameter versions".

2.  But the words are very clear and as of now it says "subsequent Diameter applications".
In any case, my point was rather conceptual than technical. Defining a Grouped AVP as a type, is similar to classifying C++ classes in the same category as simple types as int, char, etc. There is a difference after all. I found it important enough to differentiate between them with a "G" bit.

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

---

From: Mark Jones <[email-masked]>
Date: Fri, 28 Jan 2011 13:13:37 +0100

Hi Erez,

Will you be raising an issue on 3588bis so the authors can fix this bug?

Thanks
Mark

On Fri, Jan 28, 2011 at 1:20 AM, Erez Nassimi <[email-masked]>wrote:

> 1.  Based on “an unrecognized bit SHOULD be considered an error”, we could assume that “subsequent Diameter applications MAY define additional bits within the AVP Header”, should have read “subsequent Diameter versions”.
>
> 2.  But the words are very clear and as of now it says “subsequent Diameter applications”.
>
> In any case, my point was rather conceptual than technical. Defining a
> Grouped AVP as a type, is similar to classifying C++ classes in the same
> category as simple types as int, char, etc. There is a difference after all.
> I found it important enough to differentiate between them with a “G” bit.
>
>
>
> Regards,
>
> *Erez Nassimi*
>

---

From: jouni korhonen <[email-masked]>
Date: Fri, 28 Jan 2011 15:26:24 +0200

I would encourage 3588bis authors to look into this specific place. I also think it is an error that needs to be fixed.

- Jouni

On Jan 28, 2011, at 2:13 PM, Mark Jones wrote:

> On Fri, Jan 28, 2011 at 1:20 AM, Erez Nassimi <[email-masked]> wrote:
> Guys,
> 
>  
> In any case, my point was rather conceptual than technical. Defining a Grouped AVP as a type, is similar to classifying C++ classes in the same category as simple types as int, char, etc. There is a difference after all. I found it important enough to differentiate between them with a “G” bit.
> 
>  
> Regards,
> 
> Erez Nassimi
> 
> you may review at 
> http://www.amdocs.com/email_disclaimer.asp
> 
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: "Glen Zorn" <[email-masked]>
Date: Sat, 29 Jan 2011 13:01:23 +0700

Mark Jones [mailto://[email-masked]] <mailto:[mailto://[email-masked]%5d>  writes:

Hi Erez, 

Maybe it's just me, but I'm having a hard time finding a bug here (certainly
not in the same category as the IANA mess): Diameter applications can define
AVPs, so why not the flags for those AVPs, as well?  As for subsequent
versions of Diameter, those future versions (if any) don't need the
permission of 3588bis to change anything at all...

Thanks
Mark

On Fri, Jan 28, 2011 at 1:20 AM, Erez Nassimi <[email-masked]>
wrote:

Guys,

Thank you for the comments. I think everyone agrees there is a bug in RFC.
But this can lead us to 2 different interpretations:
1.  Based on "an unrecognized bit SHOULD be considered an error", we could
assume that "subsequent Diameter applications MAY define additional bits
within the AVP Header", should have read "subsequent Diameter versions".
2.  But the words are very clear and as of now it says "subsequent Diameter
applications".

A different (& more accurate IMHO) example would be the difference between
an int & a float.