I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-forces-mib-07
Reviewer: Spencer Dawkins
Review Date: 2008-09-01
IETF LC End Date: 2008-09-08
IESG Telechat date: (not known)
Summary: This document is very close to ready for publication as a Proposed
Standard. I have two technical comments below, but both are minor issues
that could resolved in AUTH48 if you think they have merit.
Comments:
OBTW, idnits 2.08.11 runs cleanly (one spurious warning about [RFCzzzz]).
3. Introduction
More specifically, the information in the ForCES MIB module relative
to associations that are up includes:
Spencer (clarity): I'd suggest s/associations/associations between Control
Elements and Forwarding Elements/, unless that's wrong (and if it is, I'd
still suggest "between X and Y", whatever X and Y are). Later uses of
"association" would be fine, of course, this is just providing initial
context.
Spencer (clarity): I'd suggest s/up/in the UP state/, or at least
all-caps-ing UP so it looks like a state.
4. ForCES MIB Overview
The MIB module contains the latest ForCES protocol version supported
by the CE (forcesLatestProtocolVersionSupported). Note that the CE
must also allow interaction with FEs supporting earlier versions.
Spencer (clarity): I'd suggest s/CE/Control Element (CE)/ (and same for FE,
ID, etc.) The reader can figure stuff like this out, but spelling it out for
the reader is just too easy.
o Number of other ForCES messages sent from the CE
(forcesAssociationOtherMsgSent) and received by the CE
(forcesAssociationOtherMsgReceived) since the association entered
the UP state. Only messages other than Heartbeat, Association
Setup, Association Setup Response, and Association Teardown are
counted.
Spencer (technical): I think I know what you're saying here, but you're not
counting "other" messages (because you exclude some of the "other" messages.
The point is that you didn't get into the table with Association
Setup/Association Setup Response, and you leave the table immediately after
Association Teardown, so you don't have to count these messages, isn't it?
:-(
If it's not too late to change this to "OperationalMsg" or something
similar, I'd suggest that, for clarity. If it is too late to change this ...
Finally, the MIB module defines the following notifications:
o Whenever an association enters the UP state, a notification
(forcesAssociationEntryUp) is issued containing the version of the
ForCES protocol running. Note that as CE ID and FE ID are
indexes, they appear in the OID of the ForCES-protocol running-
Spencer (technical): this is intended as a question, because I don't know
MIB practices, but it looks to me like CE ID and FE ID are concatenated into
ONE index, so they aren't "indexes" - right? I'm looking at the INDEX for
"ForcesAssociationEntry".
The rest of the document is pretty clear about this, so I'd suggest "CE ID
and FE ID are concatenated to form the table index", or something similar,
unless I don't understand (it happens).
version object. Optionally, a notification
(forcesAssociationEntryUpStats) can instead be issued with all
associated information for this association, except
forcesAssociationTimeDown.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf