Glen proclaimed... > -----Original Message----- > > 3. Added a version label prefix to rule syntax. Each rule now > > includes a "v1" prefix designating the rule as conforming to version > > 1 of traffic-rule syntax. The idea here is to allow future > > updates/changes to the rule syntax without having to define another > > attribute and burn another type number. > > I was under the impression that we had decided to use the new extended > attribute format for this, thus obviating the concern about 'burning > another type number'. [MS1] Well, even if consuming type is no longer an issue, wouldn't you agree that it would be cleaner to modify the same attribute than defining an entirely new attribute every time a rule syntax update was necessary? > > 4. Re-did the Diameter Considerations section [5]. Now are using the > > same approach employed by rfc4675 (RADIUS attributes for virtual LAN > > and priority support). The approach eliminates the need to re-create > > a diameter-specific version of nas-traffic-rule and rather relies on > > the general radius<->diameter interoperability mechanisms. I do have > > a question as to whether the diameter value type specified > > (OctetString) is the right one or not. I'm no diameter value type > > expert, so feedback welcome. > > A far better idea would be to get rid of the OS-specific Diameter stuff > & define an extensible grouped AVP for filters. [MS1] Can you described the pain point(s) you're experiencing with Diameter's current syntax approach? I guess I question whether Diameter's chosen approach is truly broken enough to merit a complete re-write. Cheers, MS
Attachment:
smime.p7s
Description: S/MIME cryptographic signature