Common Primitives

[chrhartl]

On behalf of the ONF IMP team, I propose that EAGLE use the following primitives (and associated stereotypes)

Model Primitives ONF.docx

[chrhartl]

Updated document (added URI) Model Primitives ONF.docx

[ghost]

ETSI NFV IM (IFA015) has defined its own set of primitive types: Identifier, Filter, TimeStamp, Value, Rule, Number, IpAddress, MacAddress, Location, Version, PositiveInteger, Binary.

TimeStamp might be equivalent to Datetime (to be confirmed), but as GSs using TimeStamp are laready released, this type cannot be changed.

[nigel-r-davis]

To be clear, we will all need to change stuff over time to converge from the mess of unnecessary variety we have in the industry to something coherent to ease integration by minimizing mappings etc.

I assume, Marc, that you mean that you do not see an opportunity at this point to converge. It would be helpful if you could comment on the specifics in the proposal with a longer term convergence path in mind.

[ghost]

On the primitive types, I don't have any issue with using UML primitives and preferably to corresponding ECore primitive types. My list is adding new primitive types to the list with only one probable conflict DateTime vs TimeStamp. It might be merged with the ONF list, with or without resolving the conflict.

On the probable conflict, we need to discuss it as TimeStamp seems better than DateTime.

The additional stereotypes are more for implementation and ETSI NFV is not yet at this stage. So no specific comment on those.

[chrhartl]

I don't have an issue with renaming DateTime to TimeStamp. I'd like to hear from the others as to what they are using now too.

[GermanoSMO]

I'm a little bit concerned about renaming DateTime to TimeStamp, especially as long as we go to UML->Yang mapping. We should be clear in understanding "how" the TimeStamp datatype is defined in ETSI NFV model. If it's defined as the "daytime expressed as YYYY-MM-DD.HH:MM:SS.xxx", then I see no clash. But if it's defined as in other contexts (e.g. IETF) as the "tick count, intended as the non-negative integer that represents the time, modulo 2^32 (4294967296 decimal), in hundredths of a second between two epochs" with conventional "t0 = Jan 1, 1970" (this is the typical Unix timestamp, by the way), then we may have interpretation issues.

In the second case, we may have issues also with the automatic UML->Yang tool, since ietf-yang-types.yang provides distinct types for date-and-time and timestamp with a totally different semantics reflecting the definitions above. Not to talk about the additional burden for converting between ticks and YYYY-MM-DD (I have in mind network protocols such as NTP using YYYY-MM-DD format which should be then converted into "ticks" at the interface just because of the choice of the reference datatype).

To be noted: if ETSI NFV defines TimeStamp with a "YYYY-MM-DD" format, then we could rename ONF DateAndTime datatype into TimeStamp and then having the tool associating this datatype to ietf-yang-types:date-and-time, but as soon as ONF or any other SDO would need to model a "timestamp datatype based on ticks", then we'll have to remember that it would be necessary to choose a different name.

[ghost]

Hi,

We don't define the structure of TimeStamp as it is a primitive type, so as defined in UML, the structure of a primitive type is not defined in UML and left for external specification. There is no assumption of the format of the TimeStamp except that it needs to be a true timestamp, i.e. not only the date but the exact time. Let me raise the issue realted to timetick to the ETSI NFV group before agreeing on any change.

[GermanoSMO]

If this can help in your investigation, please take into account that the DateAndTime type, at least as defined in the IETF Yang, provides the exact time as well, not just the date. The primitive is not just "Date" but "DateAndTime" and its complete format is: YYYY-MM-DDTHH:MM:SS.xxx where HH:MM:SS.xxx represents hour, minute, second and fractions of second, so it would fit your need with the desired accuracy.

[nigel-r-davis]

My concern with the suggested name change is that TimeStamp sounds like the name of a use of DateTime (i.e. the name of an attribute) not of the type. I could use DateTime as the type of an attribute, currentTime, of an entity that represents the real time clock. I don’t think that TimeStamp would be the expected name of the type in this context (but the structure of DataTime would apply). Why was TimeStamp chosen in ETSI-NFV as the name of the type rather than of the attribute? Is there any chance of changing this given this rationale sketch here?

[hingkamlam]

I agree with Nigel. TimeStamp sounds like an application of the data type.

[ghost]

Hi Nigel,

I think it is too late in current ETSI NFV phase 2 to change TimeStamp. Some documents are released already and the second batch is in final review cycle. I don't remember why exactly TimeStamp was chosen, but it is used in ETSI to describe a timestamp, so the name seems natural. This is another point where we will have to see in future if alignment is possible.

[ghost]

ETSI NFV IFA WG approved the change of primitive type TimeStamp to DateTime. This will be implemented in the Info Model and all GSs to be published. For the documents already published, it will have to wait for a revision.

[nigel-r-davis]

Issue reviewed on IISOMI call 20160712. Complex path. Bernd to create solution.

[bzeuner]

Proposed additional Stereotypes according to Chris' contribution:

[bzeuner]

Issue reviewed on IISOMI call 20160719: Agreed to split the issue. The proposed primitive types Uuid, DateTime and URI are accepted and are moved to issue #123. The remaining stereotypes proposal stays in this issue.

[bzeuner]

I have two concerns regarding the proposed modelling using explicite stereotypes.

1. The use of explicite stereotypes for the same kind of property opens an additional modelling pattern. Note: The other pattern is to define an attribute in an entity related stereotype. There are no clear rules for choosing this or the other pattern.
2. There are no constrains on the assignment of the stereotypes to the entities; e.g., one could assign <<16bit>> AND <<32bit>> to the same Attribute. Defining these stereotypes in one enumeration would prevent such modelling failures.

[chrhartl]

Updated document based on IISOMI feedback.

Model Primitives ONF.docx

[bzeuner]

IISOMI call July 26: Decision: The updated solution by Chris is good enough and adequate, although it still allows assigning invalid combinations of stereotypes to attributes.

[bzeuner]

New properties (bitLength, unsigned, encoding, counter) for defining the attribute types have been added to the OpenModelAttribute stereotype in v0.2.3 of the OpenModelProfile:

[bzeuner]

There is an issue with the accepted solution. All attributes have by default the first entry of the new properties; i.e.,

Adding an additional NA (not applicable) literal to the enumeration and set this as Default value could solve this issue:

[chrhartl]

Bernd, yes please add NA to the Enumerations I won't update the submission document.

[bzeuner]

IISOMI call August 9: Proposed solution is accepted and will be integrated into the UML Modeling Guidelines v1.1.04 and the OpenModel Profile v0.2.4.

[bzeuner]

Chris accepted the solution; i.e., the issue can now be closed.