Re-, Not sure which change you made. FWIW, you can seen the output of compiling your file with that statement removed at:
https://github.com/boucadair/dummy-misc/actions/runs/14218233724/job/39839769040: no error/warning. Cheers, Med > -----Message d'origine----- > De : Acee Lindem <acee.i...@gmail.com> > Envoyé : mercredi 2 avril 2025 13:04 > À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com> > Cc : Mahesh Jethanandani <mjethanand...@gmail.com>; The IESG > <i...@ietf.org>; draft-ietf-ospf-sr-y...@ietf.org; lsr- > cha...@ietf.org; lsr <lsr@ietf.org>; Christian Hopps > <cho...@chopps.org> > Objet : Re: Mahesh Jethanandani's No Objection on draft-ietf-ospf- > sr-yang-37: (with COMMENT) > > Removing causes errors with the current version of pyang > > MacBook-Pro:ietf-ospf-yang acee$ pyang --ietf-help ietf-ospf-sr- > mpls.yang > > Validates the module or submodule according to the IETF rules > found in RFC 8407. > > The module's or submodule's description statement must contain the > following text: > > Copyright (c) <year> IETF Trust and the persons identified as > authors of the code. All rights reserved. > > Redistribution and use in source and binary forms, with or > without modification, is permitted pursuant to, and subject > to > the license terms contained in, the Revised BSD License set > forth in Section 4.c of the IETF Trust's Legal Provisions > Relating to IETF Documents > > (https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Ftrustee.ietf.org%2Flicense- > info&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cea1e040250114 > 3ac31cb08dd71d630b3%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6 > 38791886944953016%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUs > IlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D% > 3D%7C0%7C%7C%7C&sdata=MvrhPifUFesmVGGmZRVcNx79aBOAw879kQPBPEloWUY% > 3D&reserved=0). > > An IETF module (but not an IANA module) must also contain the > following text: > > This version of this YANG module is part of RFC XXXX > > (https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fwww.rfc- > editor.org%2Finfo%2FrfcXXXX&data=05%7C02%7Cmohamed.boucadair%40ora > nge.com%7Cea1e0402501143ac31cb08dd71d630b3%7C90c7a20af34b40bfbc48b > 9253b6f5d20%7C0%7C0%7C638791886944970690%7CUnknown%7CTWFpbGZsb3d8e > yJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjo > iTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=2YiChBAbw80lmahuDKmb4 > eajtMQDcRleJrtTe7%2FVa9U%3D&reserved=0); see the RFC itself > for full legal notices. > > If any description statement in the module or submodule contains > RFC 2119 key words, the module's or submodule's description > statement must contain the following text: > > The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL > NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT > RECOMMENDED', > 'MAY', and 'OPTIONAL' in this document are to be interpreted > as > described in BCP 14 (RFC 2119) (RFC 8174) when, and only > when, > they appear in all capitals, as shown here. > > > > On Apr 2, 2025, at 6:08 AM, Acee Lindem <acee.i...@gmail.com> > wrote: > > > > Ok - I'll remove it. > > > > Thanks, > > Acee > > > >> On Apr 2, 2025, at 2:08 AM, mohamed.boucad...@orange.com wrote: > >> > >> Hi Acee, > >> > >> One quick comment on this part: > >> > >>>> > >>>> Section 3, paragraph 9 > >>>>> This version of this YANG module is part of RFC XXXX; > >>> see > >>>>> the RFC itself for full legal notices. > >>>> > >>>> BTW, is there an instruction for the RFC Editor on what to do > >>> with RFC XXXX? > >>> > >>> This is present is other YANG modules. For example, ietf- > ospf.yang > >>> in RFC 9129. > >>> > >> > >> That's not a reason to have it :-) > >> > >> I know that some raised comments about this in the past (Tom > Petch, if I'm not mistaken). Also, I don' think this mention > brings much as what is important with the one under the revision. > >> > >> I suggest to remove that part and align with the template at: > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F > datatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-netmod-rfc8407bis- > 22%23name-template-for-ietf- > modules&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cea1e040250 > 1143ac31cb08dd71d630b3%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0% > 7C638791886944979541%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRyd > WUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ% > 3D%3D%7C0%7C%7C%7C&sdata=t5LA3Sfn7K4phWjp52xAalFQ9J42AkA%2FWcW6v2a > Dasc%3D&reserved=0. > > Removing causes errors with pyang (maybe I need an update): > > MacBook-Pro:ietf-ospf-yang acee$ pyang --ietf-help ietf-ospf-sr- > mpls.yang > > Validates the module or submodule according to the IETF rules > found in RFC 8407. > > The module's or submodule's description statement must contain the > following text: > > Copyright (c) <year> IETF Trust and the persons identified as > authors of the code. All rights reserved. > > Redistribution and use in source and binary forms, with or > without modification, is permitted pursuant to, and subject > to > the license terms contained in, the Revised BSD License set > forth in Section 4.c of the IETF Trust's Legal Provisions > Relating to IETF Documents > > (https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Ftrustee.ietf.org%2Flicense- > info&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cea1e040250114 > 3ac31cb08dd71d630b3%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6 > 38791886944988482%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUs > IlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D% > 3D%7C0%7C%7C%7C&sdata=IR4WQ6bwoXw1Q1ZnhYMBSUOsGKoPY2fnUoFEmGPQPoo% > 3D&reserved=0). > > An IETF module (but not an IANA module) must also contain the > following text: > > This version of this YANG module is part of RFC XXXX > > (https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fwww.rfc- > editor.org%2Finfo%2FrfcXXXX&data=05%7C02%7Cmohamed.boucadair%40ora > nge.com%7Cea1e0402501143ac31cb08dd71d630b3%7C90c7a20af34b40bfbc48b > 9253b6f5d20%7C0%7C0%7C638791886944997706%7CUnknown%7CTWFpbGZsb3d8e > yJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjo > iTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=MKtf8tt1Nuixk6xpM7PwH > kEzzeIb6ADtHUid8GNOcEY%3D&reserved=0); see the RFC itself > for full legal notices. > > If any description statement in the module or submodule contains > RFC 2119 key words, the module's or submodule's description > statement must contain the following text: > > The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL > NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT > RECOMMENDED', > 'MAY', and 'OPTIONAL' in this document are to be interpreted > as > described in BCP 14 (RFC 2119) (RFC 8174) when, and only > when, > they appear in all capitals, as shown here. > > I've left it out. > > Thanks, > Acee > > > > > > > >> > >> Thank you. > >> > >> Cheers, > >> Med > >> > >>> -----Message d'origine----- > >>> De : Acee Lindem <acee.i...@gmail.com> Envoyé : mardi 1 avril > 2025 > >>> 23:40 À : Mahesh Jethanandani <mjethanand...@gmail.com> Cc : > The > >>> IESG <i...@ietf.org>; draft-ietf-ospf-sr-y...@ietf.org; > >>> lsr-cha...@ietf.org; lsr <lsr@ietf.org>; Christian Hopps > >>> <cho...@chopps.org> Objet : Re: Mahesh Jethanandani's No > Objection > >>> on draft-ietf-ospf- > >>> sr-yang-37: (with COMMENT) > >>> > >>> > >>> Hi Mahesh, > >>> > >>>> On Apr 1, 2025, at 5:14 PM, Mahesh Jethanandani via > Datatracker > >>> <nore...@ietf.org> wrote: > >>>> > >>>> Mahesh Jethanandani has entered the following ballot position > >>> for > >>>> draft-ietf-ospf-sr-yang-37: No Objection > >>>> > >>>> When responding, please keep the subject line intact and > reply > >>> to all > >>>> email addresses included in the To and CC lines. (Feel free > to > >>> cut > >>>> this introductory paragraph, however.) > >>>> > >>>> > >>>> > >>>> > >>>> ------------------------------------------------------------- > --- > >>> ------ > >>>> COMMENT: > >>>> ------------------------------------------------------------- > --- > >>> ------ > >>>> > >>>> Section 1, paragraph 0 > >>>>> This document defines a YANG data model [RFC7950] that can > be > >>> used to > >>>>> manage OSPFv2 extensions for Segment Routing [RFC8665] and > >>> OSPFv3 > >>>>> extensions for Segment Routing [RFC8666] for the MPLS data > >>> plane. It > >>>>> is an augmentation to the OSPF YANG data model [RFC9129]. > >>>> > >>>> This is a similar comment to the YANG module for SR on ISIS. > >>> There > >>>> seems to be some confusion on the use of the terms "YANG > module" > >>> and > >>>> "YANG data model" in this document. A "YANG data model" > refers > >>> to a > >>>> collection of YANG modules and submodules that together > define a > >>>> structured representation configuration, operational data, > >>>> notifications, and RPCs for a given system or protocol, while > a > >>> "YANG > >>>> module" refers to a specific YANG file (.yang) defining a set > of > >>> nodes (container, list, leaf, etc.) that represent > configuration or > >>> state data. > >>>> Moreover, a YANG module can be independent and augment other > >>> modules. > >>>> > >>>> Based on that definition, what you seem to be defining is a > YANG > >>>> module more than a YANG data model. Can that be reflected > >>> consistently in this document? > >>> > >>> I'll fix this. > >>> > >>> > >>> > >>>> > >>>> Section 3, paragraph 9 > >>>>> This version of this YANG module is part of RFC XXXX; > >>> see > >>>>> the RFC itself for full legal notices. > >>>> > >>>> BTW, is there an instruction for the RFC Editor on what to do > >>> with RFC XXXX? > >>> > >>> This is present is other YANG modules. For example, ietf- > ospf.yang > >>> in RFC 9129. > >>> > >>> > >>>> > >>>> Section 3, paragraph 28 > >>>>> grouping sid-tlv-encoding { > >>>>> description > >>>>> "SID TLV Encoding - 20-bit label or 32-bit SID whose > >>>>> interpretation is dependent on the TLV length (3 for > an > >>>>> MPLS label or 4 for a 32-bit value) or the TLV V-Flag > >>> and > >>>>> L-Flag settings: > >>>>> > >>>>> If the V-Flag is set to 0 and L-Flag is set to 0: > >>>>> The SID/Index/Label field is a 4-octet index > defining > >>>>> the offset in the SID/Label space advertised by this > >>>>> router. > >>>>> > >>>>> If V-Flag is set to 1 and L-Flag is set to 1: The > >>>>> ID/Index/Label field is a 3-octet local label where > >>> the > >>>>> 20 rightmost bits are used for encoding the label > >>> value."; > >>>>> reference > >>>>> "RFC 8665: OSPF Extensions for Segment Routing, > Section > >>> 5 > >>>>> RFC 8666: OSPFv3 Extensions for Segment Routing, > >>> Section 3"; > >>>>> leaf sid-raw { > >>>>> type uint32; > >>>>> description > >>>>> "Raw SID value - labels are in the rightmost 20 bits > >>> of > >>>>> the value"; > >>>>> } > >>>>> choice sid-value { > >>>>> case label-sid { > >>>>> leaf label-value { > >>>>> type uint32 { > >>>>> range "0 .. 1048575"; > >>>>> } > >>>>> description > >>>>> "A 20-bit MPLS Label"; > >>>>> } > >>>>> } > >>>>> case offset-sid { > >>>>> leaf offset-value { > >>>>> type uint32; > >>>>> description > >>>>> "Offset into a label space advertised by this > >>> router."; > >>>>> } > >>>>> } > >>>>> description > >>>>> "Choice of either a 20-bit MPLS lable or 32-bit > >>> offset into > >>>>> an advertised label space."; > >>>>> } > >>>>> } > >>>> > >>>> I might be completely off, but what is the relationship > between > >>>> 'sid-raw' and the choice statement of 'sid-value'? Is the > choice > >>>> statement being used to determine what value 'sid-raw' will > >>> carry? If > >>>> that is the case, YANG is being used to model a particular > wire > >>>> format. Tell me that is not what is happening here. I will > note > >>> that > >>>> Med has pointed out something similar as part of his DISCUSS > in > >>> other parts of the model. > >>> > >>> This the same value although the choice is the interpreted > value and > >>> the raw-sid is the value from the TLV without any > interpretation. I > >>> was thinking both could be useful but adamantly opposed to > removing > >>> it. > >>> > >>> > >>> > >>>> > >>>> Section 4, paragraph 9 > >>>>> Some of the readable data nodes in this YANG module may be > >>> considered > >>>>> sensitive or vulnerable in some network environments. It is > >>> thus > >>>>> important to control read access (e.g., via get, get-config, > >>> or > >>>>> notification) to these data nodes. Specifically, the > >>> following > >>>>> subtrees and data nodes have particular sensitivities/ > >>>>> vulnerabilities: > >>>> > >>>> The paragraph seems to imply that specific subtrees and data > >>> nodes > >>>> will be identified for vulnerability. Instead, what I see is > a > >>>> paragraph with some generic description. Did the authors > forget > >>> to > >>>> identify particular nodes or subtrees? > >>> > >>> > >>>> > >>>> No reference entries found for these items, which were > mentioned > >>> in the text: > >>>> [draft-ietf-rtgwg-segment-routing-ti-lfa]. > >>> > >>> What do you mean? It references the read-only Link State > Database > >>> augmentations. Are you asking me to resist every LSA? > >>> > >>> > >>> The module ietf-ospf-sr-mpls augments base OSPF module Link > State > >>> Database (LSDB) with various TLVs. Knowledge of these data > nodes > >>> can be used to attack other routers in the OSPF domain. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>>> > >>>> ------------------------------------------------------------- > --- > >>> ------ > >>>> --------- > >>>> NIT > >>>> ------------------------------------------------------------- > --- > >>> ------ > >>>> --------- > >>>> > >>>> All comments below are about very minor potential issues that > >>> you may > >>>> choose to address in some way - or ignore - as you see fit. > Some > >>> were > >>>> flagged by automated tools (via > >>>> > >>> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F > >>> gith > >>>> ub.com%2Flarseggert%2Fietf- > >>> > reviewtool&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cc52bc89 > >>> > 4a0484bb229f408dd7165db15%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7 > >>> > C0%7C638791404462869141%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn > >>> > RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoy > >>> > fQ%3D%3D%7C0%7C%7C%7C&sdata=k9wKjyoZj0KdSmuzHGFdXRx314Er2rqWFvYUnZ > >>> d54BA%3D&reserved=0), so there will likely be some false > positives. > >>> There is no need to let me know what you did with these > suggestions. > >>>> > >>>> Section 3, paragraph 10 > >>>>> reference > >>>>> "RFC XXXX"; > >>>> > >>>> s/RFC XXXX/RFC XXXX: A YANG Data Model for OSPF Segment > Routing > >>> for > >>>> the MPLS Data Plane/ > >>> > >>> Will fix. > >>> > >>> Thanks, > >>> Acee > >>> > >>> > >>> > >>>> > >>>> > >>>> > >> > >> > __________________________________________________________________ > ___ > >> _______________________________________ > >> 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. _______________________________________________ Lsr mailing list -- lsr@ietf.org To unsubscribe send an email to lsr-le...@ietf.org
