My only defense here is that in Spain we do not have April's fools but December 28th Innocent day so this is not the first time I am fooled. Besides the joke, I had a good laughter reading the 2 RFCs

Yep, you totally got me on this one :)

Or btw, is this is an April's fool joke :)

Wow, I have never seen an RFC as short as this one: https://tools.ietf.org/html/rfc1149 and also an idea like this before: https://en.wikipedia.org/wiki/IP_over_Avian_Carriers Do you mind elaborating

Hi all, I think we are losing some momentum to get something done in this release. Let me comment on the questions that are blocking this project: 1) Relationship with other projects I do not understa

+1

+1

+1

So I guess you will use existing netconf plugin in ODL + new GRPC. For this last will you coordinate with P4 project to reuse libraries/code?

Hi, I am curious about the control/configuration channel transport protocol: is this GRPC based too? or netconf? or restconf? or just any protocol supporting openconfig models. BR/Luis

I think I missed this formality for integration project split. The project split was explained here: https://lists.opendaylight.org/pipermail/integration-dev/2015-August/003976.html The new projects w

That was exactly my point the review day: we can debate whether or not we need a new network abstraction or if we should go to a single low-level one like David B proposed, but so far we have approved

Hi David, good point I really would like to hear more community opinions on whether we should provide single or multiple low-level network abstractions in OpenDaylight. I personally think the first is

Am I the only one in this community that thinks every new project introduces a lot of effort (and not just in the beginning) in terms of: - Infrastructure: LF have to provide all tools and gear (git,

Hi Colin and all, I think one of things the TSC should be pushing is not only splitting a big project like controller but also trying to consolidate projects that have common or similar scope, otherwi