Re: [Inventory-yang] IESG comments to charter

[Daniele Ceccarelli <[e-mail]>]

Hi working group,

i tried to implement all the modifications we discussed in the updated
version of the charter:

https://docs.google.com/document/d/1TVhx-9bkm9RkYrSOqdAG837VVyDq_O07Q-Yo-qF1O0w/edit

Thanks
Daniele

On Thu, May 11, 2023 at 4:45 PM <[e-mail]> wrote:

> Hi Italo,
>
>
>
> Please see further replies in line.
>
>
>
> Cheers
>
> Daniele
>
>
>
> *From:* Inventory-yang <[e-mail]> *On Behalf Of *Italo
> Busi
> *Sent:* Thursday, May 11, 2023 3:28 PM
> *To:* Daniele Ceccarelli <[e-mail]>; [e-mail]
> *Subject:* Re: [Inventory-yang] IESG comments to charter
>
>
>
> Thanks Daniele for taking care of the comments
>
>
>
> Please find some comments of mine in-line
>
>
>
> When not commenting, I fully agree with your reply
>
>
>
> Italo
>
>
>
> *From:* Inventory-yang <[e-mail]> *On Behalf Of *Daniele
> Ceccarelli
> *Sent:* giovedì 11 maggio 2023 13:45
> *To:* [e-mail]
> *Subject:* [Inventory-yang] IESG comments to charter
>
>
>
> Hi all,
>
>
>
> at the following link you can find the IESG comments to the proposed
> charter:
>
>
>
> https://datatracker.ietf.org/doc/charter-ietf-nimby/ballotpopup/918699/
>
>
>
> I had just started replying to them when I realized that they were just
> sent to the chairs-to be of the WG.
>
> I'm copying below the comments and proposed replies. Please add/amend.
>
>
>
> Thanks
>
> Daniele
>
>
>
> *1. From Éric Vyncke*
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> Coordinated work in this area is indeed very much needed! And I am
> supporting it, hoping that the comments below will be addressed before the
> external review.
>
> 1st §: should the past (i.e., removed equipment) be part of the inventory
> per
> symmetry with the 'planned' ones ?
>
> [DC]i don't have a strong opinion here. History is always good to have,
> but how to decide how long to keep the information? Weeks? Months?
>
> *[Italo Busi] Maybe I have misunderstood the charter but I am not sure
> whether the management of planned components is in the scope of the WG*
>
> *I see the “planned” term in the first paragraph as part of the motivation
> but in the scope below (e.g., item B) only the deployed equipment seems to
> be in the scope of the work*
>
> *[[DC2]] I don’t remember what we decided in the end but the charter
> indeed says “what equipment is planned and installed in their networks” at
> the top and then B says “which physical/virtual devices are deployed”. In
> the end we’re speaking about a single parameter to be added which says if a
> component is deployed, planned or removed. If a controller supports that
> info why not allowing to export it? *
>
>
>
> 2nd §: "venue for discussion of inventory YANG models" seems to contradict
> the work items list as some will be published (even already contradicting
> somehow
>
> [DC] If i get this right the word "discussion" means that the WG is not
> supposed to produce any document/model. Maybe we can just drop it and say:
> "provide a venue for inventory YANG models..."
>
> *[Italo Busi] I can see the confusion from the current wording. I am
> wondering whether we can combine this paragraph with the following two
> paragraphs to indicate that the scope of the WG is twofold:*
>
>    1. *”to derive common building-blocks”;*
>    2. *“coordinator of the inventory work” across multiple WGs and Areas *
>
> *[[DC2]] The following paragraph is already updated due to another comment
> (see below). Maybe the merge of the two paragraphs could become something
> like:*
>
>
>
> *The purpose of the YAVIN WG is twofold:*
>
> *1)      **Provide a venue for inventory YANG models from across IETF
> Areas under a common umbrella to facilitate distribution of the work,
> clarify the scope of each model, and minimize overlap between them.*
>
> *2)      **Define a core network inventory model deriving common
> building-blocks for inventory modeling that can be augmented, imported, or
> reused by other*
>
> *IETF models. *
>
> *The WG will also identify a set of requirements and some guidelines to
> ensure consistency across models related to inventory.*
>
>
>
>
> §3). s/IETF Areas and Working Groups/IETF Areas/ ?
>
> [DC] OK
>
> 5th §: are virtual networks/machines also in scope (including their
> physical
> 'anchors', i.e., hosts), it actually appears much later in the charter,
> i.e.,
> could be mentioned earlier ?
>
> [DC] i'm open to suggestions. The intro speaks about inventory and then in
> the bullets we describe what is covered.
>
> *[Italo Busi] Maybe we could expand the first paragraph to indicate that
> collecting information also for virtual equipment is an emergent
> requirement to support virtualization*
>
> *[[DC2]] Virtual equipments are already included (see B). Here we’re
> speaking of virtual machines and virtual networks, that’s a bit different,
> it’s no longer transport. *
>
>
>
> Like Lars, I would prefer something like "that
> include layers 0-3 functions". Are licences part of the inventory ? Should
> this
> WG be able to update existing models ?
>
> [DC] "network elements that operate at layers 0-3" means optical devices,
> switches, routers etc. Does "layer 0-3 functions" have the same meaning?
>
> In the milestones, s/model/YANG data model/
>
> [DC] ok
>
> Nothing is really said about the "The Working Group may also act as a
> coordinator of the inventory work" which assumes a controlling role, or
> should
> this sentence be replaced by "This WG will coordinate with other WG about
> the inventory work" ?
>
> [DC] makes sense
>
> Note: allow me to diverge a little: were there any BoF prior this
> chartering
> effort ? Was it the outcome of a dispatch WG ?
>
> [DC] Rob, some help here?
>
> Hope that the above points help
>
> Regards,
>
> -éric
>
> PS: to do some bike shedding, "Yet Another Inventory Model" (YAIM) to
> follow
> the YANG paradigm or "Yet Another Model for Inventory" (YAMI) or "YANG
> Used to
> Model Inventory" (YUMI)
>
>
>
> *2. **Roman Danyliw*
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Recommend against using the name “NIMBY”.  See
> https://en.wikipedia.org/wiki/NIMBY.
>
> > For auditing purposes,
> > inventories may also be used to collect information from the network,
> > as well as for cataloging and exposing that information.
>
> This text seems backwards to me.  Doesn’t one “collect information from the
> network” to produce an “inventory” for “audit purposes”.
>
> [DC] indeed. What about: "Inventories are use to collect, catalog and
> expose information from the network as well as for auditing purposes."
>
> >  F. Security and privacy issues: The information in a network
> >     inventory is highly sensitive as it exposes critical information
> >     about the internal topology and characterization of the
> >     components that are used to build that topology.  Mechanisms to
> >     ensure topology hiding and prevent unauthorized access are
> >     expected to be in place. However, the Working Group may consider
> >     whether additional security mechanisms are needed to protect this
> >     information from unauthorized access and manipulation.
>
> Can this scope of work be clarified as I’m have trouble envisioning how the
> work products manifesting in the context of the YANG model – is this about
> new protocols work or security mechanisms to secure the YANG models?  or
> specification of operational practices to protect the YANG models?  Is it
> work
> minimization of the data stored in the YANG model?
>
> [DC] This means to identify any new security gap, if any. The working
> group is not planning to define any protocol extension.
>
> > Jun 2024      Request publication of the above model.
> I’m having trouble finding the “model” referenced here in the charter text.
>
> > Sep 2023      Adopt an Internet-Draft describing a core network inventory
> model that can be used as a foundation by other models to establish
> technology-specific inventory models.
>
> I also don’t know where this milestone comes from based on the charter
> text.
> There is a long list of possible areas A – F, but the introduction to this
> list
> is a caution that most of these won’t be published.  Nothing there
> suggested a
> unification/baseline model approach to me.  I would recommend the text
> making crisp statement on what will be done and what might be be explored
> before this ships.
>
> [DC] what about the following change:
>
>
>
> OLD:
>
>  An objective of this effort is to derive common building-blocks for
>
> inventory modeling that can be augmented, imported, or reused by other
>
> IETF models. The WG will also identify a set of requirements and some
>
> guidelines to ensure consistency across models related to inventory.
>
>
>
> NEW
>
>  An objective of this effort is to define a core network inventory model deriving common building-blocks for
>
> inventory modeling that can be augmented, imported, or reused by other
>
> IETF models. The WG will also identify a set of requirements and some
>
> guidelines to ensure consistency across models related to inventory.
>
>
>
> *3. **John Scudder*
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Although there's a milestone about a "core network inventory model", there is
> nothing in the charter text itself that says that. The closest I found was "An
> objective of this effort is to derive common building-blocks for inventory
> modeling that can be augmented, imported, or reused by other IETF models",
> which (to my eyes at least) is relatively vague and my first impulse wouldn't
> be "oh that means they're doing a core inventory model".
>
> The lack of a clear statement about producing a model makes it hard to know
> what to make of "Mapping the inventory models that will be produced by the WG into existing IETF models (e.g., ietf-network-topology) is also in scope." Even taking as read that a "core inventory model" is a first deliverable, I'm not
> sure what this sentence means, although that might just be my ignorance rather than a lack of precision in the language.
>
> [DC] this should be addressed by the text modification suggested in a reply to Roman's comment
>
>
>
> *4. Paul Wouters*
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> This work seems closely related to the SBOM work done in OPSAWG. What was the
> reason behind not using that WG and starting a new one ?
>
> [DC] already replied as follows:
>
> the SBOM work only focuses on retrieving information on which systems have vulnerabilities.
>
> The scope of this work is to collect inventory information (both HW and SW) from all the devices in the network: optical devices, routers, switches, etc.
>
>
>
> *5. Erik Kline*
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> # Internet AD comments for charter-ietf-nimby-00-01
> CC @ekline
>
> * I support finding an alternate working group name. Even plain YANI (YANG
>   Network Inventory) might be okay.
>
> ## Comments
>
> ### P5
>
> * What's an example of a "layer 0" element?
>
> [DC] Already replied as follows:
>
> an example of a Layer 0 element is an optical device. A ROADM for example (Reconfigurable Add Drop Multiplexer).
>
>
>
>
>
>