Subject: snmpconf Comments on BCP-09

From: "David T. Perkins" <[email-masked]>
Date: Wed, 26 Jun 2002 22:03:37 -0700

HI,

Here are some comments on the -09 version of the BCP.
Note, the document has been much improved from the 
-05 version that I last reviewed.

21-june-2002: dtp
Comments on draft-ietf-snmpconf-bcp-09.txt

1) the draft is significantly improved over the last version that
   I reviewed. Note that I did not previously review the
   policy or MIB module.

2) several places in the document are two spaces where a single
   space should be. Need to do a search, to find them and then
   fix the source document.

3) In section 1.2, the document states that the scale of networks
   has increased, but gives no examples. I suggest the following
   replacement text:

    Scale - Networks have more network elements, and the network
    elements are larger and place more demands on the systems
    managing them. For example, consider the typical number and
    speed of interfaces in a modern core network element.
    In 1990, a core router might have 4 network interfaces
    with two being 1.5m bits/sec WAN interfaces and the 
    other two being 10m bits/sec LAN interfaces. In 2002,
    a core route might have 128 1g bits/sec
    LAN interfaces and 64 155m bits/set WAN interfaces.
    A managed metropolitan area network switch can have a port
    density much greater than the port density built into the
    expectations of the management systems that predated it.
    There are  also many more interrelationships within and
    between devices and device functions.

4) The start of the third paragraph, change
    "Management Framework is used successfully" to
    "Management Framework has been used successfully"

5) the definition of "policy-based management (in middle of the
   second para before section 2) doesn't seem too different
   from non-policy-based management. I suggest that at least
   it be modified to include the phrase "rule-based", as
   shown by
    "...is a methodology where rule-based configuration
     information is distributed..."

6a) In section 3.3.1, para 5, second sentence is somewhat confusing,
   since it is telling you what is wrong, but not telling you
   what is correct.
 b) in point 2, the second sentence reads pretty awkwardly.

7) There are extra lines after section 3.3.2 section head before
   the section text.

8) In section 3.3.2, second para, the first sentence should be
   changed to the following:
     Fate sharing of SNMP table data should be explicitly defined
     where possible using the SMI index qualifier AUGMENTS.

9) section 3.4.2, last para, makes a point that DNS names used
   as an index don't create a potential problem. However, unless
   the DNS definitions have been changed, DNS names can be
   upto 128 chars (and maybe international char sets make this
   worse). A DNS name consisting of close to 128 octets used
   as an index would mean that the instance could not be specified.
   This has a higher probability of a problem when two DNS
   names are used in the index.
   
10) section 3.7, this discussion about persistence is not clear,
    and it does not reflect reality. That is, when and how
    "running" configuration is written to persistent storage
    is very dependent on the system. Writing a table with
    a "StorageType" object does not change the storage model
    implemented in a device. Note the setting the value to
    "nonVolatile" does not mean that the row will be written
    to persistent storage before the operation returns. Also,
    a implementation may not allow different rows to have different
    values StorageType.
    This section is important, but also different types of
    implementations have different models for managing
    persistence of configuration data. This needs to be made
    clear.    
     
11) Section 3.10.1, second sentence, the term "context" is used,
    but this sentence does not mean "SNMP contexts". Instead,
    of context, the phrase "SNMP parameters as found in
    table snmpTargetParmsTable from RFC 2573" should be used.
    
12a) Section 3.10.2, first para, first sentence, change "informs"
     to "notifications".
  b) Second para, first sentence, change "InformRequests" to
     "notifications".
  c) Third para should be removed since it is just nonsense.
  d) Fourth para, first sentence, change "of TRAP or InformRequest
     PDUs" to "notifications".

13) Section 3.11, second paragraph, use of term "incumbent"
    is not correct here. Not sure what is the main issue being
    addressed here. In general, a management application must
    understand the semantics of configuration (that is, the
    management app must know what is valid and what is not
    valid configuration settings) and only request configuration
    settings that are believed to be valid and will succeed,
    since the actual failure can not be determined from the
    protocol returned error code.
    
14) Section 3.11, 4th and 5th paras, these look like that
    they need to be combined.
    
15) Section 3.11, last paragraph is completely nonsensical.

16) Section 3.12, last para, reference to RFC 2591 is not correct.
    Note that RFC 2591 (section 6) is incorrect (or at least
    misleading) in its description that implies that VACM
    provides per user access control. VACM does not provide
    per user, but instead provides per group granularity.
    This makes a difference, and renders the last paragraph
    in section 3.12 pretty bogus.

17) Section 3.13.1, fourth para that starts with
    "These informational object types...". Change to
    "Such informational object types...".

18) Section 3.13.1, first para after definition of PortList TC.
    Change the last word of the sentence of the para from "reset"
    to "written".

19a) Section 3.13.2, para 4 implies that only the table
    entLogicalTable from the Entity MIB (RFC 2737) can be
    used to discover values of ContextNames. However, the
    table vacmContextTable from MIB module
    SNMP-VIEW-BASED-ACM-MIB (in RFC 2575) provides a list
    of ContextName values via object vacmContextName.
    While there is not a pointer to items such as
    entLogicalType (found in entLogicalTable), a management app
    can probe each context name value to determine objects
    for the context name value.
  b) Given an update to talk about table vacmContextTable,
     point #2 is incorrect. 
  c) the first para following the two points is nonsense.
     Taken at face value, both points are incorrect.

20a) Section 4.2. This topic has already been covered. It is
    incorrectly in the "agent implementation" section, since
    it has nothing to do with agent design.
  b) in the third para, the phrase "an inform" should be
     replaced by "a notification".

21) Section 5.1.3, first para, says that an agent should
    have the capability of sending a notification "whenever
    a configuration operation is attempted or completed."
    The "attempted" should be dropped.

22) Section 6.2, second para, the phrase "access control"
    should be dropped because "authorization" is already
    specified, and the two are the same.

23a) Section 6.3 should be titled "Authentication Notifications"
     instead of "Authentication Traps".
  b) The term "trap" should be replaced by "notification" in
     all places in the text in this section.

24) Section 6.3, last sentence, repeats often incorrect 
    security warning. That is, it says to turn off generation
    of authenticationFailure notifications because a
    community string can be obtained by sniffing the
    notification (sent using SNMPv1 or SNMPv2c). However,
    this is just silly. First, the community string in
    a notification should be different than that used
    in GETs/SETs/etc. Secondly, if traffic can be sniffed,
    then when a manager does a GET/SET/etc, a community
    string can be obtained from any successful operation.
    Don't repeat urban legends.

25) Section 7.1, first para, the grammar is broken here.

26) Section 7 in whole seems too wordy for what it's saying.

27) Section 8 - example MIB. This MIB is an example of how
    not to write a MIB module! 

28) MIB module, the value of the LAST-UPDATED and REVISION
    clauses don't match. There is at least one REVISION
    clause that is missing (and possibly a second). There
    needs to be a REVISION clause that specifies when the
    module was created. And there may be a REVISION clause
    missing for the last update.

29a) MIB module, TC HvacOperation. This TC to be consistent
     with the descriptor in the MIB module maybe should have
     been named BldgHvacOperation.
  b) It is strange that there is not the enum value 'off(3)'.
     And there might need to be a value of 'fanOnly(4)'.

30) MIB module, object bldgHVACTable. Yes this is a example
     MIB module, but the text of the DESCRIPTION that
     describes to the reader about what is being done
     should be removed and moved to an ASN.1 comment.
     This is similar to showing an example C program
     that contains the line like:
         i++;
     The comment for the line SHOULD NOT be "/* increment i */",
     but should tell why this is being done.
     There are several conventions for specifying what information
     is in the DESCRIPTION clauses for tables and rows. One
     of the best is that the table contains the following
     information:
        1) a general description of the table
        2) a description of the relationship to the number of
           rows in the table with physical or logical items.
        3) a description of the relationship, if any, to
           other tables.
     For rows, the DESCRIPTION contains the following
     information:
        1) a simple description of the table, like
           "A row in the table of ...."
        2) a statement that specifies whether or not rows can
           be created and/or deleted via direct operations
           to the table, and if so, then name of RowStatus
           object (or for pre-RowStatus tables, then a description
           of what is needed for creation/deletion). For
           example, the DESCRIPTION may contain text like
           "Creation and deletion are allowed via SNMP
           operations controled by object xxxRowStatus"

31) MIB module. There are formatting problems that result in
    text of the DESCRIPTION clauses to not be indented
    appropriately.

32a) MIB module, object bldgHVACCfgTemplatePtr. It is not clear
     why RowPointer is used instead of Unsigned32 (cloning the
     data type of the index). The DESCRIPTION text is not
     clear in what it is trying to say.
  b) last paragraph in DESCRIPTION seems bogus
  
33a) MIB module, object bldgHVACFanSpeed. This object assumes
     that the speed can always be determined. It doesn't allow
     for cases when it cannot.      
  b) The last sentence in the DESCRIPTION is redundant with
     the UNITS clause.

34) MIB module, object bldgHVACCurrentTemp. The lower range
    only 0 degrees celcius. So can't get below freezing?
    This is not too realistic.

35) MIB module, object bldgHVACoolOrHeatMins. This is a counter,
    but no discontinuity object specified! Not sure that this
    is a useful object. It would be much more useful to have
    a total coolMins, total heatMins, a startTime, and value
    at startTime.

36) MIB module, object bldHVACOwner. This is completely BOGUS
    and a perversion of the RMON's OwnerStrings.

37) MIB module, object bldHVACStatus. The RowStatus TC has
    requirements of what must be specified in the DESCRIPTION
    clause. These requirements are not met.

38) MIB module. Table and row for TemplateInfo. DESCRIPTION
    clause need to be fixed.
    
39) MIB module. Object bldgHAVACCfgTemplateInfoId. Couldn't
    figure why this is needed.
    
40) MIB module, Object bldgHVACCfgTemplateInfoOwner. DESCRIPTION
    is bogus.

41) MIB module, Object bldgHVACCfgTemplateInfoStatus.
    RowStatus problem.

42) MIB module. Table and Row TemplateTable. Same problem with
    DESCRIPION.

43) MIB module. Object bldgHVACCfgTemplateTable. The DESCRIPTION
    contains "[34]", which is not allowed. A useful name is
    needed for the reference, since once the MIB module
    is extracted from the MIB module, then what "[34]" refers
    to will be lost.

44) MIB module. Objects bldgHVACCfgTemplateDesiredTemp,
    bldgHVACCfgTemplateCoolOrHeat, and
    bldgHVACCfgTemplateInfoPtr. When they can be modified
    MUST be specified in the RowStatus object.

45) MIB module. Objects bldgHVACCfgTemplateOwner and
    bldgHVACCfgTemplateStorage. Same comments as similar objects.

46) Section 8.2, first sentence. Change "sample" to "example".

-- that's all
 
Regards,
/david t. perkins

---

From: Michael MacFaden <[email-masked]>
Date: Wed, 26 Jun 2002 22:35:32 -0700

>-05 version that I last reviewed.

Thanks for posting your comments, we'll see what we can do
to improve the sections mentioned.

Mike