RE: Charter questions

["Weiss, Walter" <wweiss@Ellacoya.com>]

> > I would have a set of issues that would prevent me from
> > feasibly implementing the proposal. Many stem from the my 
> interpretation
> > that the entire QoS policy is captured in a single 'value'. 
> If anything it
> > reinforces my previous concerns about the approach AAA is taking to
> > addressing these issues: No problem, here's a new AVP.
> 
> Yup, that pretty much summarizes the mind-set ;)
> 
> I'd suggest if you think that the AVP is broken or not very 
> useful even
> for the limited set of scenarios it's trying to address, that
> an issue should be filed on this. 
>
In my opinion, this goes to the heart of the issue. Rather than the COPS and
SNMP folks giving up on AAA, our collective experience has been that AAA
folks have chosen not to work with the COPS and SNMP folks. The IntServ, RAP
and DiffServ Groups have collectively spent at least 5 years to figure out
how to support and manage QoS. Similarly, MPLS, PPP, and L2TP have spent
years developing tunneling semantics. These folks have become the subject
matter experts and the IETF has always taken the approach that the subject
matter experts are the best folks to define the appropriate management
semantics for the technology.

Your comment and the fundamental standards philosophy in AAA inverts this
tenant by asking all these subject matter experts to come to the AAA WG.
Personally, I don't have a problem with this model per se, although it does
create some scaling issues. However, this is not the way we do things today.
Further, there is plenty of evidence to suggest that many folks have made
substantial efforts to help the AAA group meet its objectives within the
larger IETF model for developing management standards. And this is the
fundamental difference between the Access Bind work and the AAA work.
 
> > NOPE. EAP requires an extra pair of messages for challenge 
> negotiation.
> 
> But COPS now does support EAP authentication as well, correct? 
> 
The protocol uses CMS and TLS for authentication. The PIB was specified to
support EAP. However, in the 00 version, provided generic EAP encapsulation
request and response objects.
 
> > Network Access is implicit. In fact, there are models that 
> are discussed in
> > the draft that allow limited Network Access policies 
> (specifically to HTTP
> > based authentication servers) prior to full Network Access 
> and user specific
> > policy assignments.
> 
> How many of the other RFC 2989 requirements does the COPS/AAA 
> functionality satisfy? Souds like you've essentially got functionality
> equivalent to Diameter NASREQ, and Accounting. Can it do Mobile IP
> too? Protection of AVPs end-to-end a la CMS-Sec? 
> 
To be honest, I stopped tracking DIAMETER issues at 150, and we never went
back to see how well the various requirements are supported by this work. I
suppose someone may be interested in investigating it though. As to the
security question, the COPS protocol supports both CMS and TLS, which
provides protection both at the protocol and the object levels.