Re: Charter questions

["Mark L. Stevens" <mlstevens@rcn.com>]

I do not see the encroachment David Harrington perceives. Instead, I see
the RAP working group filling an unaddressed need.  Historically, many
people thought that COPS was a replacement to SNMP and with good reason.
There were shortcomings,  but that is not the real issue.  The
combination of SNMP and CLI are reasonable for static configuration
management. The emphasis is on stability, but the IETF and the
networking industry has steadily moved toward a network model consisting
of a static core and a dynamic edge. We want the core of the network to
be ultimately stable. The easiest way to accomplish stability is to
configure the devices in the core and then leave them alone and many
existing methods are sufficient to the task. At the same time we have
the desire to provide and manage additional network services. A static
network provides little opportunity of offer dynamic network services.
So, edge devices are targeted as the prime location for introducing
dynamism. The risk of any resulting instability affects fewer users when
services are delivered and provisioned at edge devices.  The definition
of services remains somewhat static, but the usage of services is
dynamic. There is nothing to keep us from using one set of tools to
define services and another to manage and operate those services. COPS
and the Access Bind framework addresses the problem of managing services
a dynamic edge device.

The Access Bind framework will enable applications to relate services to
user or subscribers in real-time and without direct service provider
involvement.  The last thing you want to do when you begin offering
special network services is to have to manually reconfigure your network
devices. You want your subscribers and applications to accomplish this
task. Services won't pay if the service provider or carrier has to get
directly involved in the changes adds and deletes. Other existing
approaches do not readily provide mechanisms to do so. Remember, the
premise is to integrate QoS semantics and other service level behaviors
at the edge in real-time and by service-level behavior I include RSVP
and Diffserv as service-level behaviors.

We tried to integrate COPS and SNMP and the AAA work using a common data
model expressing users, policies, etc. A common data model may have
obviated the need to take this approach, but the common data model
approach did not progress to the point necessary to accomplish this goal
and using COPS is the next best alternative.

As David Harrington points out the most vocal AAA people argued that
they were only making the RADIUS attribute space larger and not
addressing the authorization problem space or service-level network
behaviors. The result was to extend the RADIUS attribute space with a
focus on identifying the session rather than dealing with the
provisioning of services in real time. Considering the complexity of
correlating service level behaviors with subscribers within edge
devices, the trivial piece is defining the session.  What  is needed is
service management.  Extending COPS to provide for authorization is a
trivial extension and uses existing protocols.

As for pushing the limits of the charter, the RAP working group went
through the process of re-chartering the working group last summer and
the working group continues to work within its charter.


"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.
>
> 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:bwijnen@lucent.com]
> > Sent: Sunday, January 20, 2002 6:56 AM
> > To: Durham, David; 'rap@ops.ietf.org'
> > 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
> >