Re: [netmod] Rfc8407 - what does this text mean?

[[e-mail]]

Hi Andy,

We need to be careful here to avoid redundant guidance.

For example, the guidance you are suggesting is already covered in 4.23. It even includes guidance for motivating exceptions:

   Designers SHOULD describe and justify any NMDA exceptions in detail,
   such as the use of separate subtrees and/or separate leafs.  The
   "description" statements for both the configuration and the
   operational state SHOULD be used for this purpose.

The proposed narrative text is about highlighting when a temporary non-NMDA is **included in the spec**; to echo this part from 4.23.3, bullet a:

        A temporary non-NMDA version of
        this type of module MAY exist, as either an existing model or a
        model created by hand or with suitable tools that mirror the
        current modeling strategies.  Both the NMDA and the non-NMDA
        modules SHOULD be published in the same document, with NMDA
        modules in the document main body and the non-NMDA modules in a
        non-normative appendix.  The use of the non-NMDA module will
        allow temporary bridging of the time period until NMDA
        implementations are available.

That’s said, if you have a NDMA-related text proposal of you think is worth highlighting in the narrative text, please share it. Thanks.

Cheers,
Med

De : Andy Bierman <[e-mail]>
Envoyé : vendredi 23 février 2024 02:25
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>
Cc : Kent Watsen <[e-mail]>; [e-mail]
Objet : Re: [netmod] Rfc8407 - what does this text mean?

Hi,

I don't think the issue is whether a foo-state module is included in the RFC or not.
There is an algorithm to produce the foo-state module for vendors to use.

IMO the NMDA guideline should indicate "need NMDA", and be present if it is believed that the operational state can be
different than the config. In that case a <get-data> on <operational> would be useful.
If not, then the foo-state module is not even relevant.


Andy


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