updated DSMON MIB (last one!)

[Andy Bierman <abierman@cisco.com>]

Hi,

A new version of the DSMON MIB (draft-ietf-rmonmib-dsmon-mib-08.txt) will
be published soon.  I made a few changes to clear up the remaining SMI
issues (smilint warnings).

    1) INDEX object dsmonHostAddress range causes OID to exceed max length

        changed
                  SYNTAX OCTET STRING (SIZE (0..65535))
        to
                  SYNTAX OCTET STRING (SIZE (0..110))

    2) INDEX objects dsmonMatrixSourceAddress and dsmonMatrixDestAddress
        range causes OID to exceed max length

        changed
                  SYNTAX OCTET STRING (SIZE (0..65535))
        to
                  SYNTAX OCTET STRING (SIZE (0..54))

    3) 4 deprecated GROUPs unconditionally optional (not mentioned in
        any MODULE-COMPLIANCE)

        added dsmonHCNoC64Compliance (deprecated status)
        There are now 3 MODULE-COMPLIANCE macros:
            - dsmonCompliance  (current)  for agents without HC and Counter64
            - dsmonHCCompliance (current) for agents with HC and Counter64
            - dsmonHCNoC64Compliance (deprecated) for agents with HC but
               not Counter64
         This 3rd compliance macro makes it more clear why there are 4 
deprecated
         groups in the MIB.

This is (hopefully) the very last update to the DSMON MIB before publication.
I realize that lowering the range of the 3 OCTET STRING index objects
is a semantic change, but it should not impact any implementations,
which only support IPv4 and maybe IPv6.   I don't really like setting
the upper bound of the range to what will fit in a varbind, because
the 128 sub-identifier rule is silly and arbitrary and could change someday.
On the other hand, there's no practical purpose for an arbitrarily large
address range.  (If anyone out there is using an L3 protocol with a DS
field and an address larger than 54 octets, please speak up now!)

Unless there are any objections made to the WG mailing list or
the OPS MIB mailing list by November 6, 2001, this draft will
be forwarded to the IESG for RFC publication consideration.


thanks,
Andy