Row creation & deletion and error codes - SNMP

This is a discussion on Row creation & deletion and error codes - SNMP ; Hi, I have a question concerning rows creation and deletion in an agent. First, we noticed that two different SNMP agents (different agent toolkits) allow to destroy a non-existing row and report no error. Is this ok? I believe that ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Row creation & deletion and error codes

  1. Row creation & deletion and error codes

    Hi,

    I have a question concerning rows creation and deletion in an agent. First,
    we noticed that two different SNMP agents (different agent toolkits) allow
    to destroy a non-existing row and report no error. Is this ok? I believe
    that an attempt to destroy something that does not exist is generally a
    mistake and should differ from "legal" row destruction.

    Second question: row creation. Is there any recommendation on error value
    that should be returned when row creation fails? For example, ATM cross
    connections (atmVcCrossConnectTable) are created by setting RowStatus only
    (so error status cannot be bound to another variable) but a number of
    reasons for a potential error exist. How is it possible to differ a failure
    caused by already existing row (cannot create an new row with a OID of
    existing row) from other problems? It would be valuable, for example, in a
    faulty network, when the first set operation succeeds, but agent's response
    is lost, and a repeated set fails due to already existing row (created by
    the first set operation).

    Best regards,

    Marek

  2. Re: Row creation & deletion and error codes

    Marek Malowidzki wrote:
    > I have a question concerning rows creation and deletion in an agent. First,
    > we noticed that two different SNMP agents (different agent toolkits) allow
    > to destroy a non-existing row and report no error. Is this ok? I believe
    > that an attempt to destroy something that does not exist is generally a
    > mistake and should differ from "legal" row destruction.


    Yes. If the OID being "set" does not exist, regardless of it it's
    a RowStatus or not, you should get back an "inconsistentName" error
    (I think - see rfc1905, section 4.2.5, clause 6).

    > Second question: row creation. Is there any recommendation on error value
    > that should be returned when row creation fails? For example, ATM cross
    > connections (atmVcCrossConnectTable) are created by setting RowStatus only
    > (so error status cannot be bound to another variable) but a number of
    > reasons for a potential error exist. How is it possible to differ a failure
    > caused by already existing row (cannot create an new row with a OID of
    > existing row) from other problems? It would be valuable, for example, in a
    > faulty network, when the first set operation succeeds, but agent's response
    > is lost, and a repeated set fails due to already existing row (created by
    > the first set operation).


    This problem is why many of the newer MIBs have started using
    TestAndIncr variables as "SpinLock" var - e.g. vacmViewSpinLock
    in RFC3415. See the TestAndIncr Textual Convention in RFC1903.
    By using this in the scenario you describe (set worked, response
    lost) the manager will get an inconsistentValue error value on the
    spin lock var when it tries to retry, and the agent does not process
    the retry. If the set did not work, then the retry will go through
    as expected.

    Hope this helps.

    Pete
    --
    Pete Flugstad
    Remove NO.SPAM to reply directly
    Icon Labs (http://www.icon-labs.com)


  3. Re: Row creation & deletion and error codes

    >
    > Yes. If the OID being "set" does not exist, regardless of it it's
    > a RowStatus or not, you should get back an "inconsistentName" error
    > (I think - see rfc1905, section 4.2.5, clause 6).
    >
    > [...]
    >
    > This problem is why many of the newer MIBs have started using
    > TestAndIncr variables as "SpinLock" var - e.g. vacmViewSpinLock
    > in RFC3415. See the TestAndIncr Textual Convention in RFC1903.
    > By using this in the scenario you describe (set worked, response
    > lost) the manager will get an inconsistentValue error value on the
    > spin lock var when it tries to retry, and the agent does not process
    > the retry. If the set did not work, then the retry will go through
    > as expected.
    >
    > Hope this helps.


    Yes, this helps indeed. Of course, TestAndIncr is not sufficient in itself
    if multiple managers can access the same table at the same time (and use the
    same lock). So, after an error on the spin lock variable, a manager still
    has to check what has happened.

    Thanks for your response.

    Marek

  4. Re: Row creation & deletion and error codes

    Pete Flugstad wrote:

    > Marek Malowidzki wrote:
    >> I have a question concerning rows creation and deletion in an agent.
    >> First, we noticed that two different SNMP agents (different agent
    >> toolkits) allow to destroy a non-existing row and report no error. Is
    >> this ok? I believe that an attempt to destroy something that does not
    >> exist is generally a mistake and should differ from "legal" row
    >> destruction.

    >
    > Yes. If the OID being "set" does not exist, regardless of it it's
    > a RowStatus or not, you should get back an "inconsistentName" error
    > (I think - see rfc1905, section 4.2.5, clause 6).


    I beg to differ.
    If you look at the state diagram for RowStatus in RFC 2579,
    you'll see that it explicitly addresses the situation of
    attempting to destroy a non-existant row.
    And the defined behaviour there is "no Error"

    Of course, this doesn't cover the equivalent situation for rows with a
    different row deletion mechanism, but it doesn't seem unreasonable to
    use the same approach there too.


    What to return depends on whether you think of the error status as
    applying to the process, or the result. If you regard the error as
    referring to the *process* of destroying the row, then it makes more
    sense to return a failure indication ("you can't destroy something that
    wasn't there in the first place").
    But if you regard the error as referring to the final result, then
    it makes more sense to return success ("you asked for this row to not
    exist, and it doesn't").


    Dave

+ Reply to Thread