[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Charter questions
- To: "'Kwok Ho Chan'" <khchan@NortelNetworks.com>, "Harrington, David" <dbh@enterasys.com>
- Subject: RE: Charter questions
- From: "Durham, David" <david.durham@intel.com>
- Date: Tue, 22 Jan 2002 11:51:49 -0800
- Cc: "'Wijnen, Bert (Bert)'" <bwijnen@lucent.com>, "Durham, David"<david.durham@intel.com>, "'rap@ops.ietf.org'" <rap@ops.ietf.org>, "'Randy Bush'" <randy@psg.com>, Bernard Aboba <aboba@internaut.com>, "'David Mitton'" <david@mitton.com>
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
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: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
>