Spencer, thanks for the comments. See below for the details. I reissued a draft with the editorial changes:
http://www.ietf.org/internet-drafts/draft-ietf-forces-mib-08.txt
Regards,
-Robert
"Spencer Dawkins" <spencer@xxxxxxxxxxxxxxxxx> wrote on 09/01/2008 04:07:03 PM:
>
> Gen-ART Review of draft-ietf-forces-mib-07
>
> Spencer Dawkins
>
> to:
>
> ietf
>
> 09/01/2008 04:10 PM
>
> Cc:
>
> "Ross Callon", "General Area Review Team", rha, "Patrick Droz",
> "Jamal Hadi Salim"
>
> 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.
>
I made the suggested changes.
>
> 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.
>
I made the suggested changes.
> 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?
> :-(
I agree, but I'd rather keep this explicit. As for "OtherMsg" vs "OperationalMsg": I'd rather keep it as is, given that we define what are these "other" messages.
>
> 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).
Your interpretation is correct, I changed the text as you suggested.
>
> version object. Optionally, a notification
> (forcesAssociationEntryUpStats) can instead be issued with all
> associated information for this association, except
> forcesAssociationTimeDown.
>
_______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf