IntroduceReferenceImplementationRepositories

[MarkusKuemmerle]

No description provided.

[shilpa-padgaonkar]

A template repo needs to be provided which includes the default files(codeowner, license etc.)needed for implementation repos. This repo is then used to create new repos. If this is fine, it needs to be added to the doc as well.

[patrice-conil]

I think end-to-end RI is too strongly tied to the Southern ecosystem to be useful to all partners. To be able to use it, we would need to have a southern reference ecosystem.
How about an RI that would only respond to pre-determined requests with well-formed pre-defined responses to give API consumers a chance to validate their client implementation? By the way, requests with associated replies would give us a BDD input to validate our implementations.
Such an implementation would not rely on SCEF / NEF ecosystems and would be easy to deploy/use.
What do you thik about?

[MarkusKuemmerle]

A template repo needs to be provided which includes the default files(codeowner, license etc.)needed for implementation repos. This repo is then used to create new repos. If this is fine, it needs to be added to the doc as well.

Agreed! I'll do that if the reviewers are fine with the concept presented in this pull request

[MarkusKuemmerle]

I think end-to-end RI is too strongly tied to the Southern ecosystem to be useful to all partners. To be able to use it, we would need to have a southern reference ecosystem. How about an RI that would only respond to pre-determined requests with well-formed pre-defined responses to give API consumers a chance to validate their client implementation? By the way, requests with associated replies would give us a BDD input to validate our implementations. Such an implementation would not rely on SCEF / NEF ecosystems and would be easy to deploy/use. What do you thik about?

We already have a southern reference ecosystem (NEF service provided by Nokia). For other topics beyond NEF we may need a different southern reference ecosystem. But that's something different as proposed in this pull request. Here we focus only on reference implementations for the transformation functions Southbound --> Northbound for our APIs.

[patrice-conil]

We already have a southern reference ecosystem (NEF service provided by Nokia). For other topics beyond NEF we may need a different southern reference ecosystem. But that's something different as proposed in this pull request. Here we focus only on reference implementations for the transformation functions Southbound --> Northbound for our APIs.

It was my mistake

[MarkusKuemmerle]

We already have a southern reference ecosystem (NEF service provided by Nokia). For other topics beyond NEF we may need a different southern reference ecosystem. But that's something different as proposed in this pull request. Here we focus only on reference implementations for the transformation functions Southbound --> Northbound for our APIs.

It was my mistake

Don't worry, Your idea is a good one. Let's see when it's the right time to start working on such a Southbound Mock

[MarkusKuemmerle]

A template repo needs to be provided which includes the default files(codeowner, license etc.)needed for implementation repos. This repo is then used to create new repos. If this is fine, it needs to be added to the doc as well.

Agreed! I'll do that if the reviewers are fine with the concept presented in this pull request

Templates created, description added to ProjectStructureAndRoles.md

[hdamker]

Good direction, in QoD we are waiting for it!

[patrice-conil]

Maybe a reference to template files may help. Or something like templates could be found in CAMARA root repository.

[MarkusKuemmerle]

I've created template repos with all necessary file templates:

• https://github.com/camaraproject/Template_Lead_Repository
• https://github.com/camaraproject/Template_RI_Repository

[patrice-conil]

Yes I found them ... but a reference to these repositories in the doc may help to find them quickly.

[shilpa-padgaonkar]

There were comments here camaraproject/WorkingGroups#63 which say that the word reference used here is not correct.

[jordonezlucena]

I think end-to-end RI is too strongly tied to the Southern ecosystem to be useful to all partners. To be able to use it, we would need to have a southern reference ecosystem. How about an RI that would only respond to pre-determined requests with well-formed pre-defined responses to give API consumers a chance to validate their client implementation? By the way, requests with associated replies would give us a BDD input to validate our implementations. Such an implementation would not rely on SCEF / NEF ecosystems and would be easy to deploy/use. What do you thik about?

We already have a southern reference ecosystem (NEF service provided by Nokia). For other topics beyond NEF we may need a different southern reference ecosystem. But that's something different as proposed in this pull request. Here we focus only on reference implementations for the transformation functions Southbound --> Northbound for our APIs.

Agree on the need of having a ref implementation for the transformation function. Question as for the southbound side: Should we use the network API from the standard or should we rely on the solution made available by a vendor? For example, if the network API == NEF API, should we rely on OAS captured in TS 29.522 or on the Nokia NEF? I also have the question on whether the Nokia southbound ecosystem is open for every CAMARA partner, and if so, how we can make use of it.

[MarkusKuemmerle]

There were comments here camaraproject/WorkingGroups#63 which say that the word reference used here is not correct.

Have checked it, found no necessary change

[MarkusKuemmerle]

I think end-to-end RI is too strongly tied to the Southern ecosystem to be useful to all partners. To be able to use it, we would need to have a southern reference ecosystem. How about an RI that would only respond to pre-determined requests with well-formed pre-defined responses to give API consumers a chance to validate their client implementation? By the way, requests with associated replies would give us a BDD input to validate our implementations. Such an implementation would not rely on SCEF / NEF ecosystems and would be easy to deploy/use. What do you thik about?

We already have a southern reference ecosystem (NEF service provided by Nokia). For other topics beyond NEF we may need a different southern reference ecosystem. But that's something different as proposed in this pull request. Here we focus only on reference implementations for the transformation functions Southbound --> Northbound for our APIs.

Agree on the need of having a ref implementation for the transformation function. Question as for the southbound side: Should we use the network API from the standard or should we rely on the solution made available by a vendor? For example, if the network API == NEF API, should we rely on OAS captured in TS 29.522 or on the Nokia NEF? I also have the question on whether the Nokia southbound ecosystem is open for every CAMARA partner, and if so, how we can make use of it.

We decided to use the Nokia web service as current reference NEF for CAMARA. This service is open for everybody. As soon as we get more NEF services from other partners we also can use them.

[patrice-conil]

Hi @MarkusKuemmerle
Is https://swagger.open5glab.net the southern reference you mention ?

[MarkusKuemmerle]

Hi @MarkusKuemmerle Is https://swagger.open5glab.net the southern reference you mention ?

It's this one: https://www.nokia.com/developer/open5glab#nef-in-open-5g-lab

[jordonezlucena]

I think end-to-end RI is too strongly tied to the Southern ecosystem to be useful to all partners. To be able to use it, we would need to have a southern reference ecosystem. How about an RI that would only respond to pre-determined requests with well-formed pre-defined responses to give API consumers a chance to validate their client implementation? By the way, requests with associated replies would give us a BDD input to validate our implementations. Such an implementation would not rely on SCEF / NEF ecosystems and would be easy to deploy/use. What do you thik about?

We already have a southern reference ecosystem (NEF service provided by Nokia). For other topics beyond NEF we may need a different southern reference ecosystem. But that's something different as proposed in this pull request. Here we focus only on reference implementations for the transformation functions Southbound --> Northbound for our APIs.

Agree on the need of having a ref implementation for the transformation function. Question as for the southbound side: Should we use the network API from the standard or should we rely on the solution made available by a vendor? For example, if the network API == NEF API, should we rely on OAS captured in TS 29.522 or on the Nokia NEF? I also have the question on whether the Nokia southbound ecosystem is open for every CAMARA partner, and if so, how we can make use of it.

We decided to use the Nokia web service as current reference NEF for CAMARA. This service is open for everybody. As soon as we get more NEF services from other partners we also can use them.

So for those CAMARA APIs who are built upon NEF, the approach is to go for a transformation function which maps the corresponding CAMARA API (e.g., QoD) into Nokia web service API, right?

[shilpa-padgaonkar]

Same comment as before. Reference word is not preferred. Provider could be an alternative.

[MarkusKuemmerle]

Same comment as before. Reference word is not preferred. Provider could be an alternative.

OK, then I'll change "Reference" to "Provider" after merging this Pull Request.
I don't want to loose the approvals again...

[patrice-conil]

I think end-to-end RI is too strongly tied to the Southern ecosystem to be useful to all partners. To be able to use it, we would need to have a southern reference ecosystem. How about an RI that would only respond to pre-determined requests with well-formed pre-defined responses to give API consumers a chance to validate their client implementation? By the way, requests with associated replies would give us a BDD input to validate our implementations. Such an implementation would not rely on SCEF / NEF ecosystems and would be easy to deploy/use. What do you thik about?

We already have a southern reference ecosystem (NEF service provided by Nokia). For other topics beyond NEF we may need a different southern reference ecosystem. But that's something different as proposed in this pull request. Here we focus only on reference implementations for the transformation functions Southbound --> Northbound for our APIs.

Agree on the need of having a ref implementation for the transformation function. Question as for the southbound side: Should we use the network API from the standard or should we rely on the solution made available by a vendor? For example, if the network API == NEF API, should we rely on OAS captured in TS 29.522 or on the Nokia NEF? I also have the question on whether the Nokia southbound ecosystem is open for every CAMARA partner, and if so, how we can make use of it.

We decided to use the Nokia web service as current reference NEF for CAMARA. This service is open for everybody. As soon as we get more NEF services from other partners we also can use them.

So for those CAMARA APIs who are built upon NEF, the approach is to go for a transformation function which maps the corresponding CAMARA API (e.g., QoD) into Nokia web service API, right?

FYI, I went from E/// SCEF to Nokia NEF just by switching URL...everything works like a charm.