Skip to main content

Application-Layer Traffic Optimization (ALTO) Incremental Updates Using Server-Sent Events (SSE)
draft-ietf-alto-incr-update-sse-22

Revision differences

Document history

Date Rev. By Action
2020-10-29
22 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2020-08-24
22 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2020-05-01
22 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2020-04-06
22 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2020-04-06
22 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2020-04-06
22 (System) IANA Action state changed to In Progress from Waiting on Authors
2020-04-03
22 Tero Kivinen Closed request for Last Call review by SECDIR with state 'Overtaken by Events'
2020-04-03
22 Tero Kivinen Assignment of request for Last Call review by SECDIR to Dan Harkins was marked no-response
2020-03-26
22 (System) IANA Action state changed to Waiting on Authors
2020-03-25
22 (System) RFC Editor state changed to EDIT
2020-03-25
22 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2020-03-25
22 (System) Announcement was received by RFC Editor
2020-03-24
22 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2020-03-24
22 Amy Vezza IESG has approved the document
2020-03-24
22 Amy Vezza Closed "Approve" ballot
2020-03-24
22 Amy Vezza Ballot approval text was generated
2020-03-24
22 Mirja Kühlewind IESG state changed to Approved-announcement to be sent from Approved-announcement sent
2020-03-24
22 Mirja Kühlewind IESG state changed to Approved-announcement sent from Approved-announcement to be sent::AD Followup
2020-03-20
22 Y. Richard Yang New version available: draft-ietf-alto-incr-update-sse-22.txt
2020-03-20
22 (System) New version approved
2020-03-20
22 (System) Request for posting confirmation emailed to previous authors: "Y. Yang" , Wendy Roome
2020-03-20
22 Y. Richard Yang Uploaded new revision
2020-03-19
22 (System) Request for posting confirmation emailed to previous authors: Wendy Roome , "Y. Yang"
2020-03-19
22 Y. Richard Yang Uploaded new revision
2020-03-19
22 (System) Request for posting confirmation emailed to previous authors: Wendy Roome , "Y. Yang"
2020-03-19
22 Y. Richard Yang Uploaded new revision
2020-03-19
21 (System) Sub state has been changed to AD Followup from Revised ID Needed
2020-03-19
21 Y. Richard Yang New version available: draft-ietf-alto-incr-update-sse-21.txt
2020-03-19
21 (System) New version approved
2020-03-19
21 (System) Request for posting confirmation emailed to previous authors: "Y. Yang" , Wendy Roome
2020-03-19
21 Y. Richard Yang Uploaded new revision
2020-03-12
20 Cindy Morgan IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation
2020-03-12
20 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2020-03-12
20 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2020-03-12
20 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund
2020-03-11
20 Adam Roach
[Ballot comment]
Thanks for the work on this document. I strongly agree with Suresh’s first point, regarding the restatement of the merge algorithm. I have …
[Ballot comment]
Thanks for the work on this document. I strongly agree with Suresh’s first point, regarding the restatement of the merge algorithm. I have one additional comment:

Section 3.1.2.1:

          "ipv4" : [ "192.0.2.0/24", "198.51.100.0/25",
                      "193.51.100.0/25" ],

The address "193.51.100.0" is from a block allocated to the University of Paris. Please change it to an RFC 5737 documentation address. (This occurs twice in the document)
2020-03-11
20 Adam Roach Ballot comment text updated for Adam Roach
2020-03-11
20 Adam Roach
[Ballot comment]
Thanks for the work on this document. I strongly agree with Suresh’s first point, regarding the restatement of the merge algorithm. I have …
[Ballot comment]
Thanks for the work on this document. I strongly agree with Suresh’s first point, regarding the restatement of the merge algorithm. I have one additional comment:

Section 3.1.2.1:
          "ipv4" : [ "192.0.2.0/24", "198.51.100.0/25",
                      "193.51.100.0/25" ],

The address "193.51.100.0" is from a block allocated to the University of Paris. Please change it to an RFC 5737 documentation address. (This occurs twice in the document)
2020-03-11
20 Adam Roach [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach
2020-03-11
20 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2020-03-11
20 Benjamin Kaduk
[Ballot comment]
Thanks for your response to the genart reviewer; I'm happy to see that
change staged for the next version.

It's a bit interesting …
[Ballot comment]
Thanks for your response to the genart reviewer; I'm happy to see that
change staged for the next version.

It's a bit interesting to see that we present JSON merge patch and JSON
patch in the reverse order in which they were defined (RFC 7396/7386 vs.
6902).

It's very surprising to me that we replicate the algorithm for JSON
merge patch and SSE but just refer to RFC 6902 for the JSON patch
algorithm.

What happens if either party closes the update stream without the proper
clean-up message(s)?

Section 1

  considerations by both ALTO servers and clients; Section 13 discusses
  a design feature that is not supported; Section 10 discusses security
  issues; The last two sections review the requirements for future ALTO
  services to use SSE and IANA considerations, respectively.

I think this last remark perhaps should not have survived a section
reordering to put the not-supported design feature (section 13) last.

Section 2

  Stream Control Server: An stream control server providing the stream
  control service.

Perhaps we could avoid defining a "stream control server" as a "stream
control server" that does some things.

  Control Update Message: A control update message is a message in an
  update stream for the update stream server to notify the ALTO client
  of related control information of the update stream.  The first
  message of an update stream is a control update message and provides
  the URI using which the ALTO client can send stream control requests
  to the stream control server.  Additional control update messages in
  an update stream allow the update stream server to notify the ALTO
  client of status changes (e.g., the server will no longer send
  updates for an information resource).

The way this is written makes me want to double-check that I have the
flow/terminology right: there's an update stream of update messages from
server to client, that can include data updates but also can include
control update messages.  Control update messages give the client
information about the stream control service, potentially distinct from
the (regular) update service, and the client sends requests on the
stream control service, that are expected to result in changes to what
the server sends through the (regular) update service?  Would it ever
happen that a server sends a message on the control service connection, or
that a control update message is present on the control service?

Section 3.1

Is it worth noting an explanation of why the HTTP PATCH method is
unsuitable for ALTO SSE (presumably because it goes client-to-server and
we require the opposite)?

Section 3.1.1

  one JSON value into another.  Specifically, JSON merge patch treats
  the two JSON values as trees of nested JSON objects (dictionaries of

I suggest clarifying "the two JSON values" (e.g., "the old and new JSON
values").

Section 3.3

  Despite the two features of HTTP/2, this design chooses an HTTP/1.x
  based design for the simplicity of HTTP/1.x.  An HTTP/2 based design

I suggest to say "HTTP/1.x-compatible design" rather than "HTTP/1.x
based design" -- the SSE API is part of HTML5, and as such is usable
with both those versions of HTTP (and future versions).

Section 4.1

  An update stream can provide updates to both GET-mode resources, such
  as ALTO network and cost maps, and POST-mode resources, such as ALTO
  endpoint property service.  Also, to avoid creating too many update
  streams, this design allows an ALTO client to use one update stream
  to receive updates to multiple requests.  In particular, the client
  may request to receive updates for the same resource but with
  different parameters for a POST-mode resource.  The updates for each

This implies by omission that update-stream consolidation is not
possible for GET-mode resources or different POST-mode resources; I'd
suggest to reword to clarify that this is in addition to being able to
consolidate updates for multiple resources into a single stream.

  The objective of an update stream is to continuously update the ALTO
  client on data value changes given by the client's requests.  This

nit: "data value changes given by the client's requests" almost reads
like it's the client's requests that are producing the data value
changes, rather than the client's requests indicating which data values
to report changes to.

Section 4.2

  The ALTO client can then use the URI to ask the update stream server
  to (1) send data update messages for additional resources, (2) stop

nit(?): if the client is talking to the stream control server, is it
really asking the *update stream* server to do anything?

Section 5.3

  control-uri:  the URI providing stream control for this update stream
        (see Section 7).  The server MUST send a control update message
        with an URI as the first event in an update stream.  If the URI

It seems like it's worth mentioning whether/when the server can send a
control-uri at other times.


(I agree with Alexey about describing the 'description' as
"human-readable", which it sounds like is going to happen.)

Section 6.3

  If this update stream can provide data update messages with
  incremental changes for a resource, the "incremental-change-media-
  types" field has an entry for that resource-id, and the value is the
  media-type of the incremental change.  Normally this will be

Should this be "media-type or types", since a comma-separated list is
allowed?

  When choosing the media-type to encode incremental changes for a
  resource, the update stream server SHOULD consider the limitations of
  the encoding.  For example, when a JSON merge patch specifies that
  the value of a field is null, its semantics is that the field is
  removed from the target, and hence the field is no longer defined
  (i.e., undefined); see the MergePatch algorithm in Section 3.1.1 on
  how null value is processed.  This, however, may not be the intended
  result for the resource, when null and undefined have different
  semantics for the resource.  In such a case, the update stream server
  SHOULD choose JSON patch over JSON merge patch.

I don't see how this is SHOULD (vs. MUST).  Won't things break if you
don't?

Section 6.5

  add: specifies the resources (and the parameters for the resources)
        for which the ALTO client wants updates.  We say that the add-
        request creates a substream.  The ALTO client MUST assign a
        unique substream-id (Section 5.2) for each entry, and uses those
        substream-ids as the keys in the "add" field.

Unique within what scope?  (Globally unique could prove challenging...)

  incremental-changes:  the ALTO client specifies whether it is willing
        to receive incremental changes from the update stream server for
        this substream.  If the "incremental-changes" field is "true",
        the update stream server MAY send incremental changes for this
        substream (assuming the update stream server supports
        incremental changes for that resource).  In this case, the

Since MAY is not an obligation, I think the parenthetical is not
strictly speaking needed.

        changes" to "false".  An alternative design of incremental-
        changes control is a more fine-grained control, by allowing a
        client to select a subset of incremental methods from the set
        announced in the server's capabilities.  But this adds
        complexity to the server, which is more likely to be the
        bottleneck.  Note that the ALTO client cannot suppress full

I suggest rewording to be more clear that this alternative design is not
part of this specification (and in fact was rejected from
consideration?).

        replacement.  When the ALTO client sets "incremental-changes" to
        "false", the update stream server MUST send a full replacement
        instead of an incremental change to the ALTO client.  The update
        stream server MAY wait until more changes are available, and
        send a single full replacement with those changes.  Thus an ALTO
        client which declines to accept incremental changes may not get
        updates as quickly as an ALTO client which does.

Do we have any requirement that incremental changes be sent "as quickly
as possible" or can they be delayed as well?

Section 6.7.1

  o  The first event MUST be a control update message with the URI of
      the update stream control service Section 7 for this update
      stream.

I thought it was allowed to send a null control-uri in this message.

  o  As soon as possible after the ALTO client initiates the
      connection, the update stream server MUST send a full replacement
      for each resource-id requested with a version tag.  In this case
      the update stream server MAY omit the initial full replacement for
      that resource, if the "tag" field the ALTO client provided for
      that resource-id matches the tag of the update stream's current

This second sentence contradicts the MUST in the first one; please
rephrase to avoid the internal inconsistency.  (Also, please clarify
what "this case" is, since we haven't mentioned a specific one by that
point in the text.)

  o  If this update stream provides update for resource-ids and R0 and
      R1, and if R1 depends on R0, then the update stream server MUST

nit: s/update/updates/

Section 6.7.2

  A update stream server MAY offer several different update stream
  resources that provide updates to the same underlying resource (that
  is, a resource-id may appear in the "uses" field of more than one
  update stream resource).  In this case, those update stream resources
  MUST return the same update data.

The phrase "update data" is used only once in this document, and in
light of the previous discussion about sending the "same updates" but
potentially different patch events, it seems that greater specificity is
called for in what is intended here.

Section 6.7.3

  JSON Patch and Merge Patch provide the incremental encoding benefit
  but can be applied to only a single JSON object.  If an update stream
  service (1) supports a resource providing a multipart media type and
  (2) specifies an incremental media type for the resource in its
  capabilities, the server MUST (1) use substream-id.content-id in its
  `event` field, (2) include the content-id in the multipart message,
  and (3) the content identified by the content-id must be a single
  JSON object.

Which message is "the multipart message"?  Is it on the update stream?

Section 7

  An stream control service allows an ALTO client to remove resources

nit: s/An/A/

Section 7.1

I agree with Alexey to reference RFC 3986 here.

  It is expected that the update stream server will assign a unique
  stream id to each update stream instance and will embed that id in
  the associated stream control URI.  However, the exact mechanism is
  left to the update stream server.  ALTO clients MUST NOT attempt to
  deduce a stream id from the control URI.

Is this stream ID used for anything outside of the update stream
server's internal processing?

  To prevent an attacker from forging a stream control URI and sending
  bogus requests to disrupt other update streams, stream control URIs
  SHOULD contain sufficient random redundancy to make it difficult to
  guess valid URIs.

I think this needs to be a MUST.
It is probably also worth referencing
https://www.w3.org/TR/capability-urls/ .

Section 7.5

  An stream control service accepts the same input media type and input

nit: s/An/A/

Section 7.6

  o  If any substream-id in the "remove" field was not added in a prior
      request, the error code of the error message MUST be
      E_INVALID_FIELD_VALUE; the "field" field SHOULD be "remove" and
      the "value" field SHOULD be the array of the invalid substream-

nit: s/the array/an array/; we are defining this array for the first
time.

      id in the same request.  However, it is legal to remove a
      substream-id twice.

I suggest making this requirement to track
previously-used-but-now-closed substream-ids more explicit.  (It also
comes uo for the next bullet point.)

  o  If any substream-id in the "add" field has been used before in
      this stream, the error code of the error message MUST be
      E_INVALID_FIELD_VALUE, the "field" field SHOULD be "add" and the
      "value" field SHOULD be the array of invalid substream-ids.

nit: s/the array of/an array of the/ (same reasoning as before)

Section 8

[Just noting that I, as well, did not perform a detailed check of the
examples.]

Section 8.4

  If the ALTO client needs the "bandwidth" property for additional
  endpoints, the ALTO client can send an "add" request on the stream
  control URI:

The "add" request also includes a priv:ietf-load request that we don't
mention here.

Section 9.3

  An update stream server can avoid such issues by offering update
  streams only for filtered cost maps which do not allow constraint
  tests.

Maybe say something about "having to handle such complicated behavior"
instead of "such issues" (which are not particularly clearly indicated)?

Section 10

I greatly appreciate the way these security considerations are framed,
fiting into the context of the base protocol and then with the
additional risks discussed separately; thank you!


Is there anything interesting to say about this mechanism making it
easier to use an updated resource with a stale version of a resource
used by that first resource?

With the possibility for the update server and stream control server to
be different entities, there is a risk of information skew or
communications breakdown between them, as well as invalid or spoofed
messages claiming to be on that private communications path.  It would
be worth a brief discussion of what sort of problems can arise from that
separation of roles.

Just to check: SSE guarantees that we get events in order, so there are
no reordering considerations within a stream.  IIRC we did have some
discussion about synchronization of the same updates appearing on
multiple streams and of dependent updates within a single stream, which
should take care of the main points in this space.

I was also not able to read very closely the SSE spec, but it sounded
like perhaps the client-side implementation was allowed (or required?)
to introduce linefeed characters into the data buffer for the event in
question, e.g., to reflect the line breaks in the actual transferred
encoding.  Do we need to say anything about the sender behavior to avoid
putting line breaks in places that would have semantic consequences for
the ALTO updates?

Section 10.1

  To avoid these attacks on the update stream server, the server SHOULD
  choose to limit the number of active streams and reject new requests
  when that threshold is reached.  An update stream server SHOULD also

This transfers the attack from the update server to the honst clients
trying to use it (as noted in the following paragraph); it may be
possible to use somewhat more clever logic involving IP reputation,
rate-limiting, and compartmentalizing the overall threshold into smaller
thresholds that apply to subsets of potential clients.  (Client
authentication is also a potential mitigation for some of these attacks,
as is mentioned in the following paragraph.)  None of this is
necessarily incompatible with the current "SHOULD choose to limit"
guideline, of course, though we may want to give a bit more sense of the
nuances involved.

Section 10.2

  Also, under overloading, the client may no longer be able to detect
  whether an information is still fresh or has become stale.  In such a
  case, the client should be careful in how it uses the information to
  avoid stability or efficiency issues.

Is it possible to get into a state where stale ALTO data causes a client
to behave in a way worse for the network than not using any ALTO data at
all?

Section 10.3

I thought https was a MUST for ALTO, which would provide the needed
confidentiality even in the absence of mutual authentication.

Section 11

  At the low level encoding level, new line in SSE has its own
  semantics.  Hence, this design requires that resource encoding does
  not include new lines that can confuse with SSE encoding.  In
  particular, the data update message MUST NOT include "event: " or
  "data: " at a new line as part of data message.

It may also be worth forbidding these not at a new line, since a modular
server implementation might apply an arbitrary line-breaking policy.

Section 13

I suggest adding a little more introduction at the start to give the
background that the following description is a protocol design and
considerations that could have been used, but was rejected.
2020-03-11
20 Benjamin Kaduk [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk
2020-03-11
20 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2020-03-11
20 Alexey Melnikov
[Ballot comment]
Thank you for your document. It was generally a pleasure to read. I have a few minor things that I would like to …
[Ballot comment]
Thank you for your document. It was generally a pleasure to read. I have a few minor things that I would like to discuss before recommending approval of the document:

5.3.  ALTO Control Update Message

  description:  a non-normative text providing an explanation for the
        control event.  When an update stream server stops sending data
        update messages for a resource, it is RECOMMENDED that the
        update stream server use the description field to provide
        details.

I think you should make it more explicit that this is human readable.

I am not going to insist on using language tags, because I don't think this is going to work for messages generated by developers for developers.


6.7.1.  Event Sequence Requirements

  o  When the ALTO client uses the stream control service to stop
      updates for one or more resources (Section 7), the ALTO client
      MUST send a stream control request.  The update stream server MUST
      send a control update message whose "stopped" field has the
      substream-ids of all active resources.

"Active" or "stopped"? If the former, then the name of the field is misleading.
If the latter, than the above sentence needs to be corrected.


7.1.  URI

  The ALTO client MUST evaluate a non-absolute control URI (for
  example, a URI without a host, or with a relative path)

You might want to add a reference to RFC 3986 here, as it explains relevant concepts.

  in the context of the URI used to create the update stream.

7.6.  Response

  If the request is valid but the associated update stream has been
  closed.  The stream control server MUST return an HTTP "404 Not
  Found".

I think you have 2 sentences where you really wanted to use 1. I.e, this should read:

  If the request is valid but the associated update stream has been
  closed than the stream control server MUST return an HTTP "404 Not
  Found".


With recent IESG recommendations to always use encryption, I recommend you use https:// instead of http:// URIs in examples.


Media Type registrations should use "[RFCXXXX]" or similar convention instead of just saying "this document",
because media type registrations are cut & pasted to IANA website as separate documents.
2020-03-11
20 Alexey Melnikov [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov
2020-03-11
20 Suresh Krishnan
[Ballot comment]
Section 3.1.1.:
  I feel strongly that this document should not restate the pseudo-code for the JSON merge patch algorithm and should instead …
[Ballot comment]
Section 3.1.1.:
  I feel strongly that this document should not restate the pseudo-code for the JSON merge patch algorithm and should instead use a reference to Section 2 of RFC7396 instead. This will avoid inconsistencies (e.g. note that the pseudo code in this draft is *already different* from that in RFC7396 even though the difference is only the braces) and be amenable to updates to RFC7396.

References:

Is there a reason this document is using the obsoleted JSON reference to RFC7159? Suggest updating the reference to RFC8259.
2020-03-11
20 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2020-03-10
20 Barry Leiba
[Ballot comment]
Just some very minor things here:

Please use the new BCP 14 boilerplate and add a normative reference to RFC 8174.

— …
[Ballot comment]
Just some very minor things here:

Please use the new BCP 14 boilerplate and add a normative reference to RFC 8174.

— Section 2 —
It’s a small thing, but in the first paragraph is it really useful to list the terms, only to have each one defined right below?  My eye can instead run down the paragraphs and catch the list of terms that way.

— Section 8 —
Just a note that I did not carefully review the examples.

— Section 12 —
Please add “Fragment identifier considerations” to the templates, as required by RFC 6838.  It would also not be a bad idea to separate the two templates with whitespace or a text paragraph, for readability.
2020-03-10
20 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2020-03-09
20 Elwyn Davies Request for Last Call review by GENART Completed: Almost Ready. Reviewer: Elwyn Davies. Sent review to list.
2020-03-09
20 Roman Danyliw
[Ballot comment]
** Section 7.1.  “To prevent an attacker from forging a stream control URI and sending bogus requests to disrupt other update streams, stream …
[Ballot comment]
** Section 7.1.  “To prevent an attacker from forging a stream control URI and sending bogus requests to disrupt other update streams, stream control URIs SHOULD contain sufficient random redundancy to make it difficult to guess valid URIs.”

-- This approach provides no protection against an on-path attacker if https isn’t used (Section 8.3.5 of RFC7285 only says that “ALTO server implementations … MUST support the ‘https’ URI scheme”, not MUST use). 

-- The words “random redundancy” wasn’t clear to me, but contextually, I understood the intent.

** Section 9.1. Per “For stable resources with minor changes, the update stream server may choose to send incremental changes; for resources that frequently change, the update stream server may choose to send a full replacement after a while.”, it isn’t clear what guidance this is providing as both statements are “mays”.  The server always has the ability to choose the approach of returning the updates.

** Section 9.1.  Per “Other JSON-based incremental change format may be introduced in the future”, this statement doesn’t seem to have value in an archival format without citation.
Section 10.  With the addition of the URI parameter for the stream control service, the attack surface described in Section 15.1.1 of RFC7285 gets larger (as this could cause redirection to a host of choice) – same mitigation though (use TLS).
2020-03-09
20 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2020-03-07
20 Mirja Kühlewind [Ballot Position Update] New position, Yes, has been recorded for Mirja Kühlewind
2020-03-06
20 Mirja Kühlewind Changed consensus to Yes from Unknown
2020-03-06
20 Mirja Kühlewind IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2020-03-06
20 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2020-03-04
20 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2020-03-04
20 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-alto-incr-update-sse-20. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-alto-incr-update-sse-20. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the application registry on the Media Types registry page located at:

https://www.iana.org/assignments/media-types/

two, new media types will be registered as follows:

Name: alto-updatestreamparams+json
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Name: alto-updatestreamcontrol+json
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

The IANA Functions Operator understands that this is the only action 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 meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2020-02-27
20 Jean Mahoney Request for Last Call review by GENART is assigned to Elwyn Davies
2020-02-27
20 Jean Mahoney Request for Last Call review by GENART is assigned to Elwyn Davies
2020-02-26
20 Tero Kivinen Request for Last Call review by SECDIR is assigned to Dan Harkins
2020-02-26
20 Tero Kivinen Request for Last Call review by SECDIR is assigned to Dan Harkins
2020-02-21
20 Amy Vezza Placed on agenda for telechat - 2020-03-12
2020-02-21
20 Amy Vezza IANA Review state changed to IANA - Review Needed
2020-02-21
20 Amy Vezza
The following Last Call announcement was sent out (ends 2020-03-06):

From: The IESG
To: IETF-Announce
CC: draft-ietf-alto-incr-update-sse@ietf.org, alto@ietf.org, ietf@kuehlewind.net, Vijay Gurbani , …
The following Last Call announcement was sent out (ends 2020-03-06):

From: The IESG
To: IETF-Announce
CC: draft-ietf-alto-incr-update-sse@ietf.org, alto@ietf.org, ietf@kuehlewind.net, Vijay Gurbani , alto-chairs@ietf.org, vkg@bell-labs.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (ALTO Incremental Updates Using Server-Sent Events (SSE)) to Proposed Standard


The IESG has received a request from the Application-Layer Traffic
Optimization WG (alto) to consider the following document: - 'ALTO
Incremental Updates Using Server-Sent Events (SSE)'
  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
last-call@ietf.org mailing lists by 2020-03-06. 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


  The Application-Layer Traffic Optimization (ALTO) [RFC7285] protocol
  provides network related information, called network information
  resources, to client applications so that clients can make informed
  decisions in utilizing network resources.  For example, an ALTO
  server can provide network and cost maps so that an ALTO client can
  use the maps to determine the costs between network endpoints when
  choosing communicating endpoints.

  However, the ALTO protocol does not define a mechanism to allow an
  ALTO client to obtain updates to the information resources, other
  than by periodically re-fetching them.  Because some information
  resources (e.g., the aforementioned maps) may be large (potentially
  tens of megabytes), and because only parts of the information
  resources may change frequently (e.g., only some entries in a cost
  map), complete re-fetching can be inefficient.

  This document presents a mechanism to allow an ALTO server to push
  updates to ALTO clients, to achieve two benefits: (1) updates can be
  incremental, in that if only a small s ection of an information
  resource changes, the ALTO server can send just the changes; and (2)
  updates can be immediate, in that the ALTO server can send updates as
  soon as they are available.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-alto-incr-update-sse/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-alto-incr-update-sse/ballot/


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




2020-02-21
20 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2020-02-21
20 Mirja Kühlewind Created "Approve" ballot
2020-02-21
20 Mirja Kühlewind Closed "Approve" ballot
2020-02-21
20 Mirja Kühlewind Last call was requested
2020-02-21
20 Mirja Kühlewind IESG state changed to Last Call Requested from Publication Requested
2020-02-21
20 Mirja Kühlewind Last call announcement was generated
2020-02-21
20 Mirja Kühlewind Ballot has been issued
2020-02-21
20 Mirja Kühlewind Ballot approval text was generated
2020-02-21
20 Mirja Kühlewind [Ballot Position Update] New position, Yes, has been recorded for Mirja Kühlewind
2020-02-21
20 Mirja Kühlewind Created "Approve" ballot
2020-02-21
20 Mirja Kühlewind Ballot writeup was changed
2020-02-20
20 Y. Richard Yang New version available: draft-ietf-alto-incr-update-sse-20.txt
2020-02-20
20 (System) New version approved
2020-02-20
20 (System) Request for posting confirmation emailed to previous authors: "Y. Yang" , Wendy Roome
2020-02-20
20 Y. Richard Yang Uploaded new revision
2020-02-13
19 Vijay Gurbani
Essay style shepherd writeup for draft-ietf-alto-incr-update-sse-19

1. Summary

The document shepherd is Vijay K. Gurbani. The responsible Area Director is
Mirja Kuehlewind.

This document allows …
Essay style shepherd writeup for draft-ietf-alto-incr-update-sse-19

1. Summary

The document shepherd is Vijay K. Gurbani. The responsible Area Director is
Mirja Kuehlewind.

This document allows the base ALTO protocol (RFC 7785) to fetch resources
that have changed in a more optimized manner.

In base ALTO, a client must periodically re-fetch resources that have
changed.  Some resources served by an ALTO server (network maps, for instance)
may be quite large, while the changes to the resources may be fairly localized,
and can be served in an optimal manner (sending diffs, for instance) instead
of having the client fetch the entire updated resource.

This document adds the capability of sending localized diffs in ALTO.

This document is targeted as a Standards Track document (Proposed Standard).
This designation is appropriate as the document contains normative behaviour
and message formats that should be adhered to by the communicating entities
in order to realize the extension.

2. Review and Consensus

ALTO incremental updates is a well known work to the ALTO working group.
The initial work on this started in October 2014; the working group adopted
the work in May 2015 [1], after which it has gone through about 19 revisions
to the current version.  The work is fairly mature and the design tradeoffs
in coming up with an equitable solution to the problem described above are
well documented in the draft.

The first WGLC on version -02 of the draft was held on Jul-2016 [2] and was
reviewed by Mingming Chen and Sebastial Kiesel.  However, it was pointed out
[3] after the WGLC ended that the draft could be made far more general if it
supported additional incremental update encoding options.  The draft,
therefore, continued its journey within the WG instead of being sent out
to the IESG. 

At IETF 99, a hum was taken on whether we should proceed to WGLC on version -07
[4], but the hum did not reach any hard conclusion and the work proceeded
in the
WG.

In an interim ALTO meeting held on Dec-18-2017, the authors indicated that
they were still working on the draft [5].  A second WGLC was held on
Jun-20-2018 [6], and was reviewed by three WG members (Dawn Chan, Kerim
Gokarslan and Isabelle Carson).  Pursuant to the WGLC, version -11 was
released with updates, shortly followed by version -13.  It was determined
that version -13 had some substantive changes in it that it may help in
further review from the WG [7].  Between 2018 and the issuance of a third
WGLC on Nov-14-2019 [8], work progressed on the document.  The third WGLC
resulted in review of the work by Jensen Zhang and me.

There is one known implementation of this draft, this implementation is
related to a paper titled "Steering Hyper-Giant's Traffic at Scale", 
published in the proceedings of ACM CoNEXT 2019 [9].  This implementation
implements the JSON merge patch feature, with the general JSON patch being
on their roadmap [10].

[1] https://mailarchive.ietf.org/arch/msg/alto/1nLabIj25PJz3M0SOuXAAdLlSBs
[2] https://mailarchive.ietf.org/arch/msg/alto/mnuzhFkDTBDTuRMSDIV2GKXk96A
[3] https://mailarchive.ietf.org/arch/msg/alto/XgvZXhr0PsqAU8CGfEwel1ClIBM
[4] https://mailarchive.ietf.org/arch/msg/alto/t_xHbbGE2g51LqI8cfnyIkwt0J4
[5]
https://datatracker.ietf.org/meeting/interim-2017-alto-01/materials/minutes-interim-2017-alto-01-201712180600/
[6] https://mailarchive.ietf.org/arch/msg/alto/NNrG6P7MjRW1GwYbIJFUDi1089k
[7] https://mailarchive.ietf.org/arch/msg/alto/T8NOGMtb_kRrxJtsE0ToosR-JC4
[8] https://mailarchive.ietf.org/arch/msg/alto/hHM_bC1CfwygcxTTm96zBbj7gmo
[9] https://mailarchive.ietf.org/arch/msg/alto/h7QJRu47NbTvfcnW2fveFqCBRdw
[10] https://mailarchive.ietf.org/arch/msg/alto/9IOwXNAxqKp_CwKUPsu54W4lB08

3. Intellectual Property

The entire author team has confirmed conformance with BCP 78/79 with the
shepherd.

4. Other Points
IDNITS reports problems on -18: references were not divided into normative and
informative sections. Authors have corrected this in -19 version.
2020-02-13
19 Vijay Gurbani Responsible AD changed to Mirja Kühlewind
2020-02-13
19 Vijay Gurbani IETF WG state changed to Submitted to IESG for Publication from In WG Last Call
2020-02-13
19 Vijay Gurbani IESG state changed to Publication Requested from I-D Exists
2020-02-13
19 Vijay Gurbani IESG process started in state Publication Requested
2020-02-13
19 Vijay Gurbani
Essay style shepherd writeup for draft-ietf-alto-incr-update-sse-19

1. Summary

The document shepherd is Vijay K. Gurbani. The responsible Area Director is
Mirja Kuehlewind.

This document allows …
Essay style shepherd writeup for draft-ietf-alto-incr-update-sse-19

1. Summary

The document shepherd is Vijay K. Gurbani. The responsible Area Director is
Mirja Kuehlewind.

This document allows the base ALTO protocol (RFC 7785) to fetch resources
that have changed in a more optimized manner.

In base ALTO, a client must periodically re-fetch resources that have
changed.  Some resources served by an ALTO server (network maps, for instance)
may be quite large, while the changes to the resources may be fairly localized,
and can be served in an optimal manner (sending diffs, for instance) instead
of having the client fetch the entire updated resource.

This document adds the capability of sending localized diffs in ALTO.

This document is targeted as a Standards Track document (Proposed Standard).
This designation is appropriate as the document contains normative behaviour
and message formats that should be adhered to by the communicating entities
in order to realize the extension.

2. Review and Consensus

ALTO incremental updates is a well known work to the ALTO working group.
The initial work on this started in October 2014; the working group adopted
the work in May 2015 [1], after which it has gone through about 19 revisions
to the current version.  The work is fairly mature and the design tradeoffs
in coming up with an equitable solution to the problem described above are
well documented in the draft.

The first WGLC on version -02 of the draft was held on Jul-2016 [2] and was
reviewed by Mingming Chen and Sebastial Kiesel.  However, it was pointed out
[3] after the WGLC ended that the draft could be made far more general if it
supported additional incremental update encoding options.  The draft,
therefore, continued its journey within the WG instead of being sent out
to the IESG. 

At IETF 99, a hum was taken on whether we should proceed to WGLC on version -07
[4], but the hum did not reach any hard conclusion and the work proceeded
in the
WG.

In an interim ALTO meeting held on Dec-18-2017, the authors indicated that
they were still working on the draft [5].  A second WGLC was held on
Jun-20-2018 [6], and was reviewed by three WG members (Dawn Chan, Kerim
Gokarslan and Isabelle Carson).  Pursuant to the WGLC, version -11 was
released with updates, shortly followed by version -13.  It was determined
that version -13 had some substantive changes in it that it may help in
further review from the WG [7].  Between 2018 and the issuance of a third
WGLC on Nov-14-2019 [8], work progressed on the document.  The third WGLC
resulted in review of the work by Jensen Zhang and me.

There is one known implementation of this draft, this implementation is
related to a paper titled "Steering Hyper-Giant's Traffic at Scale", 
published in the proceedings of ACM CoNEXT 2019 [9].  This implementation
implements the JSON merge patch feature, with the general JSON patch being
on their roadmap [10].

[1] https://mailarchive.ietf.org/arch/msg/alto/1nLabIj25PJz3M0SOuXAAdLlSBs
[2] https://mailarchive.ietf.org/arch/msg/alto/mnuzhFkDTBDTuRMSDIV2GKXk96A
[3] https://mailarchive.ietf.org/arch/msg/alto/XgvZXhr0PsqAU8CGfEwel1ClIBM
[4] https://mailarchive.ietf.org/arch/msg/alto/t_xHbbGE2g51LqI8cfnyIkwt0J4
[5]
https://datatracker.ietf.org/meeting/interim-2017-alto-01/materials/minutes-interim-2017-alto-01-201712180600/
[6] https://mailarchive.ietf.org/arch/msg/alto/NNrG6P7MjRW1GwYbIJFUDi1089k
[7] https://mailarchive.ietf.org/arch/msg/alto/T8NOGMtb_kRrxJtsE0ToosR-JC4
[8] https://mailarchive.ietf.org/arch/msg/alto/hHM_bC1CfwygcxTTm96zBbj7gmo
[9] https://mailarchive.ietf.org/arch/msg/alto/h7QJRu47NbTvfcnW2fveFqCBRdw
[10] https://mailarchive.ietf.org/arch/msg/alto/9IOwXNAxqKp_CwKUPsu54W4lB08

3. Intellectual Property

The entire author team has confirmed conformance with BCP 78/79 with the
shepherd.

4. Other Points
IDNITS reports problems on -18: references were not divided into normative and
informative sections. Authors have corrected this in -19 version.
2020-02-13
19 Y. Richard Yang New version available: draft-ietf-alto-incr-update-sse-19.txt
2020-02-13
19 (System) New version approved
2020-02-13
19 (System) Request for posting confirmation emailed to previous authors: "Y. Yang" , Wendy Roome
2020-02-13
19 Y. Richard Yang Uploaded new revision
2020-01-23
18 Y. Richard Yang New version available: draft-ietf-alto-incr-update-sse-18.txt
2020-01-23
18 (System) New version approved
2020-01-23
18 (System) Request for posting confirmation emailed to previous authors: "Y. Yang" , Wendy Roome
2020-01-23
18 Y. Richard Yang Uploaded new revision
2019-11-14
17 Vijay Gurbani Issued a second WGLC for 3 weeks, WGLC expires Dec 8, 2019.
2019-11-14
17 Vijay Gurbani Tag Other - see Comment Log cleared.
2019-11-14
17 Vijay Gurbani IETF WG state changed to In WG Last Call from WG Document
2019-11-14
17 Vijay Gurbani
This draft has been in WGLC for a while.  The WGLC under which this draft was ended on July 4, 2018.
The draft has been …
This draft has been in WGLC for a while.  The WGLC under which this draft was ended on July 4, 2018.
The draft has been modified after the WGLC, however, I (vkg) do not believe that the updated draft has received enough eyeballs.
Consequently, I am releasing this document from WGLC and will start a new WGLC on it, after which it can move ahead.
2019-11-14
17 Vijay Gurbani Tag Other - see Comment Log set.
2019-11-14
17 Vijay Gurbani IETF WG state changed to WG Document from In WG Last Call
2019-11-14
17 Vijay Gurbani Notification list changed to "Vijay Gurbani" <vijay.gurbani@gmail.com> from "Vijay Gurbani" <vkg@bell-labs.com>
2019-07-23
17 Y. Richard Yang New version available: draft-ietf-alto-incr-update-sse-17.txt
2019-07-23
17 (System) New version approved
2019-07-23
17 (System) Request for posting confirmation emailed to previous authors: "Y. Yang" , Wendy Roome
2019-07-23
17 Y. Richard Yang Uploaded new revision
2019-03-11
16 Y. Richard Yang New version available: draft-ietf-alto-incr-update-sse-16.txt
2019-03-11
16 (System) New version approved
2019-03-11
16 (System) Request for posting confirmation emailed to previous authors: alto-chairs@ietf.org, "Y. Yang" , Shiwei Chen , Wendy Roome
2019-03-11
16 Y. Richard Yang Uploaded new revision
2018-12-10
15 Y. Yang New version available: draft-ietf-alto-incr-update-sse-15.txt
2018-12-10
15 (System) New version approved
2018-12-10
15 (System) Request for posting confirmation emailed to previous authors: Wendy Roome , "Y. Yang" , Shiwei Chen
2018-12-10
15 Y. Yang Uploaded new revision
2018-12-09
14 Y. Yang New version available: draft-ietf-alto-incr-update-sse-14.txt
2018-12-09
14 (System) New version approved
2018-12-09
14 (System) Request for posting confirmation emailed to previous authors: Wendy Roome , "Y. Yang" , Shiwei Chen
2018-12-09
14 Y. Yang Uploaded new revision
2018-07-23
13 Shiwei Chen New version available: draft-ietf-alto-incr-update-sse-13.txt
2018-07-23
13 (System) New version approved
2018-07-23
13 (System) Request for posting confirmation emailed to previous authors: Wendy Roome , "Y. Yang" , Shiwei Chen
2018-07-23
13 Shiwei Chen Uploaded new revision
2018-07-02
12 Y. Yang New version available: draft-ietf-alto-incr-update-sse-12.txt
2018-07-02
12 (System) New version approved
2018-07-02
12 (System) Request for posting confirmation emailed to previous authors: Wendy Roome , "Y. Yang" , Shiwei Chen
2018-07-02
12 Y. Yang Uploaded new revision
2018-06-20
11 Vijay Gurbani IETF WG state changed to In WG Last Call from WG Document
2018-06-13
11 Shiwei Chen New version available: draft-ietf-alto-incr-update-sse-11.txt
2018-06-13
11 (System) New version approved
2018-06-13
11 (System) Request for posting confirmation emailed to previous authors: Wendy Roome , "Y. Yang" , Shiwei Chen
2018-06-13
11 Shiwei Chen Uploaded new revision
2018-03-18
10 Shiwei Chen New version available: draft-ietf-alto-incr-update-sse-10.txt
2018-03-18
10 (System) New version approved
2018-03-18
10 (System) Request for posting confirmation emailed to previous authors: Wendy Roome , "Y. Yang" , Shiwei Chen
2018-03-18
10 Shiwei Chen Uploaded new revision
2018-03-01
09 Shiwei Chen New version available: draft-ietf-alto-incr-update-sse-09.txt
2018-03-01
09 (System) New version approved
2018-03-01
09 (System) Request for posting confirmation emailed to previous authors: alto-chairs@ietf.org, "Y. Yang" , Wendy Roome
2018-03-01
09 Shiwei Chen Uploaded new revision
2018-01-04
08 Y. Yang New version available: draft-ietf-alto-incr-update-sse-08.txt
2018-01-04
08 (System) New version approved
2018-01-04
08 (System) Request for posting confirmation emailed to previous authors: Wendy Roome , "Y. Yang"
2018-01-04
08 Y. Yang Uploaded new revision
2018-01-04
07 (System) Document has expired
2017-07-03
07 Y. Yang New version available: draft-ietf-alto-incr-update-sse-07.txt
2017-07-03
07 (System) New version approved
2017-07-03
07 (System) Request for posting confirmation emailed to previous authors: Wendy Roome , "Y. Yang"
2017-07-03
07 Y. Yang Uploaded new revision
2017-07-02
06 Y. Yang New version available: draft-ietf-alto-incr-update-sse-06.txt
2017-07-02
06 (System) New version approved
2017-07-02
06 (System) Request for posting confirmation emailed to previous authors: Wendy Roome , "Y. Yang"
2017-07-02
06 Y. Yang Uploaded new revision
2017-03-30
05 Y. Yang New version available: draft-ietf-alto-incr-update-sse-05.txt
2017-03-30
05 (System) New version approved
2017-03-30
05 (System) Request for posting confirmation emailed to previous authors: Wendy Roome , "Y. Yang" , alto-chairs@ietf.org
2017-03-30
05 Y. Yang Uploaded new revision
2017-03-12
04 Y. Yang New version available: draft-ietf-alto-incr-update-sse-04.txt
2017-03-12
04 (System) New version approved
2017-03-12
04 (System) Request for posting confirmation emailed to previous authors: alto-chairs@ietf.org, "Y. Yang" , Wendy Roome
2017-03-12
04 Y. Yang Uploaded new revision
2017-01-16
03 Vijay Gurbani Notification list changed to "Vijay Gurbani" <vkg@bell-labs.com>
2017-01-16
03 Vijay Gurbani Document shepherd changed to Vijay K. Gurbani
2016-09-13
03 Wendy Roome New version available: draft-ietf-alto-incr-update-sse-03.txt
2016-09-13
03 Wendy Roome New version approved
2016-09-13
03 Wendy Roome Request for posting confirmation emailed to previous authors: "Wendy Roome" , "Y. Richard Yang"
2016-09-13
03 (System) Uploaded new revision
2016-04-04
02 Wendy Roome New version available: draft-ietf-alto-incr-update-sse-02.txt
2015-09-29
01 Wendy Roome New version available: draft-ietf-alto-incr-update-sse-01.txt
2015-05-29
00 Vijay Gurbani Intended Status changed to Proposed Standard from None
2015-05-29
00 Vijay Gurbani This document now replaces draft-roome-alto-incr-update-sse instead of None
2015-05-29
00 Y. Yang New version available: draft-ietf-alto-incr-update-sse-00.txt