Re: [Inventory-yang] IESG comments to charter

Adrian Farrel <adrian@olddog.co.uk> Mon, 12 June 2023 14:31 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: inventory-yang@ietfa.amsl.com
Delivered-To: inventory-yang@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E44AC15108F for <inventory-yang@ietfa.amsl.com>; Mon, 12 Jun 2023 07:31:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.096
X-Spam-Level:
X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=olddog.co.uk
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3MRgXTqaNBy5 for <inventory-yang@ietfa.amsl.com>; Mon, 12 Jun 2023 07:31:45 -0700 (PDT)
Received: from mta5.iomartmail.com (mta5.iomartmail.com [62.128.193.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1EB7C1524DE for <Inventory-yang@ietf.org>; Mon, 12 Jun 2023 07:31:43 -0700 (PDT)
Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta5.iomartmail.com (8.14.7/8.14.7) with ESMTP id 35CEVMvT001621; Mon, 12 Jun 2023 15:31:22 +0100
Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 54F204604B; Mon, 12 Jun 2023 15:31:22 +0100 (BST)
Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 3494646048; Mon, 12 Jun 2023 15:31:22 +0100 (BST)
Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs2.iomartmail.com (Postfix) with ESMTPS; Mon, 12 Jun 2023 15:31:22 +0100 (BST)
Received: from LAPTOPK7AS653V (82-69-109-75.dsl.in-addr.zen.co.uk [82.69.109.75]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.7/8.14.7) with ESMTP id 35CEVLMD019788 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 12 Jun 2023 15:31:21 +0100
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: "'Rob Wilton (rwilton)'" <rwilton@cisco.com>, 'Daniele Ceccarelli' <daniele.ietf@gmail.com>, "'maqiufang (A)'" <maqiufang1@huawei.com>, Inventory-yang@ietf.org
Cc: 'Italo Busi' <Italo.Busi=40huawei.com@dmarc.ietf.org>
References: <CAB01kMi7DLy5QKcZnVMU_PKK9m5yecSaRMXtBHV-YxyPa0up8g@mail.gmail.com> <eda0e778c89348b2a7743e5bbd6ad260@huawei.com> <124a01d98417$3634e250$a29ea6f0$@gmail.com> <CAB01kMhck=XuB8UUBMoNh3QdM_ucHuovxF+fb8tLeo17CVR34g@mail.gmail.com> <BY5PR11MB41965AB981541E9DCE38BCC1B550A@BY5PR11MB4196.namprd11.prod.outlook.com>
In-Reply-To: <BY5PR11MB41965AB981541E9DCE38BCC1B550A@BY5PR11MB4196.namprd11.prod.outlook.com>
Date: Mon, 12 Jun 2023 15:31:21 +0100
Organization: Old Dog Consulting
Message-ID: <03b201d99d3a$8f2d6080$ad882180$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_03B3_01D99D42.F0F4AEB0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQIZ2Dp5vxrzbY3BCjo0gutYFzeX9wLS/aWoASeMiXMChxXeSAHaxhbcrsPcApA=
Content-Language: en-gb
X-Originating-IP: 82.69.109.75
X-Thinkmail-Auth: adrian@olddog.co.uk
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=olddog.co.uk; h=reply-to :from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type; s=20221128; bh=qEwzDu+e3pVZC+iGhEr1h jC23GTDv0jJdp6KunMqThs=; b=B9viFS48CW/Xq4Nf97oNUGWbrkE+ZjrfuEvD4 iN6HKXuSyVfvE9NQ0jZ4WAeeDm82Z6/wnHWnF79/FM2eDrp5nggRNh84o9OT/pQd 1GbG+8XPhnGU/S9t0qWupU3+LRWetrcgIG5HNLY4dpDk1D20jEqHj51//7CWjL9d ylx8Ul8E9IiBJTfPsq0aNtbSNk/Dl4EVYTbDbBzsxRlP3fEWCY+sNRYk6+eLAH5x WEgNJucaFOvm1xhxIhifEPLKqaNU1fjeIONW/XnRxXdRVfv+qK33YQP9WbKY0o74 F2uPg0dWxl+3Xsr4W7vvqg1dFoW5GMsEqx9GZdyflZyrWRS2g==
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.1.0.2090-9.0.0.1002-27688.000
X-TM-AS-Result: No--39.815-10.0-31-10
X-imss-scan-details: No--39.815-10.0-31-10
X-TMASE-Version: IMSVA-9.1.0.2090-9.0.1002-27688.000
X-TMASE-Result: 10--39.814600-10.000000
X-TMASE-MatchedRID: vJMTL+QvMTfuYusHgJkgymjJpufOqOIAtwi3bXRtaAiqLLQbtBXZpVcF RoO05Tn40onSmB8IRuh5gF4gpi7gea5bb5QEYSkd0NnUUVMlTKa+y4Y487IcAfeFHwaPzeXJeGf PtSesbA40Ng8GlLBbmjQbcGPY644u93bduyx/IZyEroxSTl8M/W7B7UNCfebUkYdnzk6dz7bYMP FYAn4//ymqOJk2EKAC5cgZmvRfcnx0+657dxGJGDWRH7TlULWGtfVN4INWRcDO/T5SZgJlw/F6N zSl6coXMjQqGTIHxkugDHdG+k69uCAWHOR37+ATyeUl7aCTy8imczuZVoOCe2Ms5GjXLqvGF9cv 3Vcv4E8hbyKPNthsmD92VHnUMbt1fOaYwP8dcX72kudi1D33EmSYicW3M8OfQkZhxocl7a1+J/o +y9+xUoucwSE+eOjHn/RflakI9hxC3LyCIIlbjQGo1vhC/pWjUCgEErrUGFzvp3i0IFje5YSS38 vwe0AnJuVoTiK6UvuPIr9Wpu0YXOOwTKTYxz4vAPiR4btCEeZs+HFD7B2Y6a0IALyST8Y27Q1nl GLuKa1K8U9pImEyye8xITiLrtkMNmg1ckxsf6cbdKgBZxTjZZBz1ZAU7t9TQY9wbi+2lgEz3TJW I0hsNQN4bL4pFIvKE69ZAbbX99RSvcZUjrkaFr4+VVm+gjZlMq/hBI8/YbFPMCapqoJ3gL+yI5t wQVzRNXz0Ehmz/JIQ3i3MrqHvd6z+FzWjUOLzYEpG2D2kcRovvOPLgvyZJofFM47qD9Fevtojut dcN28z/ow1H26c3Zr/5QhTM8mC3BgOPjbqzrnqtOCMCMzOYUkpgPVaEY4Jo8WMkQWv6iXoC+VlR HhOyHWHf5aIr8kX0CzDI0K7cAxXhqN9H2OPZ2F5X5yuwTohDBbGvtcMofyUTGVAhB5EbQ==
X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/inventory-yang/7Chh2bJH1SIImyyqBz-o8AIM61s>
Subject: Re: [Inventory-yang] IESG comments to charter
X-BeenThere: inventory-yang@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Inventory Management using YANG <inventory-yang.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/inventory-yang>, <mailto:inventory-yang-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/inventory-yang/>
List-Post: <mailto:inventory-yang@ietf.org>
List-Help: <mailto:inventory-yang-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/inventory-yang>, <mailto:inventory-yang-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Jun 2023 14:31:49 -0000

Thanks Rob,

 

I see it’s on the agenda for the 22nd, so I haven’t applied any edits, but…

 

1.	Please check activity ‘F’ represents what you were intending?  I may change the “should consider” to “must consider” since the security considerations of precise location data was flagged by both the IAB review and a SEC AD.

 

I think F is good. “must” is fine with me. 

I would strike “indirectly” from the identification of user locations.

I worry slightly that more is less. As we move to cover all bases in our description of security, so the text grows. As it grows it looks more and more that anything left out is deliberately omitted.

But, since there is pressure to include “more”, I doubt that we can cut back, so I think we also need to add “commercially sensitive”…

 

     that could be used to identify user locations and could reveal commercially sensitive information.

 

2.	Should IEEE be listed under activity ‘A’?  Do we need/expect any coordination with these other SDOs?  Are we expecting them to leverage or build on these inventory models at all?

 

It’s the same “more is less” problem. As the list of SDOs grows, so any omission looks like exclusion. But sure, include IEEE. What about 3GPP?

 

Thanks,

Adrian

 

From: Rob Wilton (rwilton) <rwilton@cisco.com> 
Sent: 09 June 2023 00:44
To: Daniele Ceccarelli <daniele.ietf@gmail.com>; maqiufang (A) <maqiufang1@huawei.com>; Inventory-yang@ietf.org; adrian@olddog.co.uk
Cc: Italo Busi <Italo.Busi=40huawei.com@dmarc.ietf.org>
Subject: RE: [Inventory-yang] IESG comments to charter

 

I’ve had a slightly different go, also taking into account some comments from the IAB.

 

My proposed updated charter for the IVY WG is now here: Network Inventory YANG (ietf.org) <https://datatracker.ietf.org/doc/charter-ietf-ivy/> 

 

If you can give it a quick read to confirm that you are still okay with it that would be great, ideally, I would like to get it sent out for external review tomorrow if possible.

 

A couple of quick questions/comments:

 

1.	Please check activity ‘F’ represents what you were intending?  I may change the “should consider” to “must consider” since the security considerations of precise location data was flagged by both the IAB review and a SEC AD.
2.	Should IEEE be listed under activity ‘A’?  Do we need/expect any coordination with these other SDOs?  Are we expecting them to leverage or build on these inventory models at all?

 

Thanks,

Rob

 

 

From: Inventory-yang <inventory-yang-bounces@ietf.org <mailto:inventory-yang-bounces@ietf.org> > On Behalf Of Daniele Ceccarelli
Sent: 23 May 2023 15:47
To: Italo Busi <Italo.Busi=40huawei.com@dmarc.ietf.org <mailto:Italo.Busi=40huawei.com@dmarc.ietf.org> >; Inventory-yang@ietf.org <mailto:Inventory-yang@ietf.org> 
Subject: Re: [Inventory-yang] IESG comments to charter

 

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 <daniele.ietf@gmail.com <mailto:daniele.ietf@gmail.com> > wrote:

Hi Italo,

 

Please see further replies in line.

 

Cheers

Daniele  

 

From: Inventory-yang <inventory-yang-bounces@ietf.org <mailto:inventory-yang-bounces@ietf.org> > On Behalf Of Italo Busi
Sent: Thursday, May 11, 2023 3:28 PM
To: Daniele Ceccarelli <daniele.ietf@gmail.com <mailto:daniele.ietf@gmail.com> >; Inventory-yang@ietf.org <mailto:Inventory-yang@ietf.org> 
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 <inventory-yang-bounces@ietf.org <mailto:inventory-yang-bounces@ietf.org> > On Behalf Of Daniele Ceccarelli
Sent: giovedì 11 maggio 2023 13:45
To: inventory-yang@ietf.org <mailto:inventory-yang@ietf.org> 
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).