[netmod] Re: shepherd review for draft-ietf-netmod-rfc8407bis

[[e-mail]]

Re-,

I was concerned more with breaking existing models (I don’t know how many are out there with anydata use).

Formally speaking, RFC 7950 does not say that it must be present per the following in 7.10.1:

                 +--------------+---------+-------------+
                 | substatement | section | cardinality |
                 +--------------+---------+-------------+
                 | description  | 7.21.3  | 0..1        |

If you still think we need to make the change, I’d like we formally ask for WG consensus on the way to proceed here. A 1-week call would be OK. Thanks.

Cheers,
Med

De : Kent Watsen <[e-mail]>
Envoyé : vendredi 27 septembre 2024 16:01
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>; maqiufang (A) <[e-mail]>
Cc : [e-mail]; [e-mail]
Objet : Re: [netmod] shepherd review for draft-ietf-netmod-rfc8407bis


Hi Med et. al.,


On Sep 27, 2024, at 5:34 AM, [e-mail]<mailto:[e-mail]> wrote:

Section 4.14 specifies a set of YANG statements that MUST have a description substatement, but I don’t think anydata should be omitted here. Thoughts?
[Med] This list is inherited from 8407, which in its turn was inherited from 6087. anydata wasn’t in 6087 because it wasn’t defined at the time in 6020. I don’t have the context whether this was considered by the WG in the past, but I’m afraid that adding this mandatory will break existing models. For example, pyang does not make that check for anydata, while it is in place for anyxml. I suggest we leave the list as it is.
That seems like a valid concern for this NBC update, I am okay with keeping this as it is, if there is no objections from others.

Wait, `anydata` should have a description (just like `anyxml`).  It clearly seems to be an omission from before that should be rectified now.

FWIW, it doesn’t matter what the tools do, or what tools folks use, if any at all.  Also, the tools follow the specifications, not the other way around.

I recommend adding `anydata` and filing a ticket on the `pyang` issue tracker.

Kent / contributor

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