Re: [OPSAWG] CALL FOR ADOPTION: draft-ymbk-opsawg-9092-update
>>> Ah, ok. For both RSC and RTA distinct properties are listed such as >>> "applicable in long run", "usable", "complex code"; if no comparison is >>> intended I'd just remove the two paragraphs about RTA & RSC. >> >> we seem to be at cross-purposes here. the point was not comparison at >> all. never has been. the point is two illustrations of signing. > > Yes, indeed both RTA and RSC can be used to sign arbitrary digital objects > through reference of their respective SHA256 message digest. But that > applies to any and all digital objects. :) > > Given that the Geofeed specification includes a build-for-purpose > methodology (which has running code), are references to other illustrations > of signing maybe somewhat of distraction? analohgously for your bag on the side of rpki-client? :)/2 randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] CALL FOR ADOPTION: draft-ymbk-opsawg-9092-update
On Sat, 16 Sep 2023 at 02:29, Randy Bush wrote: > > Ah, ok. For both RSC and RTA distinct properties are listed such as > > "applicable in long run", "usable", "complex code"; if no comparison is > > intended I'd just remove the two paragraphs about RTA & RSC. > > we seem to be at cross-purposes here. the point was not comparison at > all. never has been. the point is two illustrations of signing. Yes, indeed both RTA and RSC can be used to sign arbitrary digital objects through reference of their respective SHA256 message digest. But that applies to any and all digital objects. :) Given that the Geofeed specification includes a build-for-purpose methodology (which has running code), are references to other illustrations of signing maybe somewhat of distraction? The current draft outlines in a good and detailed way how to authenticate a signed Geofeed file; on the other hand, the references to RSC or RTA leave a lot up in the air what exactly the workflow could/should be in context of Geofeed files. I think the Geofeed authenticator specification is superior to RTA and RSC, for the purpose of signing Geofeed files. Kind regards, Job ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] CALL FOR ADOPTION: draft-ymbk-opsawg-9092-update
> target="https://sobornost.net/~job/using_geofeed_authenticators.txt;> > > Example on how to use rpki-client to authenticate a signed > Geofeed > > > > thanks >>> In section 5 it is unclear why RPKI-RTA and RFC 9323 are compared to >>> each other in a subjective manner about perceived complexity. >> >> a *comparison* was not intended, and i don't see it there. > > Ah, ok. For both RSC and RTA distinct properties are listed such as > "applicable in long run", "usable", "complex code"; if no comparison is > intended I'd just remove the two paragraphs about RTA & RSC. we seem to be at cross-purposes here. the point was not comparison at all. never has been. the point is two illustrations of signing. > 1/ the new EE certificate uses an 'inherit' element in its RFC3779 >extension, but section 5 disallows the use of 'inherit' in EEs. sigh. russ? > 2/ given that the example EE was refreshed in -01, the example >Base64-encoded CMS signature (page 24) also must be refreshed. russ? > 3/ might be good to suggest the use of one-time-use EE certs, perhaps: > >The CA MUST sign only one Geofeed with each generated private key and >MUST generate a new key pair for each new version of the Geofeed. An >associated EE certificate used in this fashion is termed a >"one-time-use" EE certificate (see Section 3 of [RFC6487]). MUST is not "suggest." perhaps SHOULD? randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] [Inventory-yang] [CCAMP] [inventory-yang] poll for network inventory base model
Hello Daniele, Oh, absolutely nothing with bad intent or complain. I apologize if the “there is always something was wrong” phrase was too negative. All models change, more if they aim for concepts that are hard to abstract, as this one. I was just wondering if in general, as a policy, the group wanted to publish the (already good quality) models quick to bootstrap deeper discussions, and then not be afraid of updating the model if needed. As an alternative, one could wait years to gather use cases over the years to prove maturity. I have nothing against one strategy, or the other, just wanted to understand the strategy.. I am sensing the group is aiming for the first? Thanks, Camilo From: Inventory-yang on behalf of Daniele Ceccarelli Date: Friday, 15 September 2023 at 11:02 To: Camilo Cardona Cc: "inventory-y...@ietf.org" , "ivy-cha...@ietf.org" , opsawg , "cc...@ietf.org" Subject: Re: [Inventory-yang] [CCAMP] [inventory-yang] poll for network inventory base model Hi Camilo, As you said there will always be something that "could have been done better"...but we'll not request for the publication of a document/model of low quality. Moreover both the documents we're considering for adoption have been there for a while with a lot of experts working on both of them. I followed the CCAMP a bit more since i'm chairing that WG and it went through thorough reviews before being adopted in the WG. I'm not sure what your question is aiming for. Can you please elaborate a bit? Thanks Daniele On Fri, Sep 15, 2023 at 4:48 PM Camilo Cardona wrote: Hello group, Daniele, thanks for the previous summary. Option 4 is a good compromise to explore first. One question for chairs (maybe even AD): are we aiming at standardising a base model quickly and then accepting that something was wrong (there is always something wrong) and doing a new version, or are we taking our time with the core models? Thanks, Camilo From: Inventory-yang on behalf of Daniele Ceccarelli Date: Friday, 15 September 2023 at 03:45 To: "maqiufang (A)" Cc: "inventory-y...@ietf.org" , "ivy-cha...@ietf.org" , opsawg , "cc...@ietf.org" Subject: Re: [Inventory-yang] [CCAMP] [inventory-yang] poll for network inventory base model Hi working group, Thanks a lot for all the useful comments on the different drafts. There seems to be a split of preferences between option 1 and option 3. Given that the interinm meeting is soon (next week), we suggest to use it to further discuss suggestions and concerns from the working group and defer the decision by 1 week (Sep 22nd) immediately after the interim meeting. In order to have a fruitful discussion at the interim meeting please consider the following inputs: Italo made a very good proposal on the split between HW only and HW+SW use cases. Is this something we want to pursue? Do you think it makes sense to start focusing on e.g. HW and then add SW on top of it? When asking to adopt one draft or the other we were asking (as per IETF process) which you consider to be a good starting point for the working group to work on, not something that is ready for publication. This means that whatever draft we decide to adopt, we can significantly update it to properly cover all the different aspects of invently. With this regard Alex did a very good analysis in his mail. Maybe we don't need to make an hard choice between the draft but take the best of each. For example: we can take 30% of one draft and 20% of the other and build a new one as per option 3, if on the other side we decide to take 80% from one draft, then it makes more sense to start from it and build on top of that. Another good point touched by Alex is the "equipment-room". We are supposed to cover also sites and location of the inventory. Are these things connected? it seems so. If the WG prefers not to address this in the core model and add it on top, that fine, otherwise we would suggest to have sites and location added (whetehr in che core model or added on top can be discussed). Again we have a good proposal from Alex on the way forward, which is: "For example, one could start with draft-ietf-ccamp-network-inventory-yang, modifying it to remove the network-hardware-inventory container and splitting the remaining module in two (for equipment-room and network-elements, both of which will now be top-level containers). Remaining modifications can be made from there. I guess this makes me a proponent of option 3, but with the caveat that this would not need to restart from scratch - really an option 4 that says merge (for overall structure and common parts, which in this case is possible) and split the remaining difference." We don't really care whether this is called option 1, 3 or 4 but seems to be the most meaningful one...which is: use ccamp draft as a starting point, implementing the modifications suggested by Alex
Re: [OPSAWG] [Inventory-yang] [CCAMP] [inventory-yang] poll for network inventory base model
Hi Camilo, As you said there will always be something that "could have been done better"...but we'll not request for the publication of a document/model of low quality. Moreover both the documents we're considering for adoption have been there for a while with a lot of experts working on both of them. I followed the CCAMP a bit more since i'm chairing that WG and it went through thorough reviews before being adopted in the WG. I'm not sure what your question is aiming for. Can you please elaborate a bit? Thanks Daniele On Fri, Sep 15, 2023 at 4:48 PM Camilo Cardona wrote: > Hello group, > > > > Daniele, thanks for the previous summary. Option 4 is a good compromise to > explore first. > > > > One question for chairs (maybe even AD): are we aiming at standardising a > base model quickly and then accepting that something was wrong (there is > always something wrong) and doing a new version, or are we taking our time > with the core models? > > > > Thanks, > > Camilo > > > > *From: *Inventory-yang on behalf of > Daniele Ceccarelli > *Date: *Friday, 15 September 2023 at 03:45 > *To: *"maqiufang (A)" > *Cc: *"inventory-y...@ietf.org" , " > ivy-cha...@ietf.org" , opsawg , " > cc...@ietf.org" > *Subject: *Re: [Inventory-yang] [CCAMP] [inventory-yang] poll for network > inventory base model > > > > Hi working group, > > > > Thanks a lot for all the useful comments on the different drafts. > > There seems to be a split of preferences between option 1 and option 3. > Given that the interinm meeting is soon (next week), we suggest to use it > to further discuss suggestions and concerns from the working group and > defer the decision by 1 week (Sep 22nd) immediately after the interim > meeting. > > > > In order to have a fruitful discussion at the interim meeting please > consider the following inputs: > > > >- Italo made a very good proposal on the split between HW only and >HW+SW use cases. Is this something we want to pursue? Do you think it makes >sense to start focusing on e.g. HW and then add SW on top of it? >- When asking to adopt one draft or the other we were asking (as per >IETF process) which you consider to be a good starting point for the >working group to work on, not something that is ready for publication. This >means that whatever draft we decide to adopt, we can significantly update >it to properly cover all the different aspects of invently. With this >regard Alex did a very good analysis in his mail. Maybe we don't need to >make an hard choice between the draft but take the best of each. For >example: we can take 30% of one draft and 20% of the other and build a new >one as per option 3, if on the other side we decide to take 80% from one >draft, then it makes more sense to start from it and build on top of that. >- Another good point touched by Alex is the "equipment-room". We are >supposed to cover also sites and location of the inventory. Are these >things connected? it seems so. If the WG prefers not to address this in the >core model and add it on top, that fine, otherwise we would suggest to have >sites and location added (whetehr in che core model or added on top can be >discussed). > > Again we have a good proposal from Alex on the way forward, which is: > > > > "For example, one could start with > draft-ietf-ccamp-network-inventory-yang, modifying it to remove the > network-hardware-inventory container and splitting the remaining module in > two (for equipment-room and network-elements, both of which will now be > top-level containers). Remaining modifications can be made from there. I > guess this makes me a proponent of option 3, but with the caveat that this > would not need to restart from scratch - really an option 4 that says merge > (for overall structure and common parts, which in this case is possible) > and split the remaining difference." > > We don't really care whether this is called option 1, 3 or 4 but seems to > be the most meaningful one...which is: use ccamp draft as a starting point, > implementing the modifications suggested by Alex and then incorporate the > material from the opsawg draft. > > > > Given this deferral of the polling decision, if anyone else wants to ask > for a 10 mins slot at the interim, please do so now. We will put together > the agenda on Monday. > > > > Thanks you everyone > > Daniele & Qiufang > > > > > > On Mon, Aug 28, 2023 at 8:22 AM maqiufang (A) 40huawei@dmarc.ietf.org> wrote: > > Hi Working Group, > > > > It’s now time to start considering how to move forward with the inventory > base model. We have two different documents that could be used as a > starting point for our work or, in case the working group believes none of > them is “good enough”, we can start a brand new ID. > > In case the latter option is chosen, Daniele and I will write a -00 > version including just the table of content and what we’d like to be > covered in each section. The
Re: [OPSAWG] [Inventory-yang] [CCAMP] [inventory-yang] poll for network inventory base model
Hello group, Daniele, thanks for the previous summary. Option 4 is a good compromise to explore first. One question for chairs (maybe even AD): are we aiming at standardising a base model quickly and then accepting that something was wrong (there is always something wrong) and doing a new version, or are we taking our time with the core models? Thanks, Camilo From: Inventory-yang on behalf of Daniele Ceccarelli Date: Friday, 15 September 2023 at 03:45 To: "maqiufang (A)" Cc: "inventory-y...@ietf.org" , "ivy-cha...@ietf.org" , opsawg , "cc...@ietf.org" Subject: Re: [Inventory-yang] [CCAMP] [inventory-yang] poll for network inventory base model Hi working group, Thanks a lot for all the useful comments on the different drafts. There seems to be a split of preferences between option 1 and option 3. Given that the interinm meeting is soon (next week), we suggest to use it to further discuss suggestions and concerns from the working group and defer the decision by 1 week (Sep 22nd) immediately after the interim meeting. In order to have a fruitful discussion at the interim meeting please consider the following inputs: Italo made a very good proposal on the split between HW only and HW+SW use cases. Is this something we want to pursue? Do you think it makes sense to start focusing on e.g. HW and then add SW on top of it? When asking to adopt one draft or the other we were asking (as per IETF process) which you consider to be a good starting point for the working group to work on, not something that is ready for publication. This means that whatever draft we decide to adopt, we can significantly update it to properly cover all the different aspects of invently. With this regard Alex did a very good analysis in his mail. Maybe we don't need to make an hard choice between the draft but take the best of each. For example: we can take 30% of one draft and 20% of the other and build a new one as per option 3, if on the other side we decide to take 80% from one draft, then it makes more sense to start from it and build on top of that. Another good point touched by Alex is the "equipment-room". We are supposed to cover also sites and location of the inventory. Are these things connected? it seems so. If the WG prefers not to address this in the core model and add it on top, that fine, otherwise we would suggest to have sites and location added (whetehr in che core model or added on top can be discussed). Again we have a good proposal from Alex on the way forward, which is: "For example, one could start with draft-ietf-ccamp-network-inventory-yang, modifying it to remove the network-hardware-inventory container and splitting the remaining module in two (for equipment-room and network-elements, both of which will now be top-level containers). Remaining modifications can be made from there. I guess this makes me a proponent of option 3, but with the caveat that this would not need to restart from scratch - really an option 4 that says merge (for overall structure and common parts, which in this case is possible) and split the remaining difference." We don't really care whether this is called option 1, 3 or 4 but seems to be the most meaningful one...which is: use ccamp draft as a starting point, implementing the modifications suggested by Alex and then incorporate the material from the opsawg draft. Given this deferral of the polling decision, if anyone else wants to ask for a 10 mins slot at the interim, please do so now. We will put together the agenda on Monday. Thanks you everyone Daniele & Qiufang On Mon, Aug 28, 2023 at 8:22 AM maqiufang (A) wrote: Hi Working Group, It’s now time to start considering how to move forward with the inventory base model. We have two different documents that could be used as a starting point for our work or, in case the working group believes none of them is “good enough”, we can start a brand new ID. In case the latter option is chosen, Daniele and I will write a -00 version including just the table of content and what we’d like to be covered in each section. The document will then be handed over to a pool of authors which will bring it till the WG adoption. Hence, we will have a 3 weeks polling starting today. We decided to make it a bit longer than usual because this time the working group is requested to review two drafts instead of one. This mail starts a 3 weeks polling, terminating on September 15th, where we would like the working group to express your preference among: Adopt draft-ietf-ccamp-network-inventory-yang-02 in IVY and evolve it to become the network inventory base model Adopt draft-wzwb-opsawg-network-inventory-management-03 in IVY and evolve it to become the network inventory base model Start a brand new document from scratch as described above In the week after the closure of the polling (between September 18 and 25) we will have
Re: [OPSAWG] [Inventory-yang] [CCAMP] [inventory-yang] poll for network inventory base model
Daniele & Qiufang, I would like to request a slot to discuss the technical issues that need to be addressed to evolve draft-ietf-ccamp-network-inventory-yang-02 to become the network inventory base model, including how the overall network inventory model can be modularized If there is enough available time on the agenda, I would prefer to take a 20 min slot, otherwise I can live with the 10min slot duration Thanks, Italo From: Inventory-yang On Behalf Of Daniele Ceccarelli Sent: venerdì 15 settembre 2023 10:45 To: maqiufang (A) Cc: inventory-y...@ietf.org; ivy-cha...@ietf.org; opsawg ; cc...@ietf.org Subject: Re: [Inventory-yang] [CCAMP] [inventory-yang] poll for network inventory base model Hi working group, Thanks a lot for all the useful comments on the different drafts. There seems to be a split of preferences between option 1 and option 3. Given that the interinm meeting is soon (next week), we suggest to use it to further discuss suggestions and concerns from the working group and defer the decision by 1 week (Sep 22nd) immediately after the interim meeting. In order to have a fruitful discussion at the interim meeting please consider the following inputs: * Italo made a very good proposal on the split between HW only and HW+SW use cases. Is this something we want to pursue? Do you think it makes sense to start focusing on e.g. HW and then add SW on top of it? * When asking to adopt one draft or the other we were asking (as per IETF process) which you consider to be a good starting point for the working group to work on, not something that is ready for publication. This means that whatever draft we decide to adopt, we can significantly update it to properly cover all the different aspects of invently. With this regard Alex did a very good analysis in his mail. Maybe we don't need to make an hard choice between the draft but take the best of each. For example: we can take 30% of one draft and 20% of the other and build a new one as per option 3, if on the other side we decide to take 80% from one draft, then it makes more sense to start from it and build on top of that. * Another good point touched by Alex is the "equipment-room". We are supposed to cover also sites and location of the inventory. Are these things connected? it seems so. If the WG prefers not to address this in the core model and add it on top, that fine, otherwise we would suggest to have sites and location added (whetehr in che core model or added on top can be discussed). Again we have a good proposal from Alex on the way forward, which is: "For example, one could start with draft-ietf-ccamp-network-inventory-yang, modifying it to remove the network-hardware-inventory container and splitting the remaining module in two (for equipment-room and network-elements, both of which will now be top-level containers). Remaining modifications can be made from there. I guess this makes me a proponent of option 3, but with the caveat that this would not need to restart from scratch - really an option 4 that says merge (for overall structure and common parts, which in this case is possible) and split the remaining difference." We don't really care whether this is called option 1, 3 or 4 but seems to be the most meaningful one...which is: use ccamp draft as a starting point, implementing the modifications suggested by Alex and then incorporate the material from the opsawg draft. Given this deferral of the polling decision, if anyone else wants to ask for a 10 mins slot at the interim, please do so now. We will put together the agenda on Monday. Thanks you everyone Daniele & Qiufang On Mon, Aug 28, 2023 at 8:22 AM maqiufang (A) mailto:40huawei@dmarc.ietf.org>> wrote: Hi Working Group, It’s now time to start considering how to move forward with the inventory base model. We have two different documents that could be used as a starting point for our work or, in case the working group believes none of them is “good enough”, we can start a brand new ID. In case the latter option is chosen, Daniele and I will write a -00 version including just the table of content and what we’d like to be covered in each section. The document will then be handed over to a pool of authors which will bring it till the WG adoption. Hence, we will have a 3 weeks polling starting today. We decided to make it a bit longer than usual because this time the working group is requested to review two drafts instead of one. This mail starts a 3 weeks polling, terminating on September 15th, where we would like the working group to express your preference among: 1. Adopt draft-ietf-ccamp-network-inventory-yang-02 in IVY and evolve it to become the network inventory base model 2. Adopt draft-wzwb-opsawg-network-inventory-management-03 in IVY and evolve it to become the network inventory base model 3. Start a brand new document from scratch as described above In the week after the
Re: [OPSAWG] [Inventory-yang] [CCAMP] [inventory-yang] poll for network inventory base model
Hi chairs/WG As I didn’t answer the initial survey yet, I thought I was still on time. I take the opportunity to base my answer on your analysis. My preference is for the below option4, based more on the “simplicity and focus”, with the starting approach of draft-ietf-ccamp-network-inventory-yang , and as suggested, to extend and build on top of the initial HW use cases. Regarding your second point, I would like to reiterate on the approach as part of the example shown in draft-palmero-opsawg-dmlmo, on the import exercise (referred to in the appendix). We demonstrate how to extend the concept of “asset”, considering attributes that might not be initially considered in initial model, as they could be easily adopted and extended. I vote for the so called option 4, as suggested below. Many thanks, Marisol Palmero From: Inventory-yang on behalf of Daniele Ceccarelli Date: Friday, 15 September 2023 at 10:45 To: maqiufang (A) Cc: inventory-y...@ietf.org , ivy-cha...@ietf.org , opsawg , cc...@ietf.org Subject: Re: [Inventory-yang] [CCAMP] [inventory-yang] poll for network inventory base model Hi working group, Thanks a lot for all the useful comments on the different drafts. There seems to be a split of preferences between option 1 and option 3. Given that the interinm meeting is soon (next week), we suggest to use it to further discuss suggestions and concerns from the working group and defer the decision by 1 week (Sep 22nd) immediately after the interim meeting. In order to have a fruitful discussion at the interim meeting please consider the following inputs: * Italo made a very good proposal on the split between HW only and HW+SW use cases. Is this something we want to pursue? Do you think it makes sense to start focusing on e.g. HW and then add SW on top of it? * When asking to adopt one draft or the other we were asking (as per IETF process) which you consider to be a good starting point for the working group to work on, not something that is ready for publication. This means that whatever draft we decide to adopt, we can significantly update it to properly cover all the different aspects of invently. With this regard Alex did a very good analysis in his mail. Maybe we don't need to make an hard choice between the draft but take the best of each. For example: we can take 30% of one draft and 20% of the other and build a new one as per option 3, if on the other side we decide to take 80% from one draft, then it makes more sense to start from it and build on top of that. * Another good point touched by Alex is the "equipment-room". We are supposed to cover also sites and location of the inventory. Are these things connected? it seems so. If the WG prefers not to address this in the core model and add it on top, that fine, otherwise we would suggest to have sites and location added (whetehr in che core model or added on top can be discussed). Again we have a good proposal from Alex on the way forward, which is: "For example, one could start with draft-ietf-ccamp-network-inventory-yang, modifying it to remove the network-hardware-inventory container and splitting the remaining module in two (for equipment-room and network-elements, both of which will now be top-level containers). Remaining modifications can be made from there. I guess this makes me a proponent of option 3, but with the caveat that this would not need to restart from scratch - really an option 4 that says merge (for overall structure and common parts, which in this case is possible) and split the remaining difference." We don't really care whether this is called option 1, 3 or 4 but seems to be the most meaningful one...which is: use ccamp draft as a starting point, implementing the modifications suggested by Alex and then incorporate the material from the opsawg draft. Given this deferral of the polling decision, if anyone else wants to ask for a 10 mins slot at the interim, please do so now. We will put together the agenda on Monday. Thanks you everyone Daniele & Qiufang On Mon, Aug 28, 2023 at 8:22 AM maqiufang (A) mailto:40huawei@dmarc.ietf.org>> wrote: Hi Working Group, It’s now time to start considering how to move forward with the inventory base model. We have two different documents that could be used as a starting point for our work or, in case the working group believes none of them is “good enough”, we can start a brand new ID. In case the latter option is chosen, Daniele and I will write a -00 version including just the table of content and what we’d like to be covered in each section. The document will then be handed over to a pool of authors which will bring it till the WG adoption. Hence, we will have a 3 weeks polling starting today. We decided to make it a bit longer than usual because this time the working group is requested to review two drafts instead of one. This mail starts a 3 weeks polling, terminating on September 15th, where
Re: [OPSAWG] [CCAMP] [inventory-yang] poll for network inventory base model
Hi working group, Thanks a lot for all the useful comments on the different drafts. There seems to be a split of preferences between option 1 and option 3. Given that the interinm meeting is soon (next week), we suggest to use it to further discuss suggestions and concerns from the working group and defer the decision by 1 week (Sep 22nd) immediately after the interim meeting. In order to have a fruitful discussion at the interim meeting please consider the following inputs: - Italo made a very good proposal on the split between HW only and HW+SW use cases. Is this something we want to pursue? Do you think it makes sense to start focusing on e.g. HW and then add SW on top of it? - When asking to adopt one draft or the other we were asking (as per IETF process) which you consider to be a good starting point for the working group to work on, not something that is ready for publication. This means that whatever draft we decide to adopt, we can significantly update it to properly cover all the different aspects of invently. With this regard Alex did a very good analysis in his mail. Maybe we don't need to make an hard choice between the draft but take the best of each. For example: we can take 30% of one draft and 20% of the other and build a new one as per option 3, if on the other side we decide to take 80% from one draft, then it makes more sense to start from it and build on top of that. - Another good point touched by Alex is the "equipment-room". We are supposed to cover also sites and location of the inventory. Are these things connected? it seems so. If the WG prefers not to address this in the core model and add it on top, that fine, otherwise we would suggest to have sites and location added (whetehr in che core model or added on top can be discussed). Again we have a good proposal from Alex on the way forward, which is: "For example, one could start with draft-ietf-ccamp-network-inventory-yang, modifying it to remove the network-hardware-inventory container and splitting the remaining module in two (for equipment-room and network-elements, both of which will now be top-level containers). Remaining modifications can be made from there. I guess this makes me a proponent of option 3, but with the caveat that this would not need to restart from scratch - really an option 4 that says merge (for overall structure and common parts, which in this case is possible) and split the remaining difference." We don't really care whether this is called option 1, 3 or 4 but seems to be the most meaningful one...which is: use ccamp draft as a starting point, implementing the modifications suggested by Alex and then incorporate the material from the opsawg draft. Given this deferral of the polling decision, if anyone else wants to ask for a 10 mins slot at the interim, please do so now. We will put together the agenda on Monday. Thanks you everyone Daniele & Qiufang On Mon, Aug 28, 2023 at 8:22 AM maqiufang (A) wrote: > Hi Working Group, > > > > It’s now time to start considering how to move forward with the inventory > base model. We have two different documents that could be used as a > starting point for our work or, in case the working group believes none of > them is “good enough”, we can start a brand new ID. > > In case the latter option is chosen, Daniele and I will write a -00 > version including just the table of content and what we’d like to be > covered in each section. The document will then be handed over to a pool of > authors which will bring it till the WG adoption. > > > > Hence, we will have a 3 weeks polling starting today. We decided to make > it a bit longer than usual because this time the working group is requested > to review two drafts instead of one. > > > > This mail starts a 3 weeks polling, terminating on September 15th, where > we would like the working group to express your preference among: > > > >1. Adopt draft-ietf-ccamp-network-inventory-yang-02 in IVY and evolve >it to become the network inventory base model >2. Adopt draft-wzwb-opsawg-network-inventory-management-03 in IVY and >evolve it to become the network inventory base model >3. Start a brand new document from scratch as described above > > > > In the week after the closure of the polling (between September 18 and 25) > we will have an IVY interim meeting to discuss the issues/concerns raised > during the polling ( A separate mail will be sent). > > > > Thank you, > > > > Qiufang and Daniele > > > ___ > CCAMP mailing list > cc...@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
