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

[Ballot comment]
Thank you for addressing my DISCUSS points.

I haven't checked whether you addressed all of my earlier comments:

1)

2) In 4.1:

Can 429 be used when no subscription set is specified? (If yes, this should be mentioned in section 4).

3)

4) In general case it is not possible to achieve message reliability because a push server is allowed to expire messages after they were accepted for delivery due to overload. (Similarly for forced subscription expiration.) I don't think the document makes this clear in Section 7.4.

5)

[Ballot discuss]

(1) This might just me being confused (in which case,
sorry) but I'm not quite clear on how with works with the
SOP.  Given you (reasonably) recommend a different port
(which is a different origin than 443) are you saying
here that the SOP doesn't apply to the client? (Well,
actually you don't say, so I'm not sure:-) If the SOP
applies, how is the port change handled? If the SOP does
not apply, then what does? (Given that I assume some UAs
at least will not change their handling of the SOP no
matter what we say here.)

(Discuss points 2-4 cleared)

[Ballot 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

[Ballot discuss]

Apologies if some of this is a bit wrong, I had to review
this while not at a keyboard so I might make a booboo or
two mapping my mental notes to text:-) Apologies also if
some of the earlier discussion affects these, I didn't
get a chance to check the PRs created as a result of
other IESG comments.

(1) This might just me being confused (in which case,
sorry) but I'm not quite clear on how with works with the
SOP.  Given you (reasonably) recommend a different port
(which is a different origin than 443) are you saying
here that the SOP doesn't apply to the client? (Well,
actually you don't say, so I'm not sure:-) If the SOP
applies, how is the port change handled? If the SOP does
not apply, then what does? (Given that I assume some UAs
at least will not change their handling of the SOP no
matter what we say here.)

(2) So-called "capability URLs" (is that a new term here?
seems like it could be the topic for a useful
informational rfc) are clearly weak, but also clearly as
good as we'll get for some things.  However, those also
become known over time, (in which case they are toast;-)
so why don't you need to provide a way for a push service
to say "hey, instead of  in future you'll need
to use "? If that could be done as an extension
later, then I'd be ok with that in terms of clearing the
discuss, but then I think you'd need to mention it, so
that applications and UAs don't build in an assumption
that these URLs are fixed for all time (while also
needing to be kept "secret" as with other bearer tokens).

(3) Why is it not correct to encourage mutual-auth TLS
for the application to push-service connections?  I'm not
arguing to make that mandatory, but it's not that hard in
many cases and is very useful, esp since without some
client auth just knowing the URL will often enable a
sender to send a crap load of updates to possibly many
bandwidth/power-challenged UAs. (This is only a discuss
because of that potential DoS vector.)

(4) Is it really honest to say that the W3C Push API,
webpush encryption and vapid are only informative
references? The first seems easy to make normative, the
second I think really needs to exist before we ought
recommend this all get out into the wild and I'm not
clear if one could sensibly make a service for this
without the 3rd. Yes that might add some delay to the RFC
being issued, but that might be the right thing to do.
Why is it right to not wait on those two IDs and the w3c
rec? This is mainly a discuss in case the answer is "we
know nobody's gonna do webpush-encryption ever" in which
case I'd like to be convinced that implementing and
deploying based on this draft without reading those
references defines a good standard. I'm not saying that
it does not, I'm saying I'm not yet convinced.

[Ballot comment]


- Thanks for the MUST use TLS. That's totally necessary
here. (Even if maybe not sufficient:-)

- I just want to check this is correct: I think it'd be
potentially useful to be able to pad the traffic here
with NOOP pushed messages. The argument is that the
existence of a message may sometimes be the same as
knowing the message content and the cost of turning on
the radio to even check is no different from checking and
getting a NOOP pushed message, so there's no major cost
to a reasonably sized NOOP message that's only there for
traffic padding.  (While padding at other layers can also
be done, I think we do not know enough today to say at
which layers traffic padding is most useful, and we
therefore ought define it where we can.) That said, I
think one could later define a new "OnlyKidding" Urgency
or Topic (see 9.1) that'd do the job. If that's right,
consider this me asking if anyone'd like to do that
later? If that's wrong, then consider this me asking:
"how can I effectively pad traffic at this layer?"

- section 6: (A nit) I think this could be clearer if you
better explained how the subscriptions and push messages
are correlated. While the current text is fine, since
it's clear eventually from the examples, it might be
better to not assume so much familiarity with h2.

[Ballot comment]
Dan Romascanu  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

[Ballot comment]
Thanks for a well written document. I have a few questions on one topic, for which the answers may be obvious to people other than me:

In section 8, 2nd paragraph: "Applications using this protocol MUST use mechanisms that provide
  confidentiality, integrity and data origin authentication."

What must it use those mechanisms for? Are we talking about communication between the UA and app servers? Are we just talking about data in motion?  As much as I like to see such requirements in general, is it reasonable for webpush to state requirements on the internal operation of the application?

[Ballot comment]
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"?

[Ballot comment]
1)

2) In 4.1:

Can 429 be used when no subscription set is specified? (If yes, this should be mentioned in section 4).

3) In 6.1: ":link" is included in the PUSH_PROMISE and not the HEADERS block (when compared to section 6). Is this intentional or should one of the examples be fixed?

4) In general case it is not possible to achieve message reliability because a push server is allowed to expire messages after they were accepted for delivery due to overload. (Similarly for forced subscription expiration.) I don't think the document makes this clear in Section 7.4.

5)

[Ballot comment]
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.

[Ballot comment]
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. "

[Ballot comment]
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? Happen hapens 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...?

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 shuld be accpeted? 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 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. "

[Ballot discuss]
This is generally a well written document, but I have a small list of issues (which should be easy to address) I would like to discuss before recommending its approval for publication:

1) In 5.2: is there upper limit on the TTL? The ABNF doesn't restrict the value, but it is important for interoperability

2) In 5.3: urgency is defined as a list of one or more values. The description says that it defines the lowest value allowed. There is also a sentence prohibiting multiple values. Why is this a set and how would multiple values be interpreted?

3) In 6:

I don't know where the ":link" Pseudo-Header field came from. Can you clarify where it is defined?

[Ballot comment]
1)
I see you defined a new HTTP Header Field "Urgency". Can you reuse email header field "Priority" instead (possibly extending it)
      Can be 'normal', 'urgent', or 'non-urgent' and can influence
      transmission speed and delivery.
?

2) In 4.1:

Can 429 be used when no subscription set is specified? (If yes, this should be mentioned in section 4).

3) In 6.1: ":link" is included in the PUSH_PROMISE and not the HEADERS block (when compared to section 6). Is this intentional or should one of the examples be fixed?

4) In general case it is not possible to achieve message reliability because a push server is allowed to expire messages after they were accepted for delivery due to overload. (Similarly for forced subscription expiration.) I don't think the document makes this clear in Section 7.4.

5) In 9.3:

Contact: IETF Chair

- I think you should point to the WG mailing list or IESG as a whole. IETF Chair has other things to do than answer questions about IANA port registration :-).

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-webpush-protocol-10.txt. If any part of this review is inaccurate, please let us know.

We have a question about one of the actions requested in the IANA Considerations section of this document.

Upon approval of this document, we understand that there are four registry actions to complete.

First, in the Permanent Message Header Field Names subregistry of the Message Headers registry located at:

https://www.iana.org/assignments/message-headers/

three, new message headers are to be registered as follows:

Header Field Name: TTL
Template:
Protocol: http
Status: standard
Reference: [ RFC-to-be ]

Header Field Name: Urgency
Template:
Protocol: http
Status: standard
Reference: [ RFC-to-be ]

Header Field Name: Topic
Template:
Protocol: http
Status: standard
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 5226) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Second, a new registry is to be created called the Web Push Identifiers registry.

QUESTION -> Where should this new registry be located? Is it a new registry on the list of all IANA maintained protocol parameter registries or is it a subregistry of an existing registry? If it is a subregistry of an existing registry, in which registry will it be contained?

We understand that the new registry is to be managed via IETF review as defined in RFC 5226.

There are initial registrations in the new registry as follows:

URN Description Reference
----------------------------+-------------------------------------------------------------------+--------------
urn:ietf:params:push This link relation type is used to identify a resource for sending [ RFC-to-be ]
push messages.
urn:ietf:params:push:set This link relation type is used to identify a collection of push [ RFC-to-be ]
message subscriptions.
urn:ietf:params:push:receipt This link relation type is used to identify a resource for [ RFC-to-be ]
receiving delivery confirmations for push messages.

Third, in the IETF URN Sub-namespace for Registered Protocol Parameter Identifiers subregistry of the Uniform Resource Name (URN) Namespace for IETF Use registry located at:

https://www.iana.org/assignments/params/

a single, new parameter identifier will be registered as follows:

Registered Parameter Identifier: push
Reference: [ RFC-to-be ]
IANA Registry Reference: [ URL-to-be-determined ]

Fourth, this document requests that the IANA Services Operator register system port number 1001. However, we cannot reserve specific numbers.

We can make a temporary one-year early allocation, to be marked "TEMPORARY" in the registry, which could be renewed for another year if this I-D has not yet been approved for publication by the allocation's expiration date. This procedure is described in RFC 7120. In short, after obtaining approval from the group and the AD, the webpush chairs should send a request for early allocation of system port number 1001 to iana@iana.org.

We understand that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

Please note that specific values cannot be reserved. However, early allocation is available for some types of registrations. For more information, please see RFC 7120.

Thank you,

Sabrina Tanamal
IANA Services Specialist

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: alissa@cooperw.in, shida@ntt-at.com, "Shida Schubert" , draft-ietf-webpush-protocol@ietf.org, webpush-chairs@ietf.org, webpush@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Generic Event Delivery Using HTTP Push) to Proposed Standard


The IESG has received a request from the Web-Based Push Notifications WG
(webpush) to consider the following document:
- 'Generic Event Delivery Using HTTP Push'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-10-11. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  A simple protocol for the delivery of real-time events to user agents
  is described.  This scheme uses HTTP/2 server push.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-webpush-protocol/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-webpush-protocol/ballot/


No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc2818: HTTP Over TLS (Informational - IETF stream)
This reference is already listed in the acceptable Downref Registry.

1. Summary

The document shepherd is Shida Schubert. The responsible Area Director is Alissa Cooper.

This document defines simple protocol for the delivery of real-time events to user agents (web browsers etc.), using HTTP/2 server push. The working group is quite sure that this will be a useful Standards Track extension.

2. Review and Consensus

The document has progressed and iterated very rapidly on github and through discussion on the mailing list since its inception in June of 2015 and has gone through two WGLCs and this version has had a rough consensus of the WG.

Many of the contributors are those from major browser vendors (Google, Microsoft, Mozilla) but many from service provider and server software manufacturers have been contributing to stabilize the specification as well. This specification has been implemented and deployed in part and some deviation of this specification has been deployed for some time in production environment supporting the Tao of IETF both in rough consensus and a running code.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

- Proposed Standard
- The title page header indicates that it is a standard-track.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

This document defines a protocol which enables application server upon having consensus from the user agent (a subscription) to push an event-driven message called a push message (receipt of a call, a notification from a bank to authorize a transaction) through an intermediate service called push service that manages the subscription state and delivery of the push message.


(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document shepherd has read the draft and is confident that this document is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

We had contributors heavily involved in the development of HTTP2 (which the specification depends on) to reviewing and actively contributing to the draft.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

Irrelevant as no IPR disclosures have been filed.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The WG as a whole understand and agree with the current standing of specification.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summaries the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

We had one individual expressed discontent as the main driver/contributors of the draft are from major browser vendors. The same individual had some issue with lack of use-case specific feature (having the ability to send broadcast style push messages) built into the protocol. As the shepherd of this document, as enough contributors from non-major browser vendors and potential users of the protocol were involved and were content with the document, I believe one individual's discontent should not defer the progress of the document. As for the lack of feature to support particular use-case this individual had raised, the specification is able to support such use-cases without any protocol mechanism, I see no reason to bloat the specification without a consensus to add such feature.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.


== Missing Reference: 'RFCthis' is mentioned on line 1217, but not defined

RFCthis will be replaced with the RFC number of this specification once it's approved.

-- Possible downref: Non-RFC (?) normative reference: ref. 'CAP-URI'

This is not a downref.

** Downref: Normative reference to an Informational RFC: RFC 2818

RFC2818 is the specification which defines HTTPS which this specification normatively depends on (non-HTTPS allowed), so this again is not a downref.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

N/A

(13) Have all references within this document been identified as either normative or informative?

YES

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No problem here.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

Yes, RFC2818 which defines HTTPS (HTTP over TLS).

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

All the extensions defined in the draft are listed and specified in IANA consideration sections.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

Not relevant. The web push identifiers registration creates a sub-namespaces which follows the guidance of RFC3553 (requiring IETF consensus).