Introduction to the Remote Monitoring (RMON) Family of MIB Modules
draft-ietf-rmonmib-framework-05

AD (Bert) posted review comments to WG mailing list

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: woensdag 23 april 2003 0:06
To: RMON WG (E-mail)
Subject: [RMONMIB] AD review of: draft-ietf-rmonmib-framework-03.txt


Here are my comments:

- I suspect that RMON in the title needs to be expanded
  See http://www.rfc-editor.org/policy.html
- Copyright notice and abstract should not be numbered
- RMON also should be expanded in the abstract
- Section 5 (maybe others too) talks about "managing a network"
  WOuld it be better to speak about "managing and/or monitoring"?
  RMON in fact has a lot in it for just monitoring
- Section 5 (and other places) talks about the "RMON standard".
  - Some pieces are at STD while others are not.
  - In general, we should not speak about "standard". It is an
    external tag that can change at any time.
  - Better is probably to talk about the "RMON documents" or
    "RMON MIB modules"
  - If you want to use RMON-MIB (which would be the module name),
    then I guess that would be OK too.
- Section 5 talks about "running the RMON MIBs"
  Is that good terminology? There are devices that have implemented
  these RMON MIB modules, or that support these RMON MIB module.
  Are they then "running" them?
- Document still talks about RMON MIBs or RMON MIB at various places.
  (or more general it talks about XXX MIB(s) which should
  be XXX MIB Module(s) I think.
  I think it would be much better to be consistent and talk about
  MIB Modules or a MIB Module.
- Sect 7.1 Ethernet Statistics Group
  s/Ethernet interface/Ethernet segment/ ?? I just wonder if that is better
- Top of page 7
  s/two addresses/two MAC addresses/ ?? just wonder if thats better
- Page 11: User History
  WOuld novice readers (who are a primary audience) not be consfused and
  think that this is data about users, while what we really provide is
  a "user-configurable" set of varioables to be monitored? Maybe some
  extra explnation?
- I think I would add acronym SMON to the title of sect 7.5
  Makes an easier link with figures 1 and 2.
- I think I would add acronym IFTOPN to the title of sect 7.6
- HCRMON for sect 7.8
- ... and so on for some more
- I wonder if in sect 7.8 we should not point to the current RMON1/RMON2
  MIB modules as found at ftp://ftp.rfc-editor.org/in-notes/mibs/current.mibs/
- In section 7.9
  I wonder if we should say something about the 3 types of applications
  we distinguish: interactive, transactional, streaming (did I get them right?)
- Does SSPM have a place in fig 1 or 2, I guess not. SHould we say something
  about that either around fig 1 and 2 or in sect 7.12?
- Sect 8.1 says:
  The Media Independent Table is defined in the High Capacity RMON MIB
  [RFC3287].
  Mmm.,.. RFC3287 is DSMON MIB is it not?
- Sect 8.3 2nd para refers to appLocalIndex. Might be good to add a refernce
  to the actual RFC.
- It seems that in the references section you still have the long list of
  RFCs from the old MIB Boiler plate. that seems a bit superfluous to me.
- You also have only defined "informative references". Is this correct?
  A "normative" reference is a ref to a document that you must (at least
  partially) understand in order to under stand the doc that is refering
  to it. I would think we have quitea few of those, don't we?
  What we may want to be carefull with is that "normative references"
  to I-Ds will hold up publication till thise IDs also become RFCs.
  As such, we may want to make the text about RAQMON such that it
  describes possible future addition as opposed to something that is
  already a well thought out part of it.
- In the security considerations section I would add that each of the
  MIB document has (or should have) a proper security considerations
  section.


Thanks,
Bert

Checking with WG chair and about the discussion on RFC2074 and RFC2896, which seems inconsistent with the request (from WG) to advance 2074 to DS.