comments on draft-ietf-rap-frameworkpib-02

[Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de>]

I am resending my last comments on draft-ietf-rap-frameworkpib-02.txt
because they may have got lost when the mailing list was moved to a
new home.

 1. I would like to have more text in section 3.1 about the legal
    characters in roles and role combinations. I guess that both '*'
    and '+' may not be used in a role string. But are there any other
    restrictions?

 2. In the example in section 3.1, please change IfDscp... to
    ifDscp... since a descriptor for an attribute must be lowercase.

 3. I am wondering what happens if multiple wildcarded roles match a
    given interface.

 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.

 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.

 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.

 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?

 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.

12. I am wondering what am implementation should report in
    frwkDeviceIdMaxMsg and frwkDeviceIdMaxContexts if it is capable to
    dynamically allocate contexts and message buffers.

13. Similarily to item 7: What precisely is the OID for a PRC in the
    definition of frwkCompLimitsComponent?

14. frwkCompLimitsType is of type Integer32. Does this mean that error
    codes are signed?

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)'.

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?

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?

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.

20. You should say that numbers are encoded in network byte order.

21. It is unclear to me why you need to encode the length at all in
    frwkCompLimitsGuidance.

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.

23. It is unclear to me under which conditions the install-errors
    invalidDstL4PortData and invalidSrcL4PortData are generated.

24. I suggest to use Inter32 instead of INTEGER in the definition of
    frwkIpFilterProtocol, frwkIpFilterDstL4PortMin,
    frwkIpFilterDstL4PortMax, frwkIpFilterSrcL4PortMin, and
    frwkIpFilterSrcL4PortMax.

25. Would it not make sense to globally replace `frwkFilterGroupDefn'
    with `frwkFilterGroup'? What does the Defn stand for?

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.

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).

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<schoenw@ibr.cs.tu-bs.de>  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/>