Hi Wes,
Thank you for your review. Responses to your comments are inline below.
Ben
> * 1.3 4th paragarph: ...amount of traffic *that* may be delegated.
This change is included in revision 07.
> * general: I assume that there is a business relationship where one
can has a legal
> disincentive to hurt the other? Eg false information about
rates/loads or similar
> are not a concern because the relationship has mechanisms for
general resolution outside
> the scope of the features being transmitted?
I think business ramifications of incorrect information are outside the
scope of this technical specification. To cover such cases, section 1
has some straightforward language that I believe makes it clear that the
information provided via any of the defined communication channels is
advisory in nature and does not represent any type of guarantee or
commitment.
> * 2.1.1.2: the name parameter is discussed as if it's an id, so I'd
either change the property
> name or make the text match the property name. (and I hope no one
would violate that SHOULD
> as it really kills monitoring agents when things names change).
This language has been modified for revision 07.
> * 2.1.1.2: Data percentile: you should (SHOULD) probably use "mean"
instead of "average"
> to be mathematically precise.
This change is included in revision 07.
> * 2.2.1.1: I suggest putting a hyphen in "limit types" to make it
match the property name above.
This change is included in revision 07.
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx