RE: Charter questions

[Bernard Aboba <aboba@internaut.com>]

> Both the COPS community and the SNMP communities presented
> possible alternatives for accounting, pointed out the importance of trying
> to better integrate the data models of the various protocols, and requested
> that the architecture allow for the use of other protocols to provide
> certain types of functionality. 

I think you're referring to the "solicitation for protocol
submissions". The solicitation was for protocols satisfying all the
requirements, and so the evaluation team made an overall recommendation,
not a separate one for accounting and authentication. 

> The AAA WG decided to develop an
> architecture that explicitly excluded the possibility of using any other
> protocol to provide accounting capability

Not sure what you're referring to. While Diameter does support all
elements of AAA in a single protocol, use of other accounting methods is
not prohibited. Today there are quite a few networks that use RADIUS for
authentication and authorization and SNMP for accounting, and SNMP is
today the most widely used accounting protocol. I don't expect that to
change. 

> models, and does not allow users to determine which protocol or protocols to
> use to gather accounting information. AAA insisted on reinventing the wheel,
> overlapping the work already being done by other WGs.

The accounting requirements for AAA are documented in RFC 2975 and 2989. 
As noted in those documents, no existing protocol satisfied all the
accounting requirements for network access. The particular gap was in the
area of inter-domain, highly reliable and secure accounting. So while it's
fair to say that much of the functionality in Diameter is non-unique,
there are elements that are new. 

> However, they were boxed in by the actions of their area director

In terms of constraints, the biggest one has been the deadlines set by the
3G folks. This has made it difficult for the WG to take on major areas of
functionality that weren't absolutely required to solve the immediate
problem. Data modelling was one of the areas of functionality that was put
off -- though not necessarily eliminated. As has been pointed out on the
mailing list, there is no issue with putting modelled information within a
Diameter AVP. So Diameter can carry XML, ASN.1 or any other flavor that
is needed. Since accounting servers typically only write the data to disk
anyway, presumably the encoding is only relevant to the backend systems
that need to interpret it.