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.