Dear Linda,I may be wrong, but I remember that we discussed a change in the capability model to avoid sub-classing as a way to obtain different types of conditions, action, events, etc.
The new model, now under John's review, implements the decorator pattern, thus avoid sub-classing as conditions, action, events become instances (that can be easily generated, and also used dynamically at run-time and many other advantages).
Then, the NSF facing data model will probably be a superset of the capability model, obtained by extending it with concepts that are specific of NSF facing interface.
After having restructured the capability model we can discuss how this impacts the NSF facing data model.
Regards, Aldo On 30/11/2017 23:30, Linda Dunbar wrote:
Aldo,Thank you very much for the update. By the way, the version on data tracker is still 00, so your update should be 01. During our side meeting in Singapore among IM/DM authors, you stated that you don't like explicit listing of the needed attributes for capability, e.g. the line by line list of all the IP addresses format and you volunteered to restructure the NSF facing data model so that it can be easily extended. Once you prepare the preliminary NSF facing data model structure, the NSF facing data model authors can regroup the attributes accordingly. How does the tree structure in the *pdf file you sent last Friday eliminate explicit listing of all the needed attributes for "Condition" on IP addresses?Thank you very much. Linda -----Original Message----- From: Aldo Basile [mailto:[email protected]] Sent: Thursday, November 30, 2017 4:12 AM To: Linda Dunbar <[email protected]> Cc: [email protected] Subject: updates on the capability models Dear Linda, all, short update on the capability information model (IM) and data model (DM) task defined during the Wednesday meeting. I have prepared a DM that derives from the capability IM model presented by John that uses the policy and decorator patterns. This model really improves on the one I circulated last Friday. Despite the patterns, the model is not complicated. In the meantime, John is validating it, both formally and semantically. When it will pass John's validation I'll write the corresponding YANG Data model. I also prepared an informal instance of the model that I circulated in the draft-xibassnez-i2nsf-capability-02 group. This will also be checked after John's validation, aligned with YANG DM (and written in XML, I guess). I'll also provide guidelines to expand the DM instance with all the data that are currently part of the draft-hares-i2nsf-capability-data-model-05 (IMO, it will be a minor rearrangement). When DM and instance will be ready, we'll ask the WG (in particular the other authors of IMs and DMs) to verify if they agree on the proposed DM and process the proposed modifications. Furthermore, I just asked Arnaud Taddei from Symantec to share with us the additional requirements from a multi-domain-of-administration scenario he was mentioning during the I2NSF plenary. I'll process these data and share with you my findings and potential improvements to the I2NSF capability IM and DMs. Finally, the new IM and DM implies changes to the capability IM in draft-xibassnez-i2nsf-capability-02, we'll also align the document to the changes. Regards, Aldo _______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
