Re: [Dime] Diameter Group: Type?

IMHO,  applications should not be allowed to define new flags.
Applications send all of their data via the "data" part of the AVPs.
E.g. If an application needs a flag, it can define a unsigned32, which
will provide 32 flags.

The reserved flags should be reserved for diameter protocol expansion.
E.g. The Grouped bit.

Note my previous email on 1/25/2011, which explains why reserved flags
should be ignored by the receiving application.

--
David Lehmann
Ulticom, Inc.
856-787-2952

> -----Original Message-----
> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf
Of
> Mark Jones
> Sent: Monday, February 07, 2011 2:51 PM
> To: dime@ietf.org
> Subject: Re: [Dime] Diameter Group: Type?
> 
> On Sat, Jan 29, 2011 at 1:01 AM, Glen Zorn <gwz@net-zen.net> wrote:
> > Mark Jones [mailto://mark@azu.ca] writes:
> > Hi Erez,
> >
> > Will you be raising an issue on 3588bis so the authors can fix this
bug?
> >
> > 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?
> 
> So does anyone know why this "feature" is permitted for unused AVP
> flags but not for command flags?
> 
> Maybe it's just me (and the time I've spent explaining the M-bit
> usage) but I really don't see a compelling need for the added
> complexity of per-application AVP flags.  However, it is already in
> RFC3588 and I assume we need a better reason than my foreboding to
> remove it from 3588bis.
> 
> What do others think? Have any vendors/SDOs dared to use it yet?
> 
> Regards
> Mark
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime