RE: QDIM issue: the SchedulingService classes

Bob,
>
> Here's the fundamental issue we need to = resolve:
>
> -- Bob:
> >> An instance of any of the scheduling = service classes
> >> represents a scheduler, which is a = component that
> >> services a set of queues according to = the parameters
> >> of some scheduling algorithm.

This is where the real problem is. All the parameters = for the scheduler apply to specific individual instances of particular = queues. However, they are parameters of the scheduler, not the queue, = and not the binding of the queue and scheduler.

> >> A priority scheduler
> >> services queues based on static = priority values
> >> associated with each queue.
> >
> --Walter:
> >This is a slightly inaccurate description. = Each Scheduling Service
> instance represents >the scheduling = parameters associated
> with a single
> queue. The bandwidth scheduler >determines = that a single
> queue is entitled
> to. This is why the cardinality for = >SchedulerUsed is 0..1.
>
> Let's drop the names for a minute, and just = look at
> a picture:
>
>
> Q1 --- A1 ---+     = B1
>          = ;    |   +----+
>          = ;    +-->|    |
> Q2 --- A2 ------>|    = |----> outbound link
>          = ;    +-->|    |
>          = ;    |   +----+
> Q3 --- A3 ---+
>
> This figure shows three queues, some A's that = are
> one-to-one with the queues, and a B that = takes
> the packets from the three queues and places = them
> on the outbound link. If this is = priority
> queuing, then the priorities must be in the = A's:
> the one B doesn't have the right = cardinality,
> and you've already argued (correctly, I = think)
> that the priorities don't belong on the = queues
> themselves.
>
> If *appears*, then, that our disagreement = is
> really one of semantics / terminology:
>
> Bob:
>   A =3D SchedulerUsed association
>   B =3D = PacketSchedulingService
>
> Walter:
>   A =3D = PacketSchedulingService
>   B =3D (not explicitly = modeled)
>
In your proposal, is it possible to model a = multi-queue environment where some of the queues use one scheduling = discipline and other queues use a completely different one? If you have = only a single PacketSchedulingService, but you have moved all the = parameters to the association, what is the Service modeling. What are = the local properties? How do you propose to distinguish priority = bandwidth scheduling from bandwidth priority scheduling? How do you = propose to address excess capacity scheduling for bandwidth schedulers = when the excess capacity could be allocated either using priorities, = packet ratios or bandwidth ratios? This particular issue was solved = rather elegantly with the old model.

> The most "correct" model (I think) is = that the=20 scheduler has multiple inputs:=20

&nbs= p;

Modeled as an association to the Scheduler = from all the=20 classes that could be = inputs.

> each input has a set = of=20 parameters associated with it that describe
> how=20 the scheduler will handle traffic arriving on = that=20 input.

Modeled as properties on = the=20 association.

> This has = nothing whatsoever to do with the elements that are upstream from the=20
> scheduler - they could be=20 queues, they could be whatever you choose.=20

> So, the model ought to=20 allow for a multi-input scheduler with = multiple sets=20

> of=20 parameters.

&nbs= p;

This argues to generalize the SchedulerUsed = association=20 and move it up to ConditioningService in QDIM. In this way, = any of=20 the ConditioningServices (meters, markers, queues, etc.) could be an = input to a=20 scheduler.

> Unfortunately, = with the SMI=20 syntax available to us, there was no way = to=20
> represent this cleanly in the MIB: the indexing = does not=20 work well. So we chose
> to=20 move any "per-input" scheduler parameters back = (upstream) to a "queue=20 table".

&nbs= p;

If you have to use the word, "unfortunately", = this=20 means that you are compromising the semantics to fit the syntax. = This is=20 ok - but makes the info model more valuable since it describes the = semantics=20 correctly. Also, another data model that supports a different = syntax is not compromised by the syntax constraints of the = first data=20 model. Note that I am not saying that the MIB is wrong - it is = just=20 a syntax specific rendering of what we have tried to capture in=20 the info model. What matters is that the mapping is = reasonable=20 and valid - not that an association MUST map to an = association. Info=20 models are about achieving consistent and correct=20 semantics.

> To quote=20 diffserv-mib-04:
> "The Scheduler = Table=20 represented in this MIB module contains entries,
>=20 each of which represents the algorithm in use for servicing the one = or=20
> more queues that feed it.=20

In QDIM, this is the = SchedulerUsed=20 association. =

&nbs= p;

> The [MODEL] section 7.1.2 = describes=20 a scheduler
> with multiple inputs: = this is=20 represented in the MIB by including
> the=20 scheduling parameters associated with a scheduler input=20 in
> the Queue Table entry that feeds it = and having=20 that point at = one

> particular = Scheduler=20 Table = entry.

In QDIM, "scheduling = parameters"=20 are modeled as properties on the association between a=20 SchedulingService and a QueuingService (SchedulerUsed). The words, = "the=20 scheduling parameters associated with a scheduler INPUT" imply = that=20 these parameters are NOT specific to the Queue or the Scheduler but = the=20 relationship between the two.=20

> In this=20 way, sets of = Queues can=20 be grouped together as inputs to the same=20

>=20 Scheduler. This=20 table serves to represent the=20 example scheduler described in the=20

> [MODEL]: other = more complex representations might be created outside=20

> of this MIB."=20

&nbs= p;

In=20 QDIM, an instance of the SchedulerUsed association ties a specific = Queue to=20 a specific Scheduler. All the associations to an instance of = the=20 SchedulingService class describe the "set of Queues ... grouped = together as=20 inputs to the same=20 Scheduler."

&nbs= p;

>
> I don't=20 see a big problem with this. The QDIM might also have
> to make similar concessions in = clarity to=20 work with whatever =

> syntax limitations you have there.=20

&nbs= p;

I actually don't think that we have to make = any=20 concessions, related to modeling this, in=20 QDIM.

HTH,

Andrea

-----Original = Message-----
From:=20 policy-owner@raleigh.ibm.com [mailto:policy-owner@raleigh.ibm.com]On = Behalf=20 Of Weiss, Walter
Sent: Monday, August 21, 2000 12:49=20 PM
To: 'Andrew Smith'
Cc: 'remoore@us.ibm.com';=20 policy@raleigh.ibm.com
Subject: RE: QDIM issue: the = SchedulingService=20 classes

Andrew,

I think I heard you agreeing with both Bob and I. I = think you=20 agree with Bob that there is only one scheduler. I think you also agree = with me=20 that scheduling parameters are part of the scheduler and not the queue. = The=20 question here is what does the scheduler do and how should it be = represented. In=20 my mind the scheduler contains a set of table entries one per input. = These=20 entries determine how that input is drained relative to the other inputs = and=20 external constraints such as bandwidth over time=20 (non-work-conserving).

The easiest way I can think of to represent this is as = some=20 variant of a table of union structs. It is a union because it is = possible to=20 have very dissimilar scheduling rules (priority and bandwidth) within = the same=20 scheduler. Combining all possible properties for all possible schedulers = makes=20 interoperable interpretation of the table next to impossible. Further, = it makes=20 it difficult to expand as new algorithms are defined.

<snip>

------=_NextPart_000_00A1_01C00BB8.2CEFB990-- From majordomo@raleigh.ibm.com Tue Aug 22 07:07:17 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00728 for ; Tue, 22 Aug 2000 07:07:17 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id HAA26034; Tue, 22 Aug 2000 07:06:02 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id HAA34918; Tue, 22 Aug 2000 07:06:02 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA30808; Tue, 22 Aug 2000 06:39:01 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA41552; Tue, 22 Aug 2000 06:38:57 -0400 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id GAA04108 for ; Tue, 22 Aug 2000 06:38:58 -0400 Received: from mumm.ibr.cs.tu-bs.de (root@mumm.ibr.cs.tu-bs.de [134.169.34.190]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id GAA28588 for ; Tue, 22 Aug 2000 06:38:55 -0400 Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id MAA25356; Tue, 22 Aug 2000 12:38:54 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id MAA17514; Tue, 22 Aug 2000 12:38:53 +0200 Date: Tue, 22 Aug 2000 12:38:53 +0200 Message-Id: <200008221038.MAA17514@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: andreaw@cisco.com, Keith McCloghrie Cc: policy@raleigh.ibm.com In-Reply-To: Subject: Re: Policy Terminology Draft References: Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Juergen Schoenwaelder >>>>> Andrea Westerinen writes: Andrea> The Policy Framework WG has created an I-D to try to Andrea> disambiguate policy terminology across all IETF Work Groups. [...] Andrea> Please look the draft over, and if you have feedback, please Andrea> reply to me and/or to the policy mail list Andrea> (policy@raleigh.ibm.com). I have read and I believe that this document is very valuable. I also have some comments you may want to consider when you revise this text. 1. The definition of "Authentication, Authorization, Accounting" has lots of text on the current process within the AAA and related WGs. For example, the last sentence is IMHO completely irrelevant in the longer term (which does of course not mean that the work being done is irrelevant). I suggest to rewrite at least the last two sentences in this definition (perhaps removing most of it). 2. In the definition of CIM, you wrote: "CIM includes a set of files, written in the language specified in the Specification. These are known as the Core and Common Models, and define an information model for the "enterprise" ..." I think this puts too much importance on the concept of storing CIM models in a (MOF) file, which is just one way to represent a CIM model. Many people are much more familiar with the graphical UML-style representation of CIM models, I think. And this is not even explicitly mentioned in the CIM definition. 3. You define IPSP, which is an IETF working group. You do not define other working groups. I think that not defining working groups in this document is a good thing since WGs come and go (even though some WGs seem to never really go away ;-). 4. The definition of MPLS as a "label swapping framework" surprised me - but this indeed what RFC 2702 says. Anyway, I believe that "label switching framework" or perhaps "label swapping and switching framework" is less confusing - at least for me. 5. I have some more important problems with the definition of a Policy Rule Class. The current text says: $ Policy Rule Class (PRC) (M) An ordered set of scalar attributes, defined in a PIB. "Policy Rule Classes" are arranged in a hierarchical structure similar to tables in SNMP's SMIv2. [R2578, PIB] I suggest to use the following text: $ Policy Rule Class (PRC) (M) An ordered set of attributes. PRCs are defined in PIB modules and registered in the Object Identifier tree. PRIs which are instances of the same PRC are organized in a table, similar to conceptual tables in the SMIv2. [R2578, SPPI] Note that reference [PIB] does not exist anymore. I also found "scalar attribute" confusing for people who are familiar with SMIv2 scalars. You probably wanted to highlight the fact that PRC attributes are primitive and not compound - but I think you need to be more precise if this details is really essential. I also think the acronym PRI should be defined in this document, e.g. $ Policy Rule Instance (PRI) (M) is an instantiation of a PRC. $ PRI See "Policy Rule Instance" 6. Now to my fundamental PRC/PRI terminology concern: The usage of "policy rule" in the terms PRC and PRI conflicts with the definition of the term "policy rule". A PRC does not bind actions to a set of conditions. This is IMHO a very fundamental terminology problem we have. In my view of the world, PRCs and PRIs just convey (network-wide) configuration information to a device. So a better explanation of these acronyms (if we want to keep them) would probably be "Provisioning Class (PRC)" and "Provisioning Class Instance (PRI)". One could also argue that different terms should be used here. I do not expect that there is agreement here on changing the interpretation of PRC and PRI or to introduce new terms to replace them. But I think it is important to highlight that there is at least a problem here. 7. The example for "policy translation" is about the conversion of a PIB into a CLI format. I think we had several discussions about translations and mappings before. What you describe here is probably what some of us would call a mapping and not a translation. It is also unclear to me whether policy conversion is the same as policy translation and/or policy mapping. Perhaps policy conversion is the superset of policy translation and policy mapping, where policy translations happen between abstraction levels and policy mappings happen between different representations at the same abstraction level? 8. There are some funny characters in the definition of "service". /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From majordomo@raleigh.ibm.com Tue Aug 22 13:49:53 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11850 for ; Tue, 22 Aug 2000 13:49:53 -0400 (EDT) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id NAA20664; Tue, 22 Aug 2000 13:48:19 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id NAA33280; Tue, 22 Aug 2000 13:48:19 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA44778; Tue, 22 Aug 2000 13:15:46 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA52192; Tue, 22 Aug 2000 13:15:43 -0400 Received: from corp.tivoli.com (corp.tivoli.com [146.84.104.1]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id NAA18912 for ; Tue, 22 Aug 2000 13:15:44 -0400 From: Ed_Ellesson@tivoli.com Received: from tivmta4.tivoli.com (tivmta4.tivoli.com [146.84.104.47]) by corp.tivoli.com (8.9.3/8.9.0) with SMTP id MAA26263; Tue, 22 Aug 2000 12:15:12 -0500 (CDT) Received: by tivmta4.tivoli.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 86256943.005EC8F0 ; Tue, 22 Aug 2000 12:15:18 -0500 X-Lotus-Fromdomain: TIVOLI SYSTEMS To: policy@raleigh.ibm.com Cc: ah_smith@pacbell.net Message-Id: <86256943.005EC8A7.00@tivmta4.tivoli.com> Date: Tue, 22 Aug 2000 13:16:08 -0400 Subject: Re: QDIM issue: the SchedulingService classes Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Ed_Ellesson@tivoli.com I am re-posting this to the list, because it bounced on the first try.(Ed E.) Date: Mon, 21 Aug 2000 15:12:00 -0700 From: Andrew Smith Subject: Re: QDIM issue: the SchedulingService classes To: remoore@us.ibm.com Cc: "Weiss, Walter" , policy@raleigh.ibm.com Message-Id: <39A1A930.E41345E6@pacbell.net> Mime-Version: 1.0 X-Mailer: Mozilla 4.6 [en] (WinNT; I) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Accept-Language: en References: <85256942.006E5082.00@d54mta02.raleigh.ibm.com> Bob, I think I agree 99% with what Walter just wrote in his message of Mon, 21 Aug 2000 15:48:33 -0400. Everything except that where he wrote "My thinking is that a scheduler contains a table ... that ... is indexed by the queue number." he should have written "My thinking is that a scheduler contains a table ... that ... is indexed by the *input* number.". It is up to the external plumbing mechanisms to make the association between any upstream element (e.g. a queue) and the scheduler input number. See further comment below. remoore@us.ibm.com wrote: > This is confusing. You start out stating that Walter > is correct, but then you go on to demonstrate that > he's not. Walter is saying that schedulers and their > upstream elements are one-to-one. I don't see where you get this from - he's saying that, for each scheduler instance, there is a table inside it that is indexed by some "input identifier". That's not the same as saying that schedulers and their upstream elements are one-to-one. The rest of your disagreements with Walter stem from this so I'll leave those for now. Andrew From majordomo@raleigh.ibm.com Tue Aug 22 13:54:25 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11849 for ; Tue, 22 Aug 2000 13:49:53 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id NAA07334; Tue, 22 Aug 2000 13:48:17 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id NAA21040; Tue, 22 Aug 2000 13:48:14 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA43772; Tue, 22 Aug 2000 13:25:48 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA46836; Tue, 22 Aug 2000 13:25:45 -0400 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id NAA34374 for ; Tue, 22 Aug 2000 13:25:46 -0400 Received: from bor.ellacoya-nt (216-064-109-139.inaddr.vitts.com [216.64.109.139]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id NAA31960 for ; Tue, 22 Aug 2000 13:25:43 -0400 Received: by bor.ellacoya-nt with Internet Mail Service (5.5.2650.21) id ; Tue, 22 Aug 2000 13:23:28 -0400 Message-Id: From: "Weiss, Walter" To: "'John Schnizlein'" Cc: policy@raleigh.ibm.com Subject: RE: QDIM issue: the SchedulingService classes Date: Tue, 22 Aug 2000 13:23:27 -0400 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C00C5D.AF517C3E" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Weiss, Walter" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C00C5D.AF517C3E Content-Type: text/plain; charset="iso-8859-1" John, Consider a bandwidth scheduler that determines what packet is sent based on bandwidth allocations associated with queues. Some of the algorithms include CBQ and WFQ come to mind, although there are many others. The idea is to maintain fair distributions between queues. However, there may be instances in these schedulers where their is a tie in which queue should get serviced. In most cases the order of the queue decides. This is an implicit ordering. A priority provides an explicit order. Consider in contrast a simple priority scheduler. In this scenario, the highest priority queue is drained before the next priority queue may have access to the link. While this is a very desirable behavior for a PHB like EF, there is a subtle problem of starvation of the other queues. To prevent starvation, a rate limiter is introduced into the scheduler to prevent one or more queues from stealing all the bandwidth. On the link, the two systems exhibit very different behaviors. The most notable distinction is that the highest priority queue has the lowest jitter provided that the traffic does not exceed the limit, whereas in the first algorithm, the contents of all queues always affects all the queue's delay variation. Hope that helps. regards, -Walter > -----Original Message----- > From: John Schnizlein [mailto:jschnizl@cisco.com] > Sent: Monday, August 21, 2000 9:29 PM > To: Weiss, Walter > Cc: policy@raleigh.ibm.com > Subject: RE: QDIM issue: the SchedulingService classes > > > At 01:40 PM 08/21/2000 -0400, Weiss, Walter wrote: > > > > ... How do you propose to distinguish priority bandwidth > scheduling from > > bandwidth priority scheduling? > > > Could you please specify the distinction you mean here? > > ------_=_NextPart_001_01C00C5D.AF517C3E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: QDIM issue: the SchedulingService classes

John,

Consider a bandwidth scheduler that determines what = packet is sent based on bandwidth allocations associated with queues. = Some of the algorithms include CBQ and WFQ come to mind, although there = are many others. The idea is to maintain fair distributions between = queues. However, there may be instances in these schedulers where their = is a tie in which queue should get serviced. In most cases the order of = the queue decides. This is an implicit ordering. A priority provides an = explicit order.

Consider in contrast a simple priority scheduler. In = this scenario, the highest priority queue is drained before the next = priority queue may have access to the link. While this is a very = desirable behavior for a PHB like EF, there is a subtle problem of = starvation of the other queues. To prevent starvation, a rate limiter = is introduced into the scheduler to prevent one or more queues from = stealing all the bandwidth.

On the link, the two systems exhibit very different = behaviors. The most notable distinction is that the highest priority = queue has the lowest jitter provided that the traffic does not exceed = the limit, whereas in the first algorithm, the contents of all queues = always affects all the queue's delay variation. Hope that = helps.

regards,

-Walter

> -----Original Message-----
> From: John Schnizlein [mailto:jschnizl@cisco.com]=
> Sent: Monday, August 21, 2000 9:29 PM
> To: Weiss, Walter
> Cc: policy@raleigh.ibm.com
> Subject: RE: QDIM issue: the SchedulingService = classes
>
>
> At 01:40 PM 08/21/2000 -0400, Weiss, Walter = wrote:
> >
> > ... How do you propose to distinguish = priority bandwidth
> scheduling from
> > bandwidth priority scheduling?
>
>
> Could you please specify the distinction you = mean here?
>
>

------_=_NextPart_001_01C00C5D.AF517C3E-- From majordomo@raleigh.ibm.com Tue Aug 22 14:01:32 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12165 for ; Tue, 22 Aug 2000 14:01:32 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id NAA24466; Tue, 22 Aug 2000 13:58:54 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id NAA27952; Tue, 22 Aug 2000 13:58:54 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AB41184; Tue, 22 Aug 2000 13:31:00 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA40134; Tue, 22 Aug 2000 13:30:56 -0400 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id NAA30422 for ; Tue, 22 Aug 2000 13:30:58 -0400 Received: from bor.ellacoya-nt (216-064-109-139.inaddr.vitts.com [216.64.109.139]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id NAA37446 for ; Tue, 22 Aug 2000 13:30:53 -0400 Received: by bor.ellacoya-nt with Internet Mail Service (5.5.2650.21) id ; Tue, 22 Aug 2000 13:28:43 -0400 Message-Id: From: "Weiss, Walter" To: "'Andrea Westerinen'" , "'Andrew Smith'" Cc: remoore@us.ibm.com, policy@raleigh.ibm.com Subject: RE: QDIM issue: the SchedulingService classes Date: Tue, 22 Aug 2000 13:28:42 -0400 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C00C5E.6ACFE9E6" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Weiss, Walter" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C00C5E.6ACFE9E6 Content-Type: text/plain; charset="iso-8859-1" Andrea, -----Original Message----- From: Andrea Westerinen [mailto:andreaw@cisco.com] Sent: Tuesday, August 22, 2000 12:39 AM To: Weiss, Walter; 'Andrew Smith' Cc: remoore@us.ibm.com; policy@raleigh.ibm.com Subject: RE: QDIM issue: the SchedulingService classes Please note that modeling using a table is not "good" OO practice. Tables exist either because you have multiple instances of something (best done as a class with instances) or because you want to relate the rows and columns and put some data at the right spot in the table. The latter is really an implementation dependent way of modeling an association. There are always two perspectives to a "relate the rows and columns" table - in this case, the rows and columns represent queues and schedulers. The data at the intersection of the row and column is specific to BOTH the queue and the scheduler - so, it is best modeled as an association. Most everything in a router is implemented in tables. Filters, Meters, Markers, Routing entries, MAC addresses, VLANs, VCs, and Security Associations are just a few of the structures that come to mind that are typically in tables. All of these meet your criteria of being indexed in two directions. Are you saying that all of these need to be represented in associations? regards, -Walter ------_=_NextPart_001_01C00C5E.6ACFE9E6 Content-Type: text/html; charset="iso-8859-1" RE: QDIM issue: the SchedulingService classes

Andrea,

-----Original Message-----
From: Andrea Westerinen [mailto:andreaw@cisco.com]
Sent: Tuesday, August 22, 2000 12:39 AM
To: Weiss, Walter; 'Andrew Smith'
Cc: remoore@us.ibm.com; policy@raleigh.ibm.com
Subject: RE: QDIM issue: the SchedulingService classes

Please note that modeling using a table is not "good" OO practice. Tables exist either because you have multiple instances of something (best done as a class with instances) or because you want to relate the rows and columns and put some data at the right spot in the table. The latter is really an implementation dependent way of modeling an association. There are always two perspectives to a "relate the rows and columns" table - in this case, the rows and columns represent queues and schedulers. The data at the intersection of the row and column is specific to BOTH the queue and the scheduler - so, it is best modeled as an association.

<Walter> Most everything in a router is implemented in tables. Filters, Meters, Markers, Routing entries, MAC addresses, VLANs, VCs, and Security Associations are just a few of the structures that come to mind that are typically in tables. All of these meet your criteria of being indexed in two directions. Are you saying that all of these need to be represented in associations?

regards,

-Walter

------_=_NextPart_001_01C00C5E.6ACFE9E6-- From majordomo@raleigh.ibm.com Tue Aug 22 14:21:42 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12439 for ; Tue, 22 Aug 2000 14:21:40 -0400 (EDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA34902; Tue, 22 Aug 2000 14:20:22 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id OAA35336; Tue, 22 Aug 2000 14:20:22 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA47002; Tue, 22 Aug 2000 13:45:33 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA46968; Tue, 22 Aug 2000 13:45:28 -0400 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id NAA32690 for ; Tue, 22 Aug 2000 13:45:30 -0400 Received: from sigma.cisco.com (sigma.cisco.com [171.69.63.142]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id NAA06622 for ; Tue, 22 Aug 2000 13:45:27 -0400 Received: from andreawlap (atlantis-dial-1-121.cisco.com [171.68.181.122]) by sigma.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id KAA24201; Tue, 22 Aug 2000 10:43:04 -0700 (PDT) From: "Andrea Westerinen" To: "Weiss, Walter" , "'Andrew Smith'" Cc: , Subject: RE: QDIM issue: the SchedulingService classes Date: Tue, 22 Aug 2000 10:46:26 -0700 Message-Id: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001C_01C00C26.38DBE6C0" X-Priority: 3 (Normal) X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Andrea Westerinen" This is a multi-part message in MIME format. ------=_NextPart_000_001C_01C00C26.38DBE6C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit RE: QDIM issue: the SchedulingService classesI do not understand your statement that a table of Filters or MAC addresses is indexed in two directions. A Filter or MAC address is an instance of a class in an info model. Where there are relationships (for example, grouping a bunch of filter entries into a filter list, or tieing a filter list to a Classifier) - these should be represented in the info model as associations. How any of these concepts are implemented is up to the data model. In the data model, you make the determination whether you use associations, tables, arrays or something else. Andrea -----Original Message----- From: Weiss, Walter [mailto:wweiss@ellacoya.com] Sent: Tuesday, August 22, 2000 10:29 AM To: 'Andrea Westerinen'; 'Andrew Smith' Cc: remoore@us.ibm.com; policy@raleigh.ibm.com Subject: RE: QDIM issue: the SchedulingService classes Andrea, -----Original Message----- From: Andrea Westerinen [mailto:andreaw@cisco.com] Sent: Tuesday, August 22, 2000 12:39 AM To: Weiss, Walter; 'Andrew Smith' Cc: remoore@us.ibm.com; policy@raleigh.ibm.com Subject: RE: QDIM issue: the SchedulingService classes Please note that modeling using a table is not "good" OO practice. Tables exist either because you have multiple instances of something (best done as a class with instances) or because you want to relate the rows and columns and put some data at the right spot in the table. The latter is really an implementation dependent way of modeling an association. There are always two perspectives to a "relate the rows and columns" table - in this case, the rows and columns represent queues and schedulers. The data at the intersection of the row and column is specific to BOTH the queue and the scheduler - so, it is best modeled as an association. Most everything in a router is implemented in tables. Filters, Meters, Markers, Routing entries, MAC addresses, VLANs, VCs, and Security Associations are just a few of the structures that come to mind that are typically in tables. All of these meet your criteria of being indexed in two directions. Are you saying that all of these need to be represented in associations? regards, -Walter ------=_NextPart_000_001C_01C00C26.38DBE6C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: QDIM issue: the SchedulingService classes

I do=20 not understand your statement that a table of Filters or MAC addresses = is=20 indexed in two directions. A Filter or MAC address is=20 an instance of a class in an info model. Where there are = relationships (for example, grouping a bunch of filter = entries into a=20 filter list, or tieing a filter list to a Classifier) - these = should=20 be represented in the info model as associations. =20

How=20 any of these concepts are implemented is up to the data = model. In the=20 data model, you make the determination whether you use associations,=20 tables, arrays or something else.

Andrea

-----Original Message-----
From: Weiss, Walter=20 [mailto:wweiss@ellacoya.com]
Sent: Tuesday, August 22, 2000 = 10:29=20 AM
To: 'Andrea Westerinen'; 'Andrew Smith'
Cc:=20 remoore@us.ibm.com; policy@raleigh.ibm.com
Subject: RE: QDIM = issue:=20 the SchedulingService classes

Andrea,

-----Original Message-----
From: Andrea Westerinen=20 [mailto:andreaw@cisco.com]
Sent: Tuesday, August 22, 2000 = 12:39=20 AM
To: Weiss, Walter; 'Andrew Smith'
Cc:=20 remoore@us.ibm.com; policy@raleigh.ibm.com
Subject: RE: QDIM = issue:=20 the SchedulingService classes

Please note that modeling using a = table is=20 not "good" OO practice. Tables exist either because you = have=20 multiple instances of something (best done as a class with instances) = or=20 because you want to relate the rows and columns and put some data at = the right=20 spot in the table. The latter is really an implementation = dependent=20 way of modeling an association. There are always two = perspectives to a=20 "relate the rows and columns" table - in this case, the rows and = columns=20 represent queues and schedulers. The data at the intersection of = the row=20 and column is specific to BOTH the queue and the scheduler - so, it is = best=20 modeled as an association.

<Walter> Most everything in a router = is=20 implemented in tables. Filters, Meters, Markers, Routing entries, MAC=20 addresses, VLANs, VCs, and Security Associations are just a few of the = structures that come to mind that are typically in tables. All of = these meet=20 your criteria of being indexed in two directions. Are you saying that = all of=20 these need to be represented in associations?

regards,

-Walter

<= /HTML> ------=_NextPart_000_001C_01C00C26.38DBE6C0-- From majordomo@raleigh.ibm.com Tue Aug 22 14:40:04 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12789 for ; Tue, 22 Aug 2000 14:40:03 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA26448; Tue, 22 Aug 2000 14:38:04 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id OAA33430; Tue, 22 Aug 2000 14:38:05 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA56396; Tue, 22 Aug 2000 14:14:52 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA46572; Tue, 22 Aug 2000 14:14:42 -0400 Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id OAA28370 for ; Tue, 22 Aug 2000 14:14:43 -0400 From: remoore@us.ibm.com Received: from d54mta02.raleigh.ibm.com (d54mta02.raleigh.ibm.com [9.67.228.34]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.92) with SMTP id OAA33912; Tue, 22 Aug 2000 14:14:41 -0400 Received: by d54mta02.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 85256943.00643612 ; Tue, 22 Aug 2000 14:14:34 -0400 X-Lotus-Fromdomain: IBMUS To: Andrew Smith Cc: "Weiss, Walter" , policy@raleigh.ibm.com Message-Id: <85256943.006432DC.00@d54mta02.raleigh.ibm.com> Date: Tue, 22 Aug 2000 14:15:15 -0400 Subject: Re: QDIM issue: the SchedulingService classes Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: remoore@us.ibm.com Andrew, >remoore@us.ibm.com wrote: >> This is confusing. You start out stating that Walter >> is correct, but then you go on to demonstrate that >> he's not. Walter is saying that schedulers and their >> upstream elements are one-to-one. > >I don't see where you get this from - he's saying that, for each scheduler >instance, there is a table inside it that is indexed by some "input identifier". >That's not the same as saying that schedulers and their upstream elements are >one-to-one. I agree that he's saying this *now*. I was responding to the following statement from Walter's 8/18/2000 note: Each Scheduling Service instance represents the scheduling parameters associated with a single queue. The bandwidth scheduler determines that a single queue is entitled to. This is why the cardinality for SchedulerUsed is 0..1. Regards, Bob Bob Moore IBM Networking Software +1-919-254-4436 remoore@us.ibm.com From majordomo@raleigh.ibm.com Tue Aug 22 17:54:58 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16561 for ; Tue, 22 Aug 2000 17:54:50 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id RAA21734; Tue, 22 Aug 2000 17:52:25 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id RAA36070; Tue, 22 Aug 2000 17:52:27 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA53924; Tue, 22 Aug 2000 17:25:33 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA27292; Tue, 22 Aug 2000 17:25:30 -0400 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id RAA28784 for ; Tue, 22 Aug 2000 17:25:33 -0400 Received: from ups.cisco.com (ups.cisco.com [171.69.18.21]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id RAA24508 for ; Tue, 22 Aug 2000 17:25:29 -0400 Received: (from kzm@localhost) by ups.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id OAA12210 for policy@raleigh.ibm.com; Tue, 22 Aug 2000 14:25:01 -0700 (PDT) From: Keith McCloghrie Message-Id: <200008222125.OAA12210@ups.cisco.com> Subject: Re: QDIM issue: the SchedulingService classes To: policy@raleigh.ibm.com Date: Tue, 22 Aug 2000 14:25:01 -0700 (PDT) X-Mailer: ELM [version 2.5 PL1] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Keith McCloghrie Content-Transfer-Encoding: 7bit I missed the original message, which is quoted in the below, so I may have missed some of the context, but: > I would like to "modelize" Andrew's words since he is working from the > perspective of the "Informal/Conceptual" Model. Here goes ... > > > The most "correct" model (I think) is that the scheduler has multiple > inputs: > > Modeled as an association to the Scheduler from all the classes that could > be inputs. > > > each input has a set of parameters associated with it that describe > > how the scheduler will handle traffic arriving on that input. > > Modeled as properties on the association. > > > This has nothing whatsoever to do with the elements that are upstream from > the > > scheduler - they could be queues, they could be whatever you choose. > > So, the model ought to allow for a multi-input scheduler with multiple > sets > > of parameters. > > This argues to generalize the SchedulerUsed association and move it up to > ConditioningService in QDIM. In this way, any of the ConditioningServices > (meters, markers, queues, etc.) could be an input to a scheduler. > > > Unfortunately, with the SMI syntax available to us, there was no way to > > represent this cleanly in the MIB: the indexing does not work well. So we > chose > > to move any "per-input" scheduler parameters back (upstream) to a "queue > table". If I understand the need correctly, it would seem fairly straightforward to represent it "cleanly" in the MIB: if each input of the multi-input scheduler has a set of parameters, you just need to add a scheduler-input table, indexed by scheduler-id and input-id. The set of parameters would then be columnar objects in the scheduler-input table. Keith. From majordomo@raleigh.ibm.com Tue Aug 22 18:22:01 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16907 for ; Tue, 22 Aug 2000 18:22:00 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id SAA34440; Tue, 22 Aug 2000 18:20:54 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id SAA29086; Tue, 22 Aug 2000 18:20:56 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA27182; Tue, 22 Aug 2000 17:49:33 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA44326; Tue, 22 Aug 2000 17:49:30 -0400 Received: from corp.tivoli.com (corp.tivoli.com [146.84.104.1]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id RAA28562 for ; Tue, 22 Aug 2000 17:49:33 -0400 From: Ed_Ellesson@tivoli.com Received: from tivmta4.tivoli.com (tivmta4.tivoli.com [146.84.104.47]) by corp.tivoli.com (8.9.3/8.9.0) with SMTP id QAA04742 for ; Tue, 22 Aug 2000 16:49:01 -0500 (CDT) Received: by tivmta4.tivoli.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 86256943.0077DAF2 ; Tue, 22 Aug 2000 16:49:08 -0500 X-Lotus-Fromdomain: TIVOLI SYSTEMS To: policy@raleigh.ibm.com Message-Id: <86256943.0077D89C.00@tivmta4.tivoli.com> Date: Tue, 22 Aug 2000 17:49:54 -0400 Subject: Short Conf. Announcement. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Ed_Ellesson@tivoli.com Policy Folks: The WG chairs are forwarding this note as a service to the list. If too many announcements are received, or too many complaints are received, we will stop. The following conference may be of relevance to WG members. > "IP Policing International Conference": Paris, France, 12-15 September. > More details on: http://www.upperside.fr/baippol.htm Ed and Joel From majordomo@raleigh.ibm.com Tue Aug 22 18:46:36 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17188 for ; Tue, 22 Aug 2000 18:46:35 -0400 (EDT) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id SAA08662; Tue, 22 Aug 2000 18:44:27 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id SAA24328; Tue, 22 Aug 2000 18:44:29 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA46032; Tue, 22 Aug 2000 18:19:54 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA48328; Tue, 22 Aug 2000 18:19:48 -0400 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id SAA25394 for ; Tue, 22 Aug 2000 18:19:52 -0400 Received: from bor.ellacoya-nt (216-064-109-139.inaddr.vitts.com [216.64.109.139]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id SAA35566 for ; Tue, 22 Aug 2000 18:19:45 -0400 Received: by bor.ellacoya-nt with Internet Mail Service (5.5.2650.21) id ; Tue, 22 Aug 2000 18:17:35 -0400 Message-Id: From: "Weiss, Walter" To: "'Andrea Westerinen'" , "'Andrew Smith'" Cc: policy@raleigh.ibm.com Subject: RE: QDIM issue: the SchedulingService classes Date: Tue, 22 Aug 2000 18:17:34 -0400 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C00C86.C586C54E" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Weiss, Walter" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C00C86.C586C54E Content-Type: text/plain; charset="iso-8859-1" Replace <1> and <2> with table rows and columns of your choice and tell me how the scheduler is different: <1> <2> InputPort FilterTable Row Connection Security Association DestIPAddr Routing Table Entry Queue SchedulingTable Entry Please note that modeling using a table is not "good" OO practice. Tables exist either because you have multiple instances of something (best done as a class with instances) or because you want to relate the rows and columns and put some data at the right spot in the table. The latter is really an implementation dependent way of modeling an association. There are always two perspectives to a "relate the rows and columns" table - in this case, the rows and columns represent <1> and <2>. The data at the intersection of the row and column is specific to BOTH the <1> and the <2> - so, it is best modeled as an association. How any of these concepts are implemented is up to the data model. In the data model, you make the determination whether you use associations, tables, arrays or something else. Which is why a table entry is usually implemented in a class, logically indexed using an association. regards, -Walter ------_=_NextPart_001_01C00C86.C586C54E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: QDIM issue: the SchedulingService classes

Replace <1> and <2> with = table rows=20 and columns of your choice and tell me how the scheduler is=20 different:

<1> = = =20 <2>

InputPort = =20 FilterTable Row

Connection = ; =20 Security Association

DestIPAddr = ; =20 Routing Table Entry

Queue &nbs= p; SchedulingTable=20 Entry

Please note that modeling using a table = is=20 not "good" OO practice. Tables exist either because you have = multiple=20 instances of something (best done as a class with instances) or because = you want=20 to relate the rows and columns and put some data at the right spot in = the=20 table. The latter is really an implementation dependent way = of=20 modeling an association. There are always two perspectives to a = "relate=20 the rows and columns" table - in this case, the rows and columns=20 represent <1> = and <2>. The data at the = intersection of=20 the row and column is specific to BOTH the <1> and the <2> - so, it is best modeled as = an association.

How=20 any of these concepts are implemented is up to the data = model. In=20 the data model, you make the determination whether you use = associations,=20 tables, arrays or something else.

<Walter> Which is why a table entry = is usually=20 implemented in a class, logically indexed using an=20 association.

regards,

-Walter

------_=_NextPart_001_01C00C86.C586C54E-- From majordomo@raleigh.ibm.com Tue Aug 22 20:13:55 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17946 for ; Tue, 22 Aug 2000 20:13:55 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id UAA31308; Tue, 22 Aug 2000 20:11:32 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id UAA26394; Tue, 22 Aug 2000 20:11:32 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA33200; Tue, 22 Aug 2000 18:28:41 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA51878; Tue, 22 Aug 2000 18:28:38 -0400 Received: from corp.tivoli.com (corp.tivoli.com [146.84.104.1]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id SAA28426 for ; Tue, 22 Aug 2000 18:28:41 -0400 From: Ed_Ellesson@tivoli.com Received: from tivmta4.tivoli.com (tivmta4.tivoli.com [146.84.104.47]) by corp.tivoli.com (8.9.3/8.9.0) with SMTP id RAA16052 for ; Tue, 22 Aug 2000 17:28:09 -0500 (CDT) Received: by tivmta4.tivoli.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 86256943.007B6DB2 ; Tue, 22 Aug 2000 17:28:10 -0500 X-Lotus-Fromdomain: TIVOLI SYSTEMS To: policy@raleigh.ibm.com Message-Id: <86256943.007B6CEF.00@tivmta4.tivoli.com> Date: Tue, 22 Aug 2000 18:29:01 -0400 Subject: Presentation Slides in Pittsburgh Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Ed_Ellesson@tivoli.com These are the names of the files of presentation slides which I just now submitted to the proceedings in connection with our wg meeting sessions in Pittsburgh. PCIM-07.ppt Bob Moore: PCIM-07 Report for 48th IETF PCLS-07.ppt Bob Moore: PCLS-07: New Mapping Ideas PolTerm-00.ppt Andrea Westerinen: Policy Terminology -01 IETF-Pitt-Ver2.ppt Yoram Snir: QoS Policy Information Model & Schema PolicyQoSDevice.ppt Andrea Westerinen: Policy Device Info Model - 01 IETF-Policy 8-1-00.ppt Ritu Chadha: Policy Information Model for MPLS Traffic Engineering MPLS_IM_final_2minutes.ppt Marcus Brunner: Policy Framework QoS Information Model for MPLS Clarification on the Submission.ppt Mahadevan Iyer: IP VPN Policy Information Model If I missed anyone, please send me your presentation file as an attachment, and I will forward it to the proceedings people. Thanks! Ed Ellesson Tivoli Systems Durham, NC ed_ellesson@tivoli.com 919-224-2111 From majordomo@raleigh.ibm.com Wed Aug 23 20:56:54 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24944 for ; Wed, 23 Aug 2000 20:56:54 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id UAA40618; Wed, 23 Aug 2000 20:55:41 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id UAA24250; Wed, 23 Aug 2000 20:55:26 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA49578; Wed, 23 Aug 2000 14:38:13 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA29076; Wed, 23 Aug 2000 14:38:00 -0400 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id OAA27950 for ; Wed, 23 Aug 2000 14:37:27 -0400 Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA34548 for ; Wed, 23 Aug 2000 14:37:18 -0400 Received: from jschnizl1-pc (dhcp-171-68-129-121.cisco.com [171.68.129.121]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id LAA29011; Wed, 23 Aug 2000 11:36:18 -0700 (PDT) Message-Id: <4.1.20000823141710.00b65170@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 23 Aug 2000 14:35:34 -0400 To: "Weiss, Walter" From: John Schnizlein Subject: RE: QDIM issue: the SchedulingService classes Cc: policy@raleigh.ibm.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: John Schnizlein Walter, Since your intention that the second word modify the first word, which is opposite the order of Engish adjectives, you should consider using non-compound noun-phrases for this distinction. Referring to priority schedulers or bandwidth-share schedulers would be much clearer than confusing people with your subtle semantics of reversed-terms labels. The details that you suspect each of these needs parameters associated with the other (which we might not all agree with) could be described elsewhere. This is especially the case when you are asking someone how they handle this distinction. John At 09:35 AM 08/23/2000 -0400, Weiss, Walter wrote: > >> Which, of priority scheduler and bandwidth-share scheduler, >> is which of the types you asked to be distinguished: >> priority bandwidth or bandwidth priority scheduling? > >If I understand your question correctly, I was assuming that the >first word represented the primary mode of the scheduler (is it >fundamentally a bandwidth scheduler or fundamentally a priority >scheduler), and the second word to specify any special extensions >to the scheduler. >... >If my clarification was insufficient, let me know. If you would like to >propose a different term for each example (rate limiting priority >scheduler), please propose it. I have been using those terms mostly because >that was the way the classes were originally named (my fault), and because >the real point is that both schedulers use the same set of attributes with >distinctly different semantics and results. > >> > At 01:40 PM 08/21/2000 -0400, Weiss, Walter wrote: >> > > >> > > ... How do you propose to distinguish priority bandwidth >> > >scheduling from bandwidth priority scheduling? >> > >> > Could you please specify the distinction you mean here? From majordomo@raleigh.ibm.com Thu Aug 24 00:35:49 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29141 for ; Thu, 24 Aug 2000 00:35:49 -0400 (EDT) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id AAA32142; Thu, 24 Aug 2000 00:34:25 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id AAA27362; Thu, 24 Aug 2000 00:34:09 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA32224; Wed, 23 Aug 2000 18:24:20 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA50080; Wed, 23 Aug 2000 18:23:57 -0400 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id SAA35646 for ; Wed, 23 Aug 2000 18:23:30 -0400 Received: from dnsmx1pya.telcordia.com (dnsmx1pya.telcordia.com [128.96.20.31]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id SAA33990 for ; Wed, 23 Aug 2000 18:04:06 -0400 Received: from notes949.cc.telcordia.com (notes949a.cc.telcordia.com [128.96.246.8]) by dnsmx1pya.telcordia.com (8.9.3/8.9.3) with SMTP id SAA19830; Wed, 23 Aug 2000 18:01:25 -0400 (EDT) Received: by notes949.cc.telcordia.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 85256944.0078F7D3 ; Wed, 23 Aug 2000 18:01:17 -0400 X-Lotus-Fromdomain: TELCORDIA From: "Taruni Uppal Seth" To: policy@raleigh.ibm.com, "remoore@us.ibm.com" , johns@cisco.com Cc: Ed_Ellesson@tivoli.com, rmoats@coreon.net Message-Id: <85256944.0078F7BA.00@notes949.cc.telcordia.com> Date: Wed, 23 Aug 2000 18:00:21 -0400 Subject: Comment and Question on Policy Draft policy-core-schema-07.txt Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Taruni Uppal Seth" In the LDAP schema mappings of CIM classes, the following two associations refer to "containedActionAssocSet" in policyRule, however no such property seems to exist in policyRule. Can someone please clarify what this means. Taruni +-----------------------------------------------------+------------------------------------------+ | PolicyConditionInPolicyRule | DIT containment + | | | containedConditionAssocSet in | | | policyRule + | | | policyConditionDN in | | | policyRuleConditionAssociation| +-----------------------------------------------+------------------------------------------------+ | PolicyActionInPolicyRule | DIT containment + | | | containedActionAssocSet in | | | policyRule + | | | policyActionDN in | | | policyRuleActionAssociation | +------------------------------------------------+-----------------------------------------------+ From majordomo@raleigh.ibm.com Thu Aug 24 01:27:17 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01910 for ; Thu, 24 Aug 2000 01:27:17 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id BAA36570; Thu, 24 Aug 2000 01:26:01 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id BAA32404; Thu, 24 Aug 2000 01:26:00 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA52662; Wed, 23 Aug 2000 19:25:29 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA51872; Wed, 23 Aug 2000 19:25:16 -0400 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id TAA33168 for ; Wed, 23 Aug 2000 19:24:50 -0400 Received: from bor.ellacoya-nt (216-064-109-139.inaddr.vitts.com [216.64.109.139]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id TAA27702 for ; Wed, 23 Aug 2000 19:12:53 -0400 Received: by bor.ellacoya-nt with Internet Mail Service (5.5.2650.21) id ; Wed, 23 Aug 2000 19:10:34 -0400 Message-Id: From: "Weiss, Walter" To: "'John Schnizlein'" Cc: policy@raleigh.ibm.com Subject: RE: QDIM issue: the SchedulingService classes Date: Wed, 23 Aug 2000 19:10:33 -0400 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C00D57.5718DF1C" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Weiss, Walter" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C00D57.5718DF1C Content-Type: text/plain; charset="iso-8859-1" John, I agree that the terms are important for clearly distinguishing the different operational characteristics of each type of scheduler. The names of the schedulers are largely a hold-over from previous iterations of the model where the distinction was discussed, if not in the draft, then at least amoung the authors (otherwise we would not have put both in :) The question of whether the types of parameters for each type of scheduler is immaterial to the original point of the discussion. If the parameters are different, then seperate classes are needed. If they are the same set of parameters, then you need seperate classes because the meaning of the attributes to the scheduler (behavioural semantics) is different. regards, -Walter > -----Original Message----- > From: John Schnizlein [mailto:jschnizl@cisco.com] > Sent: Wednesday, August 23, 2000 2:36 PM > To: Weiss, Walter > Cc: policy@raleigh.ibm.com > Subject: RE: QDIM issue: the SchedulingService classes > > > Walter, > > Since your intention that the second word modify the first word, > which is opposite the order of Engish adjectives, you should > consider using non-compound noun-phrases for this distinction. > > Referring to priority schedulers or bandwidth-share schedulers > would be much clearer than confusing people with your subtle > semantics of reversed-terms labels. The details that you suspect > each of these needs parameters associated with the other > (which we might not all agree with) could be described elsewhere. > This is especially the case when you are asking someone how they > handle this distinction. > > John > > At 09:35 AM 08/23/2000 -0400, Weiss, Walter wrote: > > > >> Which, of priority scheduler and bandwidth-share scheduler, > >> is which of the types you asked to be distinguished: > >> priority bandwidth or bandwidth priority scheduling? > > > >If I understand your question correctly, I was assuming that the > >first word represented the primary mode of the scheduler (is it > >fundamentally a bandwidth scheduler or fundamentally a priority > >scheduler), and the second word to specify any special extensions > >to the scheduler. > >... > >If my clarification was insufficient, let me know. If you > would like to > >propose a different term for each example (rate limiting priority > >scheduler), please propose it. I have been using those terms > mostly because > >that was the way the classes were originally named (my > fault), and because > >the real point is that both schedulers use the same set of > attributes with > >distinctly different semantics and results. > > > >> > At 01:40 PM 08/21/2000 -0400, Weiss, Walter wrote: > >> > > > >> > > ... How do you propose to distinguish priority bandwidth > >> > >scheduling from bandwidth priority scheduling? > >> > > >> > Could you please specify the distinction you mean here? > > ------_=_NextPart_001_01C00D57.5718DF1C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: QDIM issue: the SchedulingService classes

John,

I agree that the terms are important for clearly = distinguishing the different operational characteristics of each type = of scheduler. The names of the schedulers are largely a hold-over from = previous iterations of the model where the distinction was discussed, = if not in the draft, then at least amoung the authors (otherwise we = would not have put both in :)

The question of whether the types of parameters for = each type of scheduler is immaterial to the original point of the = discussion. If the parameters are different, then seperate classes are = needed. If they are the same set of parameters, then you need = seperate classes because the meaning of the attributes to the = scheduler (behavioural semantics) is different.

regards,

-Walter

> -----Original Message-----
> From: John Schnizlein [mailto:jschnizl@cisco.com]=
> Sent: Wednesday, August 23, 2000 2:36 PM
> To: Weiss, Walter
> Cc: policy@raleigh.ibm.com
> Subject: RE: QDIM issue: the SchedulingService = classes
>
>
> Walter,
>
> Since your intention that the second word = modify the first word,
> which is opposite the order of Engish = adjectives, you should
> consider using non-compound noun-phrases for = this distinction.
>
> Referring to priority schedulers or = bandwidth-share schedulers
> would be much clearer than confusing people = with your subtle
> semantics of reversed-terms labels. The details = that you suspect
> each of these needs parameters associated = with the other
> (which we might not all agree with) could be = described elsewhere.
> This is especially the case when you are asking = someone how they
> handle this distinction.
>
> John
>
> At 09:35 AM 08/23/2000 -0400, Weiss, Walter = wrote:
> >
> >> Which, of priority scheduler and = bandwidth-share scheduler,
> >> is which of the types you asked to be = distinguished:
> >> priority bandwidth or bandwidth = priority scheduling?
> >
> >If I understand your question correctly, I = was assuming that the
> >first word represented the primary mode of = the scheduler (is it
> >fundamentally a bandwidth scheduler or = fundamentally a priority
> >scheduler), and the second word to specify = any special extensions
> >to the scheduler.
> >...
> >If my clarification was insufficient, let = me know. If you
> would like to
> >propose a different term for each example = (rate limiting priority
> >scheduler), please propose it. I have been = using those terms
> mostly because
> >that was the way the classes were = originally named (my
> fault), and because
> >the real point is that both schedulers use = the same set of
> attributes with
> >distinctly different semantics and = results.
> >
> >> > At 01:40 PM 08/21/2000 -0400, = Weiss, Walter wrote:
> >> > >
> >> > > ... How do you propose to = distinguish priority bandwidth
> >> > >scheduling from bandwidth = priority scheduling?
> >> >
> >> > Could you please specify the = distinction you mean here?
>
>

------_=_NextPart_001_01C00D57.5718DF1C-- From majordomo@raleigh.ibm.com Thu Aug 24 09:13:05 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16546 for ; Thu, 24 Aug 2000 09:13:05 -0400 (EDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id JAA20524; Thu, 24 Aug 2000 09:11:14 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id JAA29348; Thu, 24 Aug 2000 09:11:13 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA40820; Thu, 24 Aug 2000 08:45:34 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA40784; Thu, 24 Aug 2000 08:45:28 -0400 Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id IAA31868 for ; Thu, 24 Aug 2000 08:45:29 -0400 From: remoore@us.ibm.com Received: from d54mta02.raleigh.ibm.com (d54mta02.raleigh.ibm.com [9.67.228.34]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.93) with SMTP id IAA59018; Thu, 24 Aug 2000 08:45:28 -0400 Received: by d54mta02.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 85256945.00461268 ; Thu, 24 Aug 2000 08:45:22 -0400 X-Lotus-Fromdomain: IBMUS To: "Taruni Uppal Seth" Cc: policy@raleigh.ibm.com, johns@cisco.com, Ed_Ellesson@tivoli.com, rmoats@coreon.net Message-Id: <85256945.004609EF.00@d54mta02.raleigh.ibm.com> Date: Thu, 24 Aug 2000 08:45:52 -0400 Subject: Re: Comment and Question on Policy Draft policy-core-schema-07.txt Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: remoore@us.ibm.com Hi Taruni, These are typos in the PCLS draft: "containedConditionAssocSet" should be "policyRuleConditionList" and "containedActionAssocSet" should be "policyRuleActionList" I'll fix these in PCLS-08. (And thanks for catching them!) Regards, Bob Bob Moore IBM Networking Software +1-919-254-4436 remoore@us.ibm.com From majordomo@raleigh.ibm.com Mon Aug 28 10:50:36 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11421 for ; Mon, 28 Aug 2000 10:50:36 -0400 (EDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA19172; Mon, 28 Aug 2000 10:48:14 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id KAA22140; Mon, 28 Aug 2000 10:48:15 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA38782; Mon, 28 Aug 2000 10:21:43 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA38762; Mon, 28 Aug 2000 10:21:39 -0400 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id KAA30956 for ; Mon, 28 Aug 2000 10:21:40 -0400 Received: from chmls06.mediaone.net (chmls06.mediaone.net [24.147.1.144]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA24354 for ; Mon, 28 Aug 2000 10:21:37 -0400 Received: from [24.128.60.156] (h0050e460d16d.ne.mediaone.net [24.128.60.156]) by chmls06.mediaone.net (8.8.7/8.8.7) with ESMTP id KAA00602; Mon, 28 Aug 2000 10:21:36 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Mon, 28 Aug 2000 10:24:29 -0400 Subject: Comments on the draft-ietf-policy-terminology-00.txt document From: Jon Saperia To: , snmpconf Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Jon Saperia Content-Transfer-Encoding: 7bit Here are some comments on the recent draft. Sorry for the cross posting. I know that some on the SNMPCONF WG list are not on the policy list. On Page 3: > - "M" identifies various mechanisms to create or convey policy- > related information in a network. For example, COPS and an > "Information Model" are two mechanisms for communicating and > describing policy-related data. Perhaps we need another term. Mechanism has come to be used in the context of a technology used to realize a particular policy in a policy domain. An example would be RED or WRED in DiffServ of BGP Policy in the Routing Policy domain. In addition, there are several places in the document (see also page 7) that would benefit from a clearer expansion of the terms that are currently in use in terms of levels of abstraction. At present 4 levels of abstraction have been defined and are now in common use in the SNMPCONF documents. They are: 1. Domain Specific. 2. Mechanism Specific 3. Implementation Specific 4. Instance Specific Rather than quote the entirety of these terms, here are the reference IDs: draft-ietf-snmpconf-diffpolicy-02.txt draft-ietf-snmpconf-bcp-02.txt Additional background information is found in: draft-saperia-policysnmp-00.txt I believe that community will be well served by a common set of terms as they relate to these levels of abstraction. On Page 4 > Common Open Policy System (COPS) I have no issue with the inclusion of this specific mechanism and components of its architecture such as PDPs and PEPs. To the extent that we choose to define such technologies in this document, we should also define the SNMP-based ones as well and it based documents - those references are pretty well known. With regard to SNMPCONF specific items this document should also include items such as: Policy MIB Module Mechanism and Implementation Specific MIB Modules Policy Management Application (see above references) Also on Page 4 > configuration I found this paragraph a bit confusing. The telco industry uses configuration to refer to parameters that 'are set at the factory' and are not generally changeable by the customer. Provisioning refers to those parameters that are customer changeable. I think there is a useful concept in the paragraph which points to user or provisioning system(s) setting of object values versus those that are dynamic or run time. The best example I can give is in the routing are where a set of BGP or OSPF configuration values are set by the user, but the routing information is continuously changing while the system is running. On Page 5. > Directory Enabled Networks (DEN) My issue is not the inclusion or definition. I would like for us to have generic terms that are not dependent on the DMTF as well. For example what shall we call the general data model that is not LDAP specific? Since this is an IETF document, I think we should not only reference the work that the document is based on, but the technology over which we have change control and will use, perhaps in addition to other technologies. On pages 7, 9, 11 and 12: Terms such as policy condition, policy action, policy rule, role and role combination. I assume this document will be revised to reflect discussions that came out of the IETF meeting to resolve term conflicts that Andrea and Steve Waldbusser and others have had. I have not seen documentation of these discussions and look forward to those clarifications. Page 9 > Policy Information Base (PIB) Same comment as before. No issue with definition, we just need to add the SNMP counterparts. Page 10 > policy server I do have an issue with this definition. It states: > (P) A marketing term whose definition is imprecise. Originally, > [R2753] referenced a "policy server." As the RFC evolved, this > term became more precise and known as the Policy Decision Point > (PDP). Today, the term is used in marketing and other > literature to refer specifically to a PDP, or for any entity > that uses/services policy. In the SNMPCONF work we have been using policy application for some time since PDP and PEP have a very specific and sometimes different set of behaviors than SNMP. Also on Page 10. > PolicyRepository I feel this should be a generic term since many people will store the information cited in systems and formats not common to PCIM or CIM. These comments aside. The document is a good start and will be quite helpful. /jon From majordomo@raleigh.ibm.com Mon Aug 28 14:37:10 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18046 for ; Mon, 28 Aug 2000 14:37:09 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA22922; Mon, 28 Aug 2000 14:35:35 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id OAA26412; Mon, 28 Aug 2000 14:35:36 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA48770; Mon, 28 Aug 2000 14:14:03 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA41068; Mon, 28 Aug 2000 14:13:59 -0400 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id OAA26754 for ; Mon, 28 Aug 2000 14:14:02 -0400 Received: from sigma.cisco.com (sigma.cisco.com [171.69.63.142]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA17252 for ; Mon, 28 Aug 2000 14:13:59 -0400 Received: from andreawlap (atlantis-dial-1-95.cisco.com [171.68.181.96]) by sigma.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id LAA02299; Mon, 28 Aug 2000 11:12:40 -0700 (PDT) From: "Andrea Westerinen" To: "Juergen Schoenwaelder" , "Policy@Raleigh. Ibm. Com" Subject: FW: Policy Terminology Draft Date: Mon, 28 Aug 2000 11:16:31 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Andrea Westerinen" Content-Transfer-Encoding: 7bit Juergen, Replies inline. Thanks. Andrea -----Original Message----- From: policy-owner@raleigh.ibm.com [mailto:policy-owner@raleigh.ibm.com]On Behalf Of Juergen Schoenwaelder Sent: Tuesday, August 22, 2000 3:39 AM To: andreaw@cisco.com; Keith McCloghrie Cc: policy@raleigh.ibm.com Subject: Re: Policy Terminology Draft >>>>> Andrea Westerinen writes: Andrea> The Policy Framework WG has created an I-D to try to Andrea> disambiguate policy terminology across all IETF Work Groups. [...] Andrea> Please look the draft over, and if you have feedback, please Andrea> reply to me and/or to the policy mail list Andrea> (policy@raleigh.ibm.com). I have read and I believe that this document is very valuable. I also have some comments you may want to consider when you revise this text. 1. The definition of "Authentication, Authorization, Accounting" has lots of text on the current process within the AAA and related WGs. For example, the last sentence is IMHO completely irrelevant in the longer term (which does of course not mean that the work being done is irrelevant). I suggest to rewrite at least the last two sentences in this definition (perhaps removing most of it). In rereading the definition, the last sentences really don't add to the explanation/definition of policy and its applicability to AAA. So, we will just remove them from the draft. There were also some decisions made in AAA in Pittsburgh that need to be reflected in the text - so the new AAA explanation reads: (A) AAA efforts in the IETF have focused on the most widely deployed use of authentication: Remote Authentication Dial In User Service (RADIUS), and its expansion in Diameter (a "radius" pun and not an acronym, DIAMETER). Referencing the RADIUS RFC (R2138), a network access server sends dial-user credentials to a AAA server, and receives authentication that the user is who he/she claims along with a set of attribute-value pairs authorizing various service features for that user. Policy is implied in both the authentication, which can be restricted by time of day, number of sessions, calling number, etc., and the attribute- values authorized. 2. In the definition of CIM, you wrote: "CIM includes a set of files, written in the language specified in the Specification. These are known as the Core and Common Models, and define an information model for the "enterprise" ..." I think this puts too much importance on the concept of storing CIM models in a (MOF) file, which is just one way to represent a CIM model. Many people are much more familiar with the graphical UML-style representation of CIM models, I think. And this is not even explicitly mentioned in the CIM definition. Here is a rewrite ... (M) An object-oriented information model published by the DMTF (Distributed Management Task Force) [DMTF]. It consists of a Specification detailing the abstract modeling constructs and principles of the Information Model, and a textual language definition to represent the Model. CIM's schemas are defined as a set of files, written in the language of the Specification, with graphical renderings using UML [UML]. Sets of classes and associations represent CIM's Core and Common Models, defining an information model for the "enterprise" - addressing general concepts (in Core), and systems, devices, users, software distribution, the physical environment, networks and policy (in the Common Models). (See also "information model.") 3. You define IPSP, which is an IETF working group. You do not define other working groups. I think that not defining working groups in this document is a good thing since WGs come and go (even though some WGs seem to never really go away ;-). This is a valid point. We should only list "areas" of work, not WGs. But we must be sure to include all the data models, specification language and exchange protocols defined by IPSP in the terminology draft. 4. The definition of MPLS as a "label swapping framework" surprised me - but this indeed what RFC 2702 says. Anyway, I believe that "label switching framework" or perhaps "label swapping and switching framework" is less confusing - at least for me. Will change wording. 5. I have some more important problems with the definition of a Policy Rule Class. The current text says: $ Policy Rule Class (PRC) (M) An ordered set of scalar attributes, defined in a PIB. "Policy Rule Classes" are arranged in a hierarchical structure similar to tables in SNMP's SMIv2. [R2578, PIB] I suggest to use the following text: $ Policy Rule Class (PRC) (M) An ordered set of attributes. PRCs are defined in PIB modules and registered in the Object Identifier tree. PRIs which are instances of the same PRC are organized in a table, similar to conceptual tables in the SMIv2. [R2578, SPPI] OK - text will be updated. Note that reference [PIB] does not exist anymore. I think that the correct reference is draft-ietf-diffserv-pib-01.txt. Also, we will include the framework PIB reference (draft-ietf-rap-frameworkpib-00.txt). I also found "scalar attribute" confusing for people who are familiar with SMIv2 scalars. You probably wanted to highlight the fact that PRC attributes are primitive and not compound - but I think you need to be more precise if this details is really essential. I also think the acronym PRI should be defined in this document, e.g. $ Policy Rule Instance (PRI) (M) is an instantiation of a PRC. $ PRI See "Policy Rule Instance" Will add. 6. Now to my fundamental PRC/PRI terminology concern: The usage of "policy rule" in the terms PRC and PRI conflicts with the definition of the term "policy rule". A PRC does not bind actions to a set of conditions. This is IMHO a very fundamental terminology problem we have. In my view of the world, PRCs and PRIs just convey (network-wide) configuration information to a device. So a better explanation of these acronyms (if we want to keep them) would probably be "Provisioning Class (PRC)" and "Provisioning Class Instance (PRI)". One could also argue that different terms should be used here. I do not expect that there is agreement here on changing the interpretation of PRC and PRI or to introduce new terms to replace them. But I think it is important to highlight that there is at least a problem here. In discussions among the editors of the draft, we agree with your distinction here. We will clarify the PolTerm draft, and indicate that a discrepancy exists between the use of the words "policy rule" in PRC and other drafts. Also, we will work with the RAP team to try to get different words adopted for PRC (based on your suggestion of Provisioning Class). 7. The example for "policy translation" is about the conversion of a PIB into a CLI format. I think we had several discussions about translations and mappings before. What you describe here is probably what some of us would call a mapping and not a translation. It is also unclear to me whether policy conversion is the same as policy translation and/or policy mapping. Perhaps policy conversion is the superset of policy translation and policy mapping, where policy translations happen between abstraction levels and policy mappings happen between different representations at the same abstraction level? These distinctions are actually not made in any draft and seem to draw arbitrary dividing lines between synonomous terms. The example that you site is listed specifically as an example. We discussed this issue at some length among the PolTerm editors and found that one person's/implementation's view of changing "levels" was another's view of staying at the same level. We will be happy to add some text that "policy mapping" is another synonym - but the essence of translating/converting/mapping is the "transformation of a policy from a representation and/or level of abstraction, to another representation and/or level of abstraction." This is how the draft is currently worded. 8. There are some funny characters in the definition of "service". Will remove these. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From majordomo@raleigh.ibm.com Tue Aug 29 05:45:20 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11845 for ; Tue, 29 Aug 2000 05:45:19 -0400 (EDT) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id FAA28926; Tue, 29 Aug 2000 05:39:17 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id FAA33606; Tue, 29 Aug 2000 05:39:06 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA44714; Tue, 29 Aug 2000 05:05:40 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA49056; Tue, 29 Aug 2000 05:05:14 -0400 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id FAA34376 for ; Tue, 29 Aug 2000 05:05:12 -0400 Received: from mumm.ibr.cs.tu-bs.de (root@mumm.ibr.cs.tu-bs.de [134.169.34.190]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id FAA27234 for ; Tue, 29 Aug 2000 05:05:08 -0400 Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id LAA16591; Tue, 29 Aug 2000 11:05:07 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id LAA17351; Tue, 29 Aug 2000 11:05:07 +0200 Date: Tue, 29 Aug 2000 11:05:07 +0200 Message-Id: <200008290905.LAA17351@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: andreaw@cisco.com Cc: policy@raleigh.ibm.com In-Reply-To: Subject: Re: FW: Policy Terminology Draft References: Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Juergen Schoenwaelder >>>>> Andrea Westerinen writes: Andrea> [...] so the new AAA explanation reads: Looks good to me. Andrea> Here is a rewrite ... [...] Andrea> graphical renderings using UML [UML]. Sets of classes and Andrea> associations represent CIM's Core and Common Models, defining Andrea> an information model for the "enterprise" - addressing general Andrea> concepts (in Core), and systems, devices, users, software Andrea> distribution, the physical environment, networks and policy Andrea> (in the Common Models). (See also "information model.") So the "Policy Core Information Model" produced by the Policy WG is a "Common Model" in CIM terminology, right? Isn't that a bit confusing? [...] Andrea> These distinctions are actually not made in any draft Andrea> and seem to draw arbitrary dividing lines between synonomous Andrea> terms. The example that you site is listed specifically as an Andrea> example. We discussed this issue at some length among the Andrea> PolTerm editors and found that one person's/implementation's Andrea> view of changing "levels" was another's view of staying at the Andrea> same level. We will be happy to add some text that "policy Andrea> mapping" is another synonym - but the essence of Andrea> translating/converting/mapping is the "transformation of a Andrea> policy from a representation and/or level of abstraction, to Andrea> another representation and/or level of abstraction." This is Andrea> how the draft is currently worded. So are we going to kick people out of the door in the future who start arguing about the differences between translations and mappings? Or are we just taking the easy way out here? Sure, the line between translations and mappings will be somewhat fuzzy - but I generally thought that the distinction is useful. My understanding is that a translation requires significant additional input from secondary sources while a mapping just transforms the primary input into some new output format: (a) input | v translation <-- significant secondary input | v output (b) input | v mapping | v output For example, a rule which refers to the accounting department needs significant secondary information to turn it into concrete device configurations that use IP addresses to identify traffic to/from the accounting department while a mapping from a CIM model to an LDAP schema is basically an algorithmic problem where secondary input is only needed to fine tune the mapping. But perhaps you are right that this is just a rathole. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From majordomo@raleigh.ibm.com Tue Aug 29 11:01:28 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20698 for ; Tue, 29 Aug 2000 11:01:27 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA20290; Tue, 29 Aug 2000 10:59:51 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id KAA04210; Tue, 29 Aug 2000 10:59:52 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA42120; Tue, 29 Aug 2000 10:33:53 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA42110; Tue, 29 Aug 2000 10:33:50 -0400 Received: from corp.tivoli.com (corp.tivoli.com [146.84.104.1]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id KAA08948 for ; Tue, 29 Aug 2000 10:33:51 -0400 From: Ed_Ellesson@tivoli.com Received: from tivmta4.tivoli.com (tivmta4.tivoli.com [146.84.104.47]) by corp.tivoli.com (8.9.3/8.9.0) with SMTP id JAA04767; Tue, 29 Aug 2000 09:26:30 -0500 (CDT) Received: by tivmta4.tivoli.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 8625694A.004F57A8 ; Tue, 29 Aug 2000 09:26:37 -0500 X-Lotus-Fromdomain: TIVOLI SYSTEMS To: Juergen Schoenwaelder Cc: andreaw@cisco.com, policy@raleigh.ibm.com Message-Id: <8625694A.004F558A.00@tivmta4.tivoli.com> Date: Tue, 29 Aug 2000 10:23:40 -0400 Subject: Re: FW: Policy Terminology Draft Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Ed_Ellesson@tivoli.com Yes, in retropspect, I guess it is confusing. We called it the Policy Core Model, because it was the core part of policy, which could not be applied without extensions to specific application domains. So, the term is relative in the way it was used. That is, PCIM is "Core" with respect to the area of Policy, but it is "Common" with respect to CIM. Sorry. Ed Ellesson Tivoli Systems Durham, NC ed_ellesson@tivoli.com 919-224-2111 Juergen Schoenwaelder on 08/29/2000 05:05:07 AM Please respond to Juergen Schoenwaelder To: andreaw@cisco.com cc: policy@raleigh.ibm.com (bcc: Ed Ellesson/Tivoli Systems) Subject: Re: FW: Policy Terminology Draft >>>>> Andrea Westerinen writes: Andrea> [...] so the new AAA explanation reads: Looks good to me. Andrea> Here is a rewrite ... [...] Andrea> graphical renderings using UML [UML]. Sets of classes and Andrea> associations represent CIM's Core and Common Models, defining Andrea> an information model for the "enterprise" - addressing general Andrea> concepts (in Core), and systems, devices, users, software Andrea> distribution, the physical environment, networks and policy Andrea> (in the Common Models). (See also "information model.") So the "Policy Core Information Model" produced by the Policy WG is a "Common Model" in CIM terminology, right? Isn't that a bit confusing? [...] Andrea> These distinctions are actually not made in any draft Andrea> and seem to draw arbitrary dividing lines between synonomous Andrea> terms. The example that you site is listed specifically as an Andrea> example. We discussed this issue at some length among the Andrea> PolTerm editors and found that one person's/implementation's Andrea> view of changing "levels" was another's view of staying at the Andrea> same level. We will be happy to add some text that "policy Andrea> mapping" is another synonym - but the essence of Andrea> translating/converting/mapping is the "transformation of a Andrea> policy from a representation and/or level of abstraction, to Andrea> another representation and/or level of abstraction." This is Andrea> how the draft is currently worded. So are we going to kick people out of the door in the future who start arguing about the differences between translations and mappings? Or are we just taking the easy way out here? Sure, the line between translations and mappings will be somewhat fuzzy - but I generally thought that the distinction is useful. My understanding is that a translation requires significant additional input from secondary sources while a mapping just transforms the primary input into some new output format: (a) input | v translation <-- significant secondary input | v output (b) input | v mapping | v output For example, a rule which refers to the accounting department needs significant secondary information to turn it into concrete device configurations that use IP addresses to identify traffic to/from the accounting department while a mapping from a CIM model to an LDAP schema is basically an algorithmic problem where secondary input is only needed to fine tune the mapping. But perhaps you are right that this is just a rathole. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From majordomo@raleigh.ibm.com Wed Aug 30 05:08:00 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22637 for ; Wed, 30 Aug 2000 05:07:59 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id FAA08514; Wed, 30 Aug 2000 05:06:01 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id FAA32886; Wed, 30 Aug 2000 05:05:58 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA56106; Wed, 30 Aug 2000 04:35:43 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA56290; Wed, 30 Aug 2000 04:35:36 -0400 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id EAA35158 for ; Wed, 30 Aug 2000 04:35:41 -0400 Received: from mumm.ibr.cs.tu-bs.de (root@mumm.ibr.cs.tu-bs.de [134.169.34.190]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id EAA30658 for ; Wed, 30 Aug 2000 04:35:39 -0400 Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id KAA26821; Wed, 30 Aug 2000 10:34:40 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id KAA18407; Wed, 30 Aug 2000 10:34:26 +0200 Date: Wed, 30 Aug 2000 10:34:26 +0200 Message-Id: <200008300834.KAA18407@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: Ed_Ellesson@tivoli.com Cc: andreaw@cisco.com, policy@raleigh.ibm.com In-Reply-To: <8625694A.004F558A.00@tivmta4.tivoli.com> (Ed_Ellesson@tivoli.com) Subject: Re: FW: Policy Terminology Draft References: <8625694A.004F558A.00@tivmta4.tivoli.com> Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Juergen Schoenwaelder >>>>> Ed Ellesson writes: Ed> Yes, in retropspect, I guess it is confusing. We called it the Ed> Policy Core Model, because it was the core part of policy, which Ed> could not be applied without extensions to specific application Ed> domains. So, the term is relative in the way it was used. That Ed> is, PCIM is "Core" with respect to the area of Policy, but it is Ed> "Common" with respect to CIM. If we can't fix it, then the terminology document should at least explain that the interpretation of "core model" depends on the context. I just checked the terminology draft and it seems that there is no definition of the term "Policy Core Information Model" and the PCIM acronym only appears as a citation of the PCIM document. I think PCIM is important enough to be described as an offical term in this document. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From majordomo@raleigh.ibm.com Wed Aug 30 05:37:01 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22831 for ; Wed, 30 Aug 2000 05:37:01 -0400 (EDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id FAA31678; Wed, 30 Aug 2000 05:34:57 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id FAA30724; Wed, 30 Aug 2000 05:34:57 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA42436; Wed, 30 Aug 2000 05:05:37 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA23636; Wed, 30 Aug 2000 05:05:26 -0400 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id FAA28512 for ; Wed, 30 Aug 2000 05:05:32 -0400 Received: from sigma.cisco.com (sigma.cisco.com [171.69.63.142]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id FAA16910 for ; Wed, 30 Aug 2000 05:05:30 -0400 Received: from andreawlap (sj-dial-4-86.cisco.com [171.68.181.215]) by sigma.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id CAA20301; Wed, 30 Aug 2000 02:04:12 -0700 (PDT) From: "Andrea Westerinen" To: "Juergen Schoenwaelder" , Cc: Subject: RE: FW: Policy Terminology Draft Date: Wed, 30 Aug 2000 02:08:03 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: <200008300834.KAA18407@henkell.ibr.cs.tu-bs.de> Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Andrea Westerinen" Content-Transfer-Encoding: 7bit Juergen, I totally agree and will fix this. Andrea -----Original Message----- From: Juergen Schoenwaelder [mailto:schoenw@ibr.cs.tu-bs.de] Sent: Wednesday, August 30, 2000 1:34 AM To: Ed_Ellesson@tivoli.com Cc: andreaw@cisco.com; policy@raleigh.ibm.com Subject: Re: FW: Policy Terminology Draft >>>>> Ed Ellesson writes: Ed> Yes, in retropspect, I guess it is confusing. We called it the Ed> Policy Core Model, because it was the core part of policy, which Ed> could not be applied without extensions to specific application Ed> domains. So, the term is relative in the way it was used. That Ed> is, PCIM is "Core" with respect to the area of Policy, but it is Ed> "Common" with respect to CIM. If we can't fix it, then the terminology document should at least explain that the interpretation of "core model" depends on the context. I just checked the terminology draft and it seems that there is no definition of the term "Policy Core Information Model" and the PCIM acronym only appears as a citation of the PCIM document. I think PCIM is important enough to be described as an offical term in this document. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From majordomo@raleigh.ibm.com Wed Aug 30 15:25:27 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07661 for ; Wed, 30 Aug 2000 15:25:27 -0400 (EDT) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id PAA20584; Wed, 30 Aug 2000 15:18:18 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id PAA22648; Wed, 30 Aug 2000 15:18:18 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA47120; Wed, 30 Aug 2000 14:53:56 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA29434; Wed, 30 Aug 2000 14:53:52 -0400 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id OAA28494 for ; Wed, 30 Aug 2000 14:53:54 -0400 Received: from relay1.acec.com (relay1.acec.com [38.249.211.2]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA06610 for ; Wed, 30 Aug 2000 14:53:49 -0400 Received: from bnatale.acecomm.com (dhcppm13.acec.com [38.249.211.235]) by relay1.acec.com (8.9.3/8.9.3) with ESMTP id OAA05459; Wed, 30 Aug 2000 14:56:52 -0400 (EDT) Message-Id: <4.3.2.7.2.20000830145201.01fdc058@plymouth.acec.com> X-Sender: bnatale@plymouth.acec.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 30 Aug 2000 14:57:34 -0400 To: "Andrea Westerinen" From: Bob Natale Subject: Re: FW: Policy Terminology Draft Cc: policy@raleigh.ibm.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Bob Natale At 8/28/2000:02:16 PM, Andrea Westerinen wrote: Hi Andrea, > 7. The example for "policy translation" is about the conversion of a > PIB into a CLI format. I think we had several discussions about > translations and mappings before. What you describe here is > probably what some of us would call a mapping and not a > translation. It is also unclear to me whether policy conversion is > the same as policy translation and/or policy mapping. Perhaps > policy conversion is the superset of policy translation and policy > mapping, where policy translations happen between abstraction > levels and policy mappings happen between different > representations at the same abstraction level? > > These distinctions are actually not made in any draft and seem to draw >arbitrary dividing lines between synonomous terms. The example that you site >is listed specifically as an example. We discussed this issue at some length >among the PolTerm editors and found that one person's/implementation's view >of changing "levels" was another's view of staying at the same level. We >will be happy to add some text that "policy mapping" is another synonym - >but the essence of translating/converting/mapping is the "transformation of >a policy from a representation and/or level of abstraction, to another >representation and/or level of abstraction." This is how the draft is >currently worded. Hmmm. "Transformation" and "conversion" imply more or less the same thing to me in this context...both encompass the kinds of actions denoted by "translation" and "mapping" (and probably other terms as well). However, to my understanding, there is an important diff between "translation" and "mapping" (as typically used in technical literature); namely: - mapping is deterministic, a set of precise rules govern the conversion process; whereas - translation allows for interpretation (e.g., the application of alternatives) during the conversion process. However, I realize this issue could be debated at this level forever. So, while I understand and favor Juergen's suggestion in this respect, I think the explanation you offer above for the course of action you want to follow is reasonable enough. Cordially, BobN ------------ ISO 9001 Registered Quality Supplier ----------- Bob Natale | ACE*COMM | 301-721-3000 [v] Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] bnatale@acecomm.com| Gaithersburg MD 20878 | www.acecomm.com ------------- Free downloads at www.winsnmp.com ------------- From majordomo@raleigh.ibm.com Thu Aug 31 07:58:01 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04275 for ; Thu, 31 Aug 2000 07:58:01 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id HAA28590; Thu, 31 Aug 2000 07:55:27 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id HAA08296; Thu, 31 Aug 2000 07:55:26 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA47360; Thu, 31 Aug 2000 07:19:54 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA61940; Thu, 31 Aug 2000 07:19:50 -0400 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id HAA24762 for ; Thu, 31 Aug 2000 07:19:50 -0400 Received: from chmls05.mediaone.net (chmls05.mediaone.net [24.147.1.143]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id HAA06552 for ; Thu, 31 Aug 2000 07:19:46 -0400 Received: from [24.128.60.156] (h0050e460d16d.ne.mediaone.net [24.128.60.156]) by chmls05.mediaone.net (8.8.7/8.8.7) with ESMTP id HAA23345; Thu, 31 Aug 2000 07:19:44 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Thu, 31 Aug 2000 07:22:42 -0400 Subject: Re: Policy Terminology Draft From: Jon Saperia To: Bob Natale , Andrea Westerinen Cc: Message-Id: In-Reply-To: <4.3.2.7.2.20000830145201.01fdc058@plymouth.acec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Jon Saperia Content-Transfer-Encoding: 7bit on 08/30/2000 2:57 PM, Bob Natale at bnatale@acecomm.com wrote: >> >> These distinctions are actually not made in any draft and seem to draw >> arbitrary dividing lines between synonomous terms. The example that you site >> is listed specifically as an example. We discussed this issue at some length >> among the PolTerm editors and found that one person's/implementation's view >> of changing "levels" was another's view of staying at the same level. We >> will be happy to add some text that "policy mapping" is another synonym - >> but the essence of translating/converting/mapping is the "transformation of >> a policy from a representation and/or level of abstraction, to another >> representation and/or level of abstraction." This is how the draft is >> currently worded. I wanted to comment on this piece specifically though it was in an exchange between Bob and Andrea since it helps illustrate one of the points about levels of abstraction I made in my comments to this group a few days ago and in the ID I pointed to. In short, we want to keep the levels of abstraction discussion (and terms) distinct from the transport conversion or access mechanism terms. What an object will look like at any level of abstraction will change depending on the access method. What I mean by this is that if I am expressing a PBH for a class of traffic via the CLI, it will look quite different than if I express it via a PIB or MIB. In fact, not all transport/access methods have mappings to all levels of abstraction. Could we use 'conversion' as opposed to translation to refer to the task of changing a policy at whatever level of abstraction to a protocol specific form. This may not always be obvious or algorithmic. /jon From majordomo@raleigh.ibm.com Thu Aug 31 09:05:29 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05430 for ; Thu, 31 Aug 2000 09:05:20 -0400 (EDT) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id IAA18374; Thu, 31 Aug 2000 08:59:54 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id IAA22848; Thu, 31 Aug 2000 08:59:55 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA30514; Thu, 31 Aug 2000 08:35:27 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA61202; Thu, 31 Aug 2000 08:35:23 -0400 Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id IAA20648 for ; Thu, 31 Aug 2000 08:35:24 -0400 From: remoore@us.ibm.com Received: from d54mta02.raleigh.ibm.com (d54mta02.raleigh.ibm.com [9.67.228.34]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.93) with SMTP id IAA33290; Thu, 31 Aug 2000 08:35:21 -0400 Received: by d54mta02.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 8525694C.00452206 ; Thu, 31 Aug 2000 08:35:06 -0400 X-Lotus-Fromdomain: IBMUS To: Jon Saperia Cc: Bob Natale , Andrea Westerinen , policy@raleigh.ibm.com Message-Id: <8525694C.00451305.00@d54mta02.raleigh.ibm.com> Date: Thu, 31 Aug 2000 08:35:28 -0400 Subject: Re: Policy Terminology Draft Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: remoore@us.ibm.com Jon, >Could we use 'conversion' as opposed to translation to refer to the task of >changing a policy at whatever level of abstraction to a protocol specific >form. This may not always be obvious or algorithmic. Changing it to a protocol-specific form from what? The only answer that I can think of is "From another protocol-specific form." If this is what we want "conversion" to mean, then I think it's clearer to define it as "The task of changing a policy at a given level of abstraction from one protocol- specific form to a different protocol-specific form." Does this correspond to how you wanted us to use the term "conversion"? Regards, Bob Bob Moore IBM Networking Software +1-919-254-4436 remoore@us.ibm.com From majordomo@raleigh.ibm.com Thu Aug 31 09:34:32 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05842 for ; Thu, 31 Aug 2000 09:34:29 -0400 (EDT) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id JAA23810; Thu, 31 Aug 2000 09:31:27 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id JAA35414; Thu, 31 Aug 2000 09:31:28 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA51018; Thu, 31 Aug 2000 09:03:27 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA48696; Thu, 31 Aug 2000 09:03:23 -0400 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id JAA33950 for ; Thu, 31 Aug 2000 09:02:53 -0400 Received: from chmls05.mediaone.net (chmls05.mediaone.net [24.147.1.143]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id JAA40262 for ; Thu, 31 Aug 2000 09:01:25 -0400 Received: from [24.128.60.156] (h0050e460d16d.ne.mediaone.net [24.128.60.156]) by chmls05.mediaone.net (8.8.7/8.8.7) with ESMTP id JAA18717; Thu, 31 Aug 2000 09:00:20 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Thu, 31 Aug 2000 09:03:18 -0400 Subject: Re: Policy Terminology Draft From: Jon Saperia To: Cc: Bob Natale , Andrea Westerinen , Message-Id: In-Reply-To: <8525694C.00451305.00@d54mta02.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Jon Saperia Content-Transfer-Encoding: 7bit on 08/31/2000 8:35 AM, remoore@us.ibm.com at remoore@us.ibm.com wrote: > > > Jon, > >> Could we use 'conversion' as opposed to translation to refer to the task of >> changing a policy at whatever level of abstraction to a protocol specific >> form. This may not always be obvious or algorithmic. >> > Changing it to a protocol-specific form from what? The only answer that I can > think of is "From another protocol-specific form." If this is what we want > "conversion" to mean, then I think it's clearer to define it as "The task of > changing a policy at a given level of abstraction from one protocol- specific > form to a different protocol-specific form." Does this correspond to how you > wanted us to use the term "conversion"? > > We are getting closer. To me the various levels of abstraction are independent of the protocol/framework specifics that are used to carry the policy information around or store it in some sort of database. Here is a specific example. If I wanted EF behavior for packets with a DSCP of some value(s), then that would be realized in different machines with different mechanisms such as RED. So to convey the policy of EF for say voice, I would convey mechanism specifics (the red parameters) to the devices. How this information is conveyed and the form of the information will be quite different if I use a CLI, SNMP, or COPS-PR or some other mechanism such as FTP which is what a lot of the world uses. > "The task of changing a policy at a given level of abstraction from one > protocol- specific form to a different protocol-specific form." I would modify this just a bit and say: The task of changing a policy at a given level of abstraction to a protocol- specific form. /jon From majordomo@raleigh.ibm.com Thu Aug 31 10:20:01 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06431 for ; Thu, 31 Aug 2000 10:20:00 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA07436; Thu, 31 Aug 2000 10:18:41 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id KAA08290; Thu, 31 Aug 2000 10:18:39 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA49738; Thu, 31 Aug 2000 10:00:04 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA49702; Thu, 31 Aug 2000 10:00:00 -0400 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id JAA32726 for ; Thu, 31 Aug 2000 09:59:59 -0400 Received: from chmls05.mediaone.net (chmls05.mediaone.net [24.147.1.143]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id JAA34424 for ; Thu, 31 Aug 2000 09:59:56 -0400 Received: from [24.128.60.156] (h0050e460d16d.ne.mediaone.net [24.128.60.156]) by chmls05.mediaone.net (8.8.7/8.8.7) with ESMTP id JAA23263; Thu, 31 Aug 2000 09:59:54 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Thu, 31 Aug 2000 10:02:52 -0400 Subject: Re: Policy Terminology Draft From: Jon Saperia To: John Schnizlein Cc: Message-Id: In-Reply-To: <4.1.20000831091137.00b05aa0@diablo.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Jon Saperia Content-Transfer-Encoding: 7bit on 08/31/2000 9:26 AM, John Schnizlein at jschnizl@cisco.com wrote: > After raising the issue Juergen (who missed the "benefit" of our > conference call "discussion") reached the same conclusion we did. > Reaching consensus on particular distinctions is impossible and > pointless. Although we all agree some amount of conversion > (translation, mapping) occurs, it need not be standardized. I am confused by this. I thought the purpose was to come up with terms that we agreed were relevant to this area. What I am suggesting is that while we may not agree on how the translation/mapping takes place we should have common protocol neutral terms that describe levels of abstraction as opposed to the function of translating them (or whatever term we select) for protocol specific purposes. With regard to levels of abstraction, I think they are fundamentally important and a useful set of levels are needed. /jon From majordomo@raleigh.ibm.com Thu Aug 31 10:20:02 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06444 for ; Thu, 31 Aug 2000 10:20:01 -0400 (EDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA08454; Thu, 31 Aug 2000 10:18:40 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id KAA33566; Thu, 31 Aug 2000 10:18:40 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA07564; Thu, 31 Aug 2000 09:55:37 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA51330; Thu, 31 Aug 2000 09:55:34 -0400 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id JAA23554 for ; Thu, 31 Aug 2000 09:55:35 -0400 Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id JAA26784 for ; Thu, 31 Aug 2000 09:55:32 -0400 Received: from jschnizl1-pc (jschnizl-isdn1.cisco.com [171.68.12.74]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id GAA29198; Thu, 31 Aug 2000 06:54:29 -0700 (PDT) Message-Id: <4.1.20000831092655.00a803c0@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 31 Aug 2000 09:53:48 -0400 To: Jon Saperia , , snmpconf From: John Schnizlein Subject: on "configuration" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: John Schnizlein At 10:24 AM 08/28/2000 -0400, Jon Saperia wrote: >... The telco industry uses configuration to refer to parameters >that 'are set at the factory' and are not generally changeable >by the customer. Provisioning refers to those parameters that >are customer changeable. The Internet industry seems to use "configuration" to mean changable parameters, as in the Dynamic Host Configuration Protocol [RFC 2131]. The BOF announced with Policy Terminology was called Configuration Management (excerpt below). The WG you co-chair is called Configuration Management with SNMP (snmpconf). My impression is that there is a rough consensus that we would be better served using this word as in the Internet context rather than in the "telco industry" you cite. My dictionary (American Heritage) defines provisioning as supplying with provisions, and a provision as that which is supplied. It defines configuration as the arrangement of the parts or elements of something. This distinction does not reflect 'set at the factory'. John At 11:24 PM 10/27/1999 +0000, Bert Wijnen wrote: >There will be two BOFs that may be of interest to readers of this >mailing list. > > Configuration Management Bof > Policy Terminology BOF > From majordomo@raleigh.ibm.com Thu Aug 31 10:20:05 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06464 for ; Thu, 31 Aug 2000 10:20:03 -0400 (EDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA32748; Thu, 31 Aug 2000 10:18:33 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id KAA20954; Thu, 31 Aug 2000 10:18:33 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA51356; Thu, 31 Aug 2000 09:55:46 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA49812; Thu, 31 Aug 2000 09:55:43 -0400 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id JAA07330 for ; Thu, 31 Aug 2000 09:55:44 -0400 Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id JAA42926 for ; Thu, 31 Aug 2000 09:55:39 -0400 Received: from jschnizl1-pc (jschnizl-isdn1.cisco.com [171.68.12.74]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id GAA29167; Thu, 31 Aug 2000 06:54:28 -0700 (PDT) Message-Id: <4.1.20000831091137.00b05aa0@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 31 Aug 2000 09:26:39 -0400 To: Jon Saperia From: John Schnizlein Subject: Re: FW: Policy Terminology Draft Cc: policy@raleigh.ibm.com In-Reply-To: <200008290905.LAA17351@henkell.ibr.cs.tu-bs.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: John Schnizlein The exchange excerpted below suggests the sort of argument that appears whenever we attempt to define translation (conversion, or mapping) between different levels of abstraction. How many levels? What should they be? Between which is the process conversion or mapping or translation? It was because these philosophical discussions do not lead to any conclusion that we chose not to attempt a consensus definition. After raising the issue Juergen (who missed the "benefit" of our conference call "discussion") reached the same conclusion we did. Reaching consensus on particular distinctions is impossible and pointless. Although we all agree some amount of conversion (translation, mapping) occurs, it need not be standardized. John At 11:05 AM 08/29/2000 +0200, Juergen Schoenwaelder wrote: >... >arguing about the differences between translations and mappings? >Or are we just taking the easy way out here? >... >But perhaps you are right that this is just a rathole. At 07:22 AM 08/31/2000 -0400, Jon Saperia wrote: >... >Could we use 'conversion' as opposed to translation to refer to the >task of changing a policy at whatever level of abstraction to a >protocol specific form. This may not always be obvious or algorithmic. At 08:35 AM 08/31/2000 -0400, remoore@us.ibm.com wrote: >... >Changing it to a protocol-specific form from what? The only >answer that I can think of is "From another protocol-specific form." From majordomo@raleigh.ibm.com Thu Aug 31 10:35:09 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06766 for ; Thu, 31 Aug 2000 10:35:08 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA24136; Thu, 31 Aug 2000 10:33:31 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id KAA37298; Thu, 31 Aug 2000 10:33:30 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA61088; Thu, 31 Aug 2000 10:06:12 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA40856; Thu, 31 Aug 2000 10:06:09 -0400 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id KAA27214 for ; Thu, 31 Aug 2000 10:06:10 -0400 Received: from chmls05.mediaone.net (chmls05.mediaone.net [24.147.1.143]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA40512 for ; Thu, 31 Aug 2000 10:06:05 -0400 Received: from [24.128.60.156] (h0050e460d16d.ne.mediaone.net [24.128.60.156]) by chmls05.mediaone.net (8.8.7/8.8.7) with ESMTP id KAA26922; Thu, 31 Aug 2000 10:06:05 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Thu, 31 Aug 2000 10:09:03 -0400 Subject: Re: on "configuration" From: Jon Saperia To: John Schnizlein , , snmpconf Message-Id: In-Reply-To: <4.1.20000831092655.00a803c0@diablo.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Jon Saperia Content-Transfer-Encoding: 7bit on 08/31/2000 9:53 AM, John Schnizlein at jschnizl@cisco.com wrote: > The Internet industry seems to use "configuration" to mean > changable parameters, as in the Dynamic Host Configuration Protocol > [RFC 2131]. The BOF announced with Policy Terminology was called > Configuration Management (excerpt below). The WG you co-chair is > called Configuration Management with SNMP (snmpconf). Yes, thank you I am aware of that. > > My impression is that there is a rough consensus that we would be > better served using this word as in the Internet context rather than > in the "telco industry" you cite. The reason I suggested it is that as we are all aware, the IETF has not published much yet in this area. I have learned that the telco folks have a lot to contribute to this discussion - though I am not a telco person. The IETF does from time to time use terms and definitions from other organizations (CIM comes to mind). I believe the distinction is a useful one. /jon From majordomo@raleigh.ibm.com Thu Aug 31 11:27:42 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07819 for ; Thu, 31 Aug 2000 11:27:41 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA35488; Thu, 31 Aug 2000 11:25:14 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id LAA30180; Thu, 31 Aug 2000 11:25:16 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA28916; Thu, 31 Aug 2000 11:00:43 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA59086; Thu, 31 Aug 2000 11:00:38 -0400 Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id LAA19648 for ; Thu, 31 Aug 2000 11:00:39 -0400 From: remoore@us.ibm.com Received: from d54mta02.raleigh.ibm.com (d54mta02.raleigh.ibm.com [9.67.228.34]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.93) with SMTP id LAA32282; Thu, 31 Aug 2000 11:00:32 -0400 Received: by d54mta02.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 8525694C.005270DE ; Thu, 31 Aug 2000 11:00:28 -0400 X-Lotus-Fromdomain: IBMUS To: John Schnizlein Cc: Jon Saperia , policy@raleigh.ibm.com Message-Id: <8525694C.00524C91.00@d54mta02.raleigh.ibm.com> Date: Thu, 31 Aug 2000 10:59:55 -0400 Subject: Re: FW: Policy Terminology Draft Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: remoore@us.ibm.com John, >The exchange excerpted below suggests the sort of argument that >appears whenever we attempt to define translation (conversion, >or mapping) between different levels of abstraction. >How many levels? What should they be? >Between which is the process conversion or mapping or translation? >It was because these philosophical discussions do not lead to >any conclusion that we chose not to attempt a consensus definition. > >After raising the issue Juergen (who missed the "benefit" of our >conference call "discussion") reached the same conclusion we did. >Reaching consensus on particular distinctions is impossible and >pointless. Although we all agree some amount of conversion >(translation, mapping) occurs, it need not be standardized. I agree that it may be impossible to get consensus (and then to enforce it!) concerning how to use this set of English words, which differ only slightly in their ordinary meanings. But we should still try to capture somehow the important distinction that Jon is arguing for. I think of it in terms of two dimensions. One dimension is the level of abstraction of a model, regardless of how the model is expressed. The other dimension is the specific language / technology used to express the model. People often confuse these two dimensions, but they really are distinct. Think of what you might do starting from the complete text of "Moby Dick" (in English): - You could translate the novel into French, German, or Russian. Here you'd be keeping the level of abstraction the same, but changing to a different language (Jon's "protocol-specific form"). - You could create a Cliff's Notes for the novel, in English. Here you'd be moving to a higher level of abstraction, without changing the language. - Finally, you could do both of these steps at once, moving directly from the novel to (pardoning my lame attempt at German) die Kliffenoten for the novel. Obviously we shouldn't press this analogy too far. But I hope it illustrates that Jon is talking about an important distinction, and thus that we shouldn't just stop at saying "There are a bunch of terms that all refer to changing expressions of policy in one way or another, and we're not going to try to make any distinctions in this area." Regards, Bob Bob Moore IBM Networking Software +1-919-254-4436 remoore@us.ibm.com John Schnizlein @raleigh.ibm.com on 08/31/2000 09:26:39 AM Please respond to John Schnizlein Sent by: policy-owner@raleigh.ibm.com To: Jon Saperia cc: policy@raleigh.ibm.com Subject: Re: FW: Policy Terminology Draft The exchange excerpted below suggests the sort of argument that appears whenever we attempt to define translation (conversion, or mapping) between different levels of abstraction. How many levels? What should they be? Between which is the process conversion or mapping or translation? It was because these philosophical discussions do not lead to any conclusion that we chose not to attempt a consensus definition. After raising the issue Juergen (who missed the "benefit" of our conference call "discussion") reached the same conclusion we did. Reaching consensus on particular distinctions is impossible and pointless. Although we all agree some amount of conversion (translation, mapping) occurs, it need not be standardized. John At 11:05 AM 08/29/2000 +0200, Juergen Schoenwaelder wrote: >... >arguing about the differences between translations and mappings? >Or are we just taking the easy way out here? >... >But perhaps you are right that this is just a rathole. At 07:22 AM 08/31/2000 -0400, Jon Saperia wrote: >... >Could we use 'conversion' as opposed to translation to refer to the >task of changing a policy at whatever level of abstraction to a >protocol specific form. This may not always be obvious or algorithmic. At 08:35 AM 08/31/2000 -0400, remoore@us.ibm.com wrote: >... >Changing it to a protocol-specific form from what? The only >answer that I can think of is "From another protocol-specific form." From majordomo@raleigh.ibm.com Thu Aug 31 12:27:27 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09096 for ; Thu, 31 Aug 2000 12:27:19 -0400 (EDT) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id MAA06538; Thu, 31 Aug 2000 12:24:08 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id MAA27128; Thu, 31 Aug 2000 12:24:10 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA07596; Thu, 31 Aug 2000 12:01:55 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA07584; Thu, 31 Aug 2000 12:01:51 -0400 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id MAA12628 for ; Thu, 31 Aug 2000 12:01:52 -0400 Received: from mumm.ibr.cs.tu-bs.de (root@mumm.ibr.cs.tu-bs.de [134.169.34.190]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id MAA36026 for ; Thu, 31 Aug 2000 12:01:48 -0400 Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id RAA01472; Thu, 31 Aug 2000 17:54:12 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id RAA07092; Thu, 31 Aug 2000 17:54:11 +0200 Date: Thu, 31 Aug 2000 17:54:11 +0200 Message-Id: <200008311554.RAA07092@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: jschnizl@cisco.com Cc: saperia@mediaone.net, policy@raleigh.ibm.com In-Reply-To: <4.1.20000831091137.00b05aa0@diablo.cisco.com> (message from John Schnizlein on Thu, 31 Aug 2000 09:26:39 -0400) Subject: Re: FW: Policy Terminology Draft References: <4.1.20000831091137.00b05aa0@diablo.cisco.com> Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Juergen Schoenwaelder >>>>> John Schnizlein writes: John> After raising the issue Juergen (who missed the "benefit" of our John> conference call "discussion") reached the same conclusion we John> did. Reaching consensus on particular distinctions is John> impossible and pointless. Although we all agree some amount of John> conversion (translation, mapping) occurs, it need not be John> standardized. This was not really my conclusion. For me, there is a difference between translations and mappings. What I agree with is the observation that in many real-world situations, you may end up doing 95 % translation + 5 % mapping or 95 % mapping plus 5 % translation to get a job done. So discussing whether a concrete action is a translation or a mapping may turn out to be a rathole because most of these actions will be a combination of both. But this does not mean that a conceptual differentiation between these two activities translation and mapping is not worthwhile to understand and communicate about fundamental concepts in policy-based mgmt. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From majordomo@raleigh.ibm.com Thu Aug 31 13:58:16 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10705 for ; Thu, 31 Aug 2000 13:58:15 -0400 (EDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id NAA33158; Thu, 31 Aug 2000 13:56:29 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id NAA26336; Thu, 31 Aug 2000 13:56:31 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA57424; Thu, 31 Aug 2000 13:32:11 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA49680; Thu, 31 Aug 2000 13:32:07 -0400 Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id NAA35562 for ; Thu, 31 Aug 2000 13:32:09 -0400 From: remoore@us.ibm.com Received: from d54mta02.raleigh.ibm.com (d54mta02.raleigh.ibm.com [9.67.228.34]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.93) with SMTP id NAA59724 for ; Thu, 31 Aug 2000 13:32:07 -0400 Received: by d54mta02.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 8525694C.00604FF2 ; Thu, 31 Aug 2000 13:31:59 -0400 X-Lotus-Fromdomain: IBMUS To: policy@raleigh.ibm.com Message-Id: <8525694C.00600D3E.00@d54mta02.raleigh.ibm.com> Date: Thu, 31 Aug 2000 13:30:07 -0400 Subject: Comments on QPIM-01 draft Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: remoore@us.ibm.com Since the end of August is upon us, here are some comments I have on the QPIM-01 draft. I hear from JohnS that the authors are working on a new version of the document, so some of these concerns may have already been addressed. But I'd like to get them onto the list now: 1. Showing its roots, the QPIM is still much more of a thinly veneered LDAP schema than it is a technology independent information model. For example: - There are *no* new associations defined in the QPIM. - Containment language still plays far too prominent a role in the QPIM. 2. The class QosPolicySimpleCondition is supposed to be a subclass of PolicyCondition (from PCIM), which places it under ManagedElement. But a subclass of ManagedElement can't have the object references that QosPolicySimpleCondition contains -- object references are allowed only in association classes. 3. Something's not quite right with the modeling of meters in QPIM. The parameters for a meter are modeled not in the meter object itself, and not even in an object directly related to the meter object. Instead, they're in a traffic profile object associated with an action object, which in turn is associated with the meter object. Since multiple action objects can be associated with a single meter (representing the fan-in of multiple traffic streams into that one meter), this opens up the possibility of having two incompatible traffic profiles governing the operation of a single meter. 4. The document says that constraints are modeled in QPIM, but I can't find any class to do this. 5. The qpValueTypes property appears to repeat the same information that's already expressed in the document in Table 3. (Aside: This table looks like one that will need to transition to IANA once QPIM is published as an RFC.) Why is this known information being repeated in every instance of qosPolicyVariable? 6. For the variable names "Application" and "User" (in Table 2), how does an implementation know where in the packet to look for the values? In other words, how does an implementation know how to go about evaluating a QosPolicySimpleCondition like "Application = LotusNotes" or "User = YoramSnir"? 7. Section 8.18 needs to say a lot more about how the object reference part of the reference to a property value works. (Like naming, object references are hard to discuss at the level of a technology-independent information model.) Once you've gotten to the right object, it's relatively easy to find the right value, given that you have both the attribute (property) name and the value. But QPIM needs to generalize the object reference explanation beyond the single example of an RSVP Identity. 8. The document says that it defines nesting of policy rules, but I can't find any definitions that actually do this. Regards, Bob Bob Moore IBM Networking Software +1-919-254-4436 remoore@us.ibm.com From majordomo@raleigh.ibm.com Thu Aug 31 14:00:04 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10760 for ; Thu, 31 Aug 2000 14:00:04 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id NAA28326; Thu, 31 Aug 2000 13:56:33 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id NAA35512; Thu, 31 Aug 2000 13:56:33 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA23698; Thu, 31 Aug 2000 13:39:03 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA49680; Thu, 31 Aug 2000 13:32:07 -0400 Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id NAA35562 for ; Thu, 31 Aug 2000 13:32:09 -0400 From: remoore@us.ibm.com Received: from d54mta02.raleigh.ibm.com (d54mta02.raleigh.ibm.com [9.67.228.34]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.93) with SMTP id NAA59724 for ; Thu, 31 Aug 2000 13:32:07 -0400 Received: by d54mta02.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 8525694C.00604FF2 ; Thu, 31 Aug 2000 13:31:59 -0400 X-Lotus-Fromdomain: IBMUS To: policy@raleigh.ibm.com Message-Id: <8525694C.00600D3E.00@d54mta02.raleigh.ibm.com> Date: Thu, 31 Aug 2000 13:30:07 -0400 Subject: Comments on QPIM-01 draft Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: remoore@us.ibm.com Since the end of August is upon us, here are some comments I have on the QPIM-01 draft. I hear from JohnS that the authors are working on a new version of the document, so some of these concerns may have already been addressed. But I'd like to get them onto the list now: 1. Showing its roots, the QPIM is still much more of a thinly veneered LDAP schema than it is a technology independent information model. For example: - There are *no* new associations defined in the QPIM. - Containment language still plays far too prominent a role in the QPIM. 2. The class QosPolicySimpleCondition is supposed to be a subclass of PolicyCondition (from PCIM), which places it under ManagedElement. But a subclass of ManagedElement can't have the object references that QosPolicySimpleCondition contains -- object references are allowed only in association classes. 3. Something's not quite right with the modeling of meters in QPIM. The parameters for a meter are modeled not in the meter object itself, and not even in an object directly related to the meter object. Instead, they're in a traffic profile object associated with an action object, which in turn is associated with the meter object. Since multiple action objects can be associated with a single meter (representing the fan-in of multiple traffic streams into that one meter), this opens up the possibility of having two incompatible traffic profiles governing the operation of a single meter. 4. The document says that constraints are modeled in QPIM, but I can't find any class to do this. 5. The qpValueTypes property appears to repeat the same information that's already expressed in the document in Table 3. (Aside: This table looks like one that will need to transition to IANA once QPIM is published as an RFC.) Why is this known information being repeated in every instance of qosPolicyVariable? 6. For the variable names "Application" and "User" (in Table 2), how does an implementation know where in the packet to look for the values? In other words, how does an implementation know how to go about evaluating a QosPolicySimpleCondition like "Application = LotusNotes" or "User = YoramSnir"? 7. Section 8.18 needs to say a lot more about how the object reference part of the reference to a property value works. (Like naming, object references are hard to discuss at the level of a technology-independent information model.) Once you've gotten to the right object, it's relatively easy to find the right value, given that you have both the attribute (property) name and the value. But QPIM needs to generalize the object reference explanation beyond the single example of an RSVP Identity. 8. The document says that it defines nesting of policy rules, but I can't find any definitions that actually do this. Regards, Bob Bob Moore IBM Networking Software +1-919-254-4436 remoore@us.ibm.com From majordomo@raleigh.ibm.com Thu Aug 31 14:39:24 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11397 for ; Thu, 31 Aug 2000 14:39:23 -0400 (EDT) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA23100; Thu, 31 Aug 2000 14:36:40 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id OAA36386; Thu, 31 Aug 2000 14:36:39 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA29662; Thu, 31 Aug 2000 14:15:04 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA49062; Thu, 31 Aug 2000 14:14:57 -0400 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id OAA36300 for ; Thu, 31 Aug 2000 14:14:59 -0400 Received: from relay1.acec.com (relay1.acec.com [38.249.211.2]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA25662 for ; Thu, 31 Aug 2000 14:13:07 -0400 Received: from bnatale.acecomm.com (bnatale.acec.com [192.152.208.143]) by relay1.acec.com (8.9.3/8.9.3) with ESMTP id OAA14041; Thu, 31 Aug 2000 14:00:25 -0400 (EDT) Message-Id: <4.3.2.7.2.20000831135939.0202e108@plymouth.acec.com> X-Sender: bnatale@plymouth.acec.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 31 Aug 2000 14:02:41 -0400 To: Jon Saperia From: Bob Natale Subject: Re: Policy Terminology Draft Cc: policy@raleigh.ibm.com In-Reply-To: References: <4.3.2.7.2.20000830145201.01fdc058@plymouth.acec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Bob Natale At 8/31/2000:07:22 AM, Jon Saperia wrote: Hi Jon, >Could we use 'conversion' as opposed to translation to refer to the task of >changing a policy at whatever level of abstraction to a protocol specific >form. This may not always be obvious or algorithmic. Sounds good to me...your final sentence there rules out "mapping" in my view (as much as I wish we could do mappings!) and "conversion" seems better suited (i.e., somewhat more predictable) than "translation". Cordially, BobN ------------ ISO 9001 Registered Quality Supplier ----------- Bob Natale | ACE*COMM | 301-721-3000 [v] Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] bnatale@acecomm.com| Gaithersburg MD 20878 | www.acecomm.com ------------- Free downloads at www.winsnmp.com -------------