Subject: [alto] Benjamin Kaduk's No Objection on charter-ietf-alto-04-00: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 11 Aug 2021 22:23:50 -0700

Benjamin Kaduk has entered the following ballot position for
charter-ietf-alto-04-00: No Objection

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

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

----------------------------------------------------------------------
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?

---

From: Qin Wu <[email-masked]>
Date: Thu, 12 Aug 2021 07:37:30 +0000

Hi, Ben:
-----邮件原件-----
发件人: Benjamin Kaduk via Datatracker [mailto:[email-masked]] 
发送时间: 2021年8月12日 13:24
收件人: The IESG <[email-masked]>
抄送: [email-masked]; [email-masked]
主题: Benjamin Kaduk's No Objection on charter-ietf-alto-04-00: (with COMMENT)

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

>The "Milestones and Deliverables" should probably be converted into datatracker-native milestones.

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

[Qin Wu] Yes, it could be in a form of a living document, ideally it will be documented in the wiki page.
We have created a wiki page to track them
https://trac.ietf.org/trac/alto/wiki/Impl
If this is needed, it also can be linked to 
https://www.ietf.org/how/runningcode/implementation-reports/

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

[Qin Wu] Agree, thank for catching this.

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

[Qin Wu] Yes, IPPM, TAPS and PANRG are relevant WGs that are worth collaborating with this work, in my opinion.
We could add text to make this clear.

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

[Qin Wu] Good wording, I prefer "only supported using" which is more precise to convey the meaning.

> (The earlier text mentioned wiki or draft, but this only mentions a wiki; it's probably worth being consistent between mentions.)
[Qin Wu] Agree to make this consistency.

>Under what conditions might more than one mechanism be desirable?

[Qin Wu] Here is my thinking,
I think at least three categories need to be considered to configure, operate, and manage the ALTO protocol and networks that use ALTO.
1. How to provision ALTO server to gather data from various different data source and generate information exposed by ALTO.
2. After ALTO protocol is configured and the network gets setup, how to build monitoring
infrastructure to monitor the performance of ALTO or benchmark ALTO performance.
I think YANG model for configuration and management of ALTO server focuses on the first category, for second category, additional work is needed which is complementary to the first category.
3. After ALTO protocol is configured and the network gets setup, how to provide troubleshooting tool and trace the problem occurred, also needs to be considered.
traditional network layer OAM tools may not work, e.g., ping, traceroute, application layer monitoring tools might be needed, especially ones designed for distributed system, cloud native applications. The 3rd category is different from the 2nd category, since one focus on overall system while the other not.