Generic Event Delivery Using HTTP Push
draft-ietf-webpush-protocol-12

Here is Dan Romascanu's OPS DIR review:

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

Dan Romascanu <dromasca@gmail.com> provided the following opsdir review. which should probably be followed up by the authors for editorial changes / clarifications  but which does not for me raise any show stoppers.



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

Thank you for a well written security considerations section. 

The only thing I might add is a note on the varying levels of security offered by the HTTP authentication methods, which are documented in their RFCs.  Adding just that point to the following (phrased however you'd like) would be helpful:
    A push service MAY
   choose to authorize requests based on any HTTP-compatible
   authorization method available, of which there are numerous options.

The somewhat recent updates to Basic & Digest do a really great job at saying how awful they are and there are some experimental options that offer some promise now.

Maybe stupid questions:

1) Would it be possible for a user agent to use the same push service with multiple application servers? Or is this the case where a subscription set should be used? What happens in this case? Also, is there a possibility for different user agents to use the same push service if they would need to receive the same message from the same server...? Just thinking...

2) section 8.4 says:
"To address this case, the W3C Push API [API] has adopted Voluntary
   Application Server Identification [I-D.ietf-webpush-vapid], which
   allows a user agent to restrict a subscription to a specific
   application server. "
How does the user agent signal to the push service which application servers should be accepted? Did I miss that?

Nit?:
- In the Figure at the beginning of section 2 (which doesn't have a caption btw.) I guess you should use "application server" instead of "application" otherwise the previous definition is confusing...

Also here in section 8 (s/application/application server):
"This includes any communications
   between user agent and push service, plus communications between the
   application and the push service. "

I agree with Alexey on the "well-written document" part, but do have some minor questions.

I noticed that 

   push message subscription:  This resource provides read and delete
      access for a message subscription.  A user agent receives push
      messages (Section 6) using a push message subscription.  Every
      push message subscription has exactly one push resource associated
      with it.
      
and

   push message:  The push service creates a push message resource to
      identify push messages that have been accepted for delivery
      (Section 5).  The push message resource is also deleted by the
      user agent to acknowledge receipt (Section 6.2) of a push message.
      
don't say "A link relation of type ..." about the resource being defined, but 

   push message subscription set:  This resource provides read and
      delete access for a collection of push message subscriptions.  A
      user agent receives push messages (Section 6.1) for all the push
      message subscriptions in the set.  A link relation of type
      "urn:ietf:params:push:set" identifies a push message subscription
      set.

   push:  An application server requests the delivery (Section 5) of a
      push message using a push resource.  A link relation of type
      "urn:ietf:params:push" identifies a push resource.
      
and 

   receipt subscription:  An application server receives delivery
      confirmations (Section 5.1) for push messages using a receipt
      subscription.  A link relation of type
      "urn:ietf:params:push:receipt" identifies a receipt subscription.
      
do. Is that intentional? Or would link relation indentification not be useful for these resources (if you told me that, I'd believe you).

I see that Topic: has no semantics, but I wonder if the example use of Topic in Section 5.4 might be clearer if a different Topic was used - "Topic: upd" looks like "upd" would have semantic meaning, on first reading.

I wondered why the use of subscription sets in

   There are minor differences between receiving push messages for a
   subscription and a subscription set.  If a subscription set is
   available, the user agent SHOULD use the subscription set to monitor
   for push messages rather than individual push message subscriptions.
   
was a SHOULD, and not a MUST. Is this just an efficiency thing, or is it something else? It would be helpful to explain this.

Is there any guidance you could give about the retry mechanism described in this text? How many times, how often, etc. 

   If the push service does not receive the acknowledgement within a
   reasonable amount of time, then the message is considered to be not
   yet delivered.  The push service SHOULD continue to retry delivery of
   the message until its advertised expiration.
   
I'm guessing that

   A push service that does not support reliable delivery over
   intermittent network connections or failing applications on devices,
   forces the device to acknowledge receipt directly to the application
   server, incurring additional power drain in order to establish
   (usually secure) connections to the individual application servers.
   
isn't just about "establish", but "establish and maintain"?

Thanks for the discussion of SOP etc. I found it useful
to help me better understand webpush.