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

From: "Robert Moore" <[email-masked]>
Date: Tue, 20 Nov 2001 09:43:42 -0500

From the very beginning, capabilities have been included
among the possible values of policy roles.  Search, for
example, on "Ethernet" in RFC 3060.  I think that
PolTerm is referring to the administrator's role(:-) in
deciding to *use* "Ethernet" as a selector for associating
policy rules with the resources to which they apply.

Regards,
Bob

Bob Moore
Advanced Design and Technology
Application Integration Middleware Division
IBM Software Group
+1-919-254-4436
[email-masked]

                    "Da Silva,                                                                
                    Pedro"                 To:     "[email-masked]'" <[email-masked]>  
                    <pdasilva@orches       cc:                                                
                    tream.com>             Subject:     RE: [Diffserv] diffserv-pib-05        
                    Sent by:                comments [sic]                                    
                    diffserv-admin@i                                                          
                    etf.org                                                                   

                    11/20/01 07:46                                                            
                    AM                                                                        

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]

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:
>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:
>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:
>>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:
>>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 --
>>
>>
>>
>>
>>
>>At 03:22 PM 11/15/01 +0000, Da Silva, Pedro wrote:
>>>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?
>>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.
>>
>>
>>
>>
>>
>>>Pedro
>>>
>>>
>>>
>>>
>>>
>>>_______________________________________________
>>>diffserv mailing list
>>>[email-masked]
>>>https://www1.ietf.org/mailman/listinfo/diffserv
>>>Archive:
>>>http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillis

t.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.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.html

---

From: "Andrea Westerinen" <[email-masked]>
Date: Tue, 20 Nov 2001 10:53:48 -0800

Bob and John stated the positions of PolTerm very well.  PolTerm was meant
to provide general definitions and assumed that they could be restricted in
specific problem domains.  Where usages did contradict, we worked with the
teams to resolve the issues and come up with a consistent definition.

So, PolTerm's "managed element" is any element that is managed (including
interfaces).  And,  PolTerm's "administratively defined" is meant to convey
anything of interest to an administrator - "Fast", "Slow", "Expensive",
"Edge", "Ethernet", "VLAN capable", ...

Andrea
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf
Of Robert Moore
Sent: Tuesday, November 20, 2001 6:44 AM
To: Da Silva, Pedro
Cc: [email-masked]'; [email-masked]
Subject: RE: [Diffserv] diffserv-pib-05 comments [sic]

Regards,
Bob

Bob Moore

                    "Da Silva,
                    Pedro"                 To:     "[email-masked]'"
<[email-masked]>
                    <pdasilva@orches       cc:
                    tream.com>             Subject:     RE: [Diffserv]
diffserv-pib-05
                    Sent by:                comments [sic]
                    diffserv-admin@i
                    etf.org

                    11/20/01 07:46
                    AM

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

question.
the

together

t.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.h
tml