https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/AAA-3 aaa <p>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.:</p> <p>url: <a href="http://localhost:8080/restconf/config/openflow-action:actions-container" class="external-link" target="_blank" rel="nofollow noopener">http://localhost:8080/restconf/config/openflow-action:actions-container</a><br/> headers: Content-Type: application/json<br/> data: { <br/> "actions-container": {<br/> "action": [</p> { "type": "0" } <p> ]<br/> }<br/> }</p> <p>Operating System: Windows<br/> Platform: PC</p> AAA-3

MD-SAL should allow to configure exported set of models to northbound

New Feature Confirmed Unresolved Unassigned Juraj Sebin Thu, 28 Aug 2014 08:53:22 +0000 Thu, 21 Mar 2019 12:01:55 +0000 General 0 3 <p>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 &#8211; it is just a matter of us not currently having such an app.</p> <p>Can you propose criteria by which a 'leak' and a 'non-leak' can be discerned?</p> <p>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?</p> <p>Not really, as that would require us to model all the concepts and always perform model-to-model translation.</p> <p>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.</p> <p>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.</p> Development External issue ID 1643 External issue URL Issue Type Rank 0|i023hz: