Ok - I'll remove it. Thanks, Acee
> On Apr 2, 2025, at 2:08 AM, [email protected] 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://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-22#name-template-for-ietf-modules. > > Thank you. > > Cheers, > Med > >> -----Message d'origine----- >> De : Acee Lindem <[email protected]> >> Envoyé : mardi 1 avril 2025 23:40 >> À : Mahesh Jethanandani <[email protected]> >> Cc : The IESG <[email protected]>; [email protected]; >> [email protected]; lsr <[email protected]>; Christian Hopps >> <[email protected]> >> 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 >> <[email protected]> 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. _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
