Subject: [Dime] Another M-Flag Example

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 12 Feb 2008 13:01:12 +0100

Here is another example of M-Flag usage example that violates RFC 3588
extensibility rules:
http://www.ietf.org/rfc/rfc4675.txt
 
                                  +---------------------+
                                  |    AVP Flag rules   |
                                  |----+-----+----+-----|----+
                                  |    |     |SHLD| MUST|    |
   Attribute Name      Value Type |MUST| MAY | NOT|  NOT|Encr|
   -------------------------------|----+-----+----+-----|----|
   Egress-VLANID       OctetString| M  |  P  |    |  V  | Y  |
   Ingress-Filters     Enumerated | M  |  P  |    |  V  | Y  |
   Egress-VLAN-Name    UTF8String | M  |  P  |    |  V  | Y  |
   User-Priority-Table OctetString| M  |  P  |    |  V  | Y  |
   -------------------------------|----+-----+----+-----|----|

According to the Diameter extensibility rules one would have to define a
new Diameter application in the above case 
(since the M-bit is set with these AVPs). Obviously that wasn't done
with RFC 4675. 

I strongly believe that we need to relax the M bit definition. The split
between MUST, MAY, SHOULD NOT and MUST NOT isn't really so useful
either. 

Ciao
Hannes
_______________________________________________
DiME mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/dime

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 12 Feb 2008 09:32:51 -0500

Hi Hannes

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Tschofenig, Hannes (NSN - FI/Espoo)
> Sent: Tuesday, February 12, 2008 7:01 AM
> To: [email-masked]
> Subject: [Dime] Another M-Flag Example
> 
[TOLGA]IMHO, this can't be done without redefining Diameter Base
Protocol routing. Messages should be delivered to the entities, which
know how to process them. Currently Application-Id is the only standard
information for routing purposes. Having said that, I also agree we
should do *something* about this.

---

From: Mark Jones <[email-masked]>
Date: Wed, 13 Feb 2008 12:08:55 -0500

> should do *something* about this.

[MJ] I agree with Tolga. A solution is required but relaxing the 'M' bit definition makes capability exchanges meaningless. The current 'M' bit definition is going to mean a prolification of application ids as new releases of applications will inevitably add mandatory-to-understand AVPs. I don't see a way to address this without revisiting some fundamental definitions in the Base Protocol. However, if we don't tackle this in Dime, I suspect one of the SDOs will extend the capability exchanges anyway. IMO, Application-Version/Release AVPs can't be far away and I'd much prefer them to have common definitions than SDO-specific variants.

Regards
Mark