RE: frameworkpib-06 comments [sic]

["Da Silva, Pedro" <pdasilva@orchestream.com>]

The frwkIfRoleCombo table is actually used to associate indices with
role-combos and caps name. But that's beside the point.
You're saying that for devices (e.g. Junipers which use names to identify
its interfaces) that do not use IfIndices then one would not use this table
to configure them. This is an argument against having such a table at
framework level.
I'm saying this PIB is supposed to be the common ground.
I'm proposing that the frwkIfRoleCombo table have an index but not in the
sense of a MIB IfIndex (as the doc says in pg 3 'The SNMP experience with
ifIndex has proved this to be a difficult task'). Why not a Prid to a
generic target? Then in the domain-specific PIB you define a table that
determines what those prids actually represent.

So at framework level:

FrwkTargetRoleComboEntry ::= SEQUENCE { 
           frwkTargetRoleComboPrid         InstanceId, 
           frwkTargetRoleComboTarget       Prid, 
           frwkTargetRoleComboRoles        RoleCombination, 
           frwkTargetRoleComboCapSetName   SnmpAdminString 
   } 

frwkTargetRoleComboTarget OBJECT-TYPE 
       SYNTAX         Prid 
       STATUS         current 
       DESCRIPTION 
           "The complete PRC OID and instance identifier specifying the    
           target PRC instance."

In the domain specific pib, for instance DiffServ PIB, strictly following
the Informal model:

qosTargetTable OBJECT-TYPE 
    SYNTAX         SEQUENCE OF QosTargetEntry
    PIB-ACCESS     notify 
    STATUS         current 
    DESCRIPTION 
        "This table specifies targets on the device" 
    
qosTargetEntry OBJECT-TYPE 
    SYNTAX         QosTargetEntry
    STATUS         current 
    DESCRIPTION 
        "An instance of this class describes a target 
        on the device." 
    
QosTargetEntry ::= SEQUENCE { 
    qosTargetPrid             InstanceId, 
    qosTargetName             Unsigned32, 
    qosTargetDirection        IfDirection 
   } 

qosTargetPrid OBJECT-TYPE 
    SYNTAX         InstanceId 
    STATUS         current 
    DESCRIPTION 
        "An arbitrary integer index that uniquely identifies a 
        instance of the class." 
    
qosTargetName OBJECT-TYPE 
    SYNTAX         SnmpAdminString 
    STATUS         current 
    DESCRIPTION 
        "The name or label for the physical interface 
        (e.g. 'FastEthernet3/0')." 
    
qosTargetDirection OBJECT-TYPE 
    SYNTAX      IfDirection 
    STATUS      current 
    DESCRIPTION 
        "Specifies the target direction"

The focus here is on the framework pib, so the qosTargetTable is a rough
example.

Pedro

-----Original Message-----
From: Sahita, Ravi [mailto:ravi.sahita@intel.com]
Sent: Friday, November 16, 2001 12:02 AM
To: 'Da Silva, Pedro'; rap@ops.ietf.org
Subject: RE: frameworkpib-06 comments


Pedro,

The frwkIfRoleCombo table is only used to associate 
ifIndices on network devices with role-combinations. 
The actual policy targetting table would be in a domain-specific 
PIB (for example the qosDataPathTable in the diffserv PIB).

Note that in a hypothetical toaster PIB you can always 
define your own targetting table that contains SlotX,
role-combination, and you would'nt use the ifRoleComboTable
since in that case you would'nt need that association.

Ravi

>  -----Original Message-----
>  From: Da Silva, Pedro [mailto:pdasilva@orchestream.com]
>  Sent: Thursday, November 15, 2001 7:00 AM
>  To: rap@ops.ietf.org
>  Subject: frameworkpib-06 comments
>  
>  
>  The scope of the document is to 'define a set of PRCs and textual
>  conventions that are common to all clients...'. Having a table that
>  determines a target via the ifIndex limits the applicability of the
>  framework pib across client types.
>  
>  Shouldn't the frwkIfRoleComboTable table be more generic? 
>  The frwk PIB could
>  define PRCs that constitute a base on which each client type 
>  is able to
>  specify its particular target, be it an IfIndex+direction on 
>  a router or
>  slotX on a toaster.
>  
>  Pedro
>  
>  
>  
>  
>  --
>  This communication contains confidential information 
>  intended solely for the use of the individual/s and/or 
>  entity or entities to whom it was intended to be addressed.  
>  If you are not the intended recipient, be aware that any 
>  disclosure, copying, distribution, or use of the contents of 
>  this transmission is prohibited.  If you have received this 
>  communication in error, please contact the sender 
>  immediately, delete this communication from your system, and 
>  do not disclose its contents to any third party, or use its 
>  contents.  Any opinions expressed are solely those of the 
>  author and do not necessarily represent those of Orchestream 
>  Ltd or its group of companies unless otherwise specifically stated.
>