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

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

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

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.

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

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

[Ballot comment]
[leaving some comments in the datatracker while deciding whether or not
to ballot Block or No Objection]

    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.

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

[Ballot comment]
I don't understand the last milestone/deliverable:

  o Report to the Area Director any use cases that have strong support and a
  realistic chance of implementation and deployment.

Is this report to take a specific form?  What should the AD do with this information?  I believe that if the WG is going to be rechartered again in the future, these use cases will come out naturally -- IOW, I don't see the need to call this out in the charter.

[Ballot comment]
The "Milestones and Deliverables" should probably be converted into
datatracker-native milestones.

  o Provide a place to collect implementation deployment and experience. It is
  hoped that ALTO practioners 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.

I assume this is "an Internet-Draft not expected to be published as an RFC".

  protocol specifications: The working group will develop and publish updates as
  necessary to resolve any interoperability, performance, operational, or
  security, or privacy problems that arise. The working group will also help

(nit) we probably only need one "or" at the end of the list.

  o Develop operational support tools for the ALTO protocol. Based on experience
  from deployments, the advice in RFC 7971, and considering the latest opinions
  and techniques from the Operations and Management Area, the working group will
  develop tools to configure, operate, and manage the ALTO protocol and networks
  that use ALTO. This may include YANG models and OAM mechanisms. The working
  group may also update RFC 7971 in the light of new experience and protocol
  features that were added to ALTO after that RFC was published.

Are IPPM or any other WGs not in OPS going to be worth collaborating with for
this work?

  o Support for modern transport protocols. When work on ALTO began, the protocol
  was supported using HTTP version 1. Since then, the IETF has developed HTTP/2

(nit) "was supported using" may not be conveying the desired meaning (vs "only
supported using", "supported using", "was using", "used", etc.)

  o Conduct a survey of working group participants and the wider community to
  discover ALTO implementation and deployment experience. Record the results in a
  publicly visible wiki.

(The earlier text mentioned wiki or draft, but this only mentions a wiki; it's
probably worth being consistent between mentions.)

  o Develop and standardize at least one OAM mechanism to support ALTO, including
  a YANG model for configuration and management of ALTO servers.

Under what conditions might more than one mechanism be desirable?

[Ballot comment]
About the charter itself:

- The first § is unclear to me about what the "benefit" is for the application.
- Should there be a discussion with the PANRG ?
- as I am afraid that I have no time to read the existing ALTO documents, I really wonder about the privacy aspects of ALTO? (i.e., is it similar to the APN BoF?)

But, the more I read in the IETF-111 minutes and on the mailing list archive, the more I wonder whether ALTO is still research or is deployed (at same scale). If the former, then IETF is the wrong stream/place.

It is unclear to me whether ALTO is actually deployed, so, the first work item is important and could be the gating factor to work on the other work items. OTOH, the 'cost' for the IETF community of a WG is probably not that high (mainly scheduling conflict), so, why not continuing ALTO ?

This is the product of almost year discussing next steps for ALTO. It excludes some ambitious proposals to extend ALTO to new use cases, pending more evidence that ALTO has gained traction in the existing use cases. Therefore, the focus is on maintenance, supportability, and gathering evidence to support further extensions.

[Ballot block]

A pretty temporary BLOCK I hope, just to check the state of
play and most likely to be cleared on the call...

Would it not be worthwhile noting that specific handling of
privacy and information leakage issues should be considered
by the WG? If so I guess some text should be easy to arrive
at. If not, why not?

[Ballot comment]
My fellow ADs have already identified the issues that jumped out at me when I read this, and I support their blocks and comments.

[Ballot block]
I had stopped following ALTO for awhile, but I increasingly get the sense that it is trying to be the Everything Protocol, and that worries me. For example:

(1)
"It is a testament to the flexibility of the ALTO
protocol that it is now being considered as a solution for problems
outside the P2P domain"

We don't usually do PR in our charters, do we? That's what this sounds like to me. "ALTO is being considered as a solution ..." would work fine, I think.

(2)
"Because the issue of third-party
    server discovery is broad and not particular to ALTO, the WG will
    prefer to use server discovery mechanisms produced by other
    working groups especially chartered to do so.  In the absence of
    such existing work, the WG will develop an ALTO-specific
    third-party server discovery mechanism."

I note that this is different from the current ALTO charter, which explicitly left out of scope the creation of a new discovery mechanism. Did the WG analyze existing DNS- and DHCP-based solutions already, as it was chartered to do? What was the result of that?

(3)
"The working group will specify such extension in coordination
    with other working groups that have a focus on the related use
    cases.  The scope of extensions is not limited to those
    identified by the WGs."

Is the scope limited by anything? Which kinds of extensions are out of scope?

(4)
"After these criteria are met, the importance of the data will be
considered for prioritizing standardization work, for example the
number of operators and clients that are likely to be able to provide
or use that particular data."

It seems like the criteria used to evaluate data-related features could also usefully be applied to the earlier bullet points about extensions -- i.e., the number of operators and clients likely to implement and use particular extensions should help determine whether and when to standardize them.

[Ballot block]
    The WG will only consider abstract representation
    of the network layer; it will not consider, nor will it model,
    raw network topology, routing protocols, or RIB data.

The meaning of "abstract representation" is highly ambiguous. What is a
"raw network" in this context? Given that many layer 3 networks are
comprised of virtual links (i.e., multi-hop links in a layer 3 network)
and also of physical links and multi-hop links in layer 2 and layer 1
networks, this text does not tell me what is in scope and what is out of
scope.

It would be helpful to clarify this in terms of what the information is
used for. In the previous ALTO work, the "abstraction" was reachability
or connectivity between P2P service points. That is, the topology that
ALTO delivered indicated the best places to go to for specific content
and the parameters with which that access could be made. If a similar
type of abstraction is intended here, it should be relatively easy to
capture it in the text.

However, if the intention here is to represent network engineering
concepts, such as might be used for traffic engineering, for
constructing virtual networks, or for building layer 3 services (such as
VPNs, or pseudowires) then this work needs to be discussed more within
the routing area where it would conflict with existing work.

[Ballot comment]
Given the position I found myself with respect to alto documents I would strongly encourage the working group to consider the implications of information leakage when pursuing additional work e.g. the product of client queries to the map.

DNS it turns out has to consider some similar problems under the rubric of dnspriv.