I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes protocol for the delivery of real-time events to user agents. It uses HTTP/2 server push. It is assumed, but never explicitly stated that at least part of the operational and manageability considerations of HTTP/2 apply. As this document describes a new protocol, the RFC 5707 review applies. Here is my review, using the template described in Annex A of RFC 5706: In what follows my comments are marked DR. Regards, Dan A.1. Operational Considerations 1. Has deployment been discussed? See Section 2.1. * Does the document include a description of how this protocol or technology is going to be deployed and managed? * Is the proposed specification deployable? If not, how could it be improved? * Does the solution scale well from the operational and management perspective? Does the proposed approach have any scaling issues that could affect usability for large-scale operation? * Are there any coexistence issues? DR - Deployment, Scalability, Coexistence are not discussed.  2. Has installation and initial setup been discussed? See Section 2.2. * Is the solution sufficiently configurable? * Are configuration parameters clearly identified? * Are configuration parameters normalized? * Does each configuration parameter have a reasonable default value? * Will configuration be pushed to a device by a configuration manager, or pulled by a device from a configuration server? * How will the devices and managers find and authenticate each other? DR - Installation and initial setup are not discussed. 3. Has the migration path been discussed? See Section 2.3. * Are there any backward compatibility issues? DR - not applicable, as this is a first version 4. Have the Requirements on other protocols and functional components been discussed? See Section 2.4. * What protocol operations are expected to be performed relative to the new protocol or technology, and what protocols and data models are expected to be in place or recommended to ensure for interoperable management? DR - yes, the protocol uses HTTP/2 push mechanisms, this is explained in detail 5. Has the impact on network operation been discussed? See Section 2.5. * Will the new protocol significantly increase traffic load on existing networks? * Will the proposed management for the new protocol significantly increase traffic load on existing networks? * How will the new protocol impact the behavior of other protocols in the network? Will it impact performance (e.g., jitter) of certain types of applications running in the same network? * Does the new protocol need supporting services (e.g., DNS or Authentication, Authorization, and Accounting - AAA) added to an existing network? DR - The introduction mentions optimization of traffic loads as one important goal, but this is not sustained later. Section 6.2 mentions 'operational constraints' with no details or explanation about what it means. Section 7.1 describes management of load, especially in what concerns the high numbers of TCP connections.  6. Have suggestions for verifying correct operation been discussed? See Section 2.6. * How can one test end-to-end connectivity and throughput? * Which metrics are of interest? * Will testing have an impact on the protocol or the network? DR - No. I assume operational procedures for HTTP may apply, but this is not mentioned.  7. Has management interoperability been discussed? See Section 3.1. * Is a standard protocol needed for interoperable management? * Is a standard information or data model needed to make properties comparable across devices from different vendors? DR - No. May be not applicable.  8. Are there fault or threshold conditions that should be reported? See Section 3.3. * Does specific management information have time utility? * Should the information be reported by notifications? Polling? Event-driven polling? * Is notification throttling discussed? * Is there support for saving state that could be used for root cause analysis? DR - No. May be not applicable.  9. Is configuration discussed? See Section 3.4. * Are configuration defaults and default modes of operation considered? * Is there discussion of what information should be preserved across reboots of the device or the management system? Can devices realistically preserve this information through hard reboots where physical configuration might change (e.g., cards might be swapped while a chassis is powered down)? DR - No. A.2. Management Considerations Do you anticipate any manageability issues with the specification? 1. Is management interoperability discussed? See Section 3.1. * Will it use centralized or distributed management? * Will it require remote and/or local management applications? * Are textual or graphical user interfaces required? * Is textual or binary format for management information preferred? 2. Is management information discussed? See Section 3.2. * What is the minimal set of management (configuration, faults, performance monitoring) objects that need to be instrumented in order to manage the new protocol? 3. Is fault management discussed? See Section 3.3. * Is Liveness Detection and Monitoring discussed? * Does the solution have failure modes that are difficult to diagnose or correct? Are faults and alarms reported and logged? 4. Is configuration management discussed? See Section 3.4. * Is protocol state information exposed to the user? How? Are significant state transitions logged? 5. Is accounting management discussed? See Section 3.5. 6. Is performance management discussed? See Section 3.6. * Does the protocol have an impact on network traffic and network devices? Can performance be measured? * Is protocol performance information exposed to the user? 7. Is security management discussed? See Section 3.7. * Does the specification discuss how to manage aspects of security, such as access controls, managing key distribution, etc. DR - No special problems are anticipated, but I would have expected a better documentation on some aspects. I assume that some manageability considerations for HTTP may apply, but this is not mentioned. The protocol uses status codes which can be used for management purposes, but these are not exposed to users. Load implications are discussed in section 7, how to measure load impact is not described, it is probably assumed that HTTP load measurement applies. Securoty and privacy are discussed in a separate section. A.3. Documentation Is an operational considerations and/or manageability section part of the document? DR - Operational considerations are described in Section 7  Does the proposed protocol have a significant operational impact on the Internet? DR - it may have, maybe not on the Internet as a whole, but certainly in networks where this is deployed. Is there proof of implementation and/or operational experience? DR - not in the document, yes in the industry