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.
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art