[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comments on draft-ietf-rap-frameworkpib-02
>>>>> Sahita, Ravi writes:
js> 3. I am wondering what happens if multiple wildcarded roles match a
js> given interface.
Ravi> If multiple policies can be assigned to an interface due to more
Ravi> than one wildcarded role combo matching a given interface's role
Ravi> combo string then the PDP should be notified about the
Ravi> ambiguity, so that the administrator can control what is
Ravi> actually sent to the PEP.
Is this documented somewhere? If not, can you add text to the document
which explains how a PEP should react in this case?
js> 5. The PIB module uses Role and RoleCombination from
js> POLICY-DEVICE-AUX-MIB. There are several problems with this. First,
js> I think that the Role and RoleCombination concept is so fundamental
js> that these two TCs deserve to be defined in the COPS-PR-SPPI-TC or
js> the FRAMEWORK-PIB module, especially since the textual explanation
js> is already in the FRAMEWORK-PIB module. If folks prefer to have the
js> Role and RoleCombination definition in POLICY-DEVICE-AUX-MIB, then
js> I would say that the FRAMEWORK-PIB depends on the
js> POLICY-DEVICE-AUX-MIB and thus we need to move the
js> POLICY-DEVICE-AUX-MIB also into last call so that all 3 documents
js> can proceed together. Note also that Role is currently not used in
js> the FRAMEWORK-PIB.
Ravi> The TCs can be moved, but can MIBs import TCs defined in PIBs?
I think that a MIB can not import a TC from a PIB (since the SPPI TC
mechanism is different from the SMIv2 TC mechanism). However, a MIB
can import a TC from a MIB which was converted from a PIB using the
translation rules. Of course, this leaves the interesting question
open whether you can import a TC from a MIB module which was only
published as a PIB module or whether the converted MIB has to be
available as well. I guess the IESG will have fun with this one.
js> 12. I am wondering what am implementation should report in
js> frwkDeviceIdMaxMsg and frwkDeviceIdMaxContexts if it is capable to
js> dynamically allocate contexts and message buffers.
Ravi> This is added as additional error-avoidance mechanisms to let
Ravi> the administrators have the ability to control the number of
Ravi> contexts on the device and the message size of messages sent to
Ravi> the device. The device can send NULL for these attributes if
Ravi> they are not to be specified.
You are saying that such an implementation simply does not implement
these attributes, right? Can you add text which explicitely says this
so that implementors all do the same?
js> 17. I have no clue what the following sentence in the description
js> of frwkCompLimitsSubType tries to tell me:
js> A value of 'extendsOid(10)' means that the guidance attribute
js> provides data related to a PRC that AUGMENTS or EXTENDS the
js> identified policy class."
js> Can you be more specific what this enumerated value does?
Ravi> John Seligson's reply on 7/15/00 when I had asked him a similar
Ravi> question: The purpose of this subtype is to indicate to the
Ravi> policy server/NMS the presence of classes that AUGMENT or EXTEND
Ravi> the base class identified by the guidance attribute value. This
Ravi> is intended to inform the administrator of additional classes
Ravi> they may not know about. This is particularly useful with vendor
Ravi> proprietary extensions that augment standard tables with the
Ravi> goal being that, given the additional guidance (i.e., "here are
Ravi> some new useful attributes you may want to use"), a new PIB/MIB
Ravi> with the augments can be loaded to enhance functionality. The
Ravi> hope is that this can facilitate building more intelligent
Ravi> policy servers/NMSs.
Ravi> maybe the enum should be called - isExtendedBy(10), since the
Ravi> PEP is reporting info about PRCs IN the PIB that the PDP knows
Ravi> about (it hasnt yet loaded info about the extension PRCs) and
Ravi> when the PDP receives this complimit for a PRC X (stating PRC X
Ravi> isExtendedBy Guidance(PRC X'), it looks at the guidance and now
Ravi> knows that it will receive or can send info for PRC X' (which it
Ravi> can now load)?
Calling the enum isExtendedBy(10) definitely helps. But you should
IMHO also add some of the text above to better explain the issue.
js> 18. I am wondering how enum limits reported by a device interact
js> with the PIB revisions. To be safe on the safe side, an
js> implementation probably needs to report all supported enums in the
js> frwkCompLimitsTable or am I missing something here?
Ravi> The device optionally reports any enums it support- this is also
Ravi> to proactively avoid errors during policy deployment. -
Ravi> Regarding PIB revisions, if a PEP supports a older revision of
Ravi> an enum type attribute, and it receives a new enum type in the
Ravi> decision from the PDP which supports a new rev, the PEP should
Ravi> report an error - (this is documented in COPS-PR), This wouldnt
Ravi> happen if the PEP had reported the range in the complimits for
Ravi> the attribute - So, you are correct when you say that the pep
Ravi> needs to report all supported enums when different versions
Ravi> exist to avoid errors due to the enum attribute.
Should the document not give a hint about this so that implementors
correctly report all enums they support?
js> 19. The size restriction of frwkCompLimitsGuidance seems
js> arbitrary. Note that an OID can have 128 subidentifier and thus the
js> worst case length for an OID would be 512 octets. But even using
js> 0..512 would not work in all cases for OCTET STRINGs.
Ravi> can the size restriction be removed?
I would say yes. In fact, I think you can use the framework pib to
report the implemented size limit of this object if you can't support
the 64k limit imposed by the SPPI. ;-)
js> 23. It is unclear to me under which conditions the install-errors
js> invalidDstL4PortData and invalidSrcL4PortData are generated.
Ravi> If the filters installed have values for L4port attributes which
Ravi> the pep does not wish to support. (and the pep sent its comp
Ravi> limits for those attributes in the request - which the pdp
Hm - what is so special about port numbers? Why can I reject some port
numbers I dislike and not any other stuff in a filter I dislike?
js> 24. I suggest to use Inter32 instead of INTEGER in the definition
js> of frwkIpFilterProtocol, frwkIpFilterDstL4PortMin,
js> frwkIpFilterDstL4PortMax, frwkIpFilterSrcL4PortMin, and
Ravi> I had a question here: why do you want to use Integer32?
Purely stylistic. My personal recommendation is to use INTEGER only
for enumerated numbers and to use Integer32, Unsigned32, et.al. for
the all other numbers.
js> 25. Would it not make sense to globally replace
js> `frwkFilterGroupDefn' with `frwkFilterGroup'? What does the Defn
js> stand for?
Ravi> Defn=Definition, it was shortened as the attribute names became
Ravi> too long. and it was named so as it defines Filter Groups using
Ravi> the group semantics - it can be changed to frwkFilterGroupTable
I would prefer frwkFilterGroupTable etc.
js> 26. In the security section, we have the following two statements:
js> Even if the network itself is secure (for example by using IPSec),
js> there is no control as to who on the secure network is allowed to
js> "Install/Notify" (read/change/create/delete) the PRIs in this PIB.
js> The use of IPSEC between the PDP and the PEP, as described in
js> [COPS], provides the necessary protection against security threats.
js> Are these statements really consistent with each other? The problem
js> here is perhaps that the interpretation of "security threats" is
js> unclear and so it depends on the reader's view whether the lack of
js> access control is an issue or not.
Ravi> maybe that should be stated like this: The use of IPSEC between
Ravi> the PDP and the PEP, as described in [COPS], provides the
Ravi> necessary protection against security threats. However, even if
Ravi> the network itself is secure, there is no control as to who on
Ravi> the secure network is allowed to "Install/Notify"
Ravi> (read/change/create/delete) the PRIs in this PIB.
This reads much better I think.
Juergen Schoenwaelder Technical University Braunschweig
<email@example.com> Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax: +49 531 391 5936 <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>