Skip to main content

Application-Layer Traffic Optimization
charter-ietf-alto-05

Yes

Martin Duke

No Objection

Erik Kline
Francesca Palombini
Robert Wilton
(Alvaro Retana)

Abstain


Note: This ballot was opened for revision 04-01 and is now closed.

Ballot question: "Do we approve of this charter?"

Martin Duke
Yes
Erik Kline
No Objection
Francesca Palombini
No Objection
Robert Wilton
No Objection
Roman Danyliw
No Objection
Comment (2021-08-26 for -04-01) Not sent
Concur that the scoping/motivation issues noted by Lars, Zahed and Éric
Zaheduzzaman Sarker
No Objection
Comment (2021-08-26 for -04-01) Sent
I see a need for protocol maintenance and potential extensions based on the deployment experience.

However, for future protocol usage I don't think there is a need to a working group. This actually even puts doubts about potential direction that the working group will take, hence not a deterministic focus or item that the working group can deliver on. I mean to say, the future discussions can be separated and might result in - ALTO is not a good fit for the future usages.

Also, as far as I understand ALTO uses the HTTP semantics hence the h2/h3 adoption seems like a implementation choice on the ALTO server. Should there any issues on that adoption, that should be covered in the maintenance and extension bullet based on current deployment.

Having said that, I wont block this rechartering but would suggest to rethink about the focuses set on the charter.
Éric Vyncke
No Objection
Comment (2021-08-25 for -04-01) Sent
While I still wonder whether there is a need for a ALTO 'extension' working group, I do not object the rechartering.

Nevertheless I am puzzled by the apparent conflict of a YANG model milestone and the sentence "This *may* include YANG models and OAM mechanisms"...

About the protocol extensions for  H/2 and H/3, does it imply the use of multistreaming ?

One minor nit: please introduce OAM at first use.
Lars Eggert
(was Block) Abstain
Comment (2021-08-26 for -04-01) Sent for earlier
Overall, I remain unconvinced that there is sufficient work/interest in this space to warrant a chartered WG.

Paragraph 4, comment:
> o Collect implementation deployment and experience. It is hoped that ALTO
> practitioners will report their experiences on the mailing list, and the
> working group will track implementation and deployment reports on a wiki or in
> an Internet-Draft not expected to be published as an RFC.

It's not clear to me why this effort would need a chartered WG vs. just a
mailing list and/or a wiki.

Paragraph 4, comment:
> o Perform protocol maintenance for the existing published protocol.

The default WG for protocol maintenance for TSV-area WGs that close is TSVWG.
Any such maintenance could hence be handled there.

Paragraph 4, comment:
> o Develop operational support tools for ALTO.

I'm not aware of any larger-scale product deployments of ALTO - do some exists?
Otherwise, I question whether operational tools can effectively be developed
without relevant operational experience.

"HTTP ", paragraph 2, comment:
> o Support for modern transport protocols. ALTO only uses the capabilities of
> HTTP version 1. Since then, the IETF has developed HTTP/2 and HTTP/3. The
> working group will develop any necessary protocol extensions and guidance to
> support the use of ALTO over HTTP/2 and HTTP/3.

This seems to fall under the "protocol maintenance" bullet above, so I'm not
clear why this is a separate bullet. As stated above, this could be done in
TSVWG if anyone cared.

"HTTP ", paragraph 1, comment:
> o Future use cases. The working group will provide a forum to discuss possible
> future use cases.

This discussion can be done on a mailing list without the need for a chartered
WG.
Alvaro Retana Former IESG member
No Objection
No Objection (for -04-01) Not sent

                            
Benjamin Kaduk Former IESG member
No Objection
No Objection (2021-08-26 for -04-01) Sent
    o Support for modern transport protocols. ALTO only uses the
    capabilities of HTTP version 1. Since then, the IETF has developed
    HTTP/2 and HTTP/3.  The working group will develop any necessary
    protocol extensions and guidance to support the use of ALTO over HTTP/2
    and HTTP/3.

The IESG is reviewing on this same telechat a "bis" version of BCP56,
guidelines for applications using HTTP.  Let's discuss whether this
language is consistent with the guidance contained therein, which
includes:

   [...] Requiring a particular
   version of HTTP makes it difficult to use in these situations, and
   harms interoperability.  Therefore, it is NOT RECOMMENDED that
   applications using HTTP specify a minimum version of HTTP to be used.

   However, if an application's deployment would benefit from the use of
   a particular version of HTTP (for example, HTTP/2's multiplexing),
   this ought be noted.

My understanding is that typically it suffices to "just use HTTP", and
that there should be no need for ALTO extensions to support running the
protocol over HTTP/2 or HTTP/3.  Any HTTP-version-specific work would
then be about making more effective use of features that are available
in those later versions, without requiring them to be available, or
perhaps (hopefully not) fixing issues with the original ALTO specification
that caused it to not be HTTP-version-agnostic.