Received: from mail-pz2-x10.google.com (mail-pz2-x10.google.com [IPv6:2607:f8b0:4864:3b::10]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by mx.ietf.org (Postfix) with ESMTPS id 12E0630 for ; Fri, 18 Sep 2026 19:04:47 +0000 (UTC) Authentication-Results: mx.ietf.org; dkim=pass header.d=gmail.com header.s=20251104 header.b=kMY4U3bN; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx.ietf.org: domain of mjethanandani@gmail.com designates 2607:f8b0:4864:3b::10 as permitted sender) smtp.mailfrom=mjethanandani@gmail.com Received: by mail-pz2-x10.google.com with SMTP id 41be03b00d2f7-cc4c08393b0so933358a12.0 for ; Fri, 18 Sep 2026 12:04:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789758286; x=1790363086; darn=ietf.org; h=references:to:cc:in-reply-to:date:subject:mime-version:content-type :message-id:from:from:to:cc:subject:date:message-id:reply-to :content-type; bh=wTMcouH7k2LZrTnDfQaLJdYZmRE5nqUDsUZOge4PNVY=; b=kMY4U3bNM5HwR8Iu9TK4TjEfMNwGkOR0e03dqnGMc68tjnx/eJ9yopzsgDyRwkLVsD 7YmrgcblvhNYjW5Ny+ZSD0KPh1v+eTmDhzlyH2gT8vOFgUe8IdML/Xi4AjR0fiiE29U6 YeHYqBMnYHA4+D7lM5oBsSo7Kqg6RacddrMk2edkcV173EZl1IIPwElJ9xI1WVBmthOW 9Mw3z9P8QVE4ikTZuyB8VYrmra4MGRwU4cYlwWr5TYj/jp5wEbObfjR8rw5+Oj7z9Woc Njs3rFEqYEBp2IDLLK3LMirgy4P/vDwAmEd7tdbNkolnC9up3EYin+MdO/fj7Y/0FUFf rwZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789758286; x=1790363086; h=references:to:cc:in-reply-to:date:subject:mime-version:content-type :message-id:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=wTMcouH7k2LZrTnDfQaLJdYZmRE5nqUDsUZOge4PNVY=; b=QD7vbGPZL4XrZJNEvnCk3tkKwfDdFsAu+pHqmx59mDmf6nj0Za/dr0S+d+4+RB2XHF BjZ/pvqXVeauY8y5TXz4EaHpKD6naQk9HJohm7TTzI/xPbDgps+9K29Zqo+iyiP+97Sm Q9iXRcGZCJPVKqrpx79yY+hp1+d99J2DlUNnPOaERqolLGhkOi6EgomqD4D6Re6IRlrw 15gpH/vCbmiRaMsRx2UOs5slIxdvEXNrt0I2rSi5wT5cBDrbbJXTNSFWaD0zUbpUpNbz Q8015PDxfo8JeizK5Uh7BsM1HoUDTDjoJcoRu5ZMERMxDuPLpjreWWATW2z6NivDTJI5 DbwA== X-Forwarded-Encrypted: i=1; AKwUvBwLVeHYJ5dLCG/aCiKTrl+CEcpEMAeIJLhvWDuk/LonryIASarYUMSsHpuC2Uk/hRHf8IMyxk1U@ietf.org X-Gm-Message-State: AFuF++mc/83s6VdD2/Nl5vf7erPeXFEm3iiM5le17M5/cNMfZbMKKbI9 7HZLvbstr6Dgd/9qPXLHEdvaQLCfEH43quJ5m7YjObQVj+bueE0ZsGH4 X-Gm-Gg: AYBFou3FGCrIlaRrXNVjoTEQxl/HdSk8qMQR7s0joEIcbucjweKA4MvbEDNL+2F3Lq6 DN06md9ABC4K1Uo+qYe8VU1+r245mTyYfdh5kGLY3Bt4vUTTQ1IRq9V3DJ4GCXmmE0EDD7q48VO WlAPQHzgyaLRBwuB5QqgHzLpzicS4qDGW31Ie5QiCmTWgxijl7QgYD4CKghVEjUMT4s79pbKUm5 NbO2tm9L4EaO4UDVo24Oen8qmbKms3tKZVg0u8nieLPEV4pC2cwp+kHTXK+vHceaTMOnjCV+H4T a2qCWp4/9T8SjOtHB/+yaMo13IDtEhbtqjQBAfigcdRW6d/bb2neeqDrHuy9MvZteXrYkzrRRuB rJgC3JzEoNtvs3LpCosn9s/NhO588+iSDbzNgtqfBGRzaMWi1wNSLuHYCIlL0arqZtXh0SW5pL3 rgvWDAbjqPo81cEDY4+J4IXWYBYOK0CbVx6+q54t3m7iafP8jkmI0Qd8rmY27q+i5IdCaoVVQyu 1HXYKX1BwfbzshLyt1t2B8cGw== X-Received: by 2002:a17:90b:4ad2:b0:39e:2192:97dc with SMTP id 98e67ed59e1d1-39e54a9c566mr7383981a91.6.1789758285540; Fri, 18 Sep 2026 12:04:45 -0700 (PDT) Received: from smtpclient.apple ([67.174.194.227]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-144d55e29absm662875c88.12.2026.09.18.12.04.44 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Sep 2026 12:04:45 -0700 (PDT) From: Mahesh Jethanandani Message-Id: <89865491-E362-4A8F-8519-42229EF64F75@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_DB374BAF-9447-4AFD-851A-91AF7C27ABDA" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.700.51.1.1\)) Date: Fri, 18 Sep 2026 12:04:33 -0700 In-Reply-To: To: Italo Busi References: <178113360263.257166.12910402475067836682@dt-datatracker-56f887f959-j9c2v> X-Mailer: Apple Mail (2.3864.700.51.1.1) X-Spamd-Bar: / Message-ID-Hash: 4EK5JCTUW6VJL2RKF6UYUXIKVWCZ3XSR X-Message-ID-Hash: 4EK5JCTUW6VJL2RKF6UYUXIKVWCZ3XSR X-MailFrom: mjethanandani@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; header-match-gen-art.ietf.org-0; header-match-gen-art.ietf.org-1; header-match-gen-art.ietf.org-2; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Italo Busi , "gen-art@ietf.org" , "draft-ietf-ivy-network-inventory-yang.all@ietf.org" , "ivy@ietf.org" , "last-call@ietf.org" X-Mailman-Version: 3.3.10 Precedence: list Subject: [Gen-art] Re: [Ivy] draft-ietf-ivy-network-inventory-yang-18 ietf last call Genart review List-Id: "GEN-ART: General Area Review Team" Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --Apple-Mail=_DB374BAF-9447-4AFD-851A-91AF7C27ABDA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Italo (and Authors), Thanks for trying to address the GENART review comments from Elwyn=20 and posting the -19 version of the draft. Here is my assessment of the = document=20 after that review and the update posted. I believe you have managed to address most of the comments. There is but = one=20 MINOR and several NITS that were not addressed from his review, and some=20= that got carried over.=20 BTW, I have also requested an RTGDIR review as the shepherd flagged the=20= relationship between TEAS and ACTN work. ---------------------------------------------------------------------- MINOR ---------------------------------------------------------------------- Section 6, component integration/de-integration (GENART major issue #2) > Section 6, current text: 1531 Since this YANG data model reports what it is actually installed = in 1532 the network, if a component (e.g., a board) is physically removed 1533 from the network, also its descendant components (e.g., daughter 1534 boards and ports) are also physically removed from the network = and, 1535 as a consequence, from the inventory data being reported through = this 1536 YANG data model. This addresses removal cleanly, but Davies's question about the other direction -- how a newly added/discovered component's inventory data = gets integrated, and whether that's expected to arrive atomically or incrementally -- isn't addressed in the document, even though the = authors' list response says protocol-level change notifications handle it. A = short sentence saying so would let a future reader find the rationale without = having=20 to dig up the list thread. ---------------------------------------------------------------------- NIT ---------------------------------------------------------------------- Several of these are new in -19 -- introduced by the same edits that = fixed the -18 reviewers' comments -- so they haven't been caught by anyone = yet. Section 5, `leaf name` description: 1101 "The name of the entity (e.g., component), as specified by 1102 a network operator, that provides a non-volatile 'handle' 1103 for the entity. The The network operator can specify a 1104 different value anytime during the entity lifetime. s/for the entity. The The network operator/for the entity. The network = operator/ s/name of the entity/name of the entity/ (double space) Section 5, `leaf is-main` description: 1449 It is therefore omitted in scenarios where the 1450 network element does not contain chassis = components 1451 which can can take or not the 'main' role s/which can can take/which can take/ (Pre-existing, not introduced in -19 -- carried forward from at least = -18 unnoticed by prior reviewers.) Appendix B, Terminology of Container: 2083 Within this document , term "container" represents an hardware 2084 component class capable of containing one or more removable = physical 2085 entities, e.g., a slot in a chassis which is capabable to contain = a 2086 board. s/represents an hardware/represents a hardware/ s/which is capabable to contain a board/capable of containing a board/ (This paragraph was rewritten from -18 to remove first-person "we/our" phrasing per Davies's comment, but the rewrite introduced the article error and the "capabable" typo.) Appendix C, Efficiency Issue: 2150 The main scope of this documento is to define the generic data = model, s/documento/document/ Acknowledgments: 3378 The authors would like to thank Reshad Rahman for his YANG Doctor 3379 eview. s/YANG Doctor\n eview./YANG Doctors review./ (Missing "r") 3381 The authors would like to thank Valery Smyslov, Samier Barguil, = and 3382 for their Security Directorate, Operational Directorate = (ops-dir), 3383 and General Area Review Team (Gen-ART) reviews. This sentence is missing the GENART reviewer's name -- reads "...Samier Barguil, and for their..." with a name-sized gap before "for their." = Should presumably be "...Valery Smyslov, Samier Barguil, and Elwyn Davies for their Security Directorate, Operational Directorate (ops-dir), and = General Area Review Team (Gen-ART) reviews.=E2=80=9D Thanks. > On Sep 17, 2026, at 5:48=E2=80=AFAM, Italo Busi = wrote: >=20 > Hi Elwyn, >=20 > Thanks a lot for your review and comments >=20 > We have just uploaded the -19 version of the draft addressing your = comments as per our feedbacks below with the only exception that instead = of using the term "intended to be running" for the software modules = reported in the base inventory, which seems quite confusing, we have = improved the description of the software information in the scope of = this draft and use the term "running" consistently through the document >=20 > Thanks, Italo (on behalf of co-authors/contributors) >=20 >> -----Original Message----- >> From: Italo Busi >> Sent: gioved=C3=AC 16 luglio 2026 12:18 >> To: Elwyn Davies ; gen-art@ietf.org >> Cc: draft-ietf-ivy-network-inventory-yang.all@ietf.org; ivy@ietf.org; = last- >> call@ietf.org >> Subject: [Ivy] Re: draft-ietf-ivy-network-inventory-yang-18 ietf last = call Genart >> review >>=20 >> Hi Elwyn, >>=20 >> Thanks a lot for your review and comments >>=20 >> See our feedbacks in line >>=20 >> We are still work on the detailed text changes and we will let you = know when >> we have uploaded the I-D update addressing your comments. >>=20 >> In the meanwhile, you can follow-up the on-going editorial work on = github: >>=20 >> https://github.com/ietf-ivy-wg/network-inventory-yang/pull/166 >>=20 >> Thanks, Italo (on behalf of co-authors/contributors) >>=20 >>> -----Original Message----- >>> From: Elwyn Davies via Datatracker >>> Sent: gioved=C3=AC 11 giugno 2026 01:20 >>> To: gen-art@ietf.org >>> Cc: draft-ietf-ivy-network-inventory-yang.all@ietf.org; = ivy@ietf.org; >>> last- call@ietf.org >>> Subject: [Ivy] draft-ietf-ivy-network-inventory-yang-18 ietf last = call >>> Genart review >>>=20 >>> Document: draft-ietf-ivy-network-inventory-yang >>> Title: A Base YANG Data Model for Network Inventory >>> Reviewer: Elwyn Davies >>> Review result: Ready with Issues >>>=20 >>> I am the assigned Gen-ART reviewer for this draft. The General Area >>> Review Team (Gen-ART) reviews all IETF documents being processed by >>> the IESG for the IETF Chair. Please treat these comments just like = any other >> last call comments. >>>=20 >>> For more information, please see the FAQ at >>>=20 >>> . >>>=20 >>> Document: draft-ietf-ivy-network-inventory-yang-18 >>> Reviewer: Elwyn Davies >>> Review Date: 2026-06-10 >>> IETF LC End Date: 2026-06-10 >>> IESG Telechat date: Not scheduled for a telechat >>>=20 >>> Summary: There is one potential issue that the document itself = brings >>> out and a couple of operational ssues that could make the >>> specification difficult to use especially on larger systems. >>> Otherwise, the document has a fair number of nits and editorial = issues >>> outside the YANG specification. I have not looked at the form of = the >>> YANG in great detail. Please note that some parts of the appendices = are >> (partly) written in academic paper style and need to be = depersonalized. >>>=20 >>> Judging from the example in Appendix E, the comments in the Security >>> section about the risks of very high volumes of YANG data needed to >>> complete the inventory of a network seem rather too well justified. = I >>> don't know if this could be a show stopper but feel that = consideration >>> should be given to this matter by peole with more hands-on knowledge >>> of inventory handling. I wonder if the inventory could be segmented >>> in some way to limit the size of chunks being handled. I am unsure >>> whether there is going to be much call for complete inventories to = be >>> interchanged. It strikes me that one aspect that has not been >>> discussed here is the dynamic cnstruction of complete inventories. = I >>> could see an example where a new component is added to a network: >>> Would the expansion of the inventory be conveniently carried out by >>> the new component carrying its own inventory and passing it over to >>> the inventory server (with appropriate security checks) for >>> integration into the overall inventory - as opposed to the central >>> inventory being updated by manual/semi-automatic interaction at the >>> inventory server. There are also potential risks of the consistency = of the >> model being damaged by incomplete or faulty removal of the inventory >> associated with a componet tht has been removed. >>>=20 >>=20 >> [Authors] The volume of inventory data in large scale networks is = huge, even if >> does not change quite often during the time. Addressing the = scalability issue is >> outside the scope of the YANG data model but mainly a protocol issue = (e.g., >> through pagination/segmentations, filtering, targeted notifications), = outside >> the scope of this document. Some considerations have been already = provided >> in Appendix C. >>=20 >>> Major issues: >>> 1. Potential problem: Size of complete YANG inventory = specifications >>> if needed to be interchanged between devices. >>=20 >> [Authors] See our reply to the summary above. >>=20 >>> 2. Possble problem: Ease or difficulty of = integrating/de-integrating >>> YANG inventory specifications for added or subtracted components. >>=20 >> [Author] >>=20 >> Is the question related to adding or removing component types to the = model or >> adding or removing components from the network? >>=20 >> The inventory needs to be updated every time components are added or >> removed from the network. Protocol-specific mechanisms can be used to = notify >> the client about these changes. >>=20 >> [\Author] >>=20 >>> 3. Handling inter-component connections and disconnections. Ensuring >>> that changes to interconnections can be handled in a way that limits >>> the scope for dangling connections to be left in place after changes >>> to components. This is not discussed in the document. >>>=20 >>=20 >> [Author] Since this data model reports what it is actually installed = in the >> network, it is somewhat implicit that if a component is actually = removed from >> the network, also its descendant components are removed. We will add = some >> text to clarify this behavior. >>=20 >>> Minor issues: >>> None >>>=20 >>> Nits/editorial comments: >>>=20 >>> S1, paras1 and 2: The definition of Network Inventory really needs = to >>> appear right at the beginning of the text. As this document is the >>> primary output of the IVY WG, I would suggest copying all or at = least >>> the beginning of the first paragraph of the charter of the IVY WG to >>> supply the definition of Network >>> Inventory:- thus some of all of: >>>=20 >>> Network inventory is a foundation for network management in all >>> types >>> of: Network operators need to keep a record of what equipment >>> is planned and installed in their networks (including a variety = of >>> information such as product name, vendor, product series, = embedded >>> software, and hardware/software versions). Network inventories = may >>> be constructed from management system data to represent the >>> expected >>> devices present in the network, and also be used to audit and >>> catalog >>> what devices are discovered in the network, and to expose that >>> information in a consistent way. >>>=20 >>> and delete para 2 >>>=20 >>=20 >> [Author] Ok in principle. However, this text is the scope of the IVY = WG while the >> scope of this document is a sub-set of it. We think we need to add = some text to >> indicate that the scope of this document is a subset of the whole = network >> inventory as defined in the IVY charter (e.g., installed and active = components >> and not planned or passive components) >>=20 >>> s1, para 3: s/overall network management/scheme of network >>> management/ >>>=20 >>> s1, para 3: "which was specified many years ago" If so, can we have = a >>> reference please. I could not identify where this specification is >>> located although maybe RFC 8969 may be relevant. If there isn't = one, >>> just omit this phrase - I am quite prepared to accept that it is a = useful >> fundamental block. >>>=20 >>=20 >> [Authors] The first sentence of this paragraph is now duplicated with = the >> Network Inventory definition added as proposed above. Therefore, we = would >> remove it. >>=20 >>> s1, para 3: s/well-planned/well-managed/ (One hopes that the = planning >>> precedes definition of the inventory; the inventory essentially >>> documents the plan). >>>=20 >>=20 >> [Authors] >>=20 >> We share the concern because inventory data does not provide = information >> about whether the network is well-planned or not. However, the = intention of >> the sentence is to use inventory data to check whether the network is = working >> as planned or some re-planning is needed. >>=20 >> We would rephrase as: >>=20 >> Network inventory management is a critical component for ensuring the >> infrastructure remains up-to-date (e.g., identifying assets that need = to be >> upgraded or decommissioned), stays healthy (e.g., auditing to = identify faulty >> elements), and is maintained to meet strict performance objectives. >> [/Authors] >>=20 >>> s1, para 4: s/to retrieve network element/to retrieve information >>> relating to network element/ >>>=20 >>=20 >> [Authors] Ok, we will update as proposed >>=20 >>> s1, para 4: s/are key enablers/provides key enablers/ >>>=20 >>=20 >> [Authors] Ok, we will update as proposed >>=20 >>> s1, para 4: s/a gap about/a gap relating to/ >>>=20 >>=20 >> [Authors] Ok, we will update as proposed >>=20 >>> s1, para 5: Please delete this paragraph. This is a standards >>> document and not a poltical positioning paper. >>>=20 >>=20 >> [Authors] Ok, we will remove as proposed >>=20 >>> s1, para 8: This paragraph does not read well. Suggest: >>> OLD: >>> As outlined in Section 6, the network inventory provides a read-only >>> perspective of the actual inventory data that a network controller >>> knows of what it is actually installed within the network. NEW: As >>> outlined in Section 6, the network inventory provides a read-only >>> perspective of the actual inventory data of which a network = controller >>> is aware covering the components that are actually installed and >>> active within the network. END >>=20 >> [Authors] >>=20 >> Based on previous discussion, instead of the term "active" we have = decided to >> say "intended to be running" >>=20 >> See also this mail thread: >> https://mailarchive.ietf.org/arch/msg/ivy/WFd4SE5E6PQDdapUkuMHbHHeXh >> 8/ >>=20 >> Therefore, we would update the text as you proposed but with >> c/active/intended to be running/ >>=20 >> Note: it seems the terminology is not yet fully consistent in the = document. The >> YANG module still uses "configured to be active" and the Security >> Considerations still uses the term "active". We would align these = terms as well >> for consistency. >>=20 >> [/Authors] >>=20 >>> The term 'spare' >>> in the second sentence of this paragraph may be misleading. Networks >>> may contain backup components which are there as spares that can be >>> switched in automatically in the event of the primary component >>> failing. I would expect the inventory to account for these. This is >>> clearly different from having offline spares that might require = human >>> intervention to insert them into the active inventory. >>>=20 >>=20 >> [Authors] We would align this text with the terminology used in = section 6: >> c/spare or inactive assets/inactive assets or warehouse spares/ >>=20 >>> s2, definition of Hardware Component: s/The generalisation of/A >>> portmanteau [or alternatively 'An umbrella'] term for any of/ It >>> might be worth referencing RFC 8348 here which sets out terms for = adding >> items to the lists. >>>=20 >>=20 >> [Authors] >>=20 >> We would rephrase as: >>=20 >> "A general definition of category of components as defined in = [RFC8348] and >> [IANA_HW_YANG] (e.g., backplane, battery, container, central = processing unit >> (CPU), chassis, fan, module, port, power supply, sensor, stack, and = storage >> device components)." >>=20 >> [/Authors] >>=20 >>> s2, definition of Component: >>> OLD: >>> Component: The generalization of the hardware component definition = to >>> include other inventory objects which can be managed, from an >>> inventory perspective, like hardware components. NEW: Component: A >>> furher extension of the portmanteau hardware component definition to >>> include other inventory objects which can be managed, from an >>> inventory perspective, in the same way as hardware components. >>> END >>>=20 >>=20 >> [Authors] >>=20 >> We would rephrase as: >>=20 >> "A further extension of the hardware component definition to include = other >> inventory objects which can be managed, from an inventory = perspective, in the >> same way as hardware components." >>=20 >> [/Authors] >>=20 >>> s3.1 and s3.1.1: The use of 'such as' in the first paragraphs of = these >>> sections implies that there are other common attributes. etc. I >>> suspect that the lists givn are complete and different phraseology = should be >> used: >>>=20 >>> In s3,1; >>> OLD: >>> For all the inventory objects, there are some common attributes, = such as: >>> NEW: >>> All inventory objects have the following common attributes: >>> END >>>=20 >>=20 >> [Authors] >>=20 >> We agree that "such as" can be misleading since the list contains all = the >> attributes currently defined in the grouping = basic-common-entity-attributes. >>=20 >> However, we would prefer to rephrase this text to be also future = proof and >> remain valid even if a new attribute is added in the future. >>=20 >> We would rephrase as: "For all the inventory objects, there are some = common >> attributes, including:" >>=20 >> [/Authors] >>=20 >>> In s3.1.1: >>> OLD: >>> To be consistent with the component definition, some of the = attributes >>> defined in [RFC8348] for components are reused for network elements, = such >> as: NEW: >>> To be consistent with the component definition, the following >>> attributes defined in [RFC8348] for components are reused for = network >>> elements: END >>>=20 >>=20 >> [Authors] Ok, we will update as proposed (no need to a future proof = sentence >> since it refers to RFC8348) >>=20 >>> s3.1, definition of ne_id: 'assigned by the server' - Which server = would that >> be? >>>=20 >>=20 >> [Authors] It is the server exposing the YANG data model, as defined = in RFC7950 >>=20 >>> s3.3, para 1: s/same approach of/same approach as/ >>>=20 >>=20 >> [Authors] Ok, we will update as proposed >>=20 >>> s3.3, definitions of hardware_rev and mfg-date: Should the >>> specification offer a standard form for use in case these items are = not known? >>>=20 >>=20 >> [Authors] These attributes, likewise other attributes, are optional = and can be >> omitted if not known, as outlined in section 6. >>=20 >>> s3.3.1, para 1:s./classifies/classify/, s/and manage all/and manages >>> all/ >>>=20 >>=20 >> [Authors] Ok, we will update as proposed >>=20 >>> s3.3.2, para 3: s/an Application software modules/an Application >>> module [or Application software modules]/ Which is intended? >>>=20 >>=20 >> [Authors] >>=20 >> Both changes should be fine. We would rephrase as: >>=20 >> "For example, one Operating System and one or more Application = software >> modules can be intended to be running in a network element, and, in = the same >> way, one boot-loader, one firmware and one or more FPGA software = modules >> can be intended to be running on a component like a circuit pack." >>=20 >> [/Authors] >>=20 >>> s3.3.2, para 3: Expand FPGA - it isn't defined currently. >>>=20 >>=20 >> [Authors] Ok, we will update as proposed >>=20 >>> s3.3.2, para5: s/under definition/defined/ (By the time this draft = is >>> published, the model will have been defined) >>>=20 >>=20 >> [Authors] Ok, we will update as proposed >>=20 >>> s3.3.2, para 6: 'have similar replaceable requrements': Does this >>> mean that the components have similar requirements or = characteristics >>> as to replaceability? I don't understand what is meant here. >>>=20 >>=20 >> [Authors] >>=20 >> Your understanding is correct. >>=20 >> We would rephrase as: c/have similar replaceable requirements/have = similar >> replaceability requirements/ >>=20 >> [/Authors] >>=20 >>> s3.3.2, para 6: s/one or more software patch information/one or more >>> records of software patches that have been applied./ >>>=20 >>=20 >> [Authors] Ok, we will update as proposed >>=20 >>> s3,3.2, last para: s/like/such as/ >>>=20 >>=20 >> [Authors] Ok, we will update as proposed >>=20 >>> s5, module description item: Suggest adding reference to RFC 8342 = for >>> Datastore Architecture >>>=20 >>=20 >> [Authors] The document is following the updated guidelines in RFC9907 = which >> now requires to highlight only when the module is not-NMDA compliant >>=20 >>> s6, para 7: s/ and outside the scope/and is outside the scope/ >>>=20 >>=20 >> [Authors] Ok, we will update as proposed >>=20 >>> s6, para 8: s/dooes not constraint/does not constrain/ >>>=20 >>=20 >> [Authors] Ok, we will update as proposed >>=20 >>> s6, para 10: The term 'brownfield' is jargon that needs to be >>> explained or replaced. >>>=20 >>> I suggest somethings along the lines of: >>>=20 >>> If the inventory system defined by this document is to be = deployed >>> into a nework which has a preexistng inventory system.... >>>=20 >>=20 >> [Authors] Ok, we will update as proposed >>=20 >>> s9,2: Arguably RFC7951 and RFC 8340 are normative references. If = RFC >>> 6241 >>> (NETCONF) is nomative then I would suggest RFC 8040 (RESTCONF) is >>> normative as well... but they could also both be considered = informative. >>>=20 >>=20 >> [Authors] >>=20 >> We think that RFC7951 should remain informative since the draft does = not >> dictate any encoding but it is just using RFC7951 encoding in the = JSON >> examples. This approach is aligned with other RFCs defining YANG data = models >> with JSON examples. >>=20 >> We think that RFC8340 can remain informative to align with other RFCs >> defining YANG data models with JSON examples. >>=20 >> According to section 3.7.1 of RFC9907, within the Security = Consideration >> section, RFC6241 and RFC8040 are by default referenced as informative = unless >> normatively cited in other sections. >>=20 >> In this draft, RFC6241 is also normatively referenced in section 2.2 = and >> therefore the reference to RFC6241 should remain Normative. >>=20 >> In this draft, RFC8040 in also informatively referenced in Appendix = C, and >> therefore the reference to RFC8040 should remain informative. >>=20 >> [/Authors] >>=20 >>> Appendix A: The firstt two and last paragraphs and table of this >>> section section is written in academic paper style with 'we' do = things and >> 'our' >>> rather than impersonal standards form and need to be rewritten. >>> There are also two missing deifinte articles in the first sentence = of the second >> paragraph. >>> before Openconfig and "ietf-hardware".and another one missing in = each >>> of the third and fourth paragraphs. >>>=20 >>=20 >> [Authors] Ok, we will update the appendix as suggested >>=20 >>> Appendices B and C; Also have the academic paper style issue. >>>=20 >>=20 >> [Authors] Ok, we will update the appendices as suggested >>=20 >>> Appendix C, para 3: s/large scale of networks/large scale networks/ >>>=20 >>=20 >> [Authors] Ok, we will update as proposed >>=20 >>> Appendix C, para 4: s/ so to cover/so as to cover/, s/in YANG = model/in >>> the YANG model/, s/it is only needed/it is only necessary/ >>>=20 >>=20 >> [Authors] Ok, we will update as proposed >>=20 >>> Appendix D, para 2: s/three type of ports/three types of port/ >>>=20 >>=20 >> [Authors] Ok, we will update as proposed >>=20 >>> Appendix E:, para 2: ss/composed by/comprised of/ >>>=20 >>=20 >> [Authors] Ok, we will update as proposed >>=20 >>> Appendix E para 3 and para 8: :s/Stacked switch/Stacked switches/ >>>=20 >>=20 >> [Authors] Ok, we will update as proposed >>=20 >>> Appendix E, para 6: s/synchronzed/require synchronized/ >>>=20 >>=20 >> [Authors] Ok, we will update as proposed >>=20 >>> Appendix E, titles of Figures 5 and 6: s/a stacked switch/stacked >>> switches/ >>>=20 >>=20 >> [Authors] Ok, we will update as proposed. For consistency, we will = update also >> the title of Figure 7. >>=20 >>> Appendix E, para 9: >>> OLD: >>> Using the base network inventory YANG data model each interconnected >>> switch can be modelled as a chassis within the same network element, >>> which models the cascaded switch. The ports used to interconnect the >>> different chassis are normal (traffic) ports and modelled like other >>> ports. NEW: Using the base network inventory, the YANG data model = for >>> each interconnected switch can be set up as a chassis within the = same >>> network element, which models the cascaded switch. The ports used to >>> interconnect the different chassis are normal >>> (traffic) ports and modelled in the same way as other ports. END >>>=20 >>=20 >> [Authors] We would rephrase as: >>=20 >> Using the base network inventory YANG data model, each interconnected >> switch is modelled as a chassis component of the same network = element. The >> ports used to interconnect these switches are normal (traffic) ports = and >> modelled like other ports. >>=20 >> [/Authors] >>=20 >>> Appendix E: [Aside: Yes, that's quite a lot of YANG!! ] >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> Ivy mailing list -- ivy@ietf.org >>> To unsubscribe send an email to ivy-leave@ietf.org >> _______________________________________________ >> Ivy mailing list -- ivy@ietf.org >> To unsubscribe send an email to ivy-leave@ietf.org Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_DB374BAF-9447-4AFD-851A-91AF7C27ABDA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Italo (and = Authors),

Thanks for trying to address the GENART = review comments from Elwyn 
and posting the -19 version = of the draft. Here is my assessment of the = document 
after that review and the update = posted.

I believe you have managed to address = most of the comments. There is but one 
MINOR and several = NITS that were not addressed from his review, and = some 
that got carried = over. 

BTW, I have also requested an = RTGDIR review as the shepherd flagged the 
relationship = between TEAS and ACTN = work.

--------------------------------------= --------------------------------
MINOR
---------------= -------------------------------------------------------

Section 6, component integration/de-integration (GENART major = issue #2)

> Section 6, current = text:
1531   Since this YANG data model reports what it = is actually installed in
1532   the network, if a = component (e.g., a board) is physically removed
1533   = from the network, also its descendant components (e.g., = daughter
1534   boards and ports) are also physically = removed from the network and,
1535   as a consequence, = from the inventory data being reported through this
1536 =   YANG data model.

This addresses removal = cleanly, but Davies's question about the other
direction -- = how a newly added/discovered component's inventory data = gets
integrated, and whether that's expected to arrive = atomically or
incrementally -- isn't addressed in the = document, even though the authors'
list response says = protocol-level change notifications handle it. A = short
sentence saying so  would let a future reader find = the rationale without having 
to dig up the list = thread.

-----------------------------------------= -----------------------------
NIT
--------------------= --------------------------------------------------

Several of these are new in -19 -- introduced by the same edits that = fixed
the -18 reviewers' comments -- so they haven't been = caught by anyone yet.

Section 5, `leaf name` = description:
1101   "The name of the  entity (e.g., = component), as specified by
1102    a network = operator, that provides a non-volatile 'handle'
1103   =  for the entity. The The network operator can specify = a
1104    different value anytime during the entity = lifetime.
s/for the entity. The The network operator/for the = entity. The network operator/
s/name of the  entity/name = of the entity/ (double space)

Section 5, `leaf = is-main` description:
1449           =          It is therefore omitted in scenarios = where the
1450             =        network element does not contain chassis = components
1451             =        which can can take or not the 'main' = role
s/which can can take/which can = take/
(Pre-existing, not introduced in -19 -- carried forward = from at least -18
unnoticed by prior = reviewers.)

Appendix B, Terminology of = Container:
2083   Within this document , term "container" = represents an hardware
2084   component class capable of = containing one or more removable physical
2085   = entities, e.g., a slot in a chassis which is capabable to contain = a
2086   board.
s/represents an = hardware/represents a hardware/
s/which is capabable to = contain a board/capable of containing a board/
(This paragraph = was rewritten from -18 to remove first-person = "we/our"
phrasing per Davies's comment, but the rewrite = introduced the article
error and the "capabable" = typo.)

Appendix C, Efficiency = Issue:
2150   The main scope of this documento is to = define the generic data = model,
s/documento/document/

Acknowledg= ments:
3378   The authors would like to thank Reshad = Rahman for his YANG Doctor
3379   eview.
s/YANG = Doctor\n   eview./YANG Doctors review./
(Missing = "r")

3381   The authors would like to = thank Valery Smyslov, Samier Barguil, and
3382   for = their Security Directorate, Operational Directorate = (ops-dir),
3383   and General Area Review Team (Gen-ART) = reviews.
This sentence is missing the GENART reviewer's name = -- reads "...Samier
Barguil, and for their..." with a = name-sized gap before "for their." Should
presumably be = "...Valery Smyslov, Samier Barguil, and Elwyn Davies for
their = Security Directorate, Operational Directorate (ops-dir), and = General
Area Review Team (Gen-ART) = reviews.=E2=80=9D

Thanks.


On Sep 17, 2026, at 5:48=E2=80=AFAM, = Italo Busi <Italo.Busi@huawei.com> wrote:

Hi Elwyn,

Thanks a = lot for your review and comments

We have just uploaded the -19 = version of the draft addressing your comments as per our feedbacks below = with the only exception that instead of using the term "intended to be = running" for the software modules reported in the base inventory, which = seems quite confusing, we have improved the description of the software = information in the scope of this draft and use the term "running" = consistently through the document

Thanks, Italo (on behalf of = co-authors/contributors)

-----Original = Message-----
From: Italo Busi = <Italo.Busi=3D40huawei.com@dmarc.ietf.org>
Sent: gioved=C3=AC = 16 luglio 2026 12:18
To: Elwyn Davies <elwynd@dial.pipex.com>; = gen-art@ietf.org
Cc: = draft-ietf-ivy-network-inventory-yang.all@ietf.org; ivy@ietf.org; = last-
call@ietf.org
Subject: [Ivy] Re: = draft-ietf-ivy-network-inventory-yang-18 ietf last call = Genart
review

Hi Elwyn,

Thanks a lot for your review = and comments

See our feedbacks in line

We are still work = on the detailed text changes and we will let you know when
we have = uploaded the I-D update addressing your comments.

In the = meanwhile, you can follow-up the on-going editorial work on = github:

https://github.com/ietf-ivy-wg/network-inventory-yang/pull/= 166

Thanks, Italo (on behalf of = co-authors/contributors)

-----Original = Message-----
From: Elwyn Davies via Datatracker = <noreply@ietf.org>
Sent: gioved=C3=AC 11 giugno 2026 = 01:20
To: gen-art@ietf.org
Cc: = draft-ietf-ivy-network-inventory-yang.all@ietf.org; = ivy@ietf.org;
last- call@ietf.org
Subject: [Ivy] = draft-ietf-ivy-network-inventory-yang-18 ietf last call
Genart = review

Document: draft-ietf-ivy-network-inventory-yang
Title: = A Base YANG Data Model for Network Inventory
Reviewer: Elwyn = Davies
Review result: Ready with Issues

I am the assigned = Gen-ART reviewer for this draft. The General Area
Review Team = (Gen-ART) reviews all IETF documents being processed by
the IESG for = the IETF Chair.  Please treat these comments just like any = other
last call comments.

For more information, please see the FAQ = at

<https://wiki.ietf.org/en/group/gen/GenArtFAQ>.

Doc= ument: draft-ietf-ivy-network-inventory-yang-18
Reviewer: Elwyn = Davies
Review Date: 2026-06-10
IETF LC End Date: = 2026-06-10
IESG Telechat date: Not scheduled for a = telechat

Summary:  There is one potential issue that the = document itself brings
out and a couple of operational ssues that = could make the
specification difficult to use especially on larger = systems.
Otherwise, the document has a fair number of nits and = editorial issues
outside the YANG specification.  I have not = looked at the form of the
YANG in great detail.  Please note = that some parts of the appendices are
(partly) written = in academic paper style and need to be depersonalized.

Judging from the example in Appendix E, the comments = in the Security
section about the risks of very high volumes of YANG = data needed to
complete the inventory of a network seem rather too = well justified. I
don't know if this could be a show stopper but feel = that consideration
should be given to this matter by peole with more = hands-on knowledge
of inventory handling.  I wonder if the = inventory could be segmented
in some way to limit the size of chunks = being handled.  I am unsure
whether there is going to be much = call for complete inventories to be
interchanged.  It =  strikes me that one aspect that has not been
discussed here is = the dynamic cnstruction of complete inventories.  I
could see an = example where a new component is added to a network:
Would the = expansion of the inventory be conveniently carried out by
the new = component carrying its own inventory and passing it over to
the = inventory server (with appropriate security checks) for
integration = into the overall inventory - as opposed to the central
inventory = being updated by manual/semi-automatic interaction at the
inventory = server.  There are also potential risks of the consistency of = the
model being damaged by incomplete or faulty removal = of the inventory
associated with a componet tht has been = removed.


[Authors] The = volume of inventory data in large scale networks is huge, even = if
does not change quite often during the time. Addressing the = scalability issue is
outside the scope of the YANG data model but = mainly a protocol issue (e.g.,
through pagination/segmentations, = filtering, targeted notifications), outside
the scope of this = document. Some considerations have been already provided
in Appendix = C.

Major issues:
1. Potential = problem:  Size of complete YANG inventory specifications
if = needed to be interchanged between devices.

[Authors] = See our reply to the summary above.

2. = Possble problem:  Ease or difficulty of = integrating/de-integrating
YANG inventory specifications for added or = subtracted components.

[Author]

Is the = question related to adding or removing component types to the model = or
adding or removing components from the network?

The = inventory needs to be updated every time components are added = or
removed from the network. Protocol-specific mechanisms can be used = to notify
the client about these = changes.

[\Author]

3. Handling = inter-component connections and disconnections. Ensuring
that changes = to interconnections can be handled in a way that limits
the scope for = dangling connections to be left in place after changes
to components. =  This is not discussed in the = document.


[Author] Since this data model reports = what it is actually installed in the
network, it is somewhat implicit = that if a component is actually removed from
the network, also its = descendant components are removed. We will add some
text to clarify = this behavior.

Minor = issues:
None

Nits/editorial comments:

S1, paras1 and = 2:  The definition of Network Inventory really needs to
appear = right at the beginning of the text.  As this document is = the
primary output of the IVY WG, I would suggest copying all or at = least
the beginning of the first paragraph of the charter of the IVY = WG to
supply the definition of Network
Inventory:- thus some of = all of:

    Network inventory is a foundation for = network management in all
types
    of: Network = operators need to keep a record of what equipment
    is = planned and installed in their networks (including a variety = of
    information such as product name, vendor, product = series, embedded
    software, and hardware/software = versions). Network inventories may
    be constructed from = management system data to represent the
expected
    = devices present in the network, and also be used to audit = and
catalog
   what devices are discovered in the = network, and to expose that
   information in a consistent = way.

and delete para 2


[Author] Ok in = principle. However, this text is the scope of the IVY WG while = the
scope of this document is a sub-set of it. We think we need to = add some text to
indicate that the scope of this document is a subset = of the whole network
inventory as defined in the IVY charter (e.g., = installed and active components
and not planned or passive = components)

s1, para 3:  s/overall = network management/scheme of network
management/

s1, para 3: = "which was specified many years ago"  If so, can we have = a
reference please.  I could not identify where this = specification is
located although maybe RFC 8969 may be = relevant.  If there isn't one,
just omit this phrase - I am = quite prepared to accept that it is a useful
fundamental = block.


[Authors] The = first sentence of this paragraph is now duplicated with the
Network = Inventory definition added as proposed above. Therefore, we = would
remove it.

s1, para 3: = s/well-planned/well-managed/ (One hopes that the planning
precedes = definition of the inventory;  the inventory = essentially
documents the = plan).


[Authors]

We share the concern = because inventory data does not provide information
about whether the = network is well-planned or not. However, the intention of
the = sentence is to use inventory data to check whether the network is = working
as planned or some re-planning is needed.

We would = rephrase as:

Network inventory management is a critical component = for ensuring the
infrastructure remains up-to-date (e.g., identifying = assets that need to be
upgraded or decommissioned), stays healthy = (e.g., auditing to identify faulty
elements), and is maintained to = meet strict performance objectives.
[/Authors]

s1, para 4: s/to retrieve network element/to retrieve = information
relating to network = element/


[Authors] Ok, we will update as = proposed

s1, para 4: s/are key = enablers/provides key enablers/


[Authors] Ok, we = will update as proposed

s1, para 4: s/a = gap about/a gap relating to/


[Authors] Ok, we = will update as proposed

s1, para = 5:  Please delete this paragraph.  This is a = standards
document and not a poltical positioning = paper.


[Authors] Ok, we will remove as = proposed

s1, para 8:  This = paragraph does not read well.  Suggest:
OLD:
As outlined in = Section 6, the network inventory provides a read-only
perspective of = the actual inventory data that a network controller
knows of what it = is actually installed within the network. NEW: As
outlined in Section = 6, the network inventory provides a read-only
perspective of the = actual inventory data of which a network controller
is aware covering = the components that are actually installed and
active within the = network. END

[Authors]

Based on previous = discussion, instead of the term "active" we have decided to
say = "intended to be running"

See also this mail = thread:
https://mailarchive.ietf.org/arch/msg/ivy/WFd4SE5E6PQDdapUkuMHb= HHeXh
8/

Therefore, we would update the text as you proposed = but with
c/active/intended to be running/

Note: it seems the = terminology is not yet fully consistent in the document. The
YANG = module still uses "configured to be active" and the = Security
Considerations still uses the term "active". We would align = these terms as well
for = consistency.

[/Authors]

The term = 'spare'
in the second sentence of this paragraph may be misleading. = Networks
may contain backup components which are there as spares that = can be
switched in automatically in the event of the primary = component
failing. I would expect the inventory to account for these. = This is
clearly different from having offline spares that might = require human
intervention to insert them into the active = inventory.


[Authors] We would align this text = with the terminology used in section 6:
c/spare or inactive = assets/inactive assets or warehouse spares/

s2, definition of Hardware Component:  s/The = generalisation of/A
portmanteau [or alternatively 'An umbrella'] term = for any of/  It
might be worth referencing RFC 8348 here which = sets out terms for adding
items to the = lists.


[Authors]

We would rephrase = as:

"A general definition of category of components as defined in = [RFC8348] and
[IANA_HW_YANG] (e.g., backplane, battery, container, = central processing unit
(CPU), chassis, fan, module, port, power = supply, sensor, stack, and storage
device = components)."

[/Authors]

s2, = definition of Component:
OLD:
Component: The generalization of the = hardware component definition to
include other inventory objects = which can be managed, from an
inventory perspective, like hardware = components. NEW: Component: A
furher extension of the portmanteau = hardware component definition to
include other inventory objects = which can be managed, from an
inventory perspective, in the same way = as hardware = components.
END


[Authors]

We would = rephrase as:

"A further extension of the hardware component = definition to include other
inventory objects which can be managed, = from an inventory perspective, in the
same way as hardware = components."

[/Authors]

s3.1 and = s3.1.1: The use of 'such as' in the first paragraphs of = these
sections implies that there are other common attributes. = etc.  I
suspect that the lists givn are complete and = different phraseology should be
used:

In s3,1;
OLD:
For all the inventory objects, = there are some common attributes, such as:
NEW:
All inventory = objects have the following common = attributes:
END


[Authors]

We agree = that "such as" can be misleading since the list contains all = the
attributes currently defined in the grouping = basic-common-entity-attributes.

However, we would prefer to = rephrase this text to be also future proof and
remain valid even if a = new attribute is added in the future.

We would rephrase as: "For = all the inventory objects, there are some common
attributes, = including:"

[/Authors]

In = s3.1.1:
OLD:
To be consistent with the component definition, some = of the attributes
defined in [RFC8348] for components are reused for = network elements, such
as: NEW:
To be consistent with the component definition, the = following
attributes defined in [RFC8348] for components are reused = for network
elements: END


[Authors] Ok, we = will update as proposed (no need to a future proof sentence
since it = refers to RFC8348)

s3.1, definition of = ne_id: 'assigned by the server' -  Which server would = that
be?


[Authors] It is the server exposing = the YANG data model, as defined in RFC7950

s3.3, para 1: s/same approach of/same approach = as/


[Authors] Ok, we will update as = proposed

s3.3, definitions of = hardware_rev and mfg-date:  Should the
specification offer a = standard form for use in case these items are not = known?


[Authors] These attributes, likewise = other attributes, are optional and can be
omitted if not known, as = outlined in section 6.

s3.3.1, para = 1:s./classifies/classify/, s/and manage all/and = manages
all/


[Authors] Ok, we will update as = proposed

s3.3.2, para 3: s/an = Application software modules/an Application
module [or Application = software modules]/ Which is = intended?


[Authors]

Both changes should = be fine. We would rephrase as:

"For example, one Operating System = and one or more Application software
modules can be intended to be = running in a network element, and, in the same
way, one boot-loader, = one firmware and one or more FPGA software modules
can be intended to = be running on a component like a circuit = pack."

[/Authors]

s3.3.2, para = 3: Expand FPGA - it isn't defined = currently.


[Authors] Ok, we will update as = proposed

s3.3.2, para5: s/under = definition/defined/ (By the time this draft is
published, the model = will have been defined)


[Authors] Ok, we will = update as proposed

s3.3.2, para = 6:  'have similar replaceable requrements':  Does this
mean = that the components have similar requirements or characteristics
as = to replaceability?  I don't understand what is meant = here.


[Authors]

Your understanding is = correct.

We would rephrase as: c/have similar replaceable = requirements/have similar
replaceability = requirements/

[/Authors]

s3.3.2, = para 6: s/one or more software patch information/one or more
records = of software patches that have been = applied./


[Authors] Ok, we will update as = proposed

s3,3.2, last para: s/like/such = as/


[Authors] Ok, we will update as = proposed

s5, module description = item:  Suggest adding reference to RFC 8342 for
Datastore = Architecture


[Authors] The document is following = the updated guidelines in RFC9907 which
now requires to highlight = only when the module is not-NMDA compliant

s6, para 7: s/ and outside the scope/and is outside the = scope/


[Authors] Ok, we will update as = proposed

s6, para 8: s/dooes not = constraint/does not constrain/


[Authors] Ok, we = will update as proposed

s6, para = 10:  The term 'brownfield' is jargon that needs to be
explained = or replaced.

 I suggest somethings along the lines = of:

      If the inventory system defined by this = document is to be deployed
     into a = nework which has a  preexistng inventory = system....


[Authors] Ok, we will update as = proposed

s9,2:  Arguably RFC7951 = and RFC 8340 are normative references.  If RFC
6241
(NETCONF) = is nomative then I would suggest RFC  8040 (RESTCONF) = is
normative as well... but they could also both  be considered = informative.


[Authors]

We think that = RFC7951 should remain informative since the draft does not
dictate = any encoding but it is just using RFC7951 encoding in the = JSON
examples. This approach is aligned with other RFCs defining YANG = data models
with JSON examples.

We think that RFC8340 can = remain informative to align with other RFCs
defining YANG data models = with JSON examples.

According to section 3.7.1 of RFC9907, within = the Security Consideration
section, RFC6241 and RFC8040 are by = default referenced as informative unless
normatively cited in other = sections.

In this draft, RFC6241 is also normatively referenced = in section 2.2 and
therefore the reference to RFC6241 should remain = Normative.

In this draft, RFC8040 in also informatively = referenced in Appendix C, and
therefore the reference to RFC8040 = should remain informative.

[/Authors]

Appendix A:  The firstt two and last paragraphs and = table of this
section section is written in academic paper = style  with 'we' do things and
'our'
rather than impersonal standards form  and need to be = rewritten.
There are also two missing deifinte articles in the first = sentence of the second
paragraph.
before Openconfig and "ietf-hardware".and another one = missing in each
of the third and fourth = paragraphs.


[Authors] Ok, we will update the = appendix as suggested

Appendices B and = C; Also have the academic paper style = issue.


[Authors] Ok, we will update the = appendices as suggested

Appendix C, = para 3: s/large scale of networks/large scale = networks/


[Authors] Ok, we will update as = proposed

Appendix C, para 4: s/ so to = cover/so as to cover/, s/in YANG model/in
the YANG model/, s/it is = only needed/it is only necessary/


[Authors] Ok, = we will update as proposed

Appendix D, = para 2: s/three type of ports/three types of = port/


[Authors] Ok, we will update as = proposed

Appendix E:, para 2: = ss/composed by/comprised of/


[Authors] Ok, we = will update as proposed

Appendix E para = 3 and para 8: :s/Stacked switch/Stacked = switches/


[Authors] Ok, we will update as = proposed

Appendix E, para 6: = s/synchronzed/require synchronized/


[Authors] = Ok, we will update as proposed

Appendix = E, titles of Figures 5 and 6: s/a stacked = switch/stacked
switches/


[Authors] Ok, we = will update as proposed. For consistency, we will update also
the = title of Figure 7.

Appendix E, para = 9:
OLD:
Using the base network inventory YANG data model each = interconnected
switch can be modelled as a chassis within the same = network element,
which models the cascaded switch. The ports used to = interconnect the
different chassis are normal (traffic) ports and = modelled like other
ports. NEW: Using the base network inventory, the = YANG data model for
each interconnected switch can be set up as a = chassis within the same
network element, which models the cascaded = switch. The ports used to
interconnect the different chassis are = normal
(traffic) ports and modelled in the same way as other ports. = END


[Authors] We would rephrase as:

Using = the base network inventory YANG data model, each = interconnected
switch is modelled as a chassis component of the same = network element. The
ports used to interconnect these switches are = normal (traffic) ports and
modelled like other = ports.

[/Authors]

Appendix E: = [Aside: Yes, that's quite a lot of YANG!! = ]



_______________________________________________
Ivy = mailing list -- ivy@ietf.org
To unsubscribe send an email to = ivy-leave@ietf.org
_______________________________________= ________
Ivy mailing list -- ivy@ietf.org
To unsubscribe send an = email to = ivy-leave@ietf.org


Mahesh = Jethanandani
mjethanandani@gmail.com

<= br class=3D"Apple-interchange-newline">




= --Apple-Mail=_DB374BAF-9447-4AFD-851A-91AF7C27ABDA--