Agenda item: draft-aromanov-snmp-hiqa-04.txt

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

Comes in under Individual Submissions via RFC-Editor
Target is Informational RFC.

My proposal is to tell RFC-Editor we have no fundamental objections,
but that we would like to see an IESG note added on the front-page:

  IESG Note

  This document represents the opinions of the author.  It has not 
  been widely reviewed in the IETF.
  Publication of this document does not mean endorsement by the IESG
  or the IETF (or SNMP) community.

And also FIX some problems:

- The suggestion on page 6, bullet (b) is questionable:
   (b) an agent must return  `inconsistentValue' if the complexity of
   the SetRequest-PDU exceeds the agent's ability to perform consistency
   checking: e.g.  if the PDU contains any other variable.  If an agent
  Many people will think that a 'genErr' is more appropriate. The author
  may have a defendable position. If so, it would be good to add that.

- Section 3.2 is believed to be conflicting with the RFC 3416 specification,
  sect 4.2.5, specifically the text on page 22 towards the end of that
  section 4.2.5.
  
  Sect 3.2  of the internet-draft says:
    Since the `commitFailed' error code does not convey any meaningful
    information to NMS, an SNMP agent may substitute some meaningful
    error code (e.g.  `resourceNotAvailable') for such cases.  An SNMP
    agent should not ever find itself in the situation where it will
    return `undoFailed'.
  And so that recommendation should be taken out.

  If the intention is to indicate that an SNMP agent should try its
  utmost to first do as much checking as possible (rfc3416 says so too)
  and if it concludes that committing the SET operation would fail,
  that it then sends a 'resourceNotAvailable', then that is fine.
  But that is not what it says. 
  And RFC3416 clearly states that IF a commit fails, then you MUST
  return a commitFailed. And if an undo fails, then you MUST return
  an undoFailed.

And that we have suggestions for changes as follows:

- Change the title from
     Developing High Quality SNMP Agents
  into something aka:
     Considerations for SNMP agent developers
  Justification:
  - the doc itself is (in my view) not high quality itself.
  - the doc discussus only a small part of the whole problem
    space and the many tricky things in SNMP agent development
  - one needs to be an SNMP expert to understand what is
    being described.
- Change the "recommendations", i.e.
  - The author often speaks like "It is recommended", where
    it seems to make more sense to say "I recommend"
- References need to be made to the new SNMP STD documents (that
  is in the 341x range instead of 257x range). We understand that
  those were not yet RFCs when the I-D was submitted to RFC-Editor.
- Instead of talking about an "index string", we strongly recommend
  to talk about an "index sequence". Otherwise people too easily
  think about an ascii representation of OID components in the
  dotted notation, and the author means an array (or sequence) of
  unsigned integers that represent OID components (or sub-IDs).
- Same for "string of Object Identifiers" 
- In many places, when the author talks about "OID" he really means
  an OID component (i.e. one unsigned integer instead of a 
  sequence of unsigned integers).
- Bullet 3 on page 4 and 5. Strongly recommend to move the 1st
  sentence of the last para (i.e. 
       This OID range checking must start at the end of index string and
       progress towards its beginning. 
  to the beginning of bullet 3. Otherwise it is impossible to
  understand what the steps mean.
- We suggest that the author explains what he means by non-implied
  and explains that it is about INDEX objects that have the keyword
  IMPLIED associated with it. SO it would then also be better to
  us non-IMPLIED instead of "non-implied".

Thanks,
Bert