Re: [Dime] Diameter Group: Type?

[Sebastien Decugis <[e-mail]>]

> 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)