Development and incorporation of STANDARDS for the PLACE object

• Geolocation RFC6225,
• TM forum GB922 (PLACE OBJECT)
• MEF MCM MEF78: http://www.mef.net/resources/technical-specifications/download?id=119&fileid=file1
• A&AI Complex object (q.v. this page's addendum) - output of Graphgraph need UML model

This will be worked as the GEOLOCATION Modeling work in the R6 Modeling HLR: ONAP R6 Modeling High Level Requirements

Additional fields (low level fields) - consider context of how ONAP would use the information; it is unlikely that some of the lower level fields will be useful. (e.g. Cubicle, workstation level). Potentially rack information; equipment model IETF in M3100 stored on the Managed Element attribute.

Wiki page: Root (Root Model object)

ACTION: Information Model & PLACE Object proposal from Kevin Scaggs  / Start with "as built" model / Bob Papa & SALVATORE RICCI 

ACTION: Complex object reverse engineering - Mapping of Place & A&AI Complex Object / Do an analysis on the Complex object / Reverse engineer of Complex / logical model vs grounding in current implementation → evolution / who will consume changes & use cases - downstream system / Standards → Needs Use Cases → Information Model → Objects & Data Model  / Subject Modeling S/C. Globalization of location information / simple things we can do wo/ breaking the complex object e.g. changing behavior applied to multiple countries are we missing attributes evolving location info for other U/C needs.

ACTION: R7 need & application?  VNF will likely need the address/location info/complex before PNF. (1) Containerization (2) multi-cloud 3rd party clouds & (3) attributes missing or extended A&AI schema update (4) support globalization. / VNF verizon ETSI alignment R7 Use Case "Onboard ETSI SOL004  compliant VNF packages"