Re: Informational RFC-to-be draft-aromanov-snmp-hiqa-04.txt

[The IESG <iesg-secretary@ietf.org>]

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.