IETF71 DIME WG RFC3588bis and Extensibility Status Victor Fajardo (draft-ietf-dime-rfc3588bis-10.txt)

IETF71 DIME WG Short Summary on RFC3588bis Current version: rfc3588bis-10.txthttp:// rfc3588bis-10.txt No major changes since last IETF (09 version) –Only editorial and nits Revision history and tracker is in: Document Status –A few more nits and editorials found –Currently held up by extensibility issues Updating of the diameter extensibility section; ongoing work with the design team Any updates will have corresponding changes to the application design guidelines document (draft-ietf-dime-app- design-guide-06.txt)

IETF71 DIME WG Diameter Extensibility Design Team Status Background –Started with the M-bit issue Existing apps and extensions seem to have a random method of deciding when to set the M-bit Has obvious repercussions on app id allocation Intermediate nodes are required to validate AVPs with M-bit set and therefore be aware of any new extensions –Going down this path, additional questions then arose When do you really need to set the M-bit for extension AVPs (and therefore allocate new app ids) Do we really want to allocate new app ids for every minute changes. Note that changing or adding new values an existing enumerated AVP with the M-bit set would also require a new app id. What does MAY, SHOULD and SHOULD NOT mean for the M-bit What happens if you import an AVP with an M-bit set from another app –Going even further, it became obvious that there are even more extensibility rules missing beyond M-bit Does changing the ABNF settings of an AVPs with {} or <> trigger an app id allocation How much change in a command will trigger an app id allocation What about adding new commands, what is the implication for app id

IETF71 DIME WG Identified List of Issues –Use of application id Use application id as a versioning tool Use the new app id to indicate this specific ‘flavor’ of the original app; the resulting version is a conglomerate of one or more extensions Concern over non-hierarchal (non tree-like) approach when extending applications –Extensions being applied to applications originating from different branches of the tree will end up with different app ids –Can get unwieldy after a while IANA Rules –Are they sufficient if we go down this road –Some rules are not precise enough; i.e. when do you allocate a new application id Suggestion on the use of new versioning scheme –Use a version information to indicate specific iterations of the same application »Use of a version AVP »Split the 32-bit app id into high and low version –Same effect as allocating new app id, therefore does not really provide hierarchal solution –Concerns over adding more routing information –Use of Optional non-’M-bit’ AVPs Implications for proxies: needs deep packet inspection to look for extensions it is interested in –End-to-end capabilities exchange No way to tell if the other end supports the latest version of the app –Current possible method is to somehow convey a set of app ids across a proxy Proxy would be required to announce support for specific set of applications Is there a need for generic mechanisms

IETF71 DIME WG Diameter Extensibility Design Team Status What do we need to do –Fix some of the rules regarding M-bit; i.e. Who validates the M-bit Recommend on when to set the M-bit and clearly state the app id implications Recommend when to use optional AVPs and clearly state proxy implications –Update the extensibility rules in 3588bis to be more complete and coherent when … Extending AVPs and AVP values Extending commands Requiring allocation of new app ids Cascading effects of all of the above that will likely result in the allocation of a new app id –Simplify the app guidelines document To reflect any new changes Concentrate on explaining the rules instead of describing bad practices –Others … fixes corresponding to the list of issues

IETF71 DIME WG Diameter Extensibility Design Team Status What has tentative decision –M-bit is set based on the applications use of the AVP M-bit is set on a per-application basis When you inherit an AVP, the M-bit has to be re-evaluated –AVPs that are ‘required’ in the ABNF has to have the M-bit set This means AVPs with {} and <> –M-bit MAY(?), SHOULD and SHOULD NOT table columns will be removed MAY might have useful features to test a peers capability to process AVPs with M-bit set –Relax intermediate node validation of M-bit Proxies interested in the application MAY perform validation –Changes to a commands ABNF requires a new command code A new command code requires a new application id to be allocated