Re: [Inventory-yang] IESG comments to charter

[Adrian Farrel <[e-mail]>]

Yeah, I don’t disagree that all aspects of security concerns need to in the frame.

 

The case you mention seems to misunderstand server-based networking. Or maybe it understands it all too well :-)

 

“Obviously” an automated car asking for interpretation of local data is likely to want the additional context of its location to be taken into account. Any processing that is outside the vehicle is going to expose that information. CATS doesn’t do anything to increase that risk except in ways that attack the knowledge of availability of computing locations and capabilities. 

 

This isn’t a whole lot different from any service based on geolocation information.

 

Rather than targeting specific use cases, we should identify the information that needs to be kept secure/private, and the vectors for attack. I think the current text (plus or minus my suggested addition) does this.

 

A

 

From: Inventory-yang <[e-mail]> On Behalf Of Rob Wilton (rwilton)
Sent: 12 June 2023 16:03
To: [e-mail]; 'Daniele Ceccarelli' <[e-mail]>; 'maqiufang (A)' <[e-mail]>; [e-mail]
Cc: 'Italo Busi' <Italo.Busi=[e-mail]>
Subject: Re: [Inventory-yang] IESG comments to charter

 

I agree with the less is more concern, but I did make a couple of further edits to F before posting for external review based on feedback from an IAB review.  Sorry for not waiting ,but I went ahead because I wanted to get this posted so that the WG is hopefully formed before IETF 117.

 

The primary concern raised seems to be that this schema could be indirectly used to track users, I presume if personally assigned devices were included in the network inventory, and if those devices were giving up accurate geolocation data.  This does seem like something that the solution might want to be aware of, and perhaps cover in the operational considerations, but at the same time, I’m not sure that I completely understand or completely agree with the concern, but this does seem like an area that the WG may need to be careful about.

 

Regards,

Rob

 

 

From: Adrian Farrel <[e-mail] <mailto:[e-mail]> > 
Sent: 12 June 2023 15:31
To: Rob Wilton (rwilton) <[e-mail] <mailto:[e-mail]> >; 'Daniele Ceccarelli' <[e-mail] <mailto:[e-mail]> >; 'maqiufang (A)' <[e-mail] <mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]> 
Cc: 'Italo Busi' <Italo.Busi=[e-mail] <mailto:Italo.Busi=[e-mail]> >
Subject: RE: [Inventory-yang] IESG comments to charter

 

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) <[e-mail] <mailto:[e-mail]> > 
Sent: 09 June 2023 00:44
To: Daniele Ceccarelli <[e-mail] <mailto:[e-mail]> >; maqiufang (A) <[e-mail] <mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]> ; [e-mail] <mailto:[e-mail]> 
Cc: Italo Busi <Italo.Busi=[e-mail] <mailto:Italo.Busi=[e-mail]> >
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 <[e-mail] <mailto:[e-mail]> > On Behalf Of Daniele Ceccarelli
Sent: 23 May 2023 15:47
To: Italo Busi <Italo.Busi=[e-mail] <mailto:Italo.Busi=[e-mail]> >; [e-mail] <mailto:[e-mail]> 
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 <[e-mail]> wrote:

Hi Italo,

 

Please see further replies in line.

 

Cheers

Daniele  

 

From: Inventory-yang <[e-mail] <mailto:[e-mail]> > On Behalf Of Italo Busi
Sent: Thursday, May 11, 2023 3:28 PM
To: Daniele Ceccarelli <[e-mail] <mailto:[e-mail]> >; [e-mail] <mailto:[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] <mailto:[e-mail]> > On Behalf Of Daniele Ceccarelli
Sent: giovedì 11 maggio 2023 13:45
To: [e-mail] <mailto:[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).