Anyway, take a look at -38. I know we still have to update the example. Thanks, Acee
> On Apr 2, 2025, at 7:16 AM, mohamed.boucad...@orange.com wrote: > > 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
