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

[Ebben Aries <[e-mail]>]

Yes - my question was more surrounding that we have a grouping that is
re-used for both r/w config _and_ r/o state so writing to a node called
"last-change" is attempting to encode a behavior to dictate _when_ some
status should take effect.  Also there is some implied dependence on the
"status" leaf otherwise you could write a new "last-change" to that node
w/ no other changes.... what would that even mean?

In your examples, your "last-modified" is pure r/o state

NOTE: The latest published version
https://www.ietf.org/archive/id/draft-ietf-opsawg-teas-attachment-circuit-08.txt
has updated to the following now

          +--rw status
             +--rw admin-status
             |  +--rw status?        identityref
             |  +--ro last-change?   yang:date-and-time
             +--ro oper-status
                +--ro status?        identityref
                +--ro last-change?   yang:date-and-time

I'm not sure an admin-status r/o "last-change" is really necessary here
now as that is essentially a log of a last commit for a specific node
now...



On 2024-02-28 13:02:44, Kent Watsen wrote:
> [External Email. Be cautious of content]
> 
> 
> 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://urldefense.com/v3/__https://github.com/netconf-wg/ssh-client-server/blob/e0b092bcbf7eb3c2d55125bb0705121526e7d121/ietf-ssh-server.yang*L313__;Iw!!NEt6yMaO-gk!Dl5Mwr6xbuaAfk8n1urrcBu_OoWsscQO4QLs7zjAdy2g6uVJ3gFryqsSNWKNkZ0Zw955R6mDpwA6R-l7$
> 
>         https://urldefense.com/v3/__https://github.com/netconf-wg/http-client-server/blob/34a1972eca80aee46e6cb3321d2a4e0c659fa675/ietf-http-server.yang*L207__;Iw!!NEt6yMaO-gk!Dl5Mwr6xbuaAfk8n1urrcBu_OoWsscQO4QLs7zjAdy2g6uVJ3gFryqsSNWKNkZ0Zw955R6mDp3jvOlw9$
> 
> 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://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/yang-doctors__;!!NEt6yMaO-gk!Dl5Mwr6xbuaAfk8n1urrcBu_OoWsscQO4QLs7zjAdy2g6uVJ3gFryqsSNWKNkZ0Zw955R6mDp_hGzR2a$
>