Real-time Application Quality-of-Service Monitoring (RAQMON) MIB
draft-ietf-rmonmib-raqmon-mib-12

Proto write up for the record.

Pls note that item 1c) is incorrect. The document has had appropriate
MIB doctor review (by Bert)

-----Original Message-----
From: rmonmib-bounces@ietf.org [mailto:rmonmib-bounces@ietf.org]On
Behalf Of Andy Bierman
Sent: Saturday, January 28, 2006 08:04
To: Bert Wijnen
Cc: rmonmib@ietf.org; David Kessens; iesg-secretary@ietf.org
Subject: [RMONMIB] I-D Publication Request:
draft-ietf-rmonmib-raqmon-mib-10.txt


[Area] OPS-NM
[WG]  RMONMIB
[I-D]  draft-ietf-rmonmib-raqmon-mib-10.txt
[Qver] draft-ietf-proto-wgchair-doc-shepherding-05.txt
[Shep] Andy Bierman

1.a) Yes, the WG Chair has reviewed this version of the document.

1.b) Yes it has had adequate review.

1.c) MIB Doctor review of the RAQMON MIB modules would be helpful.

1.d) None, the RAQMON MIB does not overlap with any related work.

1.e) This document is tightly coupled to the RAQMON Framework
    document and there haven't been any significant issues
    with this MIB for some time.  There is strong WG consensus
    that this MIB meets its intended requirements.

1.f) No appeals have been threatened.

1.g) Yes, but there is one minor nit that will be fixed
    before RFC publication. (See ID-nit log below).

1.h) Yes, references are split.
    Yes, there are references to unpublished documents,
    (the other RAQMON drafts), but they are also ready
    for publication.

1.j) I-D Submission Summary

Technical Summary

  This memo defines a portion of the Management Information Base (MIB)
  for use with network management protocols in the Internet community.
  The document proposes an extension to the Remote Monitoring MIB - RFC
  2819.  In particular, it describes managed objects used for real-time
  application Quality of Service (QoS) monitoring.

Working Group Summary

  The RMONMIB Working Group has consensus to publish this document
  as a Proposed Standard.

Protocol Quality

  This document has been reviewed by Andy Bierman, Alan Clark,
  and Randy Presuhn, and Steve Waldbusser.

----------------

[ID-nit log]


idnits 1.85

tmp/draft-ietf-rmonmib-raqmon-mib-10.txt:


  Checking nits according to http://www.ietf.org/ID-Checklist.html:

    Checking conformance with RFC 3978/3979 boilerplate...

    the boilerplate looks good.

    No nits found.

  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
  - It seems as if not all pages are separated by form feeds - found 0 form
    feeds but 38 pages

  Miscellaneous warnings:
    None.

    No nits found.

AD review posted to WG list:

-----Original Message-----
From: rmonmib-bounces@ietf.org [mailto:rmonmib-bounces@ietf.org]On
Behalf Of Wijnen, Bert (Bert)
Sent: Friday, January 06, 2006 17:05
To: 'Romascanu, Dan (Dan)'; 'Siddiqui, Anwar A (Anwar)'; 'Golovinsky,
Eugene'
Cc: 'RMON WG (E-mail)'
Subject: [RMONMIB] 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

_______________________________________________
RMONMIB mailing list
RMONMIB@ietf.org
https://www1.ietf.org/mailman/listinfo/rmonmib

AD review summary posted to mailing list, editing session
with authors/editors at IETF64. See belo.

-----Original Message-----
From: Wijnen, Bert (Bert)
Sent: Thursday, November 10, 2005 22:53
To: 'Romascanu, Dan (Dan)'; 'Siddiqui, Anwar A (Anwar)';
'Eugene_Golovinsky@bmc.com'; 'ietf@andybierman.com'
Cc: RMON WG (E-mail)
Subject: RE: RAQMON I-Ds Status


For the WG:

As a follow up, the authors/editors and I spend approx 2 hours during
IETF 64 going over my handscribbled comments/notes. They took a copy
of those and will do a revision based on that. So for now I have put
the documents in "Revised ID needed" in the I-D tracker.

Bert

> -----Original Message-----
> From: Wijnen, Bert (Bert)
> Sent: Sunday, November 06, 2005 17:33
> To: 'Romascanu, Dan (Dan)'; 'Siddiqui, Anwar A (Anwar)';
> 'Eugene_Golovinsky@bmc.com'; 'ietf@andybierman.com'
> Cc: RMON WG (E-mail)
> Subject: RE: RAQMON I-Ds Status
>
>
> On my plane-ride from NL to Vancouver I did review all 3
> RAQMON documents. I have hoped that I would have just
> minor comments and that I could request IETF Last Call.
>
> However, I have found a lot of things that I want clarified
> - inconsistencies between the 3 documents
> - questions about "how one can implement from the specs and
>  assume to be interoperable"
>
> So I wonder... who in the rmonmib WG has actually seriously
> reviewed those documents? I must admit that I did not read
> the I-Ds in detail for a long time. But fro my AD-review I
> did, and I now really wonder. I'll try to speak with the
> authors during this IETF week, and then I hope to find
> time to type-up my comments/concerns at the end of IETF64.
>
> Futher I have lots of nitpicking that could be fixed.
> Since I suspect that we may need new revisions because of the
> above 2 major points, the nist may get fixed as well.
>
> Bert