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)' <[email protected]>; Kent Watsen <[email protected]>
Cc : [email protected]; [email protected]
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) <[email protected]<mailto:[email protected]>>
Envoyé : lundi 30 septembre 2024 11:11
À : Kent Watsen <[email protected]<mailto:[email protected]>>; BOUCADAIR Mohamed 
INNOV/NET <[email protected]<mailto:[email protected]>>
Cc : 
[email protected]<mailto:[email protected]>;
 [email protected]<mailto:[email protected]>
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, 
[email protected]<mailto:[email protected]> 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 <[email protected]<mailto:[email protected]>>
Envoyé : vendredi 27 septembre 2024 16:01
À : BOUCADAIR Mohamed INNOV/NET 
<[email protected]<mailto:[email protected]>>; maqiufang 
(A) <[email protected]<mailto:[email protected]>>
Cc : 
[email protected]<mailto:[email protected]>;
 [email protected]<mailto:[email protected]>
Objet : Re: [netmod] shepherd review for draft-ietf-netmod-rfc8407bis


Hi Med et. al.,

On Sep 27, 2024, at 5:34 AM, 
[email protected]<mailto:[email protected]> 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.
_______________________________________________
netmod mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to