Remote Network Monitoring Management Information Base Version 2
draft-ietf-rmonmib-rmon2-v2-05

[Ballot comment]
To Scott Hollenbeck:
Yes, http://www.ietf.org/IESG/Implementations/RFC2021-Implementation.txt
is the implementation report, as was also listed in the IETF Last Call.

To address comment from Brian Carpenter, I added the following:

Notes to RFC-Editor:

In abstract, pls change:
  OLD:
    This document obsoletes RFC 2021 and the RMON2-MIB module
    contained in this memo obsoletes the RMON2-MIB module at
    RFC3273 level.
  NEW:
    This document obsoletes RFC 2021,  updates RFC 3273 and
    contains a new version of the RMON2-MIB module.

[Ballot comment]
(from Gen-ART review by Harald Alvestrand)

Note: Perhaps try to make it clear to the RFC Editor that this document obsoletes both RFC 2021 and RFC 3273 - this wasn't blindingly obvious to me until I understood that RFC 3273 (Proposed in 2002) contained the pieces that were added to 2021 in order to create the complete object that we're considering for approval.

Had some off-line discussions with Steve Waldbusser.
Also there was one last comment posted to rmonmib mailing
list to which I have seen no reaction yet.

I am waiting for a new revision and I pinged Steve (again)
today.

Bert

Doc looks good, but I wonder about this:

  This document may not be modified, and derivative works of
  it may not be created, except to publish it as an RFC and
  to translate it into languages other than English other
  than to extract section 6 as-is for separate use.

which shows up on the front page.

I also see:
!! Missing citation for Informative reference:
  P154 L018:  [RFC3414]

!! Missing citation for Informative reference:
  P154 L024:  [RFC3415]

And I get a SYNTAX error on:
  trapDestAddress  OBJECT-TYPE
    SYNTAX    OCTET STRING
    MAX-ACCESS read-create
    STATUS    deprecated
    DESCRIPTION
        "The address to send traps on behalf of this entry.

        If the associated trapDestProtocol object is equal to ip(1),
        the encoding of this object is the same as the snmpUDPAddress
        textual convention in RFC 3417 "Transport Mappings for the
        Simple Network Management Protocol(SNMP)" [RFC3417]:
          -- for a SnmpUDPAddress of length 6:
          --
          -- octets  contents        encoding
          --  1-4    IP-address      network-byte order
          --  5-6    UDP-port        network-byte order
 
  change double quote to single quote?


And there is a TOC at the start and at the end of the doc

I am asking author/editor and WG chair how they want to address the above

Doc looks good, but I wonder about this:

  This document may not be modified, and derivative works of
  it may not be created, except to publish it as an RFC and
  to translate it into languages other than English other
  than to extract section 6 as-is for separate use.

which shows up on the front page.

I also see:
!! Missing citation for Informative reference:
  P154 L018:  [RFC3414]

!! Missing citation for Informative reference:
  P154 L024:  [RFC3415]

AD review comments posted to rmonmib wg list:

-----Original Message-----
From: Wijnen, Bert (Bert)
Sent: donderdag 15 juli 2004 16:52
To: Steve Waldbusser (E-mail)
Cc: RMON WG (E-mail)
Subject: AD review of: draft-ietf-rmonmib-rmon2-v2-01.txt


This took far too long. Applogies for that.
But here we go.

more or less serious

- Seems the REVISION dates have not been copied properly.
  smidiff tells me:
  ../ietf/RMON2-MIB:74 [3] {revision-removed} revision `2002-07-08 00:00' removed
  ./RMON2-MIB:71 [5] {revision-added} warning: revision `2004-02-14 15:00' added
  ./RMON2-MIB:78 [5] {revision-added} warning: revision `2001-10-23 15:00' added
  The MIB module at ftp://ftp.rfc-editor.org/in-notes/mibs/current.mibs/rmon2.mib
  is the one that we are (supposedly) updating. It has the 28 july 2002 date,
  not an octover 2001 date. Steve, did you get that out of a private
  copy of this MIB?

- I think the REVISION clause SHOULD contain more explicitly the changes as they are
  also described in section 12

- Maybe somewhere in the doc we should also state that the RMON2-MIB module
  at RFC3273 level, which can be found at
    ftp://ftp.rfc-editor.org/in-notes/mibs/current.mibs/rmon2.mib
  is now obsoleted. I guess we need to replace that one with this one (once
  the RFC is published). We should probably make it clear in this RFC-to-be
  that that is what we will do? Just so it is clear.

- smidiff tells me:
  ./RMON2-MIB:3860 [3] {range-added} size `(0..255)' added to type `ControlString'
  I guess that this has been thought out and is OK. I see that the size limitiation
  was always used whenever the TC was used (in this MIB). We do not know about
  possible use by other MIB modules, do we?

  Anyway, my biggest concern is that I see nothing of that explanation/justification
  anywhere in the document. Not in the TC itself, not in the REVISION clause.

- smidiff tells me:
    ./RMON2-MIB:298 [3] {to-implicit} implicit type for `protocolDirID' replaces
      type 'OctetString'
    ./RMON2-MIB:298 [3] {range-added} size `(4..128)' added to type used in
      `protocolDirID'
  It seems as if you added a SIZE (4..128)
  Again, without any explanation anywhere.

- Same for several others:
./RMON2-MIB:325 [3] {to-implicit} implicit type for `protocolDirParameters' replaces type `OctetString'
./RMON2-MIB:325 [3] {range-added} size `(1..32)' added to type used in `protocolDirParameters'
./RMON2-MIB:1016 [3] {to-implicit} implicit type for `addressMapNetworkAddress' replaces type `OctetString'
./RMON2-MIB:1016 [3] {range-added} size `(1..255)' added to type used in  `addressMapNetworkAddress'
./RMON2-MIB:1451 [3] {to-implicit} implicit type for `nlHostAddress' replaces type `OctetString'
./RMON2-MIB:1451 [3] {range-added} size `(1..255)' added to type used in `nlHostAddress'
./RMON2-MIB:1933 [3] {to-implicit} implicit type for `nlMatrixSDSourceAddress' replaces type `OctetString'
../ietf/RMON2-MIB:1953 [6] {previous-definition} info: previous definition of `nlMatrixSDSourceAddress'
./RMON2-MIB:1933 [3] {range-added} size `(1..255)' added to type used in `nlMatrixSDSourceAddress'
./RMON2-MIB:1950 [3] {to-implicit} implicit type for `nlMatrixSDDestAddress' replaces type `OctetString'
../ietf/RMON2-MIB:1970 [6] {previous-definition} info: previous definition of `nlMatrixSDDestAddress'
./RMON2-MIB:1950 [3] {range-added} size `(1..255)' added to type used in `nlMatrixSDDestAddress'
./RMON2-MIB:2038 [5] {description-changed} warning: description of object definition `nlMatrixDSEntry' changed
../ietf/RMON2-MIB:2059 [6] {previous-definition} info: previous definition of `nlMatrixDSEntry'
./RMON2-MIB:2081 [3] {to-implicit} implicit type for `nlMatrixDSSourceAddress' replaces type `OctetString'
../ietf/RMON2-MIB:2099 [6] {previous-definition} info: previous definition of `nlMatrixDSSourceAddress'
./RMON2-MIB:2081 [3] {range-added} size `(1..255)' added to type used in `nlMatrixDSSourceAddress'
./RMON2-MIB:2099 [3] {to-implicit} implicit type for `nlMatrixDSDestAddress' replaces type `OctetString'
../ietf/RMON2-MIB:2116 [6] {previous-definition} info: previous definition of `nlMatrixDSDestAddress'
./RMON2-MIB:2099 [3] {range-added} size `(1..255)' added to type used in `nlMatrixDSDestAddress'
./RMON2-MIB:2462 [3] {to-implicit} implicit type for `nlMatrixTopNSourceAddress' replaces type `OctetString'
../ietf/RMON2-MIB:2489 [6] {previous-definition} info: previous definition of `nlMatrixTopNSourceAddress'
./RMON2-MIB:2462 [3] {range-added} size `(1..255)' added to type used in `nlMatrixTopNSourceAddress'
./RMON2-MIB:2480 [3] {to-implicit} implicit type for `nlMatrixTopNDestAddress' replaces type `OctetString'
../ietf/RMON2-MIB:2509 [6] {previous-definition} info: previous definition of `nlMatrixTopNDestAddress'
./RMON2-MIB:2480 [3] {range-added} size `(1..255)' added to type used in `nlMatrixTopNDestAddress'
./RMON2-MIB:2604 [5] {description-changed} warning: description of object definition `alHostEntry' changed
../ietf/RMON2-MIB:2634 [6] {previous-definition} info: previous definition of `alHostEntry'
./RMON2-MIB:2756 [5] {description-changed} warning: description of object definition `alMatrixSDEntry' changed
../ietf/RMON2-MIB:2785 [6] {previous-definition} info: previous definition of `alMatrixSDEntry'
./RMON2-MIB:2876 [5] {description-changed} warning: description of object definition `alMatrixDSEntry' changed
../ietf/RMON2-MIB:2903 [6] {previous-definition} info: previous definition of `alMatrixDSEntry'
./RMON2-MIB:3285 [3] {to-implicit} implicit type for `alMatrixTopNSourceAddress' replaces type `OctetString'
../ietf/RMON2-MIB:3315 [6] {previous-definition} info: previous definition of `alMatrixTopNSourceAddress'
./RMON2-MIB:3285 [3] {range-added} size `(1..255)' added to type used in `alMatrixTopNSourceAddress'
./RMON2-MIB:3303 [3] {to-implicit} implicit type for `alMatrixTopNDestAddress' replaces type `OctetString'
../ietf/RMON2-MIB:3333 [6] {previous-definition} info: previous definition of `alMatrixTopNDestAddress'
./RMON2-MIB:3303 [3] {range-added} size `(1..255)' added to type used in `alMatrixTopNDestAddress'

- We may still want to consider (smilint tells me this):

  ./RMON2-MIB:5426: [5] {group-unref} warning: deprecated group
    `probeConfigurationGroup' is not referenced in this module
  ./RMON2-MIB:5461: [5] {group-unref} warning: current group
    `rmon1EthernetEnhancementGroup' is not referenced in this module
  ./RMON2-MIB:5470: [5] {group-unref} warning: deprecated group
    `rmon1TokenRingEnhancementGroup' is not referenced in this module

  I am mostly thinking about the one current group. Is it completely optional
  for at least one compliance? If so, we could add it there and state that.

    ./RMON2-MIB:105: warning: type `ZeroBasedCounter32' has no format specification
    ./RMON2-MIB:126: warning: type `LastCreateTime' has no format specification
    ./RMON2-MIB:146: warning: type `TimeFilter' has no format specification

- trapDestTable has been deprecated.
  We normally put some text into the DESCRIPTION clause to explain
  WHY we did deprecate it. I even wonder if it would not be better
  to obsolete it (but probably should have brought that up earlier)

- Same about other deprecated objects, groups, etc.

- Page 6 states:

    Implementations of this MIB must also implement the system
    group of MIB-II [9] and the IF-MIB [10].  MIB-II may also
    mandate the implementation of additional groups.

  And referes to RFC1213 for MIB-II. Do we really want that, or would
  it be better to point to systemGroup of SNMPv2-MIB, RFC3418 ?
  Could in fact specify so im MODULE-Compliance.

nits/admin

- Although we DID have an extensive COPYRIGHT statement in the
  RFC3273 revision, I think we can now use the standard copyright
  statement as per our MIB Review Guidelines (sect 3.8):

            Copyright (C) The Internet Society (date).  This version
            of this MIB module is part of RFC yyyy;  see the RFC
            itself for full legal notices."
  -- RFC Ed.: replace yyyy with actual RFC number & remove this note

- There should be no section numering for abstract and status and such
  (this is NOT new!)

- abstract should state that this document obsoletes RFC 2021.

- there should be NO citation to text in boilerplate, i.e. the [7]
  on the first page should not be there, and as a result reference
  [7] can (in fact should) go away. This rule is NOT new!

- If a new rev gets done, then pls use new RFC3667/3668 boilerplates.

- The document title is:

                  Remote Network Monitoring
                Management Information Base
                          Version 2
                        Using SMIv2

  I think I would remove the "Using SMIv2". We've not been doing that
  anymore for quite a number of years now.

- formatting is a bit weird on pages 142-144

Thanks,
Bert