Re: [yang-doctors] Encoding "time of activation" in a r/w data tree leaf

[Kent Watsen <[e-mail]>]

I’m unsure what opportunity there is for a pattern here, but generally feel that opstate should be presented in CF nodes rather than in RPC/action-replies.

FWIW, there is a “last-modified” leaf at these two locations:

	https://github.com/netconf-wg/ssh-client-server/blob/e0b092bcbf7eb3c2d55125bb0705121526e7d121/ietf-ssh-server.yang#L313

	https://github.com/netconf-wg/http-client-server/blob/34a1972eca80aee46e6cb3321d2a4e0c659fa675/ietf-http-server.yang#L207

Kent


> On Feb 9, 2024, at 11:06 AM, Ebben Aries <exa=[e-mail]> wrote:
> 
> YANG Doctors,
> 
> Readjusting the subject and resending for comment
> 
> On 2024-01-20 12:40:12, Ebben Aries wrote:
>> Hi Folks,
>> 
>> I'm curious of opinions on the design pattern used during a recent
>> review here.  It is one such where a prescribed "time of activiation" is
>> being encoded in a r/w data tree leaf vs. within the protocol/messaging
>> layer or a YANG 'action'
>> 
>> Examples:
>> 
>>    +--rw requested-start?    yang:date-and-time
>>    +--rw requested-stop?     yang:date-and-time
>>    +--ro actual-start?       yang:date-and-time
>>    +--ro actual-stop?        yang:date-and-time
>> 
>> 
>>   +--rw status
>>      +--rw admin-status
>>      |  +--rw status?        identityref
>>      |  +--rw last-change?   yang:date-and-time
>>      +--ro oper-status
>>         +--ro status?        identityref
>>         +--ro last-change?   yang:date-and-time
>> 
>> Now, a quick search through published/draft modules as well as other
>> published models I'm not sure I've seen an attempt at such a design
>> pattern previously.
>> 
>> This approach is very specific the intent of any surrounding structures
>> and one where a design pattern is likely to diverge for similar
>> intentions.  This was mostly unfolded by questioning an already
>> published module (ietf-vpn-common) where `last-change` has a r/w and r/o
>> variant.
>> 
>> Would love to hear opinions on this approach vs. handling outside of the
>> data tree.
>> 
>> /ebben
>> 
>> 
>> ----- Forwarded message from Ebben Aries <[e-mail]> -----
>> 
>> From: Ebben Aries <[e-mail]>
>> To: [e-mail]
>> Subject: Re: Yangdoctors early review of draft-ietf-opsawg-teas-attachment-circuit-03
>> Date: Sat, 20 Jan 2024 12:28:22 -0700
>> 
>> Hi Med - inline...
>> 
>> On 2024-01-17 11:33:35, [e-mail] wrote:
>>> [External Email. Be cautious of content]
>>> 
>>> 
>>> Re-,
>>> 
>>>> [Med] Please note that we are focusing mainly on service and
>>>> network models, for which NETCONF may be the transport protocol,
>>>> but I hear your point.
>>> 
>>> I actually meant
>>> 
>>>> [Med] Please note that we are focusing mainly on service and
>>>> network models, for which NETCONF may NOT be the transport protocol,
>>>> but I hear your point.
>> 
>> Understood and was only referring to an example for a specific protocol.
>> Every protocol would need to account for similar capabilities.
>> 
>> Another option could be to model a YANG 'action' for this purpose but
>> again, alternate protocols need to have awareness on how to map actions
>> intent.
>> 
>> I'd be curious to hear others opinions here as we could end up w/
>> various design patterns for this problem statement.  Encoding as regular
>> leafs in a data tree can make it transport agnostic but one that needs
>> to be clear and common in intent imo.
>> 
>> Thx
>> 
>> /ebben
>> 
>>> Apologies for the inconvenience.
>>> 
>>> Cheers,
>>> Med
>>> 
>>>> -----Message d'origine-----
>>>> De : BOUCADAIR Mohamed INNOV/NET
>>>> Envoyé : mercredi 17 janvier 2024 12:28
>>>> À : 'Ebben Aries' <[e-mail]>
>>>> Cc : [e-mail]; draft-ietf-opsawg-teas-attachment-
>>>> [e-mail]; [e-mail]
>>>> Objet : RE: Yangdoctors early review of draft-ietf-opsawg-teas-
>>>> attachment-circuit-03
>>>> 
>>>> Hi Ebben,
>>>> 
>>>> Please see inline.
>>>> 
>>>> Cheers,
>>>> Med
>>>> 
>>>>> -----Message d'origine-----
>>>>> De : Ebben Aries <[e-mail]>
>>>>> Envoyé : lundi 15 janvier 2024 16:49
>>>>> À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>
>>>> Cc :
>>>>> [e-mail]; draft-ietf-opsawg-teas-attachment-
>>>>> [e-mail]; [e-mail]
>>>>> Objet : Re: Yangdoctors early review of draft-ietf-opsawg-teas-
>>>>> attachment-circuit-03
>>>>> 
>>>>> Thx Med - one comment inline...
>>>>> 
>>>>> On 2024-01-15 06:59:58, [e-mail] wrote:
>>>>>> [External Email. Be cautious of content]
>>>>>> 
>>>>>> 
>>>> ...
>>>>>> 
>>>>>>> - For `status/admin-status/last-change`, this leaf is `r/w`
>>>>> and
>>>>>>> while I
>>>>>>>  realize this is reuse from `ietf-vpn-common`, it seems
>>>> that
>>>>> this
>>>>>>> is
>>>>>>>  incorrect and should be reflected as pure `r/o` state.
>>>>>> 
>>>>>> [Med] Actually, no. Unlike the operational status, the client
>>>>> can control that for administrative status as well. Think about
>>>>> scheduled operations for example.
>>>>> 
>>>>> I'm conflicted why this would reside in modeling for the use-
>>>> case you
>>>>> describe as this would entail a pattern that would need to be
>>>>> considered across _all_ modeling.
>>>> 
>>>> [Med] This is fair.
>>>> 
>>>>  I'm not sure I've seen this
>>>>> pattern arise before.
>>>>> 
>>>>> RFC7758 is one such example of how scheduled operations would
>>>> be
>>>>> handled at the protocol messaging layer and not scattered among
>>>> the
>>>>> data-content.
>>>> 
>>>> [Med] Please note that we are focusing mainly on service and
>>>> network models, for which NETCONF may be the transport protocol,
>>>> but I hear your point.
>>>> 
>>>> Given that for the AC models, we do define the following for a
>>>> client to control when a service can be activate/deactivated:
>>>> 
>>>>  grouping op-instructions
>>>>    +-- requested-start?   yang:date-and-time
>>>>    +-- requested-stop?    yang:date-and-time
>>>>    +--ro actual-start?      yang:date-and-time
>>>>    +--ro actual-stop?       yang:date-and-time
>>>> 
>>>> And that for advanced scheduling, the WG is working on a generic
>>>> model (draft-ma-opsawg-schedule-yang) that can be used in a
>>>> future ac augments if needed, I tweaked the draft so that the
>>>> admin last-change is ro instead of rw. The diff to track the
>>>> changes can be seen at:
>>>> 
>>>> * Diff ac-common: https://urldefense.com/v3/__https://boucadair.github.io/attachment-circuit-__;!!NEt6yMaO-gk!EX_FXGmvRZozEz2nAGr4xVgt1ak_n_R0DEq10bp0mvbLDNKWpvOyKInUF8TA_i3-wF-poJ7yyGKzq4Nt8WbNJ4bP$
>>>> model/#go.draft-ietf-opsawg-teas-common-ac.diff
>>>> * diff ac-svc: https://urldefense.com/v3/__https://boucadair.github.io/attachment-circuit-__;!!NEt6yMaO-gk!EX_FXGmvRZozEz2nAGr4xVgt1ak_n_R0DEq10bp0mvbLDNKWpvOyKInUF8TA_i3-wF-poJ7yyGKzq4Nt8WbNJ4bP$
>>>> model/#go.draft-ietf-opsawg-teas-attachment-circuit.diff
>>>> 
>>>> Better?
>>>> 
>>>> Thank you for you patience.
>>> 
>>> ____________________________________________________________________________________________________________
>>> 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.
>>> 
>> 
>> ----- End forwarded message -----
> 
> _______________________________________________
> yang-doctors mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/yang-doctors