[netmod] Re: anydata/mandatory description RE: shepherd review for draft-ietf-netmod-rfc8407bis

[[e-mail]]

Hi all,

This PR is now merged.

A new version with this change will be published SOON.

Cheers,
Med

De : BOUCADAIR Mohamed INNOV/NET
Envoyé : lundi 30 septembre 2024 16:16
À : '[e-mail]' <[e-mail]>
Cc : '[e-mail]' <[e-mail]>; 'Kent Watsen' <[e-mail]>; 'maqiufang (A)' <[e-mail]>
Objet : anydata/mandatory description RE: [netmod] shepherd review for draft-ietf-netmod-rfc8407bis

Hi all,

A candidate update Section 4.14 is available here:

https://author-tools.ietf.org/api/iddiff?url_1=https://netmod-wg.github.io/rfc8407bis/draft-ietf-netmod-rfc8407bis.txt&url_2=https://netmod-wg.github.io/rfc8407bis/anydata-description/draft-ietf-netmod-rfc8407bis.txt

I plan to submit the new version by next Friday unless I hear an objection from the WG.

Cheers,
Med

De : BOUCADAIR Mohamed INNOV/NET
Envoyé : lundi 30 septembre 2024 11:40
À : 'maqiufang (A)' <[e-mail]<mailto:[e-mail]>>; Kent Watsen <[e-mail]<mailto:[e-mail]>>
Cc : [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Objet : RE: [netmod] shepherd review for draft-ietf-netmod-rfc8407bis

Hi Kent, Qiufang,

I like Kent’s proposal. I created an issue for pyang at: https://github.com/mbj4668/pyang/issues/919.

Thank you Qiufang for sharing data for IETF modules.

Cheers,
Med

De : maqiufang (A) <[e-mail]<mailto:[e-mail]>>
Envoyé : lundi 30 septembre 2024 11:11
À : Kent Watsen <[e-mail]<mailto:[e-mail]>>; BOUCADAIR Mohamed INNOV/NET <[e-mail]<mailto:[e-mail]>>
Cc : [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Objet : RE: [netmod] shepherd review for draft-ietf-netmod-rfc8407bis

Hi, Kent, Med, all,

AFAIK, the “description” statement is never required in RFC 7950, i.e., the cardinality is always 0..1.    Notably, see how it’s defined for the “anyxml” statement: https://datatracker.ietf.org/doc/html/rfc7950#section-7.11.1

You raise a good point about legacy modules.   It might be good for pyang to only flag modules with revision dates after this document’s publication date.
Perhaps not a very big issue about legacy modules, e.g., just checked the IETF-published modules [1] with anydata definition, there are 8 of them [2], and all have the “description” as its substatement, which is not surprising to me, you should always provide the detailed description information about an unknown set of nodes defined as “anydata”.

[1] https://github.com/YangModels/yang/tree/main/standard/ietf/RFC
[2] https://github.com/search?q=repo%3AYangModels%2Fyang%20path%3A%2F%5Estandard%5C%2Fietf%5C%2FRFC%5C%2F%2F%20anydata&type=code

Best Regards,
Qiufang
On Sep 27, 2024, at 10:30 AM, [e-mail]<mailto:[e-mail]> wrote:

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]<mailto:[e-mail]>>
Envoyé : vendredi 27 septembre 2024 16:01
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]<mailto:[e-mail]>>; maqiufang (A) <[e-mail]<mailto:[e-mail]>>
Cc : [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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.
____________________________________________________________________________________________________________
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.