Alignment with etsi's fields about son-schema

[mbredel]

I know that we deviate from the ETSI IM a bit. The reason is that - after looking really closely at ETIS - I think the ETSI IM has some shortcomings and does not really fit our needs. Moreover it is a bit unstructured here and there and has redundancies that almost surely leads to errors. Maybe the next versions of the ETSI IM are better, but for now, I wouldn't follow them that closely.

Regarding the IDs: As discussed also in #61, using UUIDs in the descriptor files is not really feasible in our SDK scenario where we want to enable different developers to re-use different descriptors. Haven it all within the SP - including the descriptor generation - as, e.g. in T-NOVA, is a completely different story. So I would keep the name.trio.convention also for the VNFD and NSD.

Regarding the "vnf_" (and "ns_") prefix: I was thinking about the same thing and I am happy to remove them :-) Any other opinions on that?

[jbonnet]

@srodriguezOPT, @mbredel
+1 on eliminating prefixes like ns_ and vnf_: I think the related data always comes in the right context, so the prefix is not needed.

-1000 on considering ID's composed of UUID, group and name. We're discussing this in #61, as Michael says: UUID is itself unique, why should we add the group and the name? I wouldn't extend the name.trio.convention to the NS(D)/VNF(D): what do we gain from that? Even if reuse (see my doubt below) is the focus, e.g., the NSD that is reusing the VNFD might simply refer to it by it's UUID... or am I missing something here?

@mbredel I didn't get your claim that '...using UUIDs in the descriptor files is not really feasible in our SDK scenario where we want to enable different developers to re-use different descriptors'. Could you please elaborate a bit?

[mbredel]

@jbonnet My statement regarding the UUIDs is in line with what I said in #61. In essence that is, UUIDs are fine for machine-2-machine communication, but not if we have a developer using the SDK. And IMHO UUIDs should not be part of the descriptors (talking about the files now, not the databases). But lets do this discussion in #61 and not start over here again :-)

Regarding the prefixes: OK, decided - I will remove them.

[santiagordguez]

We agree that UUID is itself unique.

The proposal was to use fields defined by ETSI and not to create new ones for similar purposes, for example, grouping fields under ID.
This way we would use our needed fields, maintaining the ETSI's structure.

Our focus is always the alignment with ETSI because it seems that will be the future standard.
If you detect shortcomings, maybe we should report ETSI to take into account this limitations.
It worries us that SONATA's model will not be aligned with future developments from ETSI's standard, but for us it's fine for us, let's move on.

[mbredel]

I understand your point with the ETSI alignment. I think the best would be to provide feedback to ETSI. Do you (or anyone else) have an idea on how to do that best?

[mbredel]

And by looking at ETSI again, you basically mean the following?
"group" -> should be "vendor"
"name" -> should be "id"
"version" -> stays "version"

Right? That would be possible.

[jbonnet]

@mbredel
NSs and VNFs have names and ids, "name" should not be "id"

[santiagordguez]

Right?

Maybe Diego can help us with the feedback to ETSI

[mbredel]

Nice picture! That is almost my view - including the "Needed?" questions. Since the *Rs are used within the SP only, I tend to say we don't need the vendor and version in the records ... but a reference to the the VNFD ... which could be the UUID?