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

[Ebben Aries <[e-mail]>]

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 -----