Open Issue prioritization

[italobusi]

From the IVY WG discussion at IETF 120, there was some push to move the work a bit faster, considering some use cases in a future update:

https://datatracker.ietf.org/doc/minutes-120-ivy-202407241630/

In order to try to move forward a bit faster, it has been proposed to review and prioritize the current list of open issues:

• P1: must be addressed before WG LC of the base model
• P2: preferred to be addressed before WG LC of the base model but can be postponed in case of timing issues
• P3: can be addressed in the context of an augmentation model (which can be developed in parallel) or RFC-bis of the base model

[italobusi]

2024-09-11 Base Network Inventory weekly call

From the IVY WG discussion at IETF 120, there was some push to move the work a bit faster, considering some use cases in a future update:

https://datatracker.ietf.org/doc/minutes-120-ivy-202407241630/

In order to try to move forward a bit faster, it has been proposed to review and prioritize the current list of open issues:

• P1: must be addressed before WG LC of the base model
• P2: preferred to be addressed before WG LC of the base model but can be postponed in case of timing issues
• P3: can be addressed in the context of an augmentation model (which can be developed in parallel) or RFC-bis of the base model

The table below reports the result of the analysis done during the call:

Number	Title	Priority	Comment
#32	Modelling of fibers and cables	P3	Current assumption is that this should be outside the scope of the base model
#35	Unclear boundary for Ivy work	P1	To clarify which part of the issue applies to the I-D and which part applies to the IVY WG charter
#36		P2	These attributes can be removed from the first RFC and added in a -bis version of the RFC (BC change)
#37		P1	YANG code should be clean before WG LC
#40	Hardware and Firmare revisions for NE	P2	These attributes can be removed from the first RFC and added in a -bis version of the RFC (BC change)
#41	SW upgrades	N/A	To be moved to the SW inventory model after it becomes a WG document
#42	Missing component location attribute	P2	This attribute can be added in a -bis version of the RFC (BC change)
#44	Does it make sense to have an operating system name (or software name) at device level?	P2	These attributes can be removed from the first RFC and added in a -bis version of the RFC (BC change)
#45	Modeling of Port and Transceiver	P1
#46	How to add Passive Inventory?	P3	Definitely in the scope of IVY, not clear whether in the scope of the base inventory or augmentation model
#56	virtual NE vs. LNE (RFC8530)	P1	At least keep the terminology open to future extensions, the best option would be to decouple this definition from the base model
#57	Align with rfc8348	P1
#58	Warning with yanglint compilation	P1

• [x] @italobusi : propose priorities for the other open issues as an input for discussion in the next weekly call

[italobusi]

[x] @italobusi : propose priorities for the other open issues as an input for discussion in the next weekly call

Number	Title	Priority	Comment
#2	Attributes from RFC7317	P2	They can be added in a -bis version of the RFC (BC change)
#3	Child and parent component navigation	P1	It is a mandatory requirement to be supported from the first version of the model
#7	Initial text for Security Considerations	P1	Security considerations should be completed before WG LC
#8	Write operations	P3	Change from RO to RW is a BC change
#9	WG adoption comments from Med	P1 & P2	The first two comments are P1, the last is P2
#10	WG adoption comments from Qiufang	P1	It is related to the need to clarify the scope of the I-D
#11	Missing attributes from RFC8348	P2	These attributes can be removed from the first RFC and added in a -bis version of the RFC (BC change)
#12	Management of MPO ports	P1	It is a mandatory requirement to be supported by the first version of the model
#13	Clarify RFC8348 container terminology	P1	Terminology clarification
#14	Configuration Capability of Inventory Data Model	P3	Related with the support of write operations (see #8)
#16	Terminology and use cases clarification	P1
#17	Add timestamp to know when a component information was retrived	P3	Optional feature which requires further clarifications
#19	Model port breakouts	P1	Duplicated with #12?
#21	Relationship between network element and chassis	P1	It impacts some of the key definitions in the model
#22	Management of planned and removed components	P3	Related with the support of write operations (see #8)
#23	Use of term "network" is confusing	P1	It is part of terminology and scope clarification
#24	Blurring physical and functional boundary	P1	Impacts the whole inventory modelling approach
#25	Clarification of Scope	P1
#26	Specific properties	P3	Additional attributes to be reviewed
#27	Modelling software	P1	It is mainly about the need clarify the minimum set of SW inventory requirements being covered by the base model
#28	Expectation/Intention and Actual	P3	Related with the support of write operations (see #8)
#29	General considerations	P1 & P3	Some considerations are relevant for the scope of this I-D, others may be more in the scope of other I-Ds defining augmentation models
#30	Proposal for peer-mount	P1	Can we close this issue since we are following a different approach? We cannot expect the peer-mount work to be completed in time for the base network inventory model
#61	Hackathon at IETF 121	N/A	Outside the scope of the I-D
#62	Open Issue prioritization	P1

• [ ] @all: review and provide feedbacks before or at the next IVY WG weekly call

[italobusi]

2024-09-18 Base Network Inventory weekly call

The table has been reviewed and agreed as follows:

Number	Title	Priority	Comment
#2	Attributes from RFC7317	P2	They can be added in a -bis version of the RFC (BC change)
#3	Child and parent component navigation	P1	It is a mandatory requirement to be supported from the first version of the model
#7	Initial text for Security Considerations	P1	Security considerations should be completed before WG LC
#8	Write operations	P3	Change from RO to RW is a BC change
#9	WG adoption comments from Med	P1 & P2	The first two comments are P1, the last is P2
#10	WG adoption comments from Qiufang	P1	It is related to the need to clarify the scope of the I-D
#11	Missing attributes from RFC8348	P2	These attributes can be removed from the first RFC and added in a -bis version of the RFC (BC change)
#12	Management of MPO ports	P1	It is a mandatory requirement to be supported by the first version of the model
#13	Clarify RFC8348 container terminology	P1	Terminology clarification
#14	Configuration Capability of Inventory Data Model	P3	Related with the support of write operations (see #8)
#16	Terminology and use cases clarification	P1
#17	Add timestamp to know when a component information was retrieved	P3	Optional feature which requires further clarifications
#19	Model port breakouts	P1	Duplicated with #12?
#21	Relationship between network element and chassis	P1	It impacts some of the key definitions in the model
#22	Management of planned and removed components	P3	Related with the support of write operations (see #8)
#23	Use of term "network" is confusing	P1	It is part of terminology and scope clarification
#24	Blurring physical and functional boundary	P1	Impacts the whole inventory modelling approach
#25	Clarification of Scope	P1
#26	Specific properties	P3	Additional attributes to be reviewed
#27	Modelling software	P1	It is mainly about the need clarify the minimum set of SW inventory requirements being covered by the base model
#28	Expectation/Intention and Actual	P3	Related with the support of write operations (see #8)
#29	General considerations	P1 & P3	Some considerations are relevant for the scope of this I-D, others may be more in the scope of other I-Ds defining augmentation models
#30	Proposal for peer-mount	P1	To be closed to confirm the approach currently being followed in the draft
#32	Modelling of fibers and cables	P3	Current assumption is that this should be outside the scope of the base model
#35	Unclear boundary for Ivy work	P1	To clarify which part of the issue applies to the I-D and which part applies to the IVY WG charter
#36	Add "asset-id" attribute to the NE	P2	These attributes can be removed from the first RFC and added in a -bis version of the RFC (BC change)
#37	Clean-up YANG groupings	P1	YANG code should be clean before WG LC
#40	Hardware and Firmware revisions for NE	P2	These attributes can be removed from the first RFC and added in a -bis version of the RFC (BC change)
#41	SW upgrades	N/A	To be moved to the SW inventory model after it becomes a WG document
#42	Missing component location attribute	P2	This attribute can be added in a -bis version of the RFC (BC change)
#44	Does it make sense to have an operating system name (or software name) at device level?	P2	These attributes can be removed from the first RFC and added in a -bis version of the RFC (BC change)
#45	Modeling of Port and Transceiver	P1
#46	How to add Passive Inventory?	P3	Definitely in the scope of IVY, not clear whether in the scope of the base inventory or augmentation model
#56	virtual NE vs. LNE (RFC8530)	P1	At least keep the terminology open to future extensions, the best option would be to decouple this definition from the base model
#57	Align with rfc8348	P1
#58	Warning with yanglint compilation	P1
#61	Hackathon at IETF 121	N/A	Outside the scope of the I-D
#62	Open Issue prioritization	P1
#64	How would this work with a rfc8348 stack?	P1

Legenda:

• P1: must be addressed before WG LC of the base model

• P2: preferred to be addressed before WG LC of the base model but can be postponed in case of timing issues

• P3: can be addressed in the context of an augmentation model (which can be developed in parallel) or RFC-bis of the base model

• [x] @italobusi : add some label to the github open issues to track their relative priorities