IMPLIED keyword in INDEX clause - SNMP

This is a discussion on IMPLIED keyword in INDEX clause - SNMP ; Hi All, Can any explain the IMPILED keyword in INDEX clause. can any one provide some examples. Thanks In Advance -Kamaraj...

+ Reply to Thread
Results 1 to 4 of 4

Thread: IMPLIED keyword in INDEX clause

  1. IMPLIED keyword in INDEX clause

    Hi All,

    Can any explain the IMPILED keyword in INDEX clause.
    can any one provide some examples.

    Thanks In Advance
    -Kamaraj

  2. Re: IMPLIED keyword in INDEX clause

    Kamaraj wrote:

    > Can any explain the IMPILED keyword in INDEX clause.
    > can any one provide some examples.


    See RFC 2578 section 7.7.

    The general rule is that you should avoid IMPLIED, see section 4.6.4.
    in .

    /js

    --
    Juergen Schoenwaelder International University Bremen
    P.O. Box 750 561, 28725 Bremen, Germany

  3. Re: IMPLIED keyword in INDEX clause

    Kamaraj wrote:
    > Hi All,
    >
    > Can any explain the IMPILED keyword in INDEX clause.
    > can any one provide some examples.
    >
    > Thanks In Advance
    > -Kamaraj



    The IMPLIED keyword is a kind of optimization that makes it possible
    not to specify the number of subidentifiers in the value of the last
    index. For instance, if my index is a String of variable length, and
    if its value for the row I'm considering is "foo", and I have not
    specified IMPLIED in the index clause, then the OID for getting
    a columnar object x will be:

    myTable.1.x.3.ASCIICodeOf(`f').ASCIICodeOf(`o').AS CIICodeOf(`o')

    where 3 indicates that my string has 3 characters (or rather, that
    the OID built from the String has 3 subidentifiers).

    if I have specified the IMPLIED keyword, the OID will be:

    myTable.1.x.ASCIICodeOf(`f').ASCIICodeOf(`o').ASCI ICodeOf(`o')

    The string begins just after `x', and ends with the OID.


    Now let's say I have two indexes, which are both variable length
    strings, and my row is indexed by ("foo","barr")

    This time the OID (with no IMPLIED) will be:

    myTable.1.x.3.ASCIICodeOf(`f').ASCIICodeOf(`o').AS CIICodeOf(`o').
    4.ASCIICodeOf(`b').ASCIICodeOf(`a').ASCIICodeOf(`r ').
    ASCIICodeOf(`r')

    The effect of IMPLIED is to remove the subidentifier which indicates
    the length of the index value. Obviously, this can only work for
    the last index, for if I tried to remove the first length `3', then how
    would I know where "foo" ends and "barr" begins? But if I remove the
    last length `4', then I can still know where "barr" begins (because the
    first length `3' tells me where "foo" ends, hence "barr" begins just
    after), and I still know where "barr" ends, because it simply ends at the
    end of the OID.

    So why isn't IMPLIED the default? The side effect of IMPLIED is that if you
    specify an IMPLIED index, then you can no longer extends the table, because
    extending the table would mean appending something at the end of the OID,
    which you can no longer do (because you would no longer know where the
    previous index ends).

    So I would suggest *never* to use IMPLIED, unless you have very good reasons
    to do so.

    hope this helps,

    -- daniel
    +------------------------------------------------------------------+
    | D a n i e l F u c h s |
    | Sun Microsystems http://www.sun.com/ |
    +------------------------------------------------------------------+


  4. Re: IMPLIED keyword in INDEX clause

    Sure, Kamaraj.

    First you need to know that indexes which are varying length strings have an
    implicit preceding sub-identifier which tells how long the index string is.
    If you have several such indexes, the length is needed to know where each
    ends. Each byte of the string is a sub-identifier so its length cannot be
    inferred.

    Second, you can shortcut this a little by specifying on the last index (only
    last one) the qualifier IMPLIED which will omit the length sub-identifier
    and the SNMP code will then infer that all the remaining sub-identifiers are
    for that last index. It saves one byte, but...

    Note that since OIDs are organized in lexicographical order, the length
    subidentifier will cause a walk to return OIDs with no implied index to be
    returned in order of length and then ascending, but if IMPLIED, there is no
    length, so they will be just in ascending order. Could be a significant
    difference.

    The ADSL MIB (RFC2662) has two tables with an IMPLIED index in each. In
    fact, they are the only index in these cases. There are other examples in
    the RFCs.

    David Perkins' book "Understanding SNMP MIBs" is an excellent resource.

    HTH.

    Phil


    "Kamaraj" wrote in message
    news:2318efa1.0310170310.356932ce@posting.google.c om...
    > Hi All,
    >
    > Can any explain the IMPILED keyword in INDEX clause.
    > can any one provide some examples.
    >
    > Thanks In Advance
    > -Kamaraj





+ Reply to Thread