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(_at_)wonderhamster(_dot_)org> 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
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf