Miguel Angel Pedraza

I agree with @kzangeli this could be a great addition to Orion as well. As this feature is not semantic dependent, could be a good opportunity to have a contribution...

After some internal discussion of the Orion development team, we arrive that there it makes no sense to implements those features inside the Broker. Context registrations codebase present in Orion...

Regarding the first item (health check), the problem of using a separate endpoint to doing the check (i.e. an extra port opened by the contextBroker process, let’s say port number...

Regarding health-check: Since the information is available on the Orion logs, it is possible to parse and process it using bash commands to perform the health-check (we understnad that with...

Another alternative is achieve this is to use [Common Expression Language](https://github.com/google/cel-spec) It is available a [C++ library](https://github.com/google/cel-cpp) implementing the language **Pros**: Maintained by Google, available in different languages **Cons**: Different...

> It is combined issue of IoTA and Orion. We are using NGSI v2. Please find below curls commands to reproduce the problem: > > * Device Provision: > >...

The documentation link provided does not describe well the aim and the content of each JSON element, why, and how is going to be used. CI actions described on the...

Some doubts regarding the following points: 1 Forbidden characters not present in Orion-api.md, you mean file? So, adding General restrictions from `forbidden_characters.md` and including into a new section on `Orion-api.md`,...

The proposed strategy to include the content in this section is to make 5 bigger PRs with smaller sub PRs for each section: * PR1 - Modify tables * PR2...

IMHO *Alternative 2* makes more sense since it does not take another attribute name for an special functionality, even if `dateExpired` is not so aligned with the concept of "time...