Hello Dave, Aside from the ignorance-caused omissions this proposal looks like is not a platform, but a very OF-centric controller. What precisely are the capabilities and features of the platform tha

The lifecycle documents states it is the committers who decide on the Release Plan. The Simultaneous Release coordinates the release, and it states terms in 'no later than' -- there is no reason why a

The codebase itself is highly modular and reusable. The delivery vehicles allow us to not lose any of that, but our feature definitions do not take advantage of that. The feature boundaries do not ove

Unfortunately, we have had little consensus on the fact that we should be marking APIs. We currently completely lack the tools to do so in the models, too. I would hate to associate the word 'stable'

Hello, We have historically allowed waiver-less additions to APIs, which would presumably be needed for new functionality. Give that are institution functionality freeze before the API freeze, wouldn'

Hello, I understand your concern, but that differentiation does not lay on project boundaries and with Karaf in the picture, it becomes a simple matter of how our feature files are structured. As a co

Most of these annotations (like @Beta) are @Documented, so they should show up in Javadocs and similar contexts. Bye, Robert

Hello Steve, Would it be possible to expand the proposal with some mechanics/general approach? I would like to understand how you plan to deal with the actual payload. Thanks, Robert

Hello Steve, I do not have specific experience with SNMP, but on the data modeling side, I think we should take a very good look at RFC6643 and try implementing it. It should provide us with near-nati

Exactly. The SNMP integration would then work by formatting native MD-SAL data (which conforms to the MIB) into SNMP PDUs. From resource/engineering perspective, yes this is a larger chunk of work. It

Thank you for looking into this and yes, this is an excellent plan for addressing the immediate needs. I think we should put this on the next TSC call as the plan of action. You can count me in on the

There is a companion patch under review, https://git.opendaylight.org/gerrit/#/c/13651/, which should close that vulnerability when EXI is used. It still needs to be verified and then cherry-picked to

That would be my belief, but I would like that checked by David :-) Thanks, Robert

Sure thing, it just needs a controller committer :) Thanks, Robert

Actually, as soon as we bring clustering/multi-instance into the picture, a third network emerges, which is the controller-private network. While it could be shared with the network control plane, it

Hello, while it is true, certain deployment scenarios may lack the enforcement points to effectively mitigate the attack surface. I think for the purposes of the threat model we need to differentiate

Hi, for what it's worth, during the Helium timeframe we had an internal requirement for yangtools/md-sal/bgpcep/ofj/ofp to have 80% line and 60% branch coverage where that was practical to achieve. We

+1 on creating a dedicated project, +1 on migrating the code from yangtools. Bye, Robert

Hello everyone, this topic has been raised a couple of times in various places, but I cannot find a public archive which would sum it up. I would like to ask what is preventing us from switching from

Hello Devin, For a spin-out project, I do not believe we want to 'carry over' committer status at all, but rather look at the folk who are currently active in the area. Quite honestly, I see you menti