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

From: Mark Jones <[email-masked]>
Date: Mon, 7 Feb 2011 14:50:43 -0500

On Sat, Jan 29, 2011 at 1:01 AM, Glen Zorn <[email-masked]> wrote:
> Mark Jones [mailto://[email-masked]] 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

---

From: "David Lehmann" <[email-masked]>
Date: Mon, 7 Feb 2011 16:52:30 -0500

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: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Mark Jones
> Sent: Monday, February 07, 2011 2:51 PM
> To: [email-masked]
> Subject: Re: [Dime] Diameter Group: Type?
> 
> > 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
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: Sebastien Decugis <[email-masked]>
Date: Tue, 08 Feb 2011 11:00:35 +0900

> What do others think?
Hi,

I would go in favor of "be tolerant in what you accept and restrictive
in what you send" in the base Protocol.
Then, the way new flags are actually defined / used can be either left
for future extensions of the base protocol (although I am not in favor
of the Grouped flag) or left for applications to define their own needs
(meaning that only AVP with the 'V' flag would be tolerated to have
another flag, which is quite strange to me).
In any case, it seems a bad idea to mix the two approachs for flags
definitions (future Base extensions + applications) because it may lead
to conflicts.

I agree that applications will probably not use the AVP flags field,
when it is so easy to add a different AVP with the information one wants
to convey -- but there might be use cases that I am missing here, if
someone can explain where it can be useful, it would be helpful.

If no application / vendor has ever defined use for another AVP flag,
I'd be in favor of changing the text in rfc3588bis to align with the
general IETF policy (which makes more sense for future evolution).
Otherwise, I guess this change can only be applied when the version
number of Diameter will be increased to 2, meaning a future revision
somewhere after rfc3588bis.

As a point of data, in the freeDiameter implementation the unknown flags
in AVPs are not rejected, although the format of the dictionary
definitions allows to change this easily if needed.

Best regards,
Sebastien.

-- 
Sebastien Decugis
Research fellow
Network Architecture Group
NICT (nict.go.jp)