Subject: [Diffserv] Framework PIB

From: "Iliff, Tina" <[email-masked]>
Date: Wed, 20 Sep 2000 16:14:07 +0000

Just a couple of questions regarding the Framework PIB-01:
1.  Section 3.1.1.; pg. 4, last para:  Would it not be more efficient to
incorporate a mechanism where the PDP comapres the applicability of
currently installed policy to the PEP-provided data on the new interface to
determine if any of the currently installed policies are applicable?  If a
policy is applicable, then it can grab the PRIDs from the PIBIncarnation
instance and just send the PRID.  In this case the PEP would need to be
allowed to configure policy on the new interface using currently installed
policy with the PRID as a reference.
2.  Page 11;  frwkPrcSupportmaxPris:  Would it be useful to indicate that
this attribute value be calculated using the currently available resources?
This method may not be 100% accurate but it would provide a more dependable
value.
3.  Page 13;  frwkPibIncarnationLongetivity/expireOnTimeout:  Should the PEP
immediately send a client-open (OPN) to reconnect when it has timed out?
4.  Page 14;  frwkPibIncarnationActive:  Does this imply that the PRIs in
the DEC message that is returned by the PDP becomes active?
5.  frwkCompLimitsSubType/extendsOid:  What if the PRC is part of another
PIB definition (i.e. the PIB may physically reside on another box)....would
the PEP send the REQ to multiple PDPs and both PDPs send applicable PRIs
within their DECs and ensure that there PRIs do not overlap in any way?
6.  frwkIpFilter class:  What about specifying filters for other traffic;
e.g. IPX, AppleTalk, etc?
7.  frwk802Filter class:  This is good..this can also apply to wireless
traffic (e.g. IEEE 802.11 traffic).
8.  frwk802Filter class:  What about filtering based on parameters such as
packet size, security, encrypted/non-encrypted, SMTP/MIME attributes, etc?

Thank you,
Tina Iliff
(972)729-1620
MCIWorldCom ENSD