Source	Class	Status	Comment	Proposed Resolution	JIRA Task
Michela Bevilacqua Jacqueline Beaulac [Ericsson]	n/a	Not a Licence model issue, added comment (03/05)	Introduce in ONAP wiki an update list of approved classes with reference links to detailed description (a page per Release of some part of clean IM is not a long term viable way). Michela Bevilacqua (2020/02/20): why it is required: we need a way to identify classes already approved when an approval request is sent. Some additional comments about current model documentation in Readthedocs to address for improvements: Readthedocs today is prepared only at the end of the release for documentation purpose. We need a wiki page available during the life of a release to check what is approved or not. It is difficult for a developer to understand which classes are approved and ready to use and which one are not ready yet. We should include in readthedocs an explanation of the concept of experimental vs prelimanry. We should focus on the preliminary classes and not on the experimental ones. If we want to document both, we should document them separately. Relationships are not documented in readthedocs but only the classes. The absence of any diagram decreases the readability and understandability.	No direct impact on License Model. Xu Yang Action to be progressed: This should be addressed to the modeling subcommittee as a whole. Modeling RTD Link: this is the modeling readthedocs for el alto release	Michela Bevilacqua(2020/03/05) : I would suggest to open anyhow a Jira ticket to trace the activity. It can be assigned to Jacqueline that is providing a first attempt for discussion MODELING-337 - Getting issue details... STATUS
Michela Bevilacqua Jacqueline Beaulac [Ericsson]	all	Agreed	Introduce in any model proposal, the inheritance tree diagram for any new class (e.g. what is the Licensing agreement inheritance tree ?)	Yes. Andy Mayer (2020/02/17) Action to be progressed: Will include inheritance tree diagram.	ONAPMODEL-13 - Getting issue details... STATUS Michela Bevilacqua Jacqueline Beaulac [Ericsson]2020/03/30: Good. Minor comment, let´s discuss the use of the color in the diagram for the future. ACTION: Change color of Business Interaction too.
Michela Bevilacqua Jacqueline Beaulac [Ericsson]	n/a	Reviewed, added comment (03/05)	#1 Is the current model proposal “as built model” going to cover the licensing model only for VNF considering it refers only to VNFD ?	The scope of the "as built" model is presently VNF and VNFD, but nothing prevents it from being expanded in the future. No further action Michela Bevilacqua (2020/03/05). I would suggest for documentation purpose, to add a label in the diagram (i.e. main diagram as shown in section 2.1.1, License Management (Moved to Clean)#2.1Overview, about this decision to explain to any users also in future why we have decided these relationships)	Open JIRA to add note to diagram.
Michela Bevilacqua Jacqueline Beaulac [Ericsson]	n/a	Reviewed	#3 License keys, license agreements, and contractual details such as entitlement information, are all sensitive commercial information. ONAP has one single inventory database (AAI) accessible to all components in the system. It’s not clear that this sensitive information is well-protected in this kind of shared database deployment.	Presently much of this information is collected in SDC, and then distributed to other appropriate systems. Remember – this is “as built” information model. Security of the systems and related network is the responsibility of the service provider. Also details of the actual licenses and entitlements are held in an asset management system (e.g., license repository) outside the present scope of ONAP. No further action
Michela Bevilacqua Jacqueline Beaulac [Ericsson]	EntitlementInstance LicenseKeyInstance	Agreed	#8 Entitlement instance / LicenseKeyInstance classes refer to “As Built in ASDC”. Are (entitlement/LK) instance classes defined in ASDC considering it is derived from the “operationalEntity” class ? How entitlement instances are introduced in SDC ? SDC UI documentation refers to the EntitlementPool and LKPool but NOT to the EntitlementInstance and LK instance. How Entitlement instances and License key instances should be used in SDC ? In https://lf-onap.atlassian.net/wiki/display/DW/SDC+Deployment+Artifacts, it is defined the vendor license artifact as xml file including entitlement pool and license key group (attributes here are simplified respect to the VLM proposed). In this file only entitlement pool and license pool seems to be defined and it seems that instances are not available.	LicenseKeyPool and EntitlementPool are generated in SDC. LicenseKeyInstance and EntitlementInstance are not – they are in the operator’s license/asset repository. Reference to this repository is in A&AI. Make the LicenseKeyInstance and EntitlementInstance classes experimental, make the attributes experimental, and remove the reference stereotype. Andy Mayer (2020/02/17) Action to be progressed: AI: Will provide further review for the attributes of LicenseKeyInstance and EntitlementInstance. If further clarification cannot be provided, attributes will be removed. Michela Bevilacqua (2020/02/20): I suggest we clarify in the definition of these classes or in a note associated to them, they are experimental (today) as not used and stored by ONAP platform. Andy Mayer (2020/02/17) Note: AAI represents Unique ID of a license resource for generic-vnf and vce, Just the UUID, relationship to license-group, and version are represented. ACTION: Ensure that the LicenseKeyInstance and EntitlementInstance remain experimental after approval. Add a note to the descriptions of each class stating that these classes are not currently used and stored by the ONAP platform	ONAPMODEL-14 - Getting issue details... STATUS Michela Bevilacqua Jacqueline Beaulac [Ericsson]2020/03/30: LicenseKeyInstance and EntitlementInstance now removed from the proposal, ok Check: Make the LicenseKeyInstance and EntitlementInstance classes experimental, make the attributes experimental, and remove the reference stereotype. Add a note to the descriptions of each class stating that these classes are not currently used and stored by the ONAP platform Jacqueline Beaulac [Ericsson] 2020-04-16: Descriptions now OK, but "Reference" stereotype still needs to be removed in Papyrus.
Michela Bevilacqua Jacqueline Beaulac [Ericsson]	All	Agreed	#2 Mainly all the class definition in this proposal refer to the concept of software/software product more than network functions but software/sw product is not defined in ONAP model. What is the meaning of software in this context ? What is the relation between software and resource or VNF?	A fair observation. The Vnf is software, and is the product of some vendor that is then being incorporated into an operator’s resource. Definitions should be updated and generalized - this is the original documentation. One option is to generalize when a Pnf or some other non-software resource is added. In addition, we can update “softwareAssetTag” to something like “licenseAssetTag”. Michela Bevilacqua (2020/02/20): the comment is not only about the attribute softwareAssetTag but more about the fact that software is widely used in any class description. There are 38 software instances today in the wiki page. We need to clarify the relation of sotfware vs vnf instance and vnfd. For instance, does software map unique with a vnf instance? Action: update "software" to "VNF Descriptor" throughout License IM	ONAPMODEL-15 - Getting issue details... STATUS Michela Bevilacqua Jacqueline Beaulac [Ericsson]2020/03/30: "software" now removed from the proposal, but replaced with VNF (meaning VNF instance) rather than VNFD (meaning VNF type). ACTON: change VNF to "VNF Instance" in License Agreement: requirementsAndConstaints and PoolLimit: limitMetricType
Michela Bevilacqua Jacqueline Beaulac [Ericsson]	EntitlementPool	Agreed	#13 Entitlement Pool definition is partially duplicated, to be reviewed. In addition, it states “Controllers will request entitlements.” This is not a “as built in” behavior, it should be removed.	The duplicate statement was removed. Text was updated to say “Controllers may request entitlements”. Michela Bevilacqua (2020/02/20): Some sentences to be further reviewed: "Controllers will request license keys from Asset Inventory using the UUID of the group, as directed by the ASDC models for the software (i.e. VFs)." "In addition, it states “Controllers will request entitlements.” This is not a “as built in” behavior, it should be removed." A number of class definitions are based on the "Asset Inventory" component that is clearly outside of ONAP architecture. Are these relevant definitions ? i.e. should we agree from an architecture prospective the existance of an Asset Inventory component outside ONAP (and maybe also an ONAP interface with it?) ?Andy Mayer Check to see of Controller - Asset Inventory interface is described within ONAP. If not, remove these descriptions. Action: remove the "Controller will..." and "Controller may..." statements from EntitlementPool and LicenseKeyPool classes.	ONAPMODEL-16 - Getting issue details... STATUS Michela Bevilacqua Jacqueline Beaulac [Ericsson]2020/03/30: Entitlement Pool definition need to be cleaned up. There are sentences repeated and some inconsistencies. We reccomend to remove the notes as attributes definition in the table is enough. ACTION: tighten up definition. Consider removing attribute specific notes.
Michela Bevilacqua Jacqueline Beaulac [Ericsson]	LicenseKeyPool	Agreed	#16 The description of LicenceKeyPool refers to “Asset Inventory”, which is not part of ONAP and not described anywhere in the proposal	The Asset Inventory is presently outside of ONAP just as you say. This is the inventory where actual keys and entitlements would be stored and managed. Michela Bevilacqua (2020/02/20): see point 2 in comment #13 Andy Mayer Check to see of Controller - Asset Inventory interface is described within ONAP. If not, remove these descriptions. Action: Update LicenseKeyPool Description to remove "Asset Inventory"	ONAPMODEL-17 - Getting issue details... STATUS Michela Bevilacqua Jacqueline Beaulac [Ericsson]2020/03/30: Description of LicenseKeyPool is still referring to parts outside of ONAP. This paragraph: "The license key group model provides a description to interested systems for the license keys that are provided by a vendor. These system may then create a "group" and purchasing systems will send the inventory of license keys/files to be held by them in the appropriate group." ACTION: First sentence is good, the rest is outside of ONAP. Remove "These system may then create a "group" and purchasing systems will send the inventory of license keys/files to be held by them in the appropriate group." Also change License Key Group to License Key Pool
Michela Bevilacqua Jacqueline Beaulac [Ericsson]	All	Reviewed, added comment (03/05)	"General" #2 Mainly all class relationships are defined only in the diagram by the relationship name and their cardinality. Today a class definition does not include any relationship definition. We recommend to introduce the relationship definition in the class model.	A fair observation. The Vnf is software, and is the product of some vendor that is then being incorporated into an operator’s resource. Definitions should be updated and generalized - this is the original documentation. One option is to generalize when a Pnf or some other non-software resource is added. In addition, we can update “softwareAssetTag” to something like “licenseAssetTag”. Michela Bevilacqua (2020/02/20): the problem is not specific to software, so I do not understand the proposed resolution/the proposed resolution is not applicable. The problem is more that we need to define and document the relationships between the classes. An arrow with a relationship name in a diagram is not clear enough. We recommend to introduce the relationship definiton in the class definition table. Xu Yang Action to be progressed: This should be addressed to the modeling subcommittee as a whole.	Michela Bevilacqua (2020/03/05) for the comprehension of the model is an important step. I reccomend to open a Jira ticket to be porgressed. MODELING-340 - Getting issue details... STATUS
Michela Bevilacqua Jacqueline Beaulac [Ericsson]	EntitlementPool LicenseKeyPool	Reviewed, added comment 03/05	#6 We do not have evidence of the full list of attributes defined in the ONAP as built in model in particular for EntitlementPool and LicenseKeyPool classes. Considering the attributes defined in SDC UI (https://wiki.onap.org/display/DW/Resource+Onboarding, only a subset of attributes should be defined in ONAP model. Can you provide some more clear reference about SDC model ? Otherwise, should we consider only the attributes defined in SDC UI for the as built in model. In addition, some attributes are repeated in EntitlementPool/LicenseKeyPool and PoolLimit as ThresholdValue and ThresholdUnit. SPPoolLimit and VendorPoolLimit in EntitlementPool/LicensekeyPool are not defined in SDC UI so they do not seem to be used.	Can provide screenshots of UIs as well as a view of the XML being distributed from SDC. XML from SDC can be found at - https://lf-onap.atlassian.net/wiki/display/DW/SDC+Deployment+Artifacts. No further action Michela Bevilacqua (2020/03/05): SDC artifacts referenced above and the SDC UI documentation (linked in the comment #6) do not provide evidence of the SP and Vendor Pool Limit in the EntitlementPool and LicensekeyPool but only of Threshold Value and Unit. So I suggest to remove them. There is no evidence of VendorPoolLimit provided by the vendor in ONAP.	Andy Mayer will investigate SPPoolLimit and VendorPoolLimit attributes Michela Bevilacqua Jacqueline Beaulac [Ericsson]2020/03/30: This action has not been progressed yet. UPDATE: these attributes have been removed in last update. Comment is addressed.
Michela Bevilacqua Jacqueline Beaulac [Ericsson]	LicenseAgreement	Reviewed	#11 LicenseAgreement class contains free-form text information in the attributes requirementsAndConstraints and statementOfIntent that is not usable in any automation UC and thus should instead be contained in an external document	A fair point, but that is what is built. One could parse that constraint, and if the creator and receiver have agreed on some common semantics, then it could certainly be used via automation. As built representation No further action
Michela Bevilacqua Jacqueline Beaulac [Ericsson]	DesignEntity	Agreed	#12 The “validFor” attribute in EntitlementPool and LicenseKeyPool (inherited from DesignEntity) is mandatory. It’s not obvious whether this validity value then applies to all instances in the pool. If so, it’s not possible to define licenses and entitlements that are valid for an unlimited amount of time, thus the attribute needs to be made optional.	This is analogous to a Vnfd and and VnfInstance, or a ProductSpec and a Product. One can certainly put in an enddate of something very far in the future, allowing for an unlimited amount of time. We could redefine the property and make it optional as well. Action: change validFor attribute in EntitlementPool and LicenseKeyPool (inherited from DesignEntity) to optional (0..1)	ONAPMODEL-18 - Getting issue details... STATUS Michela Bevilacqua Jacqueline Beaulac [Ericsson]2020/03/30: shouldn´t we update ValidFor multiplificity (0..1 instead of 1) of DesignEntity class instead of overwrite it in EntitlementPoll and LicenseKeyPool classes ? ACTION: will check to see if change impacts any other subclasses, if not then will change.
Michela Bevilacqua Jacqueline Beaulac [Ericsson]	EntitlementPool	Agreed	#14 Entitlement Pool class: entitlementManufactureReferenceNumber has a multiplicity 0..1 and it is defined as “identifier for the entitlement as described…”. Isn´t more a entitlementPool identifier more than the entitlement (instance) identifier ? For consistency with the ONAP IM classes, we should review the name of this attribute in entitlementPoolVendorReferenceNumber.	Not clear why this attribute is not required (updated from 0..1 to 1). Name aligns with the SDC screen, and it does state that it is a Manufacturer’s Reference Number. Updated description, using phrase reference number rather than identifier. ACTION: Entitlement Pool class: entitlementManufactureReferenceNumber change back to optional (0..1)	ONAPMODEL-19 - Getting issue details... STATUS Michela Bevilacqua Jacqueline Beaulac [Ericsson]2020/03/30: we just noticed that the same attribute ManufactureReferenceNumber is also part of the LicenseKeyPool class (as the two classes definition are quite similar). Shouldn´t we have same multiplicity also there for consistency? Also change licenseManufactureReferenceNumber to 0..1
Michela Bevilacqua Jacqueline Beaulac [Ericsson]	LicenseKeyInstance	Agreed, added comment (03/05)	#15 LicenseKey attribute (in LicenseKeyInstance) is defined twice, once as a String (with upper-case “k”) and once using the type “File” (with lower-case “k”). It’s not obvious how/if either of these attributes can be used in the case of a subscription-based license. The LicenseKey of type file is defined of type “future” so it should be removed as not Asbuilt in	The attribute with type of “File” was marked as Future to make it clear that this is not “as built”. It is an item presently under development, implementation under way but not yet complete in SDC. Suggestion was to keep this as future, it does highlight present activity. Updated name to licenseKeyFile to distinguish the attributes. Michela Bevilacqua (2020/02/20): The presence of these attributes is subordinated to the action agreed in the comment #8. However, as the purpose of this model is to document the as built SDC solution and File is today not supported, I suggest to remove it to be then added in the future. ACTION: keep stereotype as Experimental after approval. Michela Bevilacqua (2020/03/05): I do not understand main response above . We have seen that EntitlementInstance and LicenseKeyInstance are not managed in ONAP. so why there is a comment about an ongoing development in SDC ? I´m not comfortable to mantain a "future" attribute in the current model. I ask to remove this attribute as it is not part of the as built solution.	ONAPMODEL-14 - Getting issue details... STATUS Note: use only Lifecycle Stereotype Proposal
Michela Bevilacqua Jacqueline Beaulac [Ericsson]	EntitlementInstance	Agreed, added comment 03/05	#17 Entitlement instance class, SoftwareAssetTag: swAssetTag not defined in SDC UI. What is a softwareAssetTag ? What is the relation with the ONAP classes ?	Given EntitlementInstances are stored in the Asset Inventory references in question 16, it’s attributes, including swAssetTag would therefore not be found in SDC. Per the definition, this is a operator internally generated value. See response to question 8 Action to be progressed: AI: Will provide further review for the attributes. If further clarification cannot be provided, attributes will be removed. Andy Mayer SoftwareAssetTag could not be found in AAI swagger file. ACTION: Remove attribute SoftwareAssetTag from EntitlementInstance and LicenseKeyInstance classes Michela Bevilacqua 2020/03/05: EntitlementInstance and LicenseKeyInstance classes includes assignmentStatus attribute defined as String but it seems that only specific values are allowed even if not defined. Please define the list of values. In release readthedocs: should we filter or annotate Experiment modeling elements? Xu Yang	ONAPMODEL-20 - Getting issue details... STATUS JIRA to discuss treatment of Experimental modeling elements. MODELING-341 - Getting issue details... STATUS
Michela Bevilacqua Jacqueline Beaulac [Ericsson]	EntitlementInstance LicenseKeyInstance	Agreed	#18 EntitlementInstance and LicenseKeyInstance classes include the mandatory attribute ssmUserId. ssmUserID not defined in SDC UI. What is SSM? ssmUserId is defined as The requestor of the entitlement. What is the requestor ?	Still researching. Action to be progressed: AI: Will provide further review for the attributes . If further clarification cannot be provided, attributes will be removed. Andy Mayer SSM User ID not found in AAI swagger file ACTION: Remove attribute ssmUserId from EntitlementInstance and LicenseKeyInstance classes	ONAPMODEL-21 - Getting issue details... STATUS Michela Bevilacqua Jacqueline Beaulac [Ericsson] (2020/03/30) check: Remove attribute ssmUserId from EntitlementInstance and LicenseKeyInstance classes Jacqueline Beaulac [Ericsson] 2020-04-16: OK, attributes removed in Papyrus.
Michela Bevilacqua Jacqueline Beaulac [Ericsson]	Vendor	Agreed	#4 “Vendor” class in the top level diagram is not defined in this proposal. It was originally included in the R5 “Party” proposal which was never approved. Current modeling proposal depends on Vendor class due to the introduction of the relation with LicenseAgreement and the definition of an indirect relation through the vendor of the VNFD with the LicensingAgreement. We recommend we agree on the Vendor class scope before we approve a Licensing model. In addition, Vendor class introduces two new attributes: status and validFor attributes and we do not agree should be part of the Vendor class but differently modelled in the context of the LVM.	At the time the root hierarchy was developed, we agreed to leave the approval of the Party related concepts until it was needed – the license model was specifically mentioned at that time as a likely reason. That time is now. The Party model is well established and documented model. Refinement suggestions to the party/partyrole/vendor classes are welcome, but keep in mind these concepts are well established and mature. Therefore approval for this model includes approval for the concept of vendor and it’s super classes. Andy Mayer (2020/02/17): Action to be progressed: Will add description of Vendor Class (and superclasses) to the License model page proposal page. Reference the relevant classes from the Common:Party model. see: Party Michela Bevilacqua (2020/02/20): I assume that the change of scope of the current model review, (including now Party model), will require a new vote for approval. Andy Mayer (2020/02/27) We will import the Vendor class and relevant superclasses from the Common model to the wiki for approval.	ONAPMODEL-23 - Getting issue details... STATUS Michela Bevilacqua Jacqueline Beaulac [Ericsson]2020/03/30: PartyRole and Vendor classes have been added but, as anticipated, R5 Party proposal included a number of other classes not yet approved (e.g. Party). Party class is mandatory in this context. Can we agree which classes are we going to approve respect to the original proposal of R5 Party ? ACTION: Specify exactly what is being approved. Party Party Role and Vendor.
Michela Bevilacqua Jacqueline Beaulac [Ericsson]	SequenceFlows	Agreed	#5 There are two EMPTY classes under SequenceFlows , “License::SequenceFlows::License Setup” and “SimpleOrderFlow class” – these have NO descriptions, NOT included in any diagrams, and are NOT thus possible to understand in the context of the proposal. We recommend to remove these two classes from the proposal.	These Papyrus (not information model) classes are the basis of two simple sequence diagram flows. It appears that the diagrams did not get included into the lasted WIKI post (see version 3) . Andy Mayer Action to be progressed:We will incorporate the diagrams on the wiki with the next update. Michela Bevilacqua (2020/02/20): A review the model is required when the two classes will be added. ACTION: Add sequence flow diagrams for review (note these are not Information Classes)	ONAPMODEL-24 - Getting issue details... STATUS Michela Bevilacqua Jacqueline Beaulac [Ericsson]2020/03/30: The same sequence diagram is repeated twice, to be fixed. What sequence diagrams are intended to be added and approved ? What is the meaning of policy in the licensing context distribution ? ACTION: will fix
Michela Bevilacqua Jacqueline Beaulac [Ericsson]	EntitlementPool LicenceKeyPool FeatureGroup	Reviewed	#7 Three related inconsistencies: The description of EntitlementPool states that “An EntitlementPool is not specific to a Feature Group. An Entitlement Pool may be related to multiple Feature Groups of a software product or even to multiple software products.” However the cardinality of the FeatureGroupHasEntitlementPool has 1 on the FeatureGroup end, meaning that EntitlementPool can only be associated with a single FeatureGroup. The description of LicenceKeyPool states that “A license key group is not specific to a feature group. A license key group may be related to multiple feature groups of a software item or even to multiple software items.” However the cardinality of the FeatureGroupHasLicenseKeyPool has 1 on the FeatureGroup end, meaning that LicenceKeyPool can only be associated with a single FeatureGroup. The description of FeatureGroup states that “If an Entitlement Pool or License Key Group is associated with a particular Feature Group, the Feature Group becomes a "constraint" for the pool/group.” That implies that it should be possible to create an EntitlementPool or LicenceKeyPool without an association to a FeatureGroup. But in the proposal, FeatureGroupHasEntitlementPool and FeatureGroupHasLicenseKeyPool indicate that both EntitlementPool and LicenceKeyPool must each be associated with one FeatureGroup.	1) Updated to allow zero to many 2) Updated to allow zero to many 3) This is covered by changing the cardinality to 0..* above. Model has been updated No further action
Michela Bevilacqua Jacqueline Beaulac [Ericsson]	LicenseAgreement	Reviewed	#9 VNFD – License Agreement relationship: There is no direct relation between the LicenseAgreement class and the VNFD class but objects are connected through the Vendor class losing the possibility to detect the VNFD/VNF type from a LicensingAgreement. Is this the real SDC “built in” model ? Is it a general enough model we want in ONAP ?	Given there is a relationship between vendor and Vnfd as well as FeatureGroup and Vnfd, a direct relationship between LicenseAgreement and Vnfd is not needed. Possible future improvement: Analyze direct relationship from Vnfd to License Agreement No further action
Michela Bevilacqua Jacqueline Beaulac [Ericsson]	VNFinstance	Agreed	#10 A VNFinstance can only have a Entitlement instance and a LKinstance. Is it a general enough model we want in ONAP ?	Please clarify what else you see as being needed. Action: Analyze cardinality of relationship between VNFInstance and LKIntance / EntitlementInstance (should a VNFInstance be able to be related to more than one LKInstance) Andy Mayer? Check AAI Andy Mayer 2020/02/27 AAI swagger does not restrict a VNF to a single instance. ACTION: Update cardinality of VNFInstance relationships to allow 0..* EntitlementInstance and LicenseKey Instance	ONAPMODEL-25 - Getting issue details... STATUS Michela Bevilacqua Jacqueline Beaulac [Ericsson] (2020/03/30) check: *VNFInstance relationships to allow 0.. EntitlementInstance and LicenseKey Instance Jacqueline Beaulac [Ericsson] 2020-04-16:** Cardinalities now OK in Papyrus (but some error for VnfHasEntitlementInstance association?)
Michela Bevilacqua Jacqueline Beaulac [Ericsson]	LicenseAgreement FeatureGroup	Reviewed	#19 It’s not clear why the LicenseAgreementHasFeatureGroup association has cardinality 1..* on each end. Further explanation needed.	Presumably, it is reasonable that a licenseagreement can have some number of feature groups. Similarly, a featuregroup can be related to multiple licenseagreements. We will check and see if SDC will support this. Michela – your perspective on this? Possible Action: include additional description for this relationship Andy Mayer 2020/02/28: We are investigating SDC behavior to verify.	Michela Bevilacqua Jacqueline Beaulac [Ericsson]2020/03/30: action not yet progressed Verified SDC allows a Feature Group to be associated with multiple License Agreements. Also a License Agreement may be associated with multiple Feature Groups.
Michela Bevilacqua Jacqueline Beaulac [Ericsson]	FeatureGroup EntitlementPool	Reviewed	#20 It’s not clear why the FeatureGroupHasEntitlementPool association has cardinality 1..* on the EntitlementPool end. Further explanation needed.	Presently, in the SDC software, the featuregroup MUST have a relationship to an entitlementpool. There is no such requirement for licensekeypool – it is optional. Hence the present multiplicity on the “pool” side of these relationships Possible Action: Describe difference in cardinality in the Class description of FeatureGroup Andy Mayer 2020/02/28: Feature Group must have at least one Entitlement Pool, because the Entitlement Pool represents the actual license assets that are being purchased. No further Action
Michela Bevilacqua(2020/02/20)	General	Agreed	Substitute the name of ASDC with SDC to refer to the ONAP component.	Agree!!!	ONAPMODEL-26 - Getting issue details... STATUS
Michela Bevilacqua (2020/02/20)	Entitlement /License Key instance	Agreed	#8+: Entitlement /License Key instance class definition to be clarified	See resolution to #8	ONAPMODEL-14 - Getting issue details... STATUS

Browser not supported