Comments on the "new structured way to describe the functions"

[PrathibaJee]

I reviewed the document Functions.md from entry level down to the Interpretation Functions. Please find the following review comments and let me know your views. Many thanks.

1. Functions.md#L7 - [Prathiba] Shall we make measurement module to take care of the functionalities mentioned in the "Private InterpretationFunctions". If generically defined conditions are fulfilled, alarms shall be created. Further, implementation module shall call the either the "public interpretation functions" Or "REST APIs" to do the abstract request.
2. Functions.md#L13 - [Prathiba] Shall we also mention about the rollback. Something like this "If the validation fails, no further actions will be performed as in the starting of every request the content of the RunningDS will be copied to the CandidateDS."
3. ProcessingCreate.md#L14 - [Prathiba] shall we also indicate the list of validation functions that shall be called from here? If the validation functions are not generic across the APIs, then we can have separate section for each service and the validation functions shall be listed like how it is done in the ProcessingEstablish.md
4. ProcessingCreate.md#L14 - [Prathiba] If the logical object could not be identify , then request shall be rejected with a custom response code. Shall we mention it here ? and Similar comment applicable for Update too.
5. ProcessingRegard.md#L29 - [Prathiba] If the logical object could not be identify , then request shall be rejected with a custom response code.

[openBackhaul]

• Referencing to 1. (Functions.md, line7a):
  [Prathiba]: Shall we make measurement module to take care of the functionalities mentioned in the "Private InterpretationFunctions"
  [Thorsten]: I would like to administrate (e.g., start, stop, configure, update) the automation separately from the measurement. More over the measurement is affecting the OperationalDS, but the automation the CandidateDS.

• Referencing to 1. (Functions.md, line7b):
  [Prathiba]: If generically defined conditions are fulfilled, alarms shall be created.
  [Thorsten]: The chain should stringently be: abstract intend => interpretation into concrete objects => implementation on the managed elements. I would not prefer the ImplementationFunction to address an abstract intent to its own domain.

• Referencing to 2. (Functions.md, line13):
  [Prathiba]: Shall we also mention about the rollback.
  [Thorsten]: Yes, added "(otherwise the CandidateDS will simply be overwritten by the RunningDS when the next cycle begins)"

• Referencing to 3. (ProcessingCreate.md, line14a):
  [Prathiba]: shall we also indicate the list of validation functions that shall be called from here?
  [Thorsten]: The main task of the ValidationOrchestrator is to invoke the correct set of ValidationTests depending on the InterpretationFunction. I'd prefer to document this relationship at the description of the ValidationOrchestrator, exclusively.

• Referencing to 3. (ProcessingCreate.md, line14b):
  [Prathiba]: ...validation functions shall be listed like how it is done in the ProcessingEstablish.md
  [Thorsten]: Planned to be done.

• Referencing to 4. (ProcessingCreate.md, line14) and 5. (ProcessingRegard.md, line29):
  [Prathiba]: If the logical object could not be identify , then request shall be rejected with a custom response code. Shall we mention it here ? and Similar comment applicable for Update too.
  [Thorsten]: The behavior of the services need further discussions.
  As you know, I would like to consolidate all tests in the Validation to avoid if-then-else and double implementations in the Interpretation.
  On the other hand, it is of course painful to see when a complex interpretation fails validation because of a flaw that was obvious from the outset.
  It might be a good compromise to give the InterpretationFunction (POST) the standard behaviour of GET, PUT and DELETE.
  Do you know of a normative reference for this behaviour?

[PrathibaJee]

Thank you for the explanation. I am agreeing with your comments.
Regarding the final comment , as you mentioned in the email we can discuss this in the upcoming Friday call and document that decision in this issue for future reference.