Hi Med, Qin, Thank you for initiating the discussion of this important topic.
At a high level, my understanding of the proposed decision-making methodology is the following: let's have an assessment (it is called rational in the email and I will use the same term) of the current state and potential state of the WG and its work, and then make decisions. It is important that (1) the set of rationals is well specified and (2) the decision for a given rational is coherent with the rational. Personally, I will use a different methodology: identify the set of actions (decisions), identify their pros and cons, and pick the best action, in the interest of IETF in specific and the Internet in general. First, I see 3 actions: (a1) maintaining the WG without opening much new work; (a2) maintaining the WG with new work; and (a0) concluding the WG. So far, we are following a1, and let me give some quick comments on the pros and cons of a0-a2. I will then switch to following the methodology of the email. a0: pros: reduce the number of meetings at IETF, reduce the number of people who attend IETF, reduce the workload on IESG/AD; maybe having fewer bad drafts/standards; cons: many of us believe that ALTO is an important component of the Internet architecture, and the opportunity is missed; multiple active participants of IETF will just leave IETF and focus on other venues. a1: pros: focus the efforts of the WG; cons: it substantially limits the energy of the WG, with each meeting emphasizing that only chartered items can be discussed. Historically, it pushed BGP-LS away from the WG with much resentment; recently, it is pushing computing-aware away, edge-aware away ... a2: pros: increase the interests/energy of the WG, designing a more coherent framework; cons: diversion of efforts It should be obvious that I support a2, and I see clear values to the IETF and the Internet. Now let me follow the methodology in the email, and follow the request to discuss the rationals. Let me first repeat the rationales and decisions and add labels for ease of reference. R1: R1.1: Many I-Ds are being proposed to ALTO; R1.2 Some deployments/products are being disclosed. R1.3 Having a referent WG is a signal that the IETF is ready to support operations and fix flaws/limitations that will be reported. R1.4 ALTO integration complications were out of the scope. R1.5 Documenting those with a set of deployment choices may be a helper for other deployments. R1.6 There is constant engagement and dedication of a core team to deliver ALTO specs. D1: D1.1 Recharter the WG with a focus on ALTO maintenance and integration with data sources. D1.2 Dedicated YANG modules will be produced. Comment: I do not see why R1.4 is supported. Further, I do not see clear logic for the decisions to be derived. For example, It looks to me that D1.1 and R1.1 do not match. I have more minor comments on R1->D1, but let me focus more on R2->D2. R2: R2.1 Some of the proposed ALTO work is research-oriented (PANRG, would be more appropriate for some items), while other may be conducted in new WGs (e.g., CATS). R2.2 Some of the key foundations of ATLO might not be valid after 15 years. R2.3 Closing the WG is not a failure, but a sign of ALTO specification maturity. R2.4 Revitalizing the ALTO effort is thus needed. D2. D2.1 Consider closing ALTO right after the completion of OAM/Transport items. D2.2 Move ALTO maintenance to TSVWG. D2.3 Use the ALTO/TSVWG mailing lists to socialize deployment experience. D2.4 Based on the maintenance that might be shown in TSVWG and shared deployments, reassess the interest of the community in enriching ALTO with additional features by organizing a formal BoF. Comments: - I agree with R2.1, but if there is one thing I sincerely feel, it is that the core team of WG focuses their efforts on non-research, but engineering, for the interest of the WG. Also, some are research-oriented does not imply all are research-oriented. - I am not sure about the meaning of R2.2. ALTO provides some of the simplest abstractions. It will be great if we can list those foundations which are not ready. As I said above, I found the action list D2 not ideal (see cons of a0). Overall, I want to add, in particular, to those fellow ALTO core team members and those who work on ALTO, please do not take this discussion with only negativity. It is a dedicated team who volunteers their time to IETF and designs protocols to make the Internet better. This team follows the advice and focuses on deployment-driven design. It is sad that the efforts are not met with more appreciation, encouragement and positivity, but such discussions. Many of us strongly believe in this work and we will surely work together. Thanks, Richard On Wed, Mar 22, 2023 at 4:09 AM <[email protected]> wrote: > Hi all, > > > > As the WG is about to finalize the last chartered items, we would like to > have a discussion on the future of the WG with all of you. We will also > have a slot during the IETF#116 meeting on this matter. The plan is to let > this discussion open for the coming two months (i.e., ** till end of May > **). > > > > Please note that we are also planning to organize a set of interims > (mostly in replacement of the weekly meetings). Announcements should follow > soon. > > > > Together with Qin, we discussed the following two options: > > > > # Proposal # 1: Support ATLO Operations > > ## Rationale > > - Many I-Ds are being proposed to ALTO. > - Some deployments/products are being disclosed. > - Having a referent WG is a signal that the IETF is ready to support > operations and fix flaws/limitations that will be reported. > - ALTO integration complications were out of the scope. Documenting > those with a set of deployment choices may be a helper for other > deployments. > - There is constant engagement and dedication of a core team to > deliver ALTO specs. > > ## Proposed direction of work > > - Recharter the WG with a focus on ALTO maintenance and integration > with data sources. Dedicated YANG modules will be produced. > > > > # Proposal # 2: Revitalize ALTO > > ## Rationale > > - Some of the proposed ALTO work is research-oriented (PANRG, would be > more appropriate for some items), while other may be conducted in new WGs > (e.g., CATS). > - Some of the key foundations of ATLO might not be valid after 15 > years. > - Closing the WG is not a failure, but a sign of ALTO specification > maturity. > - Revitalizing the ALTO effort is thus needed. > > ## Proposed direction of work > > - Consider closing ALTO right after the completion of OAM/Transport > items. > - Move ALTO maintenance to TSVWG. > - Use the ALTO/TSVWG mailing lists to socialize deployment experience. > - Based on the maintenance that might be shown in TSVWG and shared > deployments, reassess the interest of the community in enriching ALTO with > additional features by organizing a formal BoF. > > > > We are seeking for the WG feedback/preference for each of these two > options. Specifically, feel free to challenge the rationales above, propose > concrete action items for #1, disclose ALTO products developments you are > aware of, etc. > > > > Absent sufficient engagement, the ** default that the Chairs will formally > discuss with our AD is Proposal #2 **. > > > > FWIW, we expect this discussion to be an input for Martin, as we do have > the following in the current charter: > > > > Furthermore, the Area Director and chairs will assess the state of the > > deliverables at the end of 2022. If the Area Director judges that > delivery of > > these documents is not imminent, and that documentation of wide > deployment is > > missing, the AD may close the working group immediately. > > > > Thank you. > > > > Cheers, > > Qin & Med > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
