Draft message to RFC-Editor for draft-aromanov-snmp-hiqa-04.txt

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

Secretariat, as discussed on todays telechat, here is a
draft message to the RFC-Editor for the IESG advise on
draft-aromanov-snmp-hiqa-04.txt document.

I suggest to wait till say Monday noon to see if any IESG member
has any additional comments or issues.

Bert
---------- Draft note to RFc-Editor ----

RFC-Editor,

The IESG has considered draft-aromanov-snmp-hiqa-04.txt and
wants the following serious problems to be fixed before publication:

- 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 think that a 'genErr' is more appropriate. The author
  may have a defendable position. If so, it would be good to add that
  defendable position.

- 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 (before actually trying a commit) 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.

Also, the IESG would like an IESG note added to the document once
it gets publisged as follows:

  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.