Hi Ebben,
Please see inline.
Cheers,
Med
> -----Message d'origine-----
> De : Ebben Aries <e...@juniper.net>
> Envoyé : lundi 15 janvier 2024 16:49
> À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com>
> Cc : yang-doct...@ietf.org; draft-ietf-opsawg-teas-attachment-
> circuit....@ietf.org; opsawg@ietf.org
> 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, mohamed.boucad...@orange.com 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://boucadair.github.io/attachment-circuit-model/#go.draft-ietf-opsawg-teas-common-ac.diff
* diff ac-svc:
https://boucadair.github.io/attachment-circuit-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.
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
