Subject: Charter questions

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Fri, 18 Jan 2002 16:17:00 +0100

Dear RAP WG,

Various people are asking me what the RAP WG is doing and
if it is staying with in its (intended) WG charter.

The questions are of the type of:

- draft-ietf-rap-frameworkpib-06
  the thought of yet another accounting protocol does 
  raise serious questions.

- draft-ietf-rap-access-bind-00.txt, 
  which *is* in fact a whole new AAA protocol,
  under the guise of a COPS extension. 

- it looks to me like COPS is being proposed as a AAA
  protocol for network access -- including 802.11, 
  Dialup, and even Mobile IP, as well as SIP and possibly
  a few other things. That pretty much covers the scope
  of AAA usage. 

As you can imagine, these type of comments come from the 
AAA side of the house.

Now... in the RAP WG charter, I do read:

   For the work on the [FEEDBACKFWRK] and [FEEDBACKPIB],
   the WG will work with other WGs (like AAA WG) to prevent 
   duplication and overlapping solutions. 

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?

Thanks,
Bert Wijnen
(explicitly speaking as AD)

---

From: "Kulkarni, Amol" <[email-masked]>
Date: Fri, 18 Jan 2002 16:01:42 -0800

Bert,

I assume you meant draft-ietf-rap-feedback-fr-pib-01 when you wrote
draft-ietf-rap-frameworkpib-06.

The [FEEDBACKFWRK] and [FEEDBACKPIB] DO NOT define a new accounting
protocol. They are simply a tool for providing feedback on provisioned
policy usage so that future policies may be 'tweaked' for better
performance. As such they fall within the purview of COPS-PR and PIBS; and
just clarify certain points regarding feedback which are ALREADY PRESENT in
COPS-PR.

Also, there is an extra link on the RAP page which points to an old draft.
The latest drafts can be found here:
http://www.ietf.org/internet-drafts/draft-ietf-rap-feedback-frwk-01.txt
http://www.ietf.org/internet-drafts/draft-ietf-rap-feedback-fr-pib-01.txt

Thanks,
Amol

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
Sent: Friday, January 18, 2002 7:17 AM
To: [email-masked]'
Cc: Randy Bush
Subject: Charter questions

Dear RAP WG,

Thanks,
Bert Wijnen

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Sat, 19 Jan 2002 01:17:37 +0100

Appology. I meant draft-ietf-rap-acct-fr-pib-01.txt               
instead of draft-ietf-rap-frameworkpib-06

Cut and paste error. That framework-pib doc was one that
I had in my ciut and paste buffer too.... Guess why?

Bert 

> From: Kulkarni, Amol [mailto:[email-masked]]
> Sent: Saturday, January 19, 2002 1:02 AM
> To: 'Wijnen, Bert (Bert)'; [email-masked]'
> Cc: 'Randy Bush'
> Subject: RE: Charter questions
> 
> 
> 
> Bert,
> 

Thanks,
Amol

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
Sent: Friday, January 18, 2002 7:17 AM
To: [email-masked]'
Cc: Randy Bush
Subject: Charter questions

Dear RAP WG,

Thanks,
Bert Wijnen

---

From: "Durham, David" <[email-masked]>
Date: Sat, 19 Jan 2002 14:13:16 -0800

Hi Bert,

I took another look at the access-bind PIB and I disagree with your
assertion. 

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

> Sent: Friday, January 18, 2002 4:18 PM
> To: Kulkarni, Amol; [email-masked]'
> Cc: 'Randy Bush'

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Sun, 20 Jan 2002 12:56:17 +0100

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?

> I took another look at the access-bind PIB and I disagree with your
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: 

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: Kwok Ho Chan <[email-masked]>
Date: Mon, 21 Jan 2002 20:14:14 -0500

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

---

From: "Weiss, Walter" <[email-masked]>
Date: Wed, 23 Jan 2002 11:38:35 -0500

> Well, it certainly sounds like you believe that you have developed a
> completely RFC 2989 compliant AAA protocol. At the least, I'd 
> suggest that
> this compliance be documented for all the AAA applications that you've
> chosen to support. 
>
As I said, I don't know if we are 2989 compliant and I don't know which AAA
applications are supported. The goal of the effort was to define a mechanism
for binding existing QoS policy semantics to authenticated or
unauthenticated users and to leverage the Feedback work to get per policy
statistics. If the RAP WG or the ADs think it is important to perform a 2989
analysis, we can certainly include it in the next version.

regards,

-Walter

---

From: "Durham, David" <[email-masked]>
Date: Wed, 23 Jan 2002 09:49:22 -0800

Seems the Bind PIB fulfills the requirements and architecture defined in RFC
2753, as it should.
-Dave

> From: Weiss, Walter [mailto:[email-masked]]
>