camaraproject / Governance

Telco network capabilities exposed through APIs provide a large benefit for customers. By simplifying telco network complexity with APIs and making the APIs available across telco networks and countries, CAMARA enables easy and seamless access.
53 stars 44 forks source link

IntroduceReferenceImplementationRepositories #73

Closed MarkusKuemmerle closed 1 year ago

shilpa-padgaonkar commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

jordonezlucena commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

MarkusKuemmerle commented 1 year ago

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 commented 1 year ago

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?

MarkusKuemmerle commented 1 year ago

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 commented 1 year ago

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.