[manet] Re: Mahesh Jethanandani's Discuss on draft-ietf-ma net-dlep-da-credit-extension-20: (with DISCUSS and COMMENT)

Hi Donald,

> On Feb 15, 2025, at 8:46 PM, Donald Eastlake <[email protected]> wrote:
> 
> Hi Mahesh,
> 
> On Sat, Feb 1, 2025 at 7:49 PM Mahesh Jethanandani via Datatracker
> <[email protected]> wrote:
>> Mahesh Jethanandani has entered the following ballot position for
>> draft-ietf-manet-dlep-da-credit-extension-20: Discuss
>> 
>> ...
>> 
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>> 
>> Here, here! This DISCUSS is just that. A DISCUSSion around how something could
>> be clarified better. I expect it should be fairly easy to address it.
>> 
>> Section 3, paragraph 2
>>>   If this extension is supported, that support MUST be declare using
>>>   the Extensions Supported Data Item (see Section 13.6 of [RFC8175]).
>>>   DiffServ Aware Credit Window Extension Data Items MUST NOT be emitted
>>>   by a DLEP participant unless such support was specified in the
>>>   initialization message received from its peer.  The use of the
>>>   extension defined in this document SHOULD be configurable on both
>>>   modems and routers.
>> 
>> The document clearly states that the extension needs to be configured on both
>> modems and routers. Further down there are references to "network management
>> mechanisms", which could imply NETCONF/RESTCONF, or they could also imply
>> Syslog but that is not entirely clear reading the document. How exactly is this
>> feature going to be configured if there is no YANG module defined or planned?
>> Can it be explained better?
> 
> There is currently no MIB or YANG module specified for DLEP nor is
> there any management work item in the current MANET Charter. However,
> there is a draft revised Charter to which a DLEP management work item
> could be added. Would it be satisfactory to plan to do that and to
> change the draft text to just say "manually configured"?

RFC 5706, Section 3 talks about management considerations, particularly as they relate to how a protocol will be managed. The document states that besides clearly identifying what needs to be managed from a configuration perspective, it also needs to specify how the extension can be monitored, e.g., a notification pushed through a management protocol such as NETCONF/RESTCONF or through a Syslog event. Defining a YANG model is just one of the ways, and if the WG decides to revise the charter to include such work, it could be said that management of the feature would be considered as part of future work to develop a YANG model. The authors could also decide, as it says in Section 1.2, that the feature can be managed solely by using a proprietary CLI, but that decision should be explicit in a management discussion.

In short, identify what needs to be configured, what should be monitored, and how it will be done. That clarity would help a reader of this document but also help the future design of the YANG module, should the WG pick up the work. Does that help?
 
> 
> Thanks,
> Donald
> ===============================
> Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
> 2386 Panoramic Circle, Apopka, FL 32703 USA
> [email protected]


Mahesh Jethanandani
[email protected]

_______________________________________________
manet mailing list -- [email protected]
To unsubscribe send an email to [email protected]