[AAA-3] MD-SAL should allow to configure exported set of models to northbound Created: 28/Aug/14 Updated: 21/Mar/19 |
|
| Status: | Confirmed |
| Project: | aaa |
| Component/s: | General |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | New Feature | ||
| Reporter: | Juraj Sebin | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Operating System: Windows |
||
| Description |
|
openflowjava yang models are leaking to md-sal and are therefore exposed via rest api and it's possible to sent successfull requests, e.g.: url: http://localhost:8080/restconf/config/openflow-action:actions-container ] |
| Comments |
| Comment by Robert Varga [ 11/Nov/14 ] |
|
I am not sure what is the leak. The simple fact is that the API is present in the system and it can reasonably appear in MD-SAL – it is just a matter of us not currently having such an app. Can you propose criteria by which a 'leak' and a 'non-leak' can be discerned? |
| Comment by Juraj Sebin [ 15/Jan/15 ] |
|
Shoudln't openflowjava models be hidden by openflowplugin? And openflowjava should function only as a driver from openflowplugin to device and therefore shoudln't be accessed by MD-SAL? |
| Comment by Robert Varga [ 15/Jan/15 ] |
|
Not really, as that would require us to model all the concepts and always perform model-to-model translation. What we really want to have is a set of core protocol concepts, which are then used by OFJ (on-wire) and OFP (semantic) models. Given the inter-project dependencies, those shared concepts need to live in OFJ. |
| Comment by Robert Varga [ 13/Nov/15 ] |
|
We need to solve this in the AAA broker facades, which have enough information about user authentication. This essentially means that the schema context exposed from the facade needs to be filtered, too. |