Subject: [Webpush] Benoit Claise's No Objection on draft-ietf-webpush-protocol-11: (with COMMENT)

From: "Benoit Claise" <[email-masked]>
Date: Thu, 13 Oct 2016 06:36:59 -0700

Benoit Claise has entered the following ballot position for
draft-ietf-webpush-protocol-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-webpush-protocol/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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

---

From: Martin Thomson <[email-masked]>
Date: Fri, 14 Oct 2016 14:39:33 +1100

> draft-ietf-webpush-protocol-11: No Objection
[...]
> Here is Dan Romascanu's OPS DIR review:

I have confess, I don't see an awful lot of actionable material in
this review.  I worry that RFC 5706 isn't an entirely appropriate
template for a review of this sort of thing.  I will concede that the
level of consistency across the industry when it comes to managing and
operating HTTP servers and services is almost uniformly inconsistent.

Dan does observe that the draft doesn't mention that typical HTTP
operational practices apply; it was my understanding that this was
assumed to be obvious enough to omit.

(I'm happy to have a more involved conversation about operational and
management concerns with push services, but it's probably something
that is better done with a different CC list.)

---

From: Benoit Claise <[email-masked]>
Date: Fri, 14 Oct 2016 12:38:35 +0200

Martin,

Here is the high level message: no show stopper here from my 
perspective, but from an OPS point of view it could be better documented.

Regards, Benoit
> .

---

From: Dan Romascanu <[email-masked]>
Date: Fri, 14 Oct 2016 18:10:16 +0300

Hi,

I agree with Benoit that the document in its current phase does not seem to
include any show stopper. As the OPS-DIR reviews are written to help the
OPS ADs, its up to them if the lack of some of the operational and
manageability considerations is critical for such documents.

I do with however to express my reservations about Martin's statement that
the would not be 'an awful lot of actionable material in
this review'. The review clearly points to the lack of considerations
related to a number of operational and manageability aspects like
scalability, coexistence, initial setup, fault management, etc. One can
decide and be explicit or not about dealing with these, but how to fix the
lack of documentation about these aspects is actionable in my opinion.

I also do not see why RFC 5706 would not apply for such a document that
describes a standards track IETF protocol extension. OPS-DIR reviewers are
referred to RFC 5706 for such documents.

Also, I disagree with the statement that '[HTTP operational practions] ...
this was
assumed to be obvious enough to omit.' The Security Consideration section
starts with the sentence:

> This protocol MUST use HTTP over TLS [RFC2818] following the

   recommendations in [RFC7525].

Security considerations are based on previous documents and this is
explicitly stated. There is no reason not to state explicitly the same
for the manageability considerations

Regards,

Dan

On Fri, Oct 14, 2016 at 1:38 PM, Benoit Claise <[email-masked]> wrote:

> Martin,
>
> Here is the high level message: no show stopper here from my perspective,
> but from an OPS point of view it could be better documented.
>
> Regards, Benoit
>