Session Date/Time: 21 Jul 2026 07:00
[00:00:07] Qiufang Ma: So
[00:00:11] Qiufang Ma: I think it's time. So hello, everyone. I think it's time. Let's get started. Hello. Welcome to the IETF one twenty six IVY working group meeting. Good morning, good afternoon, good evening, everybody. Thanks for joining us. My name is and my co chair, Daniele, sitting beside me. As a usual reminder, please be aware that this session is being recorded. So for the note 12, I'm not sure if we have new participants in this room, but please be aware that by participating in the IETF, you agree to follow IETF processes and policies. So this generally relate to the your code of conduct and the RPR policies. So ITF participants are expected to behave in a professional manner and extend our respect and courtesy to our colleagues. And if you are aware of any IP any ATF contributions is covered by patents or patent applications, you have the responsibility to disclose that fact or not participate in the discussion at all. So if you would like more details and if you have any concerns and questions, feel free to look at a couple of RFCs highlighted in this slide, or feel free to reach out to chairs or ADs for otherwise. K? So the meeting tips. As you know, we use the Meetecho for joining the meeting. So for the in person participants, make sure to sign into the session via the data tracker or the QR code in this session so that we can capture your attendance. And you could use the either the Meetecho Lite or the full Meetecho version to join the mic, make a comment, and participate in the show of hands. But please ensure to keep your audio and the video off if you are the on-site version if you are not using the on-site version. Sorry. And for remote participants, please also make sure your audio and the video off unless you are actively speaking. We recommend a use of the headset. Please be aware of that. And the note taking, please help with our notes. We might need one or two volunteers to help with the notes. Feel free to join with the note taking. Our session today will be one hour and a half, and the materials are available. So feel free to look at the slides. So as a reminder that we work remotely for the most of the times, I think, only hold mean the three times minutes each year. So most of the time, we communicate through the mailing list. Any working group consensus is determined on the mailing list. So please make good use of the mailing list to resolve your open issues, to review change of the working group documents, introducing your new drafts, or other topics that you would like to see discussed in I in IVY working group. We could also run into the interim meetings as needed, but those are the virtual meetings. So if you have any topics that you would like to be covered in the interim meetings, please make request to chairs so that we could arrange as needed. We also have the informal working group Webex meeting resources. This is usually used for the design team discussion. Could be, like, the weekly, the biweekly, or monthly depending on the preference. So if if you if you would like some Webex meeting resources, you could make a request to chairs as well. But be aware that these meeting resources will be completely public and be announced on the mailing list, so everyone is available to join that discussion. So here is our agenda today. So I think kind of a little packed today, but it should be fine. We have the ten minutes for the buffer time. I think, probably, we will give the presentation of the inventory software and the inventory location, and then Diego will present the entitlement update. And then will present the passive network inventory. And, also, Nigel will give the report on the implementation of network inventory. Thanks for leading this effort, Nigel. And we also have a new topic today. So the draft doesn't indicate ivy as the working group home, but it's a new topic and kind of, like, high relevant to the the inventory with regarding some security perspective, the cryptographic asset discovery and inventory. So we will see how that would be discussed here today. So any comments and questions on the agenda? Okay. Then I will pass control to my co chair.
[00:05:33] Danielee Ceccarelli: Thank you. So a brief update for you on the on the working group status. This is the list of our actually actual working group drafts. Two of them are almost crossing the finish line. The core model was sent back to the others for the very final edits after the usual reviews. Also, my shared some comments. I talked to the to the authors that they are planning to address them very soon. So I expect that in in few weeks, the the the draft will be ready to be sent back to the ISG. Network inventory topology, the draft passed to the working group last call. Olga volunteered to be the shepherd for this for the document. Thanks a lot, Olga, for for doing that. She already prepared the the write up. But given that the authors are planning to address the the latest comments, we we ask there to hold it for for for the next release and publish publish the write up once we have the final version. So, also, this draft is very closer to the finish line. Then we have the network inventory location and network inventory software, which will be which are on the agenda, will be presented by Bo in in a minute. And the last one, which is the entitlement that is actually, all of the drafts are in the agenda because also the the the entitlement and the the passive network inventory will be presented later on. Liaisons. Surprisingly, for the first time, we don't have any incoming nor outgoing liaison. Just for your information, through c camp, we managed to create a liaison ship liaison relationship with the OIF. So if you think that this could be relevant for any work in IVY, let us know. Italo has been appointed the liaison manager for the relationship between ITF and and OIF. So in case you need to access the OIF documents early in, in the process or have any any relationship, with them, let us know. And I think that's it. We can switch to the first presentation and have a little bit more time for discussion.
[00:08:34] Bo Wu: Good morning, everyone. My name is Bo, and I will present the latest update on this network inventory software extension model. Since last IETF meeting, we actually posted two revision. And zero three mainly clean up some references because, like, six nine nine one and some some young example has been fixed. So, in this update, I will mainly present it version four states updates. And some quick recap on this model. The model is intended to complements the base inventory with some nonphysical network elements such as virtual devices, network controllers, and some software components such as operating system, software modules, that kind of components because base inventory only covers hardware attributes, hardware components of network elements. And following the base inventories design consideration, this module also provides the read only reporting of software status and associated timestamps. So this the real reason revision four, we mainly to resolve Adrian's review comments. Adrian give quite thorough review on this whole document. So these four major changes used to resolve the agents that those comments. The first major update is about the new section operational consideration. We didn't add this. So so we think it is useful to give some consideration on the why we designed the read only approach and also how to use those attributes. So I will talk about in the following slides. And then the second item is regarding the refining the definite description for the software in store and activated because in store is quite straightforward, but activated is not that clear. And then we removed the that 2119 boy plate because we don't use those mandatory requirements. And the last one is about we make the alignment with ninety nine zero seven template. And I also attached the open issue list link to the slides so that you can see that right now we don't have some remaining open issue. So this is shows a whole overview of this software extension structure. Left, you can see why we are doing this extension to the base inventory. We augmented more of software attributes software specific attributes. You can see on the right where we mainly have the two part of update extensions. The first part is about network elements extension, which relevant with software revision and patch. And the other the the down part relates to component specific software revision and patch. So this model is quite mature and stable since the working group adoption. So the only change that we made alignment with the base inventories software updates. And this is a operational consideration I said earlier. So this is a totally a new section that we missed out. And in this section, we mainly try to highlight this model user read only reporting to consistent with the base inventory. So, like, the software life cycle management, how to install and patch, those management is out of scope of this software extension definition. And this is young description. I mentioned earlier that we clean up the software status. Before, it's quite simple. And so in these updates, we make it more clear, especially this activated that will taking effect on the network elements or component. So so given we have made those whole draft clean up and we already addressed all the open issues, so we think this is draft is stable, and we like to request working group last call. So if chairs like to can start some young doctor reviews, we'd like to have that. Yes.
[00:14:41] Mahesh Jethanandani: Mahesh.
[00:14:42] Danielee Ceccarelli: Mhmm.
[00:14:42] Mahesh Jethanandani: So I think you just said what I was gonna say, which is if you're gonna request for working group last call, this would be a good time to start some early reviews on the document. I didn't see any being requested. So
[00:14:57] Qiufang Ma: Sure. We will request YANG Doctors early review after this meeting. Yeah?
[00:15:01] Danielee Ceccarelli: Sure. I'll do it now. Okay.
[00:15:07] Qiufang Ma: Go ahead.
[00:15:18] Fatai Liang: Thank you both for pushing this forward. I really supported working group last call because as you know, like, from the liaison from the program forum, this document is depend is being used throughout the program foreign mock data models. And as of now, because of the status of the of the document, this has been it should it has decided to be removed from the first publication, but then we gonna publish an amendment which will include this document. Hopefully, it will be it will be scheduled to push for publication by the end of the year, which should be which should align with the working group last course. So I can at least
[00:16:10] Danielee Ceccarelli: Can you remember as of which were the the the documents that were included in that list? If I could the core model was one of the this one?
[00:16:18] Fatai Liang: The software and the location.
[00:16:19] Danielee Ceccarelli: And the location. Yeah. Okay.
[00:16:20] Fatai Liang: So the core model, it's assuming that it's gonna be passing the working group for last call going through publication. That should not be issued. So it's waiting for the core model to be published. But the other software allocation, definitely, we welcome it to to to go forward working with last call. And the other thing is, they have reviewed, the document. It's stable. It's it's it addressed all the dependencies of from broadband and format. I'm gonna have them have a second review on the update, but that should be a big issue as far as I can see. Thank you. Thanks,
[00:17:12] Danielee Ceccarelli: And the and the general comment for the authors of the other drafts, whether they are working group or individual contributions, I've not checked all of them, honestly. But following the template with the operational considerations and updating the security session according to RFC ninety nine zero zero seven. That's something that would would significantly improve the quality of the document and make it easier to to move forward and have less less iterations when when the drafts move forward. So please take this in mind.
[00:17:52] Bo Wu: Yes.
[00:17:52] Danielee Ceccarelli: Keep this in mind.
[00:17:53] Qiufang Ma: Yes. I will.
[00:17:55] Bo Wu: And me again. So I'm I will also give updates present updates on the network inventory location model also. And since last IETF meeting, we made this only revision revision six. In this revision, we think we have addressed all the major issues pro proposed by Brad. Brad has major two issues, but the third one is also related with the first two. So these two major changes are all relevant. The first issue is about rack security classification attribute. Brad stated that our previous definition, we don't think it seems that our assumption is that the rack class is mainly for the data center racks. He suggested we add a rack classification type to have some security setting or access control, that kind of assurance support. So in this revision, we added identity for this security typed classificate type. We have defined it for identity to address this. So I will talk in the following slides. And the second way that last last item, Shenzhen meeting, the working group gave us the suggestions on that. We will choose this read only design principles to to be consistent with base inventory that this model that this approach is, like, I showed on the right hand side that there could be, like, two consider design approach. One is OS centric and the other is a controller centric. Working group considers mostly for IP and optical network. The controller centric is more typical one. So working group suggested us we go with the network controller centric ones. So controller can have this information, location information either from manually entered or some tooling to help to discovery all those, like, location information. So in this revision, we don't really change any operational consideration, but I I like to emphasize that because, like, for the security consideration, we actually remove the read write risk warnings. So but and also other we added some, like, rack security levels consideration also into the security one. And I also attached the open issues here. Beyond all these major issues we have addressed, there are two one pending ones. One is that a young grouping related. We're thinking this is at this version, we go with the read only one, but in the future version, we may have the, like, planning extensions. So we will make the young grouping will be reusable for both read only and read write. And the other open issue is that we think the whole draft haven't have this consistency on the read only because previous version, we think we can support both read only and read write modes. But so these are two remaining issue we we are going to address, and we will, like, post a new version after this ITF meeting. So this is a major summary of this issues we are resolved. And this slide shows the whole young RAC class updates. You can see that rack in the rack list, we add a new rack class attributes. And on the right, you can see that based on Brad's suggestion, he also noted there is no common rack security classification. But for, like, Australia, for the operational practice, there could be have these four kinds of rack security definition. One is the standard one. There's no secure secure like, physical case or some access control. And so we define the three categories of secure definition, like baseline, medium, and high to fit this Brad's practice. So this is and we I like to because we posted these updates just before IETF meeting, we like to have a press to see whether this have addressed his concern. And then this is a young structure overview of you can see the two we we don't have much change since last since last revision. We only add a new rack class attributes. You can see on the left, we have a quite general location list, which can support some hierarchical location, site room, etcetera. And we have contained Sashi under this location so you can curate different location with, like, Sashi relationship. And the rack also have this container chassis that you can curate what kind of chassis under these racks. So with this definition, we think we cover both non rack and rack definition scenarios. So I think currently, we don't have major issue left. We only have that two consistency clean up issue. We will post that change updates ITF meeting. So we like to ask also working request on this.
[00:25:10] Danielee Ceccarelli: We we will start start with the the reviews. Yes. The YANG Doctors review, etcetera.
[00:25:16] Bo Wu: Okay. Thanks.
[00:25:17] Qiufang Ma: So I'm I joined the queue. Can you move to the slide where you have the rank class definition? I have a minor comment.
[00:25:24] Bo Wu: This one?
[00:25:25] Qiufang Ma: Yeah. Right. So if the targeting is simply for the security perspective classification. I'm wondering whether a specific parameter name like the security level or security class would make small sense instead of the a very red rank class definition. I'm not sure if you want to tag it in more more broad perspective of the classification.
[00:25:52] Bo Wu: Yeah. I think from my first instinct, I think it's it's we we can accept this because right now, we want to define the security one and non security one cabinets, but the major definitions is to differentiate this security consideration. So I think it's we we can make it more clear. Yeah.
[00:26:21] Qiufang Ma: Thank you. Yeah.
[00:26:24] Danielee Ceccarelli: I have a comment which is more loud thinking rather rather than a comment. So I understand that that the rack security level is something that is defined by the site in the sense that either all everything inside that site is highly secured or pretty secured. I was wondering if this piece of information might mean be needed per device in case location is not supported. So if it if this is something that might be useful independently from from the site model. So I'm thinking of implementations that do not support the the location model, but that would would like to specify this level of security for given devices, for example, in the core model. Would this make sense, or we can live with this? Again, it's it's loud thinking. It's something that came to my mind right now, so I don't know if my comment makes sense or not. Just wanted to raise it.
[00:27:38] Bo Wu: My response to your question is that I think base inventory right now only covers network elements, and they don't have direct references with this rack. And rack as it's it can be a independent rack list. So and you can see that we have this oh, I cannot show that. It's contained. The chassis is under this rack. So you can see whether this chassis needs some security.
[00:28:11] Danielee Ceccarelli: For sure. For sure. Yes. That but so my my comment was a little bit broader. So in the core model, we speak about the devices. Yes. So should we add the security level per device for those implementations so that they do not support the location model?
[00:28:28] Bo Wu: Okay.
[00:28:28] Danielee Ceccarelli: I don't know if it makes sense or not. Just wanted that to trigger discussion and thoughts from the working group.
[00:28:35] Bo Wu: I I I like like, if if
[00:28:38] Qiufang Ma: know mhmm. Yeah. Hi. I was just listening to the conversation. One of the thoughts is that since a rack is not a powered device, would it be covered by the passive inventory one? And then we kind of point to that. Just a thought. Okay. I mean, you're you're doing loud thinking. I'm doing even more loud thinking. Okay. Let's see.
[00:29:01] Danielee Ceccarelli: You're increasing entropy.
[00:29:03] Fatai Liang: I'm just increasing that. Yes.
[00:29:06] Danielee Ceccarelli: Maybe it's a discussion we can have
[00:29:08] Bo Wu: on the mailing list. Can discuss on the mailing list on this. Yeah. I I will add this. We'll track this open issue on my on the GitHub. Yeah.
[00:29:18] Danielee Ceccarelli: So is in the queue. You mentioned the passive inventory, and you woke him up. Just
[00:29:31] Fatai Liang: a quick question. For the rec class definition of those identities, is there a standard for this? Or because No.
[00:29:38] Bo Wu: No? Okay. There's no common standards, but Brad gave some link to the Australia rack security definition. They have a b c three levels of secure. Like, if whether you have a physical k or some very high secured
[00:29:56] Fatai Liang: Yeah. Big
[00:29:57] Bo Wu: scenario. So
[00:29:58] Fatai Liang: because they seem like without referencing those standards, it's it's it's hard to understand the type of rec classes.
[00:30:06] Bo Wu: So maybe we can add more clarification under it. We can give, like, Brad's practice as some example in our modeling description.
[00:30:17] Qiufang Ma: Maybe also give a a reference statement.
[00:30:20] Bo Wu: Reference, that is only Australia country specific security definitions. So not
[00:30:27] Danielee Ceccarelli: We we we can adopt it. I mean, who prevents us from from from adopting the Australian way of of encoding? It's just mean, the the the comment is very valid. I have this level of security. Is it considered medium or high? I don't know. So we we need either either to describe it in the draft. What what does it mean medium or high or reference something? Mean, if it's defined by an Australian authority,
[00:30:52] Qiufang Ma: that's fine.
[00:30:53] Bo Wu: Then I can add to the main text on giving some informative reference that people can take a look on what kind of security will be Just used in their implementations. Okay. So I don't see any Thank you.
[00:31:12] Danielee Ceccarelli: Thank you. Thank you. Next one is Diego. We did the wrong T shirt today. No. No. Mean
[00:31:28] Diego Lopez: Have have you heard about cleanliness?
[00:31:34] Danielee Ceccarelli: I thought you had the tens of them.
[00:31:35] Diego Lopez: Under weather. No. No. I mean, the the I I was wearing my my a T shirt that is not there from the team the day of the match because it's a mother of superstition, but just the day was done.
[00:31:47] Danielee Ceccarelli: Okay.
[00:31:47] Diego Lopez: But today today, I have to change.
[00:31:49] Danielee Ceccarelli: In in any case that you need a new one with the two stars. Yeah.
[00:31:52] Diego Lopez: Yeah. Exactly. No. No. Exactly. No. No. I'm gonna buy the the red and the white. I I like those. So yes.
[00:31:57] Danielee Ceccarelli: So that you can wear the full
[00:31:58] Diego Lopez: Exactly. No. Two stars to to to jerseys. Then we will go for a yeah. Yeah. I have them here. Yes.
[00:32:05] Danielee Ceccarelli: Okay. So
[00:32:08] Diego Lopez: quickly because can you oh, it's me. We can move on. Yes. So, basically, is that we are we are polishing the the draft because we are we believe we are close to the final stages of it. And this is the last meeting where we have been making some some updates to the basically, the models and examples. And, well, we have changed a few types. Yesterday, in green, somebody was talking about negative consumption. We have made something like making unsigned some some cases and of trying to follow the naming convention. Something that is you will see we will see that is is quite straightforward. And the main focus or the or the most important part are regarding avoiding circular references and and security. The models update the model updates are as simple as these. There are two when talking about maximum and current values, we have moved to, one restrictions because making a restriction that is negative starts thinking about the, which is the the name in English, the, complex numbers and the, I, you know, the the the square root of, minus one and things like that. So we we we made them more straightforward and and unsigned. And there was a where we have changed a number of underscores into normal iPhones just to follow the the common practice in January. It's not that the other is forbidden, only that we were told that it was a little bit weird. So now they are we are normal. And the the part that probably has changed a little bit more is there is specific warnings about avoiding complex circular references between entitlements that are connected to one woman another that this is because the direct circular references can be avoided by can be detected. But, well, the language and this is probably for Jam two version two. The language is doesn't allow the formal mechanisms, doesn't allow for the the detecting more sophisticated circular references with several intermediaries. So there is a warning about be careful and don't don't create these circular references, etcetera. And that, well, a management system could add some some routines for that. And then there there is a the the security considerations going a little bit more depth regarding the sensitivity of data. And, well, basically, it's about how to avoid disclosing data because when it comes to this, it's a sensitive data is what you have paid for, is what you have is a commercial relationships and can be can be a little bit, well, delicate. And just to finish, we consider the document is essentially completed. For some iterations, we believe that the basic concepts, the models themselves and examples should be clear enough. We we have been, as I said, we have been, what we have been doing is is trying to polish the final, the the the final aspects and, well, it's it's time to start reviews as much as you consider necessary. For sure for sure, whoever here or in the list have any idea, they will be more than welcome. Young doctors, apply for a shepherd, whatever is this requirement. And this one, we go through it. Well, let's go for lost call. That that's basically the idea. And then we will have time to align with some other ideas on on on capabilities that Nigel and Marisol and I have been discussing. Camilo's there? No. But ah, yeah. And Camilo. That's I didn't didn't spot you. Sorry. So but that's a mother for the for the coming is a this is a teaser for what's has to come. And that's all. Thank you.
[00:36:12] Qiufang Ma: Thank you. So I I have a a comment, actually. So can you go back to the previous slide? I think you you said you'll try to avoid the bidirectional reference. Right? So when I reviewed the draft this morning, I saw the young module. You have the inventory. You have the capability, and you have the entitlement, and the draft try to build the mapping of the correlation among those three things. Right? So when you said the bidirectional reference, are you referring to those bidirectional mapping among those?
[00:36:46] Diego Lopez: No. It's it's it's about think think about that the an an entitlement is is defined as what you do what you are required to to have a capability. And the idea is that some entitlements might be somehow entitled by another. So there there is a relationship. Think about to to run a particular feature in a in a router, you need a particular version of the of the operating system. So you need to run this capability, you need sorry. To to to activate the entitlement for MPLS, you need the entitlement for the operating system. And in some cases, it might be tempted to go the other way around. That for running probably the operating system is not, but think about a routing a routing feature that requires a particular version of MPLS. And in in a certain moment, you can be asking an entitlement to be or that if if you prefer to use the word license, it's it's the same. But it's you you would require to activate an entitlement, you would require another entitlement. And you can make the mistake of requiring the the the same entitlement for the other one. So it's a it's a mutual reference at the at the same level. It's not about the capabilities.
[00:38:05] Olga Havel: Okay.
[00:38:06] Diego Lopez: So it's it's it's simply it's simply avoiding that you are asking me, you need to have money on your right pocket to have money on your left pocket and then the other say say, you have to have money in the left pocket to have money in the right pocket. So it's it's it's avoiding this.
[00:38:22] Fatai Liang: Thank you.
[00:38:28] Diego Lopez: So yeah.
[00:38:31] Danielee Ceccarelli: I I just had the had a comment on the on the capabilities. So I remember there there was a work proposed in on capabilities that then would be extended here on any progress in in a month?
[00:38:51] Diego Lopez: Yeah. We are being yeah. It's a we we have been absorbed by other by other obligations. That's simply that.
[00:38:59] Danielee Ceccarelli: No problem.
[00:39:00] Diego Lopez: But we we we keep doing what we this morning, we were talking about the how other people are doing regarding well, 20 that behind is talking about post quantum post quantum capabilities, etcetera, that we would like to connect to their capabilities. Just to give you an example of that. We keep an eye on that.
[00:39:21] Danielee Ceccarelli: So so the the plan is to have a debt and mop document as the route, and then in IT, you have something for
[00:39:29] Diego Lopez: In Adi, in in this document, we have, let's say, I would say, a practical solution for the capability issue, but we want to to analyze it in more in more detail beyond beyond the the or or including matters related to the inventory and what you can do with inventory and trying to go a little bit further.
[00:39:51] Fatai Liang: Perfect. Thank you. Thank you.
[00:39:53] Qiufang Ma: I you can review some request some early reviews for this draft as well. Right?
[00:39:59] Danielee Ceccarelli: I'm doing it right now as I promised.
[00:40:01] Fatai Liang: Okay. Thank you.
[00:40:11] Danielee Ceccarelli: I pushed the deadline very far because now it's vacation period. IT coming back from ITF, so I allowed for more time.
[00:40:25] Fatai Liang: Okay. So here's the brief update on the Yamato for passive inventory. So right as of right now, the version o five is currently under IP app. I think it's pretty much done. Right? With so in this revision, this only change is we added the definition of the passive inventory according to the consensus from last time, and it was agreed and with also only minor editorial updates. We we still have quite some open issues, but I believe those can be also which is progressing offline, but also we could make this change once it's as a normal working group process once it's adopted. So the first one is is an open issue number six, which is about how do we model passive devices. We have been discussing a lot about the different modeling options because currently, the a passive device is defined as a new inventory object. And now and all then we discussed further about, you know, whether we could reuse the the the the base inventory model, but and instead modeling passive devices as an extension of of the base inventory, which by which we could reuse whatever we have defined of the basic base inventory object, but then add extensions to specifically model the passive device characters. Right? And and then there's a third option which model passive devices as a topology object by augmenting RFC eighty three forty five, which we also discussed offline as part of the c map hierarchy disc discussion. And we had a some rough consensus of going option two, which is to model passive devices as a new network element type. This would involve some model modeling changes on that. And and also the the benefit of that is we could also support a mix of passive and active network inventory under the same umbrella and using the same interface. So so this, we're gonna discuss further on the work on the mailing list and and finalize the modeling changes for that. The second open issue is to associate a link with the cable. Basically, there was a question about whether we need to define the association between the link and a cable, which is in the passive imagery because a we already have a termination point associated with the with the port through the topology to inventory mapping. And and then the association between a link and a cable could be also indirectly inferred from the the the the relationship between the link t p to port association path. Right? So do we need or not an explicit mapping between the tip between the link and the cable will will also impact the modeling of passive inventory. Basically, right now, we have the cable as it has the associated information of a and z and. So depending on our on the decision, that information may be retained or will be removed from the from modeling. So we have also an example of navigation from link to passive imagery in this in in the last presentation for the metric imagery topology. So if you are interested, take a look at that, and we can discuss the comment. I see. Olga, you have a question on that?
[00:44:56] Olga Havel: Hi. Could you just go please back to the slide with those two options? I just wanted to kind of refer to the option two versus option three. I think discussion was mostly like, I think any types is agreed fully like option two because there was never a suggestion to have notes only without the inventory object. You know? So that that's I think the option two is absolutely correct with using the topology inventory to extend. For option three, it was mostly about the other issue, you know, for topology, like, doing the modeling of the links and hops and all of that. So so I think when I raised the issue, I think option three was not about any Okay. But more about links and connectivity.
[00:45:45] Fatai Liang: In Linux connectivity. Okay. That's fine. Yes. Okay. So then we have also a very good number of, you know, different types of passive devices that we're considering in in the range and needs to be modeled to to to cover those devices. And so there are quite a few open issues associated with that. For example, we need to model a table joint box, which could be done either in an in in a a separate modeling construct or also, you know, a cable joint box could be potentially an effort element. But the the point is there are so many cable joint boxes in the field. So do we wanna do that or and and and explode the the passive injury or just make it lightweight and make it ad hoc use an ad hoc modeling for that. And there's also the the notion of a fiber fiber closure, which could be modeled as a passive component, which is inside an active device or act in in the active network element or in a passive device. And the and, also, we need to consider the modeling of the MPU cables, which could be either modeled as a multipoint cable with one one a end and multiple z end. And the also, the modeling of the connectivity inside of passive device. There's also thoughts about, you know, how do we trace fibers from from the beginning to the end when it's going through a cable cable joint box, you need to understand how the cables are routed or dispatched in from from one end to the other end inside of the box so so it can follow the path across end to end. Right? And there's also in the in the transport, there's also the the OCS switch which has been discussed widely. So there needs to be this discussion on whether it could be covered or not with the passive inventory. I see, Mahesh, you you wanna
[00:48:31] Mahesh Jethanandani: Mahesh, I think I've asked this question before, and I'll open it up again because I think what I want to understand is no. I'm not specific to this list of open issues that you have, but in general, what is the boundary for of definition of passive devices? Because, theoretically, this could go on.
[00:48:55] Fatai Liang: Yeah. Right?
[00:48:56] Mahesh Jethanandani: We're already talking about racks and securing racks and definition of racks and all that. So I'll rather than specific items, what I wanna understand as does a work group have a definition for what is going to be included and what is not gonna be included as part of the passive inventory model? Because, really, unless you draw a boundary, anything and everything could be modeled in this draft. So what is that boundaries, I think, is what I'm looking for a definition for.
[00:49:38] Fatai Liang: Yeah. Thanks, Marshall. I mean, let me quickly expand. So in the in the discussion of the definition of the passive inventory, right, we have put put in there, like, anything that's part of the infrastructure, the transmission, or communication infrastructure that's used to carry signal from one end to the other end is considered as part of the modeling for passive. Of course, this gonna be this is gonna be wide. Yeah. It's a bit broad, so we probably need to because as you see also from the discussion, there are a lot of, you know, things just popping up and saying, oh, I need I I have this tracked in my inventory, which is used to carry fibers or to enclose fibers. Right. So the those are the things that yeah. I I don't have a clear answer. Probably, we need to make clear of that to better, you know, enclose like you said, set a boundary to that.
[00:50:40] Mahesh Jethanandani: Right. And I I I and I'll admit I made your problem worse by talking about racks being also passive inventory. So really, this and it's more a check for you to be able to say, this is what the boundary definition is and whether that's why something either falls within it or falls outside.
[00:51:01] Fatai Liang: Okay. Yeah. So that's
[00:51:03] Danielee Ceccarelli: We we already tried with the definitions in the past. I remember the exercise that that Nigel did that to try to find the definition. He came up with a slider that was bigger than my apartment. So I don't know. If there is no way to find a definition that is good enough and with the clean boundaries, reinforce what I suggested the first time at least. So we can go to the work to to the mailing list and say, hey. Look. We were thinking to add these five elements. Say which ones should be there, which ones should be not, and so we can have a cleaner boundaries. Yeah. I think because finding definition, I I understand it's really, really hard.
[00:51:45] Fatai Liang: Yeah. We could we could we could potentially restart the exercise that Nigel has has proposed.
[00:51:50] Danielee Ceccarelli: No. Please don't. No.
[00:51:53] Fatai Liang: Because other You you let me know. There are always brilliant people who always come up with with with the with the device that already said and deployed in the field that they are tracking that as part of the inventory. So oh, I mean, yeah. We can we can discuss it offline on that. But there's yeah. I agree with you, Mahesh. There needs to be a boundary for that. Otherwise, it's gonna just explode and and never ends. Yeah.
[00:52:22] Danielee Ceccarelli: Alberto?
[00:52:23] Fatai Liang: Okay. Yeah.
[00:52:25] Roberto Manzotti: Just to extend a little bit on this definition. So we already discussed probably in some meeting about the possibility to have passive components. So I've seen during the IV hackathon, for example, that modeling our device, I was needing to model a few amount of passive component inside the network element, like, AWGmax, dmax, breakout, PO breakout, combined splitter. While here in the model, we still have only the full passive network element. And I don't know if this is something that we need to address or something.
[00:53:04] Fatai Liang: Yeah. I think so. I think I think there's also an open issue to track. Ah, okay. And remember, like, if when we when we agree to change the method of modeling passive devices the same way as an active device, then we generally can model anything pure passive, pure pure active, or or a mix of passive and and and active components inside the same network elements. Thank you. Okay. So the next stop next step is we will hopefully, we'll have the blessing for working group to adopt this work, and then we'll continue addressing all those open issues as we expect quite a good amount of discussion on that.
[00:53:50] Qiufang Ma: We have Mohammed in the queue. Do you want my comment?
[00:53:58] Danielee Ceccarelli: Yeah. Mohammed from. Hello. So, yeah, you asked about you presented extending the range of passive inventory. So my question is, is there this range extension also in domain extension considered so that, let's say, radio access or Ethernet or microwave be modeled also as part of this draft? I know radio access, we there is a lot of reservations here. Yeah. But
[00:54:33] Fatai Liang: It's like or microwave. Yeah. That's also a good point. Remember, like, we have had this microwave part of that, in the initial draft, but we still need some clarifications of whether, you know, this could be part of the description for the image for the passive imagery. I know there are different thoughts. I don't have an answer. We probably need to explore further on that. Yeah. But, definitely, it could be part of the topics. Then it's gonna unfortunately, it's gonna if if we agree to include that, it's gonna be yet another extended list of of things. So yeah.
[00:55:14] Danielee Ceccarelli: So microwave is a part of our scope and expertise. In SeaComp, we are modeling a microwave, so expertise is there. Traditionally, we don't go beyond those boundaries. We don't dress around and Packet Core, etcetera. But, I mean, there is nothing that prevents us from doing it. It's just a tradition thing plus combined with a a competence thing. In ITF, the competence is is is in the transport network from from the optical to the the the IP level. That said that we are contribution driven. So if you believe that this is the right model to be extended that to add support also for run packet core. If if a contribution is written on that, we are more than happy to consider it.
[00:56:12] Qiufang Ma: My my my comment on on so my again, right, so on on that is that I would believe that microwave or or or other devices would actually be powered and and would be visible to no? Okay. So I mean, because then then you would not be in the in the in the fully passive one. That's what I would assume. Because you would for I mean, for example, for for microwave, if I take microwave as an example, it will have a config. Right? So you will have power. You will be able to to retrieve it.
[00:56:46] Danielee Ceccarelli: It. I would expect microwave to have impacts both on the core model and the. Both of them.
[00:56:53] Qiufang Ma: The. Okay. Yeah.
[00:57:05] Nigel Davis: Nigel, Dave is not in the queue. Sorry. Yeah. So you've got you've got wave guys. They're passive. You've got these tubes that are just you know, they're like cutting out cables. So you start to model those. They're not they're not powered. Sorry. They're not powered. Yeah. Yeah. So Okay.
[00:57:22] Fatai Liang: Oh, yeah. Well, I guess we we probably need some more discussion on that. Okay. Thanks.
[00:57:28] Danielee Ceccarelli: Thank you. My job.
[00:57:39] Nigel Davis: Must say I thought you liked my slide. I'm deeply hurt. You know? Right. So, So, hackathon. So that's the, the the team. I'm not sure that was sorry. But that's the team, that's the AI generated poster. And, click yeah, on. Good. So I'm gonna go through the the detail of the the the little slide that's there a bit later in the slide pack. I forgot I used the PowerPoint feature that isn't available on Meetech also. But the we pre hackathon, we did some excellent pre engagement work. Critical thing, we got strong operator interest. So that's the tip OPT slide. I'll go to that in the back of the pack. But they've endorsed the oh, sorry. Endorsed, supported the hackathon also the direction we're trying to go to with that the hackathon. So it's critical to get engagement. And
[00:58:40] Diego Lopez: in the part of
[00:58:41] Nigel Davis: the hackathon, we fabricated some devices realistic but not real. And we tried to deal with the interconnect issues but didn't succeed in that, so we had a lot of interconnect difficulties, but we got through them all. We went through that little set of set of things up here. That one seems to be covered by another slide, but I'll go to the thing on it. So the basic thing is a Cisco solution at the top. So their their product at the top monitoring us and then and Cisco, and then, likewise, the Sienna Navigator at the top, and then the these alternate tops on here as well again. So we've got a number of different configurations. I'll go through this in a bit more detail later. But the so we use actual actual product. We had a stub down here from Cisco for the bottom end and our actual product down here, it's the same sort of setup. We had a power recovery, which was very enjoyable. So the servers went down suddenly, and we had to put back together again. As I said, security was a challenge with the interconnect, actually, so we need to do better at that next time. So we won't promise not to make that difficult. We demonstrated various interconnects. Review reviewed the data in a lot of detail to make sure we'd actually got stuff transferred appropriately. And we did a TAPI, as you can see on here, tiny text TAPI and IV side by side, so we transferred data. We actually did a transfer from Sienna and Cisco through Sienna through Sienna with both Tappy and Ivy and then up to Cisco. So we show the data propagates road chain. So that sort of demonstrates that we can deal with mappings and so on. After the hackathon, I'll do that at the end. Actually, I've got a better slide for that. This this is the slide I presented at the hackathon. The we did a a compart part of the point of the hackathon was to validate that we could do equivalents of what Tabby has. And oops. Sorry. It wasn't intentional. So we'll do that. So we've seen, obviously, they both provide a model that is a standard representation of equipment. They both provide good foundation. They both have a sort of a component orientation. The there's work going on in Ivy at the moment to do that location as we've seen, obviously, topology and so on. TAPI currently has an equivalent, but we should take care to align with the Tappy sort of flexibilities as we're doing that so you can then support. As you as you know, my I'm I'm well, you don't know necessarily. I'm the primary editor of Tappy at moment. My intention is to help us as an industry migrate from a pair of inventory. So we've got Tappy inventory, equipment inventory, and IV equipment inventory to navigate Tappy to be able to use IV. So that's my intention. That's part of the point I hacked on. The operator, we've put that position very clearly to the operators, so it was very obvious that's what we're trying to do, and they endorse that as a oh, sorry. Support. We shouldn't use the word endorse. Support that intention as a longer term intention. So so we're all on the same sort of track. There was one thing here of identifying functions. So there was an input from Cisco specifically that that the the the functional, so the o OTN switch, ROADM, etcetera, are not explicitly stated. That was an intentional position in both Tapia and Ivy. So we wanna just consult the operators on that, make sure we're that's that's okay. Our intention is to use the capability material to to allow a solution to determine exactly what the components that are present can do and so on. So that was something that was highlighted. It was intentional of both those. And equipment types supported in IV, not in TAPI, intentionally not TAPI, but, you know, it's again, there's a a thing we might wanna discuss here on on subtlety. That goes back to the spec thing. And then holder embedded my favorite one. Holder embedded in equipment. So Tabby has that. Ivy doesn't have that. Ivy has a different solution. We were able to map it, though. It's a challenge, but we're able to map it. So the important is it does actually you can actually move from one to the other model. So we did a bit of a cheap mapping admittedly in the hackathon, but you can do it. A couple of few other things here noted in the hackathon was software licenses and so on. We know we've got these items coloring it, and identity correlation across different systems was pointed out by Cisco. We did do some tappy ID mappings in in our portion, but we need to do a lot more work on that to make sure that works properly. So we did a little hack of that, but which is here. So as I said earlier, we we actually put some IV and Tappy together in our solution. It was a lightweight version, but it we could we can see some challenges, but we can get some stuff working. We did actually transfer the equivalent information through IVs we had in TAPI with notes, so you can't see what this is, but this is provisioned there. I have got slides later on that do this. I could have clicked on it. It didn't have. That was my fault. So we were able to transfer a the view of intended equipment through through the IV solutions, well, as Tapi solution by putting this hack into the IV solution. So we inserted some that that is pure TAPI. We just inserted it into the IV structure. We could do a more normalized version of that, and that's something we should be looking at. I know we deferred it in IV, but we should be looking at that. But, again, we need to ask the operators whether that's a relevant thing to look at or not. So my back to my previous slide. Previous, but one slide down here. Maybe not on that. Not on that slide. That was on the later one, isn't it? So we need to we need to consult the operators to determine whether that's something they really want us to put into our idea or not. So so the the summary next steps, we will meet after the hackathon. So after this meeting, Roberto and the team and the Sienna team meet, and we'll identify what what things we think we found, what we need to we'll continue to review the data so we can validate we didn't lose anything. We'll review TAPI further to look for any, know, any missing properties. I thought at CSLO, you and I should look at g seven seven eleven and see if that also has anything further beyond TAPI and beyond IV. So we should look at that, and maybe that would also apply to other things we're doing here. We We can can deem the seven seven eleven and ITT and look for other features that we may not have covered in either TAPI or or IV that we may wanna bring into play. Ask the operators in general. So once we've done that set of reviews and then discuss and take that to the operators and say and especially through tip mantra because they've said they're interested in what we're doing here, but also other operators and and validate that the stuff we've identified as missing or the we think we should do is things they think are important. So we can do that through the we've now opened an avenue up with the hackathon to actually have a formal statement to them and say, this is what we found. Is what we think we should cover, and then do they agree? And then also, obviously, where they agree, we bring the stuff to IBM and add it add it in. And where they don't agree, they think it's not important, then we can obviously park it. Further hackathons, potentially, as appropriate, I've got some listed down the bottom there, discuss whether we wanna do what we wanna do with the hackathons themselves, for other other activities we wanna go and couple with. So online with so YangPush might be an interesting one to look at over YangPush maybe. So I've got a number of listed propo you know, proposed potential hackathons down the bottom there. Obviously, I enjoyed the hackathon, so I'm happy to run more. It was good fun. So worth doing. So and that's the that was the end of the actual slides, but I wanted to just go quickly to the pictures that you couldn't see earlier and then I showed them a little bit more detail if that's alright. You didn't put the time off. Where's Where's my my time? Time?
[01:06:49] Fatai Liang: We have.
[01:06:50] Qiufang Ma: You you have plenty of time.
[01:06:52] Qiufang Ma: Have so much time.
[01:06:53] Nigel Davis: I'll just work down to the end of the so I've gotta go down a long way here, if I'm sorry. So if you bear with me, I'll just show the pictures, and then I'll I'll take the questions. Oops. Let me get. There we go. So that was the the little slide that's at the bottom. I'm just showing so you can see these here. Sienna detail with a Sienna loading only. Cisco Roberto's stub that had a set of data we picked up from the Ciena solution. Then there's the Ciena solution with both both the Ciena and Cisco products together. They were from the the the same pictures again. And then the Cisco solution with north the northbound solution with both Cisco and Sienna products together. So, again, I'm showing those two things. So we we were successfully successfully transferred data. This is the set of things we did, although it got screwed up by PowerPoint generously. So Cisco's HCO, Sienna's navigator, was at the bottom there. And we showed that in those various configurations. So as I showed earlier, you can see it with a bit more detail. And we've run all of those configurations essentially during. And that's just a screenshot of the OPT hackathon like no. Sorry. In interest in hackathon. And the key thing down the bottom here is the longer near term and longer term aim to the evolution of Tapi to Ivy, which they, as I said, they seemed to to see as a as a sensible thing to be trying to do. And that was the little hack in I put in. As I said, it's it's actually tapping stuck into the I the tapping to come and stuck into the IV model. But we could do that properly, clearly, but it's something I think we need to come back. Okay. And that was the slide the two slides I showed with the detail. And we missed a bit of mapping, so we had a a mapping error, but that's fine. Okay. It's all.
[01:08:49] Italo Busi: Yes. I have a comment on this table that you showed. Yes. I'll go back to that
[01:08:54] Nigel Davis: now. Mhmm.
[01:08:57] Diego Lopez: Do you
[01:08:57] Nigel Davis: want to say what the comment was while I saying?
[01:08:59] Italo Busi: Yes. It's on the when you said something about the functionality being split intentionally out of scope of that year and IE. Yeah. Understand the rationale behind the request. The issue is that it's not unfortunately, it's not this. Alright. There are some simple cases like a layer three router is is is a network element Otherwise. Which embeds a single function, which is a dAppy node. Yeah. And you have to switch network and which has been and not yet switches effect. It's not gonna enrich and and not yet switch function. But there are more complex scenarios. I know people is combining OTS switching and all that functions in the same box, or sometimes something like an EFA is a board, and sometimes we put multiple function into the same board or some MPLS, which is I know they have they are distributed to over multiple cards and a lot. So it's very difficult to if you want to cover every scenario
[01:09:52] Nigel Davis: It gets worse. It gets worse because I might start with something that looks like an OTN switch and then, oh, now it's a ROADM because it's like I've taken some boards out and put other boards in. I've got a versatile backplane. It's mutated from one type
[01:10:03] Italo Busi: to another. So it's very difficult. That's why I that's why there was a intention.
[01:10:08] Fatai Liang: Yes.
[01:10:08] Nigel Davis: That's why I put those two crosses in green. They were both intentional, not done. And I think that is where the probable answer is, where you look at the capability of the thing and you say, as a as a controller, I know it's got that sort of capabilities. I will now represent it as that because I've looked through the capabilities and I can safely do that. Or, no, it isn't a ROADM or an OTN switch because it can mutate between the two of them. So I'll make it a general purpose device or something because I've looked at the specs and all the things that are possible, and I concluded that I think it needs to be done with that properly, not just a a designation.
[01:10:43] Italo Busi: And some example maybe help them. So showing some maybe simple example, like, this specific case
[01:10:49] Nigel Davis: But but
[01:10:49] Italo Busi: that's where you understand that.
[01:10:50] Nigel Davis: The point was it was raised. So it's important that we actually put a proper response back from Ivy saying, this is why we haven't done this, and this is how we think it should be solved. So I I aligned with you fully on why we haven't done it. That's so I I obviously, we didn't do it in TAPI. We didn't do it in IV.
[01:11:10] Italo Busi: Good same example so people will understand I
[01:11:12] Nigel Davis: think so too.
[01:11:13] Italo Busi: Why it has not be done and how it should be done. Otherwise, it's
[01:11:16] Nigel Davis: The reason I record this is because it was raised at the hackathon. I think we haven't put enough explanation as to why we haven't done it in either TAPI or IV. Yes. And therefore, think we just need to go through that work. Okay. So Camilo.
[01:11:32] Camilo Cardona: Hi, Camilo. Cardone entity. First of all, this work is amazing, Nigel. I based it almost brings tears to my eyes because, I mean, two two vendors doing interoperability in ITF who would have thought of that, and that is not happening anymore and and see them. Congratulations. Well, it'll cover more or less what I wanted to say. That's called identity function. It's tricky because it can go to a lot of corner cases. Yeah. That's right. But if you are doing phone I mean, these these management pieces of software, they usually are for people in the NOC, and they do value these sort of things. It's just that when you go you go scientific and you, of course, a layer to switch against a router. I mean, nobody has been able to explain that. But in in in the in the field for the NOC, they do for certain networks, they do have these simple reasons. The NOC has to think less, and they do want to know that. So that might be UX more than than inventory, but it it's still good that you're that that you're evaluating that. And very good work on it, honestly.
[01:12:36] Nigel Davis: Thank you. Thank you.
[01:12:42] Roberto Manzotti: Yeah. In fact, this comment was coming from our development team and was more oriented to the user experience. So the fact that an operator may like when looking at the inventory to know which which function is that item doing within the network. So do not have to rely to look at the name of the device and then have to look back to the data sheet and understand whatever it's doing. So that's the the the concept.
[01:13:08] Nigel Davis: Yeah. No. I I mean, I I think I think it's important that we actually explain why we haven't got it, how you could then achieve that, and such that if you've got, you on your UI, you can then do this by using these properties or whatever. I think it's important we do that. It's not through the interface between the controllers, but it's yeah. Okay. Victor. Victor, hi.
[01:13:34] Victor Lopez: Victor Lopez from Nokia. Well, I congratulate you for the interoperability activity like the like the rest. I was thinking about the how the hackathon work could be extended for IP for the IP side. What I understand on the next steps in the slide that you have is that you are planning to focus maybe more on a the notification side.
[01:13:57] Diego Lopez: This That
[01:13:57] Nigel Davis: was just that was just my preference. But, I mean, we can take any import.
[01:14:00] Victor Lopez: No. I I just wanted to because in the slide, you are commenting that the use cases are defined there. I wonder if there is somewhere else that I we could get more the typical use cases where you get the information, which components that you have compared on the testing. Because this way, we could do a parallel validation on IP, for example. Yes. And my last question, it is related with the with the notification side. Does it really matters the underlying transport technology, either if it is ampoules or No.
[01:14:32] Nigel Davis: No. It doesn't mean doesn't. It was just
[01:14:34] Victor Lopez: And why, let's say, are you targeting other use cases that that you didn't do here, like OEM or other use cases?
[01:14:42] Nigel Davis: These were just oh, so interesting. I know it's a separate thing. These are just proposals for specifically possible hackathons in future with with the I've I've still got this. I'd like to migrate Tappy to Ivy in mind. And on that basis, I know these things might be useful because we've got we've got Tappy streaming. We've got Yang push. I can if I can do an equivalence, I can then go, well, you haven't lost that feature. You haven't lost this job. So it's that that in mind, but there's another set of possible hackathon directions that could take onboard other things. And, OEM's interesting, though, because OEM is I was looking at physical inventory here, and OEM obviously is a much more of a behavioral functional thing. But I think having hackathons for other interoperability activities around this will be very valuable as well.
[01:15:27] Victor Lopez: Tapia streaming is oriented to alarms and OEM. This is why I mentioned it. But, again, you are maybe thinking more about pluggable insertion and notifications on the inventory. So, well, I would like to to keep exploring these mitigation use cases.
[01:15:42] Nigel Davis: And Just to clarify on TAPI streaming, we use TAPI streaming for everything. So TapiStream is just a general purpose transfer mechanism for PMs, equipment, for for OIM, for alarms, for you know? So I'm just trying to use the equivalents and think, well, okay. The yang push thing. Oh, you want me to go away now? Yeah. Tell me the I've been I've been sent times at the same time of my time zone now. Yeah. So I'll just That
[01:16:07] Victor Lopez: would be nice maybe to define the use cases. Yeah. We we should targeting instead of talking about the underlying technology.
[01:16:13] Nigel Davis: I think we can do that. That was just a little that was only a little proposal from the hackathon. Nothing. We not not a mandatory thing.
[01:16:18] Danielee Ceccarelli: Okay. The this was an excellent starting point about it. We can build on top of that with the new use cases, new vendors.
[01:16:24] Nigel Davis: So Yep. K.
[01:16:36] Fatai Liang: Hi, guys. Today, Today, I'm gonna present something a little bit new. It's called CADI. It stands for cryptographic asset discovery and inventory. Alright. So a little bit of recap. The q day is it's kind of a people think q day is 2035, and there's some new consensus that says the q day might be accelerating because the California Institute of Technology says you need a computer, quantum computer, and quantum algorithms. Quantum algorithms are already here. It's just a matter of time with the quantum computers, and it's very close because you have a 10 you need 10,000 to to to have a few days to come, and now it's about 6,000. So what is CADI? So CADI stands for cryptographic asset discovery and inventory. It is a set of tools and guidelines that help you to identify devices and services that needs PQC transition. So cryptographic assets is not something like Bitcoins or Dockcoins. It's actually a digital physical element that protects the confidentiality and the integrity of the security of the transmission or storage. So it could be algorithms. It could be modules, configurations. So at the very top layer, you see the devices and software and services. And if you see very closely inside of it, it's actually the cryptographic modules and libraries, credentials, secrets, protocols, all that kind of things that are making PQ qualify the devices happen. Right? So why should we even consider looking at this kind of thing? Is that because if we can have this kind of inventory discovery and have a unified view of all these kind of things, you could have multiple benefits for the c suite's officers because for number one, there's some supervision requirements for reporting. I have some analysis in the next slide. And then you can also make practical PQ transition plans. Also, maybe financial budgets. You can have, like, a c, like, this is my network. This is a network management. There's a there's a poor icon, but here's are some network elements that you can see that for some protocols, it's already PQ ready. It's the green one. Maybe for the SSH, for the management plane, it still needs some PQ capabilities to have it all works. So and, also, it can help you to give a quantitative assessment for the security posture. So many good reasons to maybe think about it if this thing could be useful. So this is a lot of you wanna or okay. So there's there's some I I don't wanna go to details, but here, you can see there are some statements or consensus that says for 2035, you should have all system to be completed for 2030. For critical infrastructures and high security systems, you should be completing transition. And starting from '25, there are some road maps, important dates, and some suggested steps of doing this kind of PQ migration. Here, you can see there's a six steps framework. It's from the preparation to inventory discovery, risk assessment, and before you actually do PQ migration. So it's also something that's suggested or recommended by The US guidelines that says that there's a five stage way of doing things, like, first is preparation awareness, and then is the identification. So in here, actually, several guidelines that, already says you should be doing inventory identification. And for some agencies, you should also, have yearly crypto asset reports to, like, show, like, are are you actually, making progress on this kind of things? So, I think The US, timeline is more detailed. Also, it's kind of a good practice that's followed by many places in the world. For the EU, it's more forgiving and a little, you know, more flexible in the time. But you can see the certification or the procurement should happen around '27 to meet the 2030 important date. So you can you can do end of service or sunsetting at that time to have a to meet the important dates of twenty twenty thirty. So those are all backgrounds. Okay. And so how should we do that? I I I think for for today's presentation is just for people to, you know, think about this kind of thing, to understand this kind of thing before jumping into details, but I'm I'm gonna be quick about how should we do this kind of thing. You have two ways. You have active discovery or passive discovery. So for active discovery, it's all in know also known as voluntary identification. It involves changes to the vendor's production procedures. So we need the device and services to actively self announce their cryptographic assets. Well, the the picture here is very vague, but I said basically, it says during the CICD production and that you should be declaring that I'm using this certificate certificates with speaker capability or with not. So the the good side of this one is we can have very detailed dependency maps. Like, this function is depending on this library. This library is depending on this protocol module, so you can have very detailed information. But the problem is if you are looking for the use case of legacy devices to be migrated, you you you this is our new thing. This only applies to new devices. You cannot even install some kind of probes or programs to legacy devices. So another way of doing this is through passive discovery. So you could do some simulated handshakes. You can do configuration extraction, traffic analysis, all those kind of things that applies to the legacy cryptographic assets and devices. And the good side is that you are agnostic to the design of the target. You can work for many heterogeneous vendor products and maybe new different networks. It's all good for use. The bad side is some internal modules will remain silent, but that's just corner case for for now. And this is the part that may have may welcome some discussion is that because after discovery, we should have a unified view of the cryptographic assets. So they are I kind of this part is something that will invite Ivy people's suggestions or devices because there are ways of doing it. You could we could consider adopting this kind of thing or not. The the easy way is that we could be just adding some one or two properties to existing the data models of how do we describe devices, software, and services. That's the easy way of doing this. And the whole process of everything I said here could be going to PQIP or or some some other places. It does not have to be an r to c track. It could be just informational. But this is something that maybe that from the inventory perspective, we could add some kind of important information for our CTOs, to look at. So this is the part we invite, the ops experts and inputs, common suggestions, contributions, collaborate to, collaborators. So when I say actually should associate assets with protocols is because, usually, posture is related to communication. So this is a easy appendix. What kind of I I did a little bit of research on on the statistics on IPsec TLS certificates. So, basically, some of them are done, some of them are in progress, but it's very quick in the progress. But, eventually, it's the communication ports that is creating posture. So this could be a perspective of of considering now the the the full set of the of the things. Questions? Comments?
[01:24:48] Mahesh Jethanandani: Mahesh, I'm gonna ask this more as a process and a scope question, not the content itself. So the IV charter is for hardware elements, software inventory, entitlements, clearly layer zero through three. And our cryptographic assets as it relates to this are at best adjacent to what the charter is supposed to work on. So really the question is, does this really belong in IV, or is this something since it's a tooling security kind of related question, it should be sec sec dispatch maybe the right place to send this to really determine whether it should be discussed there than here.
[01:25:47] Danielee Ceccarelli: But it it's so Okay. Answer to the first question, actually, no. It doesn't belong here. Second, it belong to SEC? Yeah. It's it's a cross domain thing because it's a SEC inventory. I don't know if they are doing any SEC inventory in the SEC area.
[01:26:08] Fatai Liang: Mhmm.
[01:26:09] Danielee Ceccarelli: Maybe we can talk to SEC dispatcher and see if they have something, a box where this would fit. If not, if there is willingness in the working group to work on it, why why not extending our charter to do it?
[01:26:30] Mahesh Jethanandani: Right. So even if it is security inventory, there's nothing to say that somebody in security cannot augment a base inventory model to define security assets.
[01:26:44] Danielee Ceccarelli: Yes.
[01:26:44] Mahesh Jethanandani: So but so there's a distinction with whether the work we have the expertise in this working group, or does it really belong in sec for that purpose?
[01:26:54] Danielee Ceccarelli: Yep. Okay.
[01:26:57] Kent Watsen: Hi. This is Kent. I had similar thoughts, but a different angle to it. My first thought is whether it's worth standardizing at all. Like, why should the ITF do this? For instance, is it used to help make routing decisions? Sorry. What what? Routing decisions. No. Like, well, it could be.
[01:27:17] Danielee Ceccarelli: Well
[01:27:17] Kent Watsen: If if I I could so that's that's the first thought. Because if it's not actually used to help, you know, run and make the Internet better, then it's just an offline database, and the ITF doesn't need to standardize it. But But I actually can make a case for it needing to be something that could be used to make routing decisions. So for instance, I have a policy, and I want to ensure end to end, I have at least five twelve bits of security. And the only way I can do that is by, you know, the router is looking at this kind of information, just finding the path that would ensure that level of security through end to end. So I think maybe there's a case for it, but I had to think about it first to get to to get to that point. Secondly, is it the right working group? I know there's a debate ops versus sec. I actually think this is a ops thing. Yes. It's security assets, but it's operationally relate it's operations. Like, for instance, my crypto types document was heavily security related, but it made sense for it to be done NETCONF working group. And I actually think this is more of an ops thing than a sec thing. We're not defining the algorithms. We're not defining the, you know, the Cypher suites. We're just defining a database that Yes. Captures asset data. So I think it's the right place in ops area, I should say. Is it the right working group? I actually think it is. I mean, it's inventory data. The charter is a little bit gray. I also reread the charter mesh. And it's it it kinda gives examples. Like, you know, for instance, software. For instance, entitlement. For instance, security assets. You know? So I think I think it actually fits without charter rechartering, but it's certainly suitable for recharter as well if you wanted to make it more explicit. And then my last thoughts are more like nits. The title of the slide probably should have been summary of current activity in the industry about CADI. When I first read it, I thought, like, this was all your work. I was like, man, that's amazing. But then I discovered you're actually, like, recapping about two years worth of worker. And so anyway. And, ultimately, I imagine this would lead to a Yang model, and I was actually looking for what is the Yang model, but, clearly, that's not what this document's about. It's really just an informational.
[01:29:55] Danielee Ceccarelli: But good analysis. Thanks. Julian?
[01:30:01] Julien Meuric: Julian, of all, I should thank him because most of the thing I was about to say was already said before. But I just wanted to acknowledge that I feel this is very useful work from a perspective. And I believe since it's more inventory than security itself, I believe ops sounds like a great place. Maybe not this working group. I don't have any strong opinion about that. But I definitely support this work as being tackled by the ATF and probably ops area, whether it's here or not. Thank you.
[01:30:40] Kent Watsen: I'm back with you.
[01:30:41] Nigel Davis: I'm back
[01:30:41] Diego Lopez: with you. No. Simply simply to add what can what I said there, I I believe that the inventory collecting this and building a crypto inventory is is an inventory. Is it is this same way that we say, no. If we're going to inventory it optical themes that that be belongs to TEAS or whatever. It belongs here. Something different probably is the methods. I mean, how what you're doing, etcetera. Standardizing this is something that I don't see here and probably is more for the for the people that know about security or the people that are concerned about that. But the inventory, the model, how you will will represent this is well, I I I think it's a is another aspect that we have to to include in the inventory. And, well, since I see this very much connected with the CN, these are perfect examples of what we have we were trying to to to model with the idea for capability, something that is there.
[01:31:40] Kent Watsen: K. Kent again. And so I was thinking about, is this a network l and, like, what would the Yang model be if it were a Yang model? Right? Because you could clearly associate this with network elements. And what kind of assets does each network element have. Right? But you wouldn't wanna stop there. You'd also wanna do endpoints. So the actual clients, the actual servers. And it's like, currently, the definition of a network element, which is in the base model, is the inner, like, networking components does not include the endpoints. So that might be a charter update.
[01:32:21] Danielee Ceccarelli: Right? Yes. Correct. Agree. Roberto.
[01:32:33] Roberto Manzotti: Yeah. I was many my my idea is that I I have the feeling that this is required considering the increasing regulation that are around the cryptographic environment. My point is related also to the discussion on the network inventory and the location where we may need to identify this. We have also something that need to be tracked at the component level. So most of the unit now is to have a secure boot and potentially a quantum resistance secure boot. And I think from the asset point of view, tracking also that information at the component level may be interesting, and I think can fit somehow in in IV.
[01:33:25] Danielee Ceccarelli: So it seems that there is a general support for this work to belong to the ops area. And if it's in the ops area, most likely in IV with or without recharter. Actually, I mean, we we've been talking about rechartering and not to cover just these, but if if I correctly remember last time we were speaking about including capabilities. Capabilities are not included today. So, I mean, as as Diego correctly pointed out, these might fit into the capabilities. So maybe we can take two birds with the stone and and and the recharter in that sense. Sound good sounds good. Thanks a lot for bringing some fresh air in in the working group, and thank you, everyone.
[01:34:20] Qiufang Ma: We will see you in San Francisco.
[01:34:22] Fatai Liang: Thank you.
[01:34:35] Danielee Ceccarelli: We also need some fresh meat because I asked the I asked them for the officer review, and it went to me. And I asked them for the young