Subject: [Diffserv] diffserv-pib-05 comments [sic]

From: "Da Silva, Pedro" <[email-masked]>
Date: Thu, 15 Nov 2001 16:24:12 -0000

The capability tables (e.g. qosIfMeteringCapsTable) have a UNIQUENESS clause
that includes the capability spec itself (as well as the direction from the
base class). This means that a user may specify more than one capability set
in one given direction, which in turn entails more work for the entity
managing and checking capabilities specs per se and capabilities specs
against policies.
Shouldn't the UNIQUENESS clause be restricted to the direction?

Pedro

-----Original Message-----
From: Kwok-Ho Chan [mailto:[email-masked]]
Sent: Monday, November 12, 2001 5:00 PM
To: Brian E Carpenter
Cc: Diff Serv
Subject: Re: [Diffserv] Re: WG Last Call for
draft-ietf-diffserv-pib-05.txt

Brian:
I will add the additional text for items 1 and 2.
Will let the IPR URLs be supplied by its owner.
-- Kwok --

At 05:29 PM 11/12/01 +0100, Brian E Carpenter wrote:
>Here are my own Last Call comments
>
>1. There is no Abstract; this is required for the RFC version.
>
>2. The ISOC Copyright text and the IETF intellectual property
>text are missing. Since there *is* a reference (section 12) to
>IPR claims, this text is needed.
>
>In relation to the latter, could somebody send the URLs for
>the relevant IPR claims?
>
>Thanks
>    Brian
>
>Brian E Carpenter wrote:
> >
> > It is proposed to forward draft-ietf-diffserv-pib-05.txt
> > to the IESG for publication as a Proposed Standard.
> >
> > Any final working group comments should be sent
> > to this list by November 26, 2001.
> >
> > Regards
> >    Brian Carpenter
> >    Kathie Nichols
> >    diffserv WG co-chairs
> >
> > -------- Original Message --------
> > Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-pib-05.txt
> > Date: Mon, 12 Nov 2001 07:03:18 -0500
> > From: [email-masked]
> > Reply-To: [email-masked]
> > To: IETF-Announce: ;
> > CC: [email-masked]
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> > This draft is a work item of the Differentiated Services Working Group 
> of the IETF.
> >
> >         Title           : Differentiated Services Quality of Service
Policy
> >                           Information Base
> >         Author(s)       : M. Fine, K. McCloghrie et al.
> >         Filename        : draft-ietf-diffserv-pib-05.txt
> >         Pages           : 95
> >         Date            : 09-Nov-01
> >
> > [SPPI] describes a structure for specifying policy information that
> > can then be transmitted to a network device for the purpose of
> > configuring policy at that device.  The model underlying this
> > structure is one of well-defined policy rule classes and instances
> > of these classes residing in a virtual information store called the
> > Policy Information Base (PIB).
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-diffserv-pib-05.txt
>
>_______________________________________________
>diffserv mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/diffserv
>Archive: 
>http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.
html

_______________________________________________
diffserv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/diffserv
Archive:
http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h
tml

_______________________________________________
diffserv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

---

From: "Kwok-Ho Chan" <[email-masked]>
Date: Thu, 15 Nov 2001 15:02:33 -0500

Pedro:
Thank you for your comments.  Please see response below.
I believe you have sent the same comments again on the list.
I will skip the duplicate.  Please let me know if it is not duplicate.
Thanks!
-- Kwok --

>Shouldn't the UNIQUENESS clause be restricted to the direction?

No, I think the UNIQUENESS clause is correct as is.  We do want to
allow 2 or more entries in the qosIfMeteringCapsTable for the same direction,
each one having different capabilities.  This allows the device to have 
more than
one different types of meter, may be for more than one kind of interface type.

The specific data path using the different types of meter is specified by
frwkIfCapSetTable entries provided by the Framework PIB -06 at
  http://www.ietf.org/internet-drafts/draft-ietf-rap-frameworkpib-06.txt

I hope inspecting the qosIfMeteringCapsTable and frwkIfCapSetTable together
will clarify the concerns you expressed.
Please let me know if more explanation is needed.

>http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

---

From: "Da Silva, Pedro" <[email-masked]>
Date: Fri, 16 Nov 2001 10:58:18 -0000

I thought the table was instantiated per interface type and not for all of
the interfaces types, thus the confusion.
Therefore it does make sense to have the caps specs in the uniqueness
clause.
 
Pedro

-----Original Message-----
From: Kwok-Ho Chan [mailto:[email-masked]]
Sent: Thursday, November 15, 2001 8:03 PM
To: Da Silva, Pedro
Cc: [email-masked]'; Kwok-Ho Chan
Subject: Re: [Diffserv] diffserv-pib-05 comments [sic]

Pedro:

No, I think the UNIQUENESS clause is correct as is.  We do want to
allow 2 or more entries in the qosIfMeteringCapsTable for the same
direction,
each one having different capabilities.  This allows the device to have more
than
one different types of meter, may be for more than one kind of interface
type.

The specific data path using the different types of meter is specified by
frwkIfCapSetTable entries provided by the Framework PIB -06 at
   <http://www.ietf.org/internet-drafts/draft-ietf-rap-frameworkpib-06.txt>
http://www.ietf.org/internet-drafts/draft-ietf-rap-frameworkpib-06. txt
<http://www.ietf.org/internet-drafts/draft-ietf-rap-frameworkpib-06.txt> 

Pedro

_______________________________________________
diffserv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/diffserv
<https://www1.ietf.org/mailman/listinfo/diffserv> 
Archive:
http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h
tml
<http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.
html>

---

From: "Kwok-Ho Chan" <[email-masked]>
Date: Fri, 16 Nov 2001 09:00:10 -0500

Pedro:
Thanks for raising the issue.
If there is confusion, then I will improve the text.
Please don't hesitate to raise any concerns.
We need to fix them now before Last Call is done.
Thanks!
-- Kwok --

At 10:58 AM 11/16/01 +0000, Da Silva, Pedro wrote:
>Therefore it does make sense to have the caps specs in the uniqueness clause.
>
>Pedro

---

From: "Da Silva, Pedro" <[email-masked]>
Date: Mon, 19 Nov 2001 13:13:06 -0000

I do have a concern about how the DiffServ PIB fits in the Policy WG
drafts-stds
 
In the Policy WG we have [managed element]--[role]--[policy] relationships,
where role is 'an administratively specified characteristic of a managed
element'. QPIM goes further to say that 'The use of roles for mapping policy
to network elements provides an efficient and simple method for compact and
abstract policy definition. A given abstract policy may be mapped to a group
of network elements without the need to specify configuration for each of
those elements based on the capabilities of any one individual element.'
 
On the other hand, in the DiffServ PIB we have
[interface]--[userRole+capabilityName+direction]--[policy]
The DS PIB has a policy selector that is more than just a role and includes
what QPIM explicitly excludes, capability specs.
 
So the semantics of roles are different between the two. And the concept of
'managed element' has been limited to being an interface in the DiffServ PIB
whereas the Policy WG drafts-stds imply that it could be more than
interfaces.
 
There is no specific question, it's more of a 'what do you think?' question.
 
Pedro
 
 -----Original Message-----
From: Kwok-Ho Chan [mailto:[email-masked]]
Sent: Friday, November 16, 2001 2:00 PM
To: Da Silva, Pedro
Cc: [email-masked]'
Subject: RE: [Diffserv] diffserv-pib-05 comments [sic]

Pedro:

 
Pedro 

-----Original Message----- 

From: Kwok-Ho Chan [ mailto:[email-masked]
<mailto:[email-masked]> ] 

To: Da Silva, Pedro 

Pedro: 

Thanks! 

-- Kwok --

against policies. 

Pedro

diffserv mailing list 

[email-masked] 

Archive:

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 19 Nov 2001 09:40:59 -0500

PIBs are a mechanism to describe policy.  They can be thought of as a data 
model or as a policy implementation technology.  Policy Framework work is 
an information model.  As such, one expects some change of details when one 
maps between them.  The QPIM/ / QDDIM work is carefully designed to be able 
to represent DiffServ requirements.  The Diffserv PIB is carefully designed 
to represent not just the abstract policy needs, but the details of 
DiffServ delivery.  The two are not identical, and are not expected to be 
identical./  The difference in "role" is the difference in the policy 
concept of role and the COPS implementation of role.  The differences are 
actually very minor.

Yours,
Joel M. Halpern

At 01:13 PM 11/19/01 +0000, Da Silva, Pedro wrote:
>In the Policy WG we have [managed element]--[role]--[policy] 
>relationships, where role is 'an administratively specified characteristic 
>of a managed element'. QPIM goes further to say that 'The use of roles for 
>mapping policy to network elements provides an efficient and simple method 
>for compact and abstract policy definition. A given abstract policy may be 
>mapped to a group of network elements without the need to specify 
>configuration for each of those elements based on the capabilities of any 
>one individual element.'
>
>The DS PIB has a policy selector that is more than just a role and 
>includes what QPIM explicitly excludes, capability specs.
>
>So the semantics of roles are different between the two. And the concept 
>of 'managed element' has been limited to being an interface in the 
>DiffServ PIB whereas the Policy WG drafts-stds imply that it could be more 
>than interfaces.
>
>>I thought the table was instantiated per interface type and not for all 
>>of the interfaces types, thus the confusion.

---

From: "Da Silva, Pedro" <[email-masked]>
Date: Tue, 20 Nov 2001 12:46:32 -0000

Sure we're talking about different abstraction levels but the definition in
the terminology draft specifically excludes any concretizations in data
models (e.g. the one in the diffserv PIB) from having non-administratively
assigned aspects to them ("Role(3): An administratively specified
characteristic of a managed element").
I believe that the diffserv pib is a good example of roles that have
non-administratively assigned elements being a Good Thing: I was wondering
what the general feeling about relaxing the definition in the terminology
draft is...

cheers,
Pedro

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]]
Sent: Monday, November 19, 2001 2:41 PM
To: Da Silva, Pedro; [email-masked]'
Subject: RE: [Diffserv] diffserv-pib-05 comments [sic]

Yours,
Joel M. Halpern