Juergen Schoenwaelder writes: >For operational state data, it is not entirely clear where and when >validation will occur or if it will occur at all. In fact, if a system >is in a weird state, it might actually be useful for certain purposes >to expose the weird state. And, as Martin pointed out, inconsistencies >may also result from the technical difficulties to take a consistent >snapshort of a system with several concurrent subsystems. For these >reasons, the assumption that a server always returns valid operational >state data is likely not true.
Amen. It's more important to give data values that are accurate than to give values that can be validated. The client wants to see what's going on right now; raw, real, and not sugar coated. Consider the case where a list is limited to 1000 entries, but as the device is reporting the list, entries are being created and deleted. The result may be that more than 1000 entries are emitted. But we would not want the device to be forced to stop at 1000 just to avoid breaking the constraints of the data model. The client should be prepared to handle operational data that does not conform to the constraints of the data model. Or more exactly, we should be describing the constraints that may be violated and example scenarios where it might occur. Some constraints (identifiers) should never be violated. Thanks, Phil _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
