...
Source | Class | Status | Comment | Proposed Resolution Changes saved |
---|---|---|---|---|
n/a | Not a Licence model issue | 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:
| No direct impact on License Model. Xu Yang Action to be progressed: This should be addressed to the modeling subcommittee as a whole. https://docs.onap.org/en/elalto/submodules/modeling/modelspec.git/docs/index.html this is the modeling readthedocs for el alto release | |
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. | |
n/a | Reviewed | #1 Is 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. | |
n/a | Need further discussion | #3 License License keys, license agreements, and contractual details such as entitlement information, are all sensitive commercial information.
| 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. | |
EntitlementInstance LicenseKeyInstance | Reviewed | #8 Entitlement Entitlement instance / LicenseKeyInstance classes refer to “As Built in ASDC”.
| 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 as (today) not used and stored by ONAP platform. | |
All | Review | #2 #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.
| 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? | |
EntitlementPool | Review | #13 Entitlement Entitlement Pool definition is partially duplicated, to be reviewed.
| The duplicate statement was removed. Text was updated to say “Controllers may request entitlements”. Michela Bevilacqua (2020/02/20):
| |
LicenseKeyPool | Review | #16 The 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. | |
All | Review | "General" #2 Mainly 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.
| 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 softare, 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 enough. We recommend to introduce the relationship definiton in the class definition table. | |
EntitlementPool LicenseKeyPool | Review | #6 We 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 provide screenshots of UIs as well as a view of the XML being distributed from SDC. XML from SDC can be found at - | |
LicenseAgreement | Review | #11 LicenseAgreement 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. | |
DesignEntity | Review | #12 The 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.
| 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. | |
EntitlementPool | Review | #14 Entitlement Entitlement Pool class: entitlementManufactureReferenceNumber has a multiplicity 0..1 and it is defined as “identifier for the entitlement as described…”.
| 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. Updated name to licenseKeyFile to distinguish the attributes. | |
LicenseKeyInstance | Review | #15 LicenseKey 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”).
| 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. | |
EntitlementInstance | Review | #17 Entitlement 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 | |
EntitlementInstance LicenseKeyInstance | Review | #18 EntitlementInstance EntitlementInstance and LicenseKeyInstance classes include the mandatory attribute ssmUserId.
| Still researching. | |
Vendor | Reviewed | #4 “Vendor” “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.
| 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 Andy Mayer (2020/02/17): Action to be progressed: Will add description of Vendor Class (and superclasses) to the Licence model page proposal page. 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. | |
SequenceFlows | Review | #5 There 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.
| 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. | |
EntitlementPool LicenceKeyPool FeatureGroup | Review | #7 Three Three related inconsistencies:
| 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. | |
LicenseAgreement | Review | #9 VNFD 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.
| 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. | |
VNFinstance | Review | #10 A A VNFinstance can only have a Entitlement instance and a LKinstance.
| Please clarify what else you see as being needed. | |
LicenseAgreement FeatureGroup | Review | #19 It’s It’s not clear why the LicenseAgreementHasFeatureGroup association has cardinality 1..* on each end.
| 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? | |
FeatureGroup EntitlementPool | Review | #20 It’s It’s not clear why the FeatureGroupHasEntitlementPool association has cardinality 1..* on the EntitlementPool end.
| 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 | |
Michela Bevilacqua(2020/02/20) | General | Substitute the name of ASDC with SDC to refer to the ONAP component. | ||
Michela Bevilacqua (2020/02/20) | Entitlement /License Key instance | #8+: Entitlement /License Key instance class definition to be clarified | ||