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" <[EMAIL PROTECTED]> 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 mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
