[netmod] Re: Mail regarding draft-ietf-tvr-schedule-yang

[[e-mail]]

Hi Yingzhen,

Thanks for the follow-up.

Please see inline.

Cheers,
Med

De : Yingzhen Qu <[e-mail]>
Envoyé : dimanche 14 juillet 2024 06:09
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>
Cc : [e-mail]; [e-mail]; [e-mail]; [e-mail]
Objet : Re: Mail regarding draft-ietf-tvr-schedule-yang

Hi Med,

Thanks for the review and comments.


  *   There is a disconnect between the types used in existing topology/interface models and the TVR one.
Do you mean the model is not augmenting existing models? If so, that's done on purpose so we don't create dependencies to existing models.

[Med] No, I meant that the type of some data nodes are not matching the types used for similar nodes in existing models: e.g., if/name is a union in your case while this is a string in 8343, your node-id is yang:dotted-quad in ietf-tvr-node while it is a uri in 8345 (but you have it right in ietf-tvr-topology), source-link-id is a string while this is a uri in 8345. Some text to explain the rationale why you deviate from those is missing, IMO. Also, the change of the type between modules in the same document raises the question of correlation between these modules (e.g., node-id).


  *   Are there cases where the same schedule will be used by multiple interfaces/nodes? If so, consider factorizing and only have a reference to that same schedule rather that defining it for each interface/node.
Are you suggesting for example we define a list of schedules with IDs, then under each interface/node use the IDs to reference the schedules? It's possible there might be multiple interfaces using the same schedule, however the attributes such as bandwidth may not be the same.

[Med] Profiling does not prevent overriding a value when needed.

The current design is simpler.

[Med] It is simpler but may not be optimal for storing and manipulating large topology files. I’m not pushing for any direction here but simply checking if you considered these aspects. You may refer to https://mailarchive.ietf.org/arch/msg/opsawg/uqvSkt5w-spTkRJ0f-DzUDTwT0c/ for an example where such considerations are problematic when not adequately handled in the design. If you are confident that all is well set in your design and that such issues are not applicable in your case, please say so in the draft. Thanks.

Other editorial suggestions I will fix in the next version of the draft after the datatracker opens.

Thanks,
Yingzhen

On Fri, Jul 12, 2024 at 3:00 AM <[e-mail]<mailto:[e-mail]>> wrote:
Hi Authors, all,

As part of our effort to check that the NETMOD Common Schedule module (draft-ietf-netmod-schedule-yang) common basis set for target uses, I reviewed all the I-Ds that use draft-ietf-netmod-schedule-yang. The review also focuses on whether the grouping are used as intended and if some of the existing groupings makes sense for a specific context.

Great to see that the new revision uses the utc grouping that we created as an outcome of the IETF#119 TVR discussion.

I didn’t flagged any major issue related to the use of the common structures. The narrative text should be updated to redirect the readers to the common spec for more details about the period/recurrence data nodes. That’s an easy to fix thing.

One open question though, is whether you considered to graft the state grouping to the TVR modules (e.g. track failure of triggered actions, invocation counters, etc.).

The review below includes a more detailed list of open questions, but I’m providing here main ones:

  *   There is a disconnect between the types used in existing topology/interface models and the TVR one.
  *   Are there cases where the same schedule will be used by multiple interfaces/nodes? If so, consider factorizing and only have a reference to that same schedule rather that defining it for each interface/node.


FWIW, my detailed review of draft-ietf-tvr-schedule-yang can be found at:


  *   pdf: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2024/draft-ietf-tvr-schedule-yang-01-rev%20Med.pdf
  *   doc: https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/2024/draft-ietf-tvr-schedule-yang-01-rev%20Med.doc

Cheers,
Med

Orange Restricted



Orange Restricted

____________________________________________________________________________________________________________

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