[yang-doctors] Fwd: Re: Yangdoctors early review of draft-ietf-opsawg-teas-attachment-circuit-03

[Ebben Aries <[e-mail]>]

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