N implementation. The volume of this category of messages is expected to be on the average, mostly in low kilobytes/s range for any given producer. The other characteris- tic of such messages is that they will be typically identified within the integrated network YANG model's defining configuration and operational state. This set of messages is also considered historical in most cases, often generated as a result of onboard processing; or they are transactional in nature, and at best might only represent close to real-time status. 2. High volume message producers. Such producers would include nontraditional streaming data such as anonymized flow records and other types of "raw" data that might be used for closed- loop automation. The volume of this category of messages is expected to be on the average, in the megabytes/second range for any given producer. These messages are also expected to be identified within the integrated YANG model's defining configuration and operational state, with their format conforming to some defined YANG model. This set of messages is consid- ered real-time, or at worst, near-real-time, and their timely delivery to the target is important. Keeping in mind the above considerations, the following choices are specified for telemetry: For traditional low-volume message producers, the use of NETCONF/YANG or RESTCONF/YANG is recommended b. For diagnostic related low-volume, one-time message producers, the use of NETCONF/ YANG or RESTCONF/YANG is recommended C. For the high-volume message producers, Apache AVRO or functionally equivalent protocols such as gRPC [12] with JSON object payload is recommended It is expected that over time, a single solution might be picked to meet all telemetry requirements, but given the newness of these technologies, the above two selections will give us the flexibility to grow each message domain into maturity. While a preference is indicated for telemetry solutions, much work needs to be done to qualify such solutions and one can expect further refinements in