Regarding comment&comment response #18 below:
Well, shouldn't the frwkPrcSupported table provide the mechanism for the device to report all component types (PRCs and attributes) which it supports?
#24: I suggest using unsigned32
#26: Are you trying to state that "user level" and "hostname level" security is not provided. In other words user&host roles and policies are not provided?
Tina Iliff
MCIWorldCom ENSD
(972)729-1620
-----Original Message-----
From: Sahita, Ravi [mailto:ravi.sahita@intel.com]
Sent: Tuesday, October 10, 2000 8:54 PM
To: 'Juergen Schoenwaelder'; rap@ops.ietf.org
Subject: Re: comments on draft-ietf-rap-frameworkpib-02
The easier changes to the following have been made:
2. In the example in section 3.1, please change IfDscp... to
ifDscp... since a descriptor for an attribute must be lowercase.
4. The IMPORTS clause in the PIB module needs serious work. First,
you should import OBJECT-GROUP and TEXTUAL-CONVENTION from
COPS-PR-SPPI. Also note that TEXTUAL-CONVENTION is not used right
now.
8. I suggest to add UNITS "seconds" to the definition of
frwkPibIncarnationTtl.
9. The size restriction for SnmpAdminString in the definition of
frwkDeviceIdDescr is not needed since SnmpAdminString is already
limited to size 0..255 in the SNMP-FRAMEWORK-MIB.
10. I suggest to add UNITS "octets" to the definition of
frwkDeviceIdMaxMsg.
11. I suggest to add UNITS "contexts" to the definition of
frwkDeviceIdMaxContexts.
15. In the description of frwkCompLimitsType, please change DscpMapEntry
to dscpMapEntry since it can't start with an uppercase character.
16. In the description of frwkCompLimitsSubType, please change
'enumMin(7)' to 'enumMax(7)'.
20. You should say that numbers are encoded in network byte order.
22. I found the definition of the frwkDeviceCapClasses confusing since
it was not clear to me from reading these two documents where
capability PRCs are defined. Perhaps some more introductionary
text could help.
27. I think there should be additional references added for things
that are used by this document, such as RFC 2571, RFC 2851, the
relevant IEEE 802 standards, the Role/RoleCombination definition
(if it is not moved into some other document).
The other comments:
> 3. I am wondering what happens if multiple wildcarded roles match a
> given interface.
Ravi>If multiple policies can be assigned to an interface due to
more than one wildcarded role combo matching a given interface's role
combo string then the PDP should be notified about the ambiguity,
so that the administrator can control what is actually sent to the PEP.
> 5. The PIB module uses Role and RoleCombination from
> POLICY-DEVICE-AUX-MIB. There are several problems with
> this. First, I think that the Role and RoleCombination concept is
> so fundamental that these two TCs deserve to be defined in the
> COPS-PR-SPPI-TC or the FRAMEWORK-PIB module, especially since the
> textual explanation is already in the FRAMEWORK-PIB module. If
> folks prefer to have the Role and RoleCombination definition in
> POLICY-DEVICE-AUX-MIB, then I would say that the FRAMEWORK-PIB
> depends on the POLICY-DEVICE-AUX-MIB and thus we need to move the
> POLICY-DEVICE-AUX-MIB also into last call so that all 3 documents
> can proceed together.
> Note also that Role is currently not used in the FRAMEWORK-PIB.
Ravi>The TCs can be moved, but can MIBs import TCs defined in PIBs?
> 6. The PIB module uses PIB-ACCESS which defined OID subids for the
> SPPI->MIB conversion. Note that this is not necessary with the
> revised SPPI since there is now a default. You may want to use
> it.
Ravi> RowStatus place holders removed.
> 7. frwkPrcSupportSupportedPrc holds an OBJECT IDENTIFIER value of a
> supported PRC. Is this the OID of the table of the OID of the
> table entry node?
Ravi>OID of the table entry - added text.
> 12. I am wondering what am implementation should report in
> frwkDeviceIdMaxMsg and frwkDeviceIdMaxContexts if it is capable to
> dynamically allocate contexts and message buffers.
Ravi>
This is added as additional error-avoidance mechanisms to let the
administrators have the ability to control the number of contexts
on the device and the message size of messages sent to the device.
The device can send NULL for these attributes if they are not to
be specified.
> 13. Similarily to item 7: What precisely is the OID for a PRC in the
> definition of frwkCompLimitsComponent?
Ravi>the value is the OID for a table entry or a PRC attribute.
-added text.
> 14. frwkCompLimitsType is of type Integer32. Does this mean that error
> codes are signed?
Ravi>changed to Unsigned32.
> 17. I have no clue what the following sentence in the description of
> frwkCompLimitsSubType tries to tell me:
>
> A value of 'extendsOid(10)' means that the guidance
> attribute provides data related to a PRC that
> AUGMENTS or EXTENDS the identified policy class."
>
> Can you be more specific what this enumerated value does?
John Seligson's reply on 7/15/00 when I had asked him
a similar question:
The purpose of this subtype is to indicate to the
policy server/NMS the presence of classes that
AUGMENT or EXTEND the base class identified by the
guidance attribute value. This is intended to
inform the administrator of additional classes
they may not know about. This is particularly
useful with vendor proprietary extensions that
augment standard tables with the goal being that,
given the additional guidance (i.e., "here are
some new useful attributes you may want to use"),
a new PIB/MIB with the augments can be loaded
to enhance functionality. The hope is that this
can facilitate building more intelligent policy
servers/NMSs.
Ravi> maybe the enum should be called -
isExtendedBy(10), since the PEP is reporting
info about PRCs IN the PIB that the PDP knows
about (it hasnt yet loaded info about the extension PRCs)
and when the PDP receives this complimit for a PRC X
(stating PRC X isExtendedBy Guidance(PRC X'),
it looks at the guidance and now knows that it will
receive or can send info for PRC X' (which it can now load)?
> 18. I am wondering how enum limits reported by a device interact with
> the PIB revisions. To be safe on the safe side, an implementation
> probably needs to report all supported enums in the
> frwkCompLimitsTable or am I missing something here?
Ravi>The device optionally reports any enums it support-
this is also to proactively avoid errors during policy deployment.
- Regarding PIB revisions, if a PEP supports a older revision
of an enum type attribute, and it receives a new enum type in the
decision from the PDP which supports a new rev, the PEP should
report an error - (this is documented in COPS-PR), This
wouldnt happen if the PEP had reported the range in the
complimits for the attribute - So, you are correct when you
say that the pep needs to report all supported enums when different
versions exist to avoid errors due to the enum attribute.
> 19. The size restriction of frwkCompLimitsGuidance seems
> arbitrary. Note that an OID can have 128 subidentifier and thus
> the worst case length for an OID would be 512 octets. But even
> using 0..512 would not work in all cases for OCTET STRINGs.
Ravi> can the size restriction be removed?
> 21. It is unclear to me why you need to encode the length at all in
> frwkCompLimitsGuidance.
Ravi>yes, the OCTET STRING can be extracted from the encoding length,
and then it can be handled depending on the CompLimitBaseType.-corrected
> 23. It is unclear to me under which conditions the install-errors
> invalidDstL4PortData and invalidSrcL4PortData are generated.
Ravi>If the filters installed have values for L4port attributes which
the pep does not wish to support. (and the pep sent its comp limits
for those attributes in the request - which the pdp violated)
> 24. I suggest to use Inter32 instead of INTEGER in the definition of
> frwkIpFilterProtocol, frwkIpFilterDstL4PortMin,
> frwkIpFilterDstL4PortMax, frwkIpFilterSrcL4PortMin, and
> frwkIpFilterSrcL4PortMax.
Ravi>I had a question here: why do you want to use Integer32?
> 25. Would it not make sense to globally replace `frwkFilterGroupDefn'
> with `frwkFilterGroup'? What does the Defn stand for?
Ravi>Defn=Definition, it was shortened as the attribute names
became too long. and it was named so as it defines Filter Groups
using the group semantics -
it can be changed to frwkFilterGroupTable though.
> 26. In the security section, we have the following two statements:
>
> Even if the network itself is secure (for example by using
> IPSec), there is no control as to who on the secure network is
> allowed to "Install/Notify" (read/change/create/delete) the PRIs
> in this PIB.
>
> The use of IPSEC between the PDP and the PEP, as described in
> [COPS], provides the necessary protection against security
> threats.
>
> Are these statements really consistent with each other? The
> problem here is perhaps that the interpretation of "security
> threats" is unclear and so it depends on the reader's view
> whether the lack of access control is an issue or not.
Ravi>maybe that should be stated like this:
The use of IPSEC between the PDP and the PEP, as described in
[COPS], provides the necessary protection against security
threats. However, even if the network itself is secure, there
is no control as to who on the secure network is allowed to
"Install/Notify" (read/change/create/delete) the PRIs in this PIB.
Ravi