Subject: RE: Charter questions

From: "Durham, David" <[email-masked]>
Date: Tue, 22 Jan 2002 11:51:49 -0800

David H,
 
I must take offense at one of your comments. I'm one COPS person who has
devoted a great deal of my personal time to help the SNMP community. My
record is Chair of SMIng (wanna guess how much time this requires?), NIM, as
well as contributing at several of the SNMPConf Interims. I've also helped
with the DiffServ MIB among others from time to time. 
 
What more does a guy have to do?
-Dave

-----Original Message-----
From: Kwok Ho Chan [mailto:[email-masked]]
Sent: Monday, January 21, 2002 5:14 PM
To: Harrington, David
Cc: 'Wijnen, Bert (Bert)'; Durham, David; [email-masked]'; 'Randy Bush';
Bernard Aboba; 'David Mitton'
Subject: RE: Charter questions

Dave and all:
Please see comments inline.
I hope to help clarify the situation.
How about put the differences and politics aside and do our best
building a better Internet.  IMHO, use some of the goals and spirit
of what created the IETF many years ago.
-- Kwok Ho Chan --

At 12:20 PM 1/20/02 -0500, Harrington, David wrote:

Hi, 

I was going to just sit on the sidelines on this issue, but one of buttons
has just been pushed. 

I am an SNMP bigot, and I strongly resent that COPS has repeatedly
encroached on the functionality that is the purpose of SNMP, while the IESG
repeatedly prevented the SNMP community from doing anything other than
security, which COPS wasn't required to address. I have felt that COPS has
been trying to sell itself as the solution for everything, and that the WG
has continually expanded into new areas that really required a stretch of
the charter. As part of their sales strategy they have repeatedly attacked
SNMP. Obviously, I am not a great lover of how many members of the RAP WG
have behaved.

I and other members of the RAP Community have tried to complement SNMP/MIB.
For example, the DiffServ MIB was developed with SNMPConf in mind.
The DiffServ MIB can be used at the part of the network where more static
configuration
make sense, and DIffServ PIB can be used where Policy Control is required.
Having the 2 data object definitions evolve closely so we really is giving
the
different implementations a choice depending on technology applicability at
the different
parts of the network.  Notice the similar data object definitions allow for
common
APIs when implementing the MIB and PIB so common coding can be done.
I am not sure how much more corporation is required before we can be viewed
as
a friend and not an enemy.

I still remember that we had the 8+ hour meeting back at the previous
Washington DC
IETF Meeting where we discussed what are some of the values and good
features we
see in COPS/PIB and provided what we think the industry wants in terms of
Policy
Control and how it may be valuable at the edge of the network.
The RAP Community have been very open in terms of the technical design of
COPS/PIB and don't mind if there is technology transfer into the SNMP/MIB
designs.  Working toward a better Internet.

The RAP Community never set out to compete with any other technology.   We
are just
trying to provide solution for the need of Policy Control of Resource
Allocation.
The exact goal of the RAP WG.
We never try to overlap any of the work in RAP with any other WG.
We are just trying to provide solution for Policy Control.

The Usage Feedback Framework PIB is used to indicate how the Policy Control
have affected
the resource used and provide a direct feedback in relation to the Policy.
COPS is used to control valuable resources, a feedback is required in all
control systems
I know of.  And the Report Message Type in COPS has been there from the very
beginning.
COPS is a transactional protocol with deterministic results.   Usage
Feedback Framework PIB
simply supports this feature of COPS to solve real world problem in relation
to Policy
Control Resource Allocation.
I don't see any overlap of Usage Feedback Framework PIB with AAA at the COPS
and PIB level.

However, I find it interesting to have the AAA WG raise issues about COPS
moving into areas that might overlap with the charter of other WGs. I find
it particularly galling to have it suggested that RAP has not worked to
integrate with other WGs, and implicitly indicating that AAA has been so
willing.

I used to attend and contribute to the AAA WG effort until it became
extremely clear that AAA had absolutely no interest (see the footnote) in
developing an architecture that could allow for the integration of AAA and
COPS and SNMP. 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. The AAA WG decided to develop an
architecture that explicitly excluded the possibility of using any other
protocol to provide accounting capability, did little to integrate the data
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.

So while I agree that the RAP WG seems to continually push the limits of the
charter rather than concentrating on their core deliverables, I feel it is
unfair to ignore their efforts to integrate with the work of other WGs,
especially the AAA WG.

dbh 

footnote: The AAA WG actually was a bit more open-minded than this appears.
A significant minority believed that work should be done to integrate with
other protocols, or at least the scope of possible integration should be
studied further. However, they were boxed in by the actions of their area
director, Randy Bush, when he took over the control of a meeting from the
chairs, and forced a vote on a question that was phrased in a highly
prejudicial way, to adopt an approach that precluded such integration.

> -----Original Message----- 
> From: Wijnen, Bert (Bert) [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: Sunday, January 20, 2002 6:56 AM 
> To: Durham, David; [email-masked]' 
> Cc: 'Randy Bush'; Bernard Aboba; 'David Mitton' 
> Subject: RE: Charter questions 
> 
> 
> I have added the two AAA WG chairs. 
> Bernard/David, do you want the type of discussion on the 
> AAA mailing list as I suggest below, or would you rather 
> direct some of the AAA paritipants to the RAP WG mailing 
> list? 
> 
> Dave Durham writes: 
> > Hi Bert, 
> > 
> > I took another look at the access-bind PIB and I disagree with your 
> > assertion. 
> > 
> Pls.. read my posting again. I did not make any assertion yet. 
> I reported what type of questions were/are coming my way. 
> and I do notice that we have an explicit statement in teh charter 
> that tells us to interact with AAA WG about these types of matters. 
> 
> So I was asking: 
> 
>  So what kind of action has the WG taken or WILL the WG take 
>  in order to make sure that we do not overlap or compete 
>  in this space? 
> 
> And so it seems that you do not agree with the allegations that 
> seem implicit in the questions that are getting to me. And so 
> it seems that there is a NEED to interact with the AAA WG to 
> see where both WGs stand and how they understand each others 
> work. 
> 
> So a way to start a discussion with the AAA WG chairs, or     
> on the AAA WG list and use the following text as a way to start 
> discussion as to the matter of overlap/conflict of work. 
> 
> > The whole point of that work is about binding all those 
> > diverse signaling protocols so they may work together AND 
> > the required device resources may be properly allocated in 
> > a coordinated fashion. That certainly seems a good thing to 
> > do and within the charter of a resource allocation protocol. 
> > 
> > I hardly see how a network can work without giving some 
> > semblance as to how these many diverse signaling mechanisms 
> > (RSVP, RSVP-TE, SIP, etc.) can work together given limited 
> > and already partially provisioned network resources. 
> > Their approach in the Access-Bind PIB seems to me to be an 
> > elegant way to deal with this complex problem. 
> > 
> > -Dave 
> > 
> Bert 
>

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 22 Jan 2002 12:01:12 -0800 (PST)

> Both the COPS community and the SNMP communities presented
> 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
> 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. 

> 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.