Hi, Robert,
Thanks for the quick response on all the comments - to be explicit, version 8
addresses all my comments, except for one question (below).
It actually could be OK to retain the OtherMsg name and definition, if there is
a reason to do so (one reason might be "deployed systems use this name and
definition"). What I was saying was that it violates the Principle of Least
Astonishment - you could also clearly define "3" as "2", but implementers would
still think "3" was "3" when scanning quickly.
:-)
This is an IETF Last Call review comment, so other reviewers can tell you
"Spencer is worried about nothing", and Gen-ART comments are never blocking
unless an AD includes them in a DISCUSS.
I'll trust that you guys will do the right thing, which might or might not be
to make a change.
Thanks for hearing me out.
Spencer
> 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.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf