Subject: FW: AD review of draft-ietf-snmpconf-pm-11.txt - part 2

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Wed, 5 Feb 2003 19:05:14 +0100

OK, here is part 2. I know... back on Jan 28 I promised
it would come "tomorrow"... I guess that means (for most
of you) just one night sleep :-() .. Oh well.

The part 1 is also attached at the bottom in case anyone 
wants it all together.

Continuing from Page 69

- sect 9.4.14 and sect 9.4.15

  I get confused. A character in a UTF-8 string can be composed of
  multiple octets. I am sure that that is intended. But are we sure
  everybody understands. Specifically with the focus that a 7-bit
  ASCII character is the same in ASCII as in UTF-8 may confuse people.
  The chr() function may return a string of multiple octets length
  and the octets used from the str argument in ord() function
  may be several octets long to return an integer that will exceed
  255. I'd add something to make that clear.

- sect 11 MIB definitions general comments:
  - StorageType object MUST specify which columns are
    to be writable for 'permanent' entries
  - RowStatus objects MUST specify which columns can be
    modified while a row is 'active'
  - in front of (before) various tables you have extensive
    MIB comment lines. I think a lot of that would be better
    placed in the DESCRIPTION clause of the table.

- once you want this to be considered for PS, you better change
  the import of experimental to mib-2 and do a
    ::= { mib-2 xxx } -- xxx to be assigned by IANA
- pls add a copyright statement to the DESCRIPTION clause of
  MODULE-IDENTITY as per
     http://www.ietf.org/IESG/STATEMENTS/MIB-COPYRIGHT.txt
- Pls change
        "The original version of this MIB, published as RFCXXXX."
  Into
        "The original version of this MIB, published as RFCXXXX."
         -- RFC-Editor assigns XXXX
- Why is there a UTF8String TC ??
  How does it differ (why must it differ) from SnmpAdminString?
  Same question for Utf8String from RFC2287 ??
  I would like to avoid a proliferation of various UTF*String TCs
- I see:
    pmPolicyAdminGroup OBJECT-TYPE
        SYNTAX      UTF8String (SIZE(0..8))
  That size restriction makes it 1 or 2 characters in some 
  languages, no? Is that wise?
- I see:
  pmPolicyPrecedenceGroup OBJECT-TYPE
    SYNTAX      UTF8String (SIZE (0..32))
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "An administratively assigned string that is used to group
        policies. For each element, only one policy in the same
        precedence group may be active on that element. If multiple
        policies would be active on an element (because their
        conditions return non-zero), the execution environment will
        only allow the policy with the highest value of
        pmPolicyPrecedence to be active."
    ::= { pmPolicyEntry 3 }
  I think this will require the use of stringprep.
  I discussed this use of stringprep with authors already and had
  an APPS AD involved as well. I'll not repeat this comment, but
  it potentially applies to other objects, where UTF8 strings need
  to be sequenced or compared.
- I see various objects iwth RANGES like:
    pmPolicySchedule OBJECT-TYPE
       SYNTAX      Unsigned32 (0..65535)
  WOuld it be better to not have a range and specify such a range
  in a/the MODULE-COMPLIANCE ??
  But how this match to pmSchedIndex OBJECT-TYPE
                         SYNTAX      Unsigned32 (1..4294967295)
  Is that not a table to which this value is a link?

- pmPolicyElementTypeFilter OBJECT-TYPE
    SYNTAX      UTF8String (SIZE (0..128))
  Is this how you want to do that? WOuld it not be better to have
  a ptr to a table of OID entries? Now it is so limited in the
  number of OIDs you can put in here.
  In the last sentence in the DESCRIPTION clause it says "if a value
  is registered". WOuld you rather s/registered/included/ ??
- pmPolicyConditionScriptIndex OBJECT-TYPE
    SYNTAX      Unsigned32
  I think a range to exclude zero would be wise. Otherwise explain
  what special value zero means?
  RRef [23] is normative I think. 
- Similar comment for ActionScriptIndex
- pmPolicyDebugging OBJECT-TYPE
    SYNTAX      INTEGER {
                    off(0),
                    on(1)
                }
  we (MIB reviewers) tend to tell people to start enums at 1.
  I also wonder if
     pmPolicyDebuggingOn OBJECT-TYPE
        SYNTAX      TruthValue
  would not be better here
- pmPolicyAdminStatus OBJECT-TYPE
    SYNTAX      INTEGER {
                    disabled(0),
                    enabled(1),
                    enabledAutoRemove(2)
  start enum at 1.
  I wonder... do you want a OperStatus as well?
- pmPolicyStorageType OBJECT-TYPE
  You must explain/describe in DESCRIPTION clause which
  objects must be writable for 'permanent' entries

- pmPolicyCodeTable
  I see nothing about persistency of this table, nor do I see
  a STorageType object
  Should some (or all) of the comments before this table 
  not just go into the DESCRIPTION clause?
  Same for other tables.
- pmElementTypeRegTable
  Mmm... I wonder if we do not need to specify the contextName
  as well ??
- in DESCRIPTION clause of pmElementTypeRegOIDPrefix

        This object identifier value is specified down to the 'entry'
        component (i.e. ifEntry) of the identifier.
  s /i.e./e.g./ ??

        A special OBJECT IDENTIFIER '0.0' can be written to this
        object. '0.0' represents the single instance of the system

  Mmmm... ? This is an INDEX object and so is not accessible.
  So "can be written to this object" sounds pretty weird to me

- pmElementTypeRegDescription OBJECT-TYPE
    SYNTAX      UTF8String (SIZE (0..32))
  Mmm... seems only some 5 characters in some languages.
  Sounds short for a "descriptive label" to me

- pmRoleContextName OBJECT-TYPE
    SYNTAX      SnmpAdminString
  I believe that in all other mib modules that use ContextName
  we have a SIZE of 0..32. Might make sense here too

- pmRoleContextEngineID OBJECT-TYPE
    SYNTAX      OCTET STRING (SIZE (0..32))
  Would it not be better to use (5..32) as we have defined
  SnmpEngineID with that size in RFC3414 ??
  I also wonder about 
        .................... If the element is on the local system
        this object will be the empty string."
  Why not use the local SnmpEngineID ?? If you do use empty string
  then Size could be SIZE(0 | 5..32).

- pmCapabilitiesType
  talks about "traps", probably better to use "notifications"
  May need to talk about "MIB module" in stead of MIB or MIBs,
  Instead of "standard MIBs" I would say "MIB modules on the 
  standards track"
  Talks about OIDs registered with IANA. But I don't see any
  IANA considerations or a registry where they can be registered.

- pmCapabilitiesOverrideState OBJECT-TYPE
    SYNTAX      INTEGER {
                    invalid(0),
                    valid(1)
                }
  start enums at 1, or better use TruthValue ??

- page 101
            20000101T080000/20000131T120000

              January 1, 2000, 0800 through January 31, 2000, noon
  Might want to use T130000 for 1pm to show 24hour clock?

- in pmSchedEntry and pmSchedStorageType you talk about
   pmSchedHour and pmSchedMinute objects, but I cannot find them

- pmTrackingPEContextName OBJECT-TYPE
    SYNTAX      SnmpAdminString
  SIZE (0..32) ??

- pmTrackingPEContextEngineID
  Same questions as above for xxxContextEngineID

- pmTrackingEPContextName OBJECT-TYPE
    SYNTAX      SnmpAdminString
  pmTrackingEPContextEngineID OBJECT-TYPE
    SYNTAX      OCTET STRING (SIZE (0..32))
  Same questions as above

- pmTrackingEPStatus OBJECT-TYPE
    SYNTAX      INTEGER {
                    on(0),
                    forceOff(1)
                }
  start enum at 1. Possibly a TruthValue?

- pmDebuggingTable
  What happens with any entries if a system reboots/restarts?

-   pmDebuggingContextName      SnmpAdminString,
    pmDebuggingContextEngineID  OCTET STRING,

  Same questions as a
  By the way, why is ...ContextEngineID not of TC SnmpEngineID.
  Probably because of the empty string ?? Another reason to not
  do that.

-     pmConformance   OBJECT IDENTIFIER ::= { pmMib 20 }
  why the sudden jump to 20 ??

- Please check your Security COnsiderations section against the
  latest http://www.ops.ietf.org/mib-security.html
  guidelines.

- Pls split references in normative and informative references
  as per http://www.rfc-editor.org/policy.html

bove...
Thanks,
Bert 

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]]
Sent: dinsdag 28 januari 2003 0:54
To: Snmpconf (E-mail)
Subject: AD review of draft-ietf-snmpconf-pm-11.txt - part 1

Here is a list of NITS, admin/bureucratic comments and
more or less serious concerns/questions.

- on the fornt page, I would not repeat the authors/editors'
  names under the title.
- At next revision, update copyright date
- the RFC-Editor does not want the abstract to be a numbered 
  section
- Section 2, we have a new MIB boilerplate since the SNMPv3
  RFCs have been published as STD 62.
  See: http:/www.ops.ietf.org
- We also have a new MIB security guidelines at the same
  place. You may want to check if that means some changes
  to your Security Considereations section.
- References need to be split in Normative and Informative
  See http://www.rfc-editor.org/policy.html
- last para on page 4 talsk about 
   "..this document defines standard management objects" and
   "... in a standard form..."
  The attribute of STDs track is assigned external to an RFC,
  so you should not state/claim that this is standard in the
  document itself.
- First list of bullets in section 3 seems to be a marketing
  statement. We do not need those in RFCs.
- In general, I would like the authors/editors to go through 
  the document and to properly use the terms MIB, MIB Module.
  I think too often then term "MIBs" is used when you really 
  mean "MIB Modules". I noticed it at least twice in sect 5.3
- Sect 5.5.1.
  s/are are/are/
- Section 6 states in 3rd para:
  "Some examples of the features that have been removed...."
  Not sure it is really "have been removed" or if it is better
  stated as "are not used" or "are not available" or 
  "are not inherited" or such.
- Has anyone checked the EBNF specification via a syntax checker?
  See http://www.ietf.org/ID-nits.html section 2 6th bullet,
  which also points to
  http://www.ietf.org/IESG/STATEMENTS/pseudo-code-in-specs.txt
  For example, I am not sure this is correct (page 18)
         unary_op:          '+' | '-' | ' | '!' | '++' | '--'
  What does that single quote between the 2nd and 3rd } mean?
- sect 6.2.1
  I get a bit confused when you talk about 8-bit elements for
  a string (in UTF-8 context). Steve tried to explain, but 
  the current text still confuses me. I think he was going to
  try and add some text to unconfuse me (and possibly others).
- When you use EBNF, LHS, RHS and such acronyms the first time 
  in the document, pls expand them Thisis another RFC-Editor
  policy.
- I had some conversation with Steve about the Library functions,
  on hos they are split in 4 categories and which of the
  "reserved words" can be used when and where. Also a question
  on the "which categories must be supported". I believe the 
  answer was all. Steve is going to clarify some of this.
- Sect 9.1.1 starts with a ">"... ??
  I saw that at a few more places
- Sect 9.1.1 I see
    snmp-function(...[, integer mPModel,
                        string tDomain, string tAddress,
                        integer secModel, string secName,
                        integer secLevel, string contextEngineID
    ]) 

  It seems to me we need to be able to express the contextName
  for local and for remote SNMP engines? How do we do that?
  I think when I look further in the document, that one of the
  "..." arguments is probably the contextName. Might be good to 
  explain some of that.

- when I see this
    snmp-function(...[, integer mPModel,
                        string tDomain, string tAddress,
                        integer secModel, string secName,
                        integer secLevel, string contextEngineID
    ]) 

  and if I understand it correctlym then all those extra args
  are positional and optional, is then not the better notation:

    snmp-function(...[, integer mPModel [,
                        string tDomain [, string tAddress [,
                        integer secModel [, string secName [,
                        integer secLevel [, string contextEngineID
    ]]]]]]]) 

- The sample that follows
    getVar("sysDescr.0", "", SNMPv3, "snmpUDPDomain",
           "192.168.1.1/161", SNMPv3, "joe", "NoAuthNoPriv");
  confuses me somewhat. 
  I think it is a getVar for sysDescr.0, in the default contextName
  but it seems to list a SN MPv3 secModel. I am not aware that
  we have such a secmodel, do we? We have a USM secModel.
  We also have an SNMPv1 and SNMPv2c, or even an any secModel.
  But not an SNMPv3 secModel.

- Sect 9.1.1 also talks about TDomain. I would suggest to consider
  to use terms from RFc3419, which includes values for IPv6, which
  is something that IESG really wants these days.

- bottom of page 34. Why do we allow a trailing dot if it can case 
  strncmp() problems?

- sect 9.1.3.1
  The empty (zero length)  string is the default context.
  so I guess if one omits it that one also gets the default
  context. Not sure if that is clear here.
  At least the text
              If 'contextName' is not present,
        this element's contextName will be used.
  Confuses me. What does that mean?
  This comes back in a lot of the function descriptions

- Sect 9.1.3.1 and following sections
  So do we realize that a "programmer" of these scripts needs
  to speak OID lingo as opposed to descriptors?
  Do we really believe that that is encouraging?

- Sect 9.1.3.2
    The exists() function is used to verify the existence of an
    SNMP MIB instance.
  Do you mean s/MIB/MIB object/ 
  You cannot be meaning a complete MIB instance, do you?
  Similar text is used in following sections too.

- I guess that exists() returns an integer cause we do not
  have a boolean in our language, right?

- Sect 9.1.3.4
  Mmm... why not rename "pattern" to "searchString" ??

  And is the programmer expected to use digits to express
  which mode to use? Or are there reserved words for that?

- Sect 9.1.3.6
  I wonder how rows that have multiple integers, or octet
  strings or such as index, how they get created?

  Does the last para on page 42 agree with the code fragment
  on the next page? Spefically, does the if createRow() call
  and and checking of return code and index agree with that
  para? Maybe I am just confused.

- page 44 talks about "noSuchName or noSuchObject"
  - do we still want to talk about noSuchName (SNMPv1 ??)
  - do we not need to talk about noSuchInstance?

- sect 9.1.4.1
  How about error-status and error-index?

- sect 9.1.4.2
  I wonder if pdu should not be prefixed with &pdu ?

  Can this function never return an error?

- sect 9.1.4.3 and 9.1.4.4
  I see
          int readVar(integer pdu, integer varBindIndex,
  and I see
    integer snmpSend(integer reqPDU, integer reqNumVarbinds,
  So I wonder, do we have both int and integer as a datatype?

- sect 9.1.4.5
  What if you pass a non-existing pdu handle?
  Will it return an error? so should it be:

  integer  readError(integer pdu, integer numVarbinds,
                     integer &errorStatus, integer &errorIndex,
                     integer &hasException)

  to show that it can return an error?
  The same question for some of the other functions in sect 9.1

- sect 9.2
  I wonder if this is not better sect 9.1.5 ??
  It is part of the SNMP library functions, no?

- sect 9.2
    const integer Integer       = 2;
  So does that potentially cause confusion for people to
  recognize the difference between integer with lowercase i
  and upprecase I ??
  In fact I wonder if these could not all better be prefixed
  with some string like SNMP or so, e.g.

  const integer SNMP_Integer       = 2;
  const integer SNMP_Integer32     = 2;
  etc

  You refer to RFC1905, better to refer to RFC3416

  You also refer to RFC2571, better to use RFC3411

- sect 9.3.1
  I fail to see how the function returns an indication on
  how the object is indexed.
  And does the prototype function not need arguments?

- sect 9.3.4 and 9.3.5
  I had asked steve if the function ev() and ec()
  could be better named elementValue() and elementCount().
  He answered that thes function will be used a lot, similar
  to argv and argc in C. So.. are we happy that these
  are such cryptic functiuon names? Is elemv() and elemc() 
  a better compromise. 
  I can live with ev() and ec() if the WG says it is OK.

- sect 9.3.4 and 9.3.5
  I wonder if it is easy to know what "this element" means.
  I think it is explained in sect 7... but that is quite
  a few pages back. 

- When I see things like the roleMatch function and I know
  that we are in a UTF-8 environment, then I think we need
  to include stringprep functionality as per RFC3454.
  In fact Patrik Faltstrom, APPS AD has confirmed that this
  is needed, and he has already pointed the authors to a
  sample.

- I guess we have another set of reserved words at the end of
  sect 9.3.7
  Maybe we need one section that lists them all, no?

- sect 9.4.6 last sentence
  "... twice if is an expression" ???

- sect 9.4.8
  I first thought that oid needed to be &oid.
  But the resulting OID is returned as a string (is what Steve
  told me). I guess the "...replace len subids in oid1.."
  is what confused me.

OK, part 2 comes tomorrow.

Bert

Thanks,
Bert