[onions] Re: Proposed charter for ONSEN

[Mahesh Jethanandani <[e-mail]>]

Hi Reshad,

> On Jun 1, 2026, at 7:22 PM, Reshad Rahman <[e-mail]> wrote:
> 
> Hi Mahesh and Chongfeng (single reply to your responses),
> 
> Thanks for your responses, it did answer my questions and I do understand the goals better.
> 
>> > 2. Defining the abstraction layer, using device-level YANG models as the basis for the abstraction. As part of that, new service or network-level YANG models will be developed as needed.
> 
> A follow up question on the above: as we know there are very few implementations of IETF device-level YANG models by networking vendors. Could that be a problem if we use IETF device-level models as the basis for the abstraction? Or is the idea that the "mapping" to vendor models should be straight-forward?

In defining what is abstraction layer, the charter says amongst other things:

"Abstraction enables interaction between managed components and automation management systems without directly exposing the underlying device-specific implementations."

In an effort to support that statement, there cannot be an assumption that the underlying device model has to be IETF device-level YANG models. Whether that abstraction is achieved using a “mapping” layer or some other method is for the WG to decide.

Cheers.

> 
> Regards,
> Reshad.
> 
> On Tuesday, May 5, 2026 at 03:09:47 PM EDT, Mahesh Jethanandani <[e-mail]> wrote:
> 
> 
> Hi Reshad,
> 
> Thanks for the questions, and no need to apologize — they are good ones.
> 
> On "defining simplified constructs":
> 
> Your suggestion is well-taken. Many of the relevant constructs already exist (L2SM, L3SM, L2NM, L3NM, SAP, etc.) — much of ONSEN's work is updating and refining them rather than creating them from scratch. I'll update the definition to read "defining or reusing existing simplified constructs" to make that explicit.
> 
> On the abstraction layer and how it differs from existing YANG:
> 
> To address your three implied sub-questions:
> 
> Is the abstraction layer defined in YANG? Yes, within ONSEN's scope, the abstraction layer is YANG-based — this is an OPS Area WG building on IETF's YANG toolchain.
> 
> How is it different from existing YANG? The difference is the level of focus and integration. Device-level YANG models exist across many WGs and describe device-specific capabilities. Service-level YANG models (L2SM, L3SM, etc.) also exist, but as the IAB NEMOPS workshop highlighted, these service and network abstractions are inconsistent with each other, poorly integrated, and don't map cleanly to OSS/BSS interfaces. ONSEN's goal is to make those abstractions coherent and operationally useful as a set, not just individually correct.
> 
> Does it provide a mapping between service and device YANG models? Not explicitly — ONSEN will not define a mapping protocol or translation rules. The service and network YANG models (new or existing) are the abstraction layer; they sit above device-level YANG. What ONSEN will define or refine is the content of that layer (the models themselves), including informational guidance on how those models interface with OSS/BSS systems (e.g., TMF640).
> 
> Does that clarify the intent?
> 
> Regards,
> 
> On Monday, May 4, 2026 at 11:03:05 PM EDT, Chongfeng Xie <[e-mail]> wrote:
> 
> 
> 
> Hi Reshad,
> I try to answer your question from my perspective,
> Regarding the first question, although there have been such constructs, such as network models and service models, they are not easily to be used and pieced together to form into a coherent system. As mentioned by the problem statement presentation of ONSEN BOF, new requirements have emerged to these models.  So ONSEN needs to update existing models or design new ones.
> For the second question, I think the abstraction layer includes YANG-based network and service models, they will be updated and maintained at ONSEN based on new requirements.
> 
> Best regards
> Chongfeng
> 
> 
>> On May 4, 2026, at 5:23 PM, Reshad Rahman <[e-mail]> wrote:
>> 
>> Hi Mahesh, all,
>> 
>> A couple of questions.
>> 
>> > For this WG, the term "abstraction" refers to the process of defining simplified constructs that represent network and service-level capabilities. Abstraction enables interaction between managed components and automation management systems without directly exposing the underlying device-specific implementations. The layer between the managed components and the automation management system is referred to as the "abstraction layer".
>> 
>> Regarding "defining simplified constructs", can some of those constructs already? If yes, change to "defining or reusing existing simplified constructs"?
>>  
>> > 2. Defining the abstraction layer, using device-level YANG models as the basis for the abstraction. As part of that, new service or network-level YANG models will be developed as needed.
>> 
>> Does this mean the "abstraction layer" is defined in YANG? If yes, how is that different from existing YANG? Will it provide a "mapping" between the service and device YANG models?
>> 
>> 
>> I haven't followed prior threads/discussions closely, so apologies if I'm repeating previously discussed points/questions.
>> 
>> Regards,
>> Reshad.
>> 
>> On Friday, May 1, 2026 at 05:20:05 PM EDT, Mahesh Jethanandani <[e-mail]> wrote:
>> 
>> 
>> Hi ONSEN participants,
>> 
>> In preparing the ONSEN charter, my goal has been to give the chairs — and ultimately the IESG — a clear basis for determining whether a given draft is in scope for the WG. The charter focuses on work items that are well-defined and ready to proceed. Items that need further discussion or refinement before being chartered can still be brought to the WG as individual drafts; if there is sufficient interest, the charter can be updated accordingly.
>> 
>> The chairs, Ian and Mithun, and I have proposed the following charter for IESG consideration:
>> 
>> https://datatracker.ietf.org/doc/charter-ietf-onsen/
>> 
>> Please review and send any comments or objections to this list in the next one week.
>> 
>> Mahesh Jethanandani
>> [e-mail]
>> 
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> onions mailing list -- [e-mail] <mailto:[e-mail]>
>> To unsubscribe send an email to [e-mail] <mailto:[e-mail]>
> 
> 
> Mahesh Jethanandani
> [e-mail]
> 
> 
> 
> 
> 
> 


Mahesh Jethanandani
[e-mail]