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 <[email protected]>
Envoyé : vendredi 23 février 2024 02:25
À : BOUCADAIR Mohamed INNOV/NET <[email protected]>
Cc : Kent Watsen <[email protected]>; [email protected]
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.
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
