Operationalizing Network & SErvice abstractioNs
charter-ietf-onsen-01

[Ballot comment]
One nit, in the last bullet:

OLD
... by these WG will remain in these WGs
NEW
... by these WGs will remain in these WGs

Changed charter milestone "Send LSes to TMF, 3GPP, BBF, GSMA, Linux Foundation, TIP, and EANTC about ONSEN", set due date to August 2026 from June 2026

[Ballot comment]
Some comments:

s/The ONSEN WG aims to make IETF service and network abstractions easier to implement and use, improving automation,/The ONSEN WG aims to make IETF service and network abstractions easier to implement and use, *therefore* improving automation,/

Be specific about the intended publication status for the docs in `The WG may decide that some documents, such as the problem statement, use-cases, scope, and priorities, are not intended for RFC publication and will be maintained as WG documents`

In the list of relationships, aggregate the ones about `BESS/CCAMP/TEAS:`

Added charter milestone "WG adoption of draft updating the YANG Data Model for Network and VPN Service Performance Monitoring as a Proposed Standard", due March 2028

Added charter milestone "WG adoption of draft updating the Abstraction and Control of TE Networks (ACTN) YANG data model as a Proposed Standard", due March 2028

Added charter milestone "WG adoption of draft that updates the YANG data model for the Attachment Circuit Network Model as a Proposed Standard", due March 2028

Added charter milestone "WG adoption of draft updating the YANG data model for Service Assurance for Intent-Based Networking (SAIN) as a Proposed Standard", due November 2027

Added charter milestone "WG adoption of draft that updates the YANG data model for Attachment Circuit as a Service (ACaaS) as a Proposed Standard", due November 2027

Added charter milestone "WG adoption of draft that updates the YANG data model for the Attachment Circuit Common Model as a Proposed Standard", due November 2027

Added charter milestone "WG adoption of draft updating the Network Slicing YANG data model | Updated draft for the Network Slicing YANG data model based on operational feedback and deployment experiences as a Proposed Standard", due July 2027

Added charter milestone "WG adoption of a draft for new service and network level YANG data models for the abstraction layer as a Proposed Standard", due July 2027

Added charter milestone "WG adoption of a draft for Service-layer APIs based on YANG service models to interface with OSS/BSS as a Proposed Standard", due July 2027

Added charter milestone "WG adoption of draft updating the YANG network data models for L3NM and L2NM | Updated drafts for L2NM and L3NM YANG data models based on operational feedback and deployment experiences, with attention to operational state data and identified gaps as a Proposed Standard", due March 2027

Added charter milestone "WG adoption of a problem statement draft defining the use-cases, scope and priorities for the work items identified in the WG, with input from operators and the [IAB NEMOPS Workshop Report](https://datatracker.ietf.org/doc/draft-iab-nemops-workshop-report/) not to be published as an RFC.", due November 2026

[Ballot comment]
Thanks to everyone that contributed to get this WG formed and creating a place where operators can drive the work in the abstraction layers.

Thanks for taking care of clarifying how the existing WG documents in progress in RTG area WGs will be handled.

[Ballot comment]

General:  spell out acronyms on first use - OSS/BSS for example.

First milestone: How will success be measured?  When the LS is sent?  When a reply is received?  Sometimes having someone who attends these organizations is more effective.

[Ballot block]
Thanks to everyone that contributed to get this WG formed and creating a place where operators can drive the work in the abstraction layers.

In a previous version of the charter, there were two bullets related to coordination which have been taken out and I would like to understand the reasons behind that. Also, how are those aspects being taken care of.

* Technology- or protocol-specific modeling efforts (e.g., device-level YANG data models) remain the responsibility of their respective WGs.
-> It is important to clarify what is not in scope of the WG as well

* BESS/CCAMP/TEAS: ONSEN WG will take on future network and service data modeling efforts, while technology- or protocol-specific modeling efforts remain in these WGs.
-> This was there to ensure that existing work (adopted by those WGs) continue in those WGs with appropriate coordination (e.g., cross-posting to ONSEN for adoption and WGLCs) with ONSEN.

[Ballot comment]
I also have one comment to offer:

1) "The WG may decide that some documents, such as the problem statement, use-cases, scope, and priorities, are not intended for RFC publication and will be maintained as WG documents."

Per https://datatracker.ietf.org/doc/statement-iesg-support-documents-in-ietf-working-groups-20230824/ it would help if some specific guidelines could be given on the criteria for publication of support documents. I appreciate one milestone addressing this for a specific document deliverable but that would not cover other support documents that the WG can pick up in the future. One criteria that comes to my mind is if such a document is required as a stable reference by some SDO outside the IETF then that is an excellent reason to publish as an RFC.

[Ballot block]
Thanks for work done in drafting the charter. I have two comments, the last one being BLOCKing

1) `Updating key YANG data models, including refactoring or restructuring, which includes at least the following:` is followed by a very long list, is this list mandatory ?

2) while I can guess the intended publication status of all work items, let's avoid ambiguities and specify them in the charter.

[Ballot comment]
I have no objection to the charter, and I am very impressed with the milestone list.

I do have a non-blocking comment regarding the first working group milestone, which is to send Liaison Statements to the various SDOs. Who executes this milestone? Do the chairs to do it? Does the rAD do it? Do the statements require WG consensus?

[Ballot comment]
Two editorial items:

(1) Consider expanding "BSS"

(2) Compliments to the authors of this charter for making a very clear milestone chart.  The mapping between the work-items back to the charter text and the status was extremely useful.  It is with regret that I recommend that before this is charter is approved (assuming community consensus) that they get moved into the official datatracker milestone scheme.  The reasoning is that if any changes need to be made to the milestones this would require directly editing the charter text which triggers a re-charter.