Re: [L2sm] L2SM charter proposal

[Benoit Claise <[e-mail]>]

Michael, Adrian,

Thank you for the discussion, and the text proposal.
That lead to this new charter text, v00-05: 
https://datatracker.ietf.org/doc/charter-ietf-l2sm/
See in line (removing some text)...
>
>> How about...
>>
>> OLD
>> The deliverable from this working group will provide information to evaluate
>> the
>> set of YANG models that have already been developed or are under development,
>> and will help identify any missing models or details. The deliverable can be
>> viewed as driving requirements for protocol configuration model so that the
>> service parameters can be mapped into inputs used by the protocol models.
>> NEW
>> The deliverable from this working group will provide information that other
>> working groups can use to evaluate the set of YANG models that they have
>> already
>> developed or that are under development. This will help them to identify any
>> missing models or details. Thus, the deliverable can be viewed as driving
>> requirements for service delivery models so that the customer service
>> parameters
>> can be mapped into inputs used by the protocol configuration models.
>> END
> In practice, a customer service model is much more abstract than specific configuration models, i.e., it only includes a subset of parameters. It seems a bit strange to me that the charter assumes that missing model details in protocol configuration will be derived from an abstract representation. And I am not sure if this has ever happened in the L3SM case.
If we look at the L3SM customer service model, we can deduce which 
technologies  orchestrator/controller will have to configure on devices: 
routing, interface, multicast, etc. This is the idea behind this text. 
Note that it doesn't have to be a formal WG deliverable.
>
> In my experience, the real-world question is whether a customer service model indeed includes all the relevant parameters e.g. from a protocol configuration model, e.g., if a customer of a service provider has specific needs. This is exactly the opposite of the workflow that is assumed in the charter.
>
> Of course, it doesn't do harm to make void statements.
>
>> But we could...
>> OLD
>> The working group will coordinate with other working groups responsible for
>> L2VPN protocol work (most notably with BESS and PALS) and with the MEF.
>> NEW
>> The working group will coordinate with other working groups responsible for
>> L2VPN protocol work (most notably with BESS and PALS). It will also coordinate
>> with other organizations working on related L2VPN data models (such as the
>> MEF).
>> END
> Noting external dependencies in a separate sentence is better.
>
> Do the WG proponents plan to share details on how they plan to deal with the overlapping work in MEF?
That's a good questions for the draft authors.
 From a process point of view, the communication with MEF started.

Regards, Benoit