AD review of draft-ietf-rmonmib-raqmon-mib-09.txt

Thanks for the new revision.

Pls read the following and let me know if you agree that
probably one more rev makes sense?
  
SMICng tells me:

  E: f(raqmon.mi2), (104,48) Index item "raqmonParticipantIndex"
     must be defined with syntax that includes a range
is zero a valid value? By using a range that becomes clear.
Andnote thatnormally we do not like to have zero as an index value.
  E: f(raqmon.mi2), (991,20) Index item "raqmonParticipantIndex"
     must be defined with syntax that includes a range
This is just a repeat of the previous (you re-use the same index)
  E: f(raqmon.mi2), (992,20) Index item "raqmonQosTime"
     must be defined with syntax that includes a range
Makes sense to add a range I think
  E: f(raqmon.mi2), (1171,20) Index item "raqmonParticipantIndex"
     must be defined with syntax that includes a range
Same as first error (because of re-use)
  W: f(raqmon.mi2), (1151,8) Row "raqmonParticipantAddrEntry"
     has indexing that may create variables with more than 128 sub-ids
Can be ignored. I think I would remove the
                The possible compilation warnings resulted by the
                use of this indexation in this table can be ignored.
from the DESCRIPTION clause.
You explain why it won't be a problem, and I would not start to
discuss specific warnings from any possible compilation tools.
I won't block on it though.
  W: f(raqmon.mi2), (1168,20) Row "raqmonParticipantAddrEntry"
     does not have a consistent indexing scheme - index item
     raqmonParticipantAddr from base row raqmonParticipantEntry
     is not defined as an index item
I think this is OK.

- I wonder though if it would not be better to also use
  raqmonParticipantAddrType as an index. Seems better (more consistent)
  to me. I do understand that from the length (at least with current IPv4
  and IPv6 only allowed) you could determine the type and you would not
  expect clashes in the value.

- Similarly I wonder if it would not be wise to also include the
  InetAdddressTypes in the raqmonSessionAlarm notification 
  Again, I won;t block on this.

- For 
       raqmonConfigPort OBJECT-TYPE
           SYNTAX Unsigned32 (0..65535)
  I wonder why you are not re-using the InetPortNumber TC from RFC4001?

- Similarly I wonder why you would not use InetPortNumber for
      raqmonParticipantSendPort OBJECT-TYPE
           SYNTAX Integer32 (-1|0..65535)
           MAX-ACCESS read-only
           STATUS current
           DESCRIPTION
               "Port from which session data is sent.
                If the value was not reported to the collector,
                this object will have the value -1."
           REFERENCE
               "Section 5.5 of the [RAQMON-FRAMEWORK]"

           ::= { raqmonParticipantEntry 6 }

       raqmonParticipantRecvPort OBJECT-TYPE
           SYNTAX Integer32 (-1|0..65535)
           MAX-ACCESS read-only
           STATUS current
           DESCRIPTION
               "Port on which session data is received.
                If the value was not reported to the collector,
                this object will have the value -1."
           REFERENCE
               "Section 5.6 of the [RAQMON-FRAMEWORK]"
           ::= { raqmonParticipantEntry 7 }

  and then specify the value zero in case no data has been reported 
  to the collector. Or am I missing something here?

 
- For raqmonSessionExceptionRowStatus
  - s/the all read-create/all the read-create/
  - It (in fact ALL RowStatus objects) should also state which 
    writable objects in the row can or cannot be changed while
    the row is active (as per RFC2579)

- I see
       raqmonSessionExceptionIndex OBJECT-TYPE
           SYNTAX Unsigned32 (1..65535)
           MAX-ACCESS not-accessible
           STATUS current
           DESCRIPTION
               "An index that uniquely identifies an
               entry in the raqmonSessionExceptionTable."
           ::= { raqmonSessionExceptionEntry 2 }

  And wonder how a management station is going to know which index
  number to use when it wants to create a new entry. Is the idea
  that it just does a tryal and error, or that it loops with a getnext
  or getbulk through the table to fidn one?

- In the MODULE-COMPLIANCE, I would add OBJECT clauses for all your
  InetAddressType and InetAddress objects to specify that only
  IPv4 and IPv6 need to be supported.

- I note that in order to be compliant with the MODULE-COMPLIANCE,
  such implementations MUST all support the read-write and read-create
  objects/tables in read-write and read-create mode! If that is
  intentional, then fine.

Nits:
- inclomplete DESCRIPTION.
      raqmonParticipantAddr OBJECT-TYPE
           SYNTAX InetAddress
           MAX-ACCESS read-only
           STATUS current
           DESCRIPTION
               "The Internet Address of the participant for this
                session."
           ::= { raqmonParticipantEntry 5 }
  according to RFC4001, you MUST specify which object of InetAddresType
  controls/specifies the formatting of this object.

- Same for raqmonParticipantPeerAddr

- You have 
          REFERENCE
              "RFC 1890, Section 5.25 of the [RAQMON-FRAMEWORK]"
          ::= { raqmonParticipantEntry 13 }
  but RFC1890 is not in the References sections.
  and I think it would be clearer if you did
              "RFC 1890 and Section 5.25 of the [RAQMON-FRAMEWORK]"

- For naming consistency, I would rename
     raqmonRDSTimeout
  to
     raqmonConfigRDSTimeout

Bert