italobusi

It has been claimed that OpenAPI specification is RESTFUL (RFC8040) compliant but interoperability with any RESTFUL/YANG implementations not using OpenAPI is not ensured One argument is that RFC8040 is ambiguous...

I think there are three possible cases: 1) OpenAPI specification is compliant and interoperable with RESTCONF (RFC8040) In this case, the OpenAPI specification is useless and potentially harmful (since ONF...

IETF RFC8040 has been prepared by the Netconf WG: https://datatracker.ietf.org/wg/netconf/about/ If ONF believes the specification has issues, it would be worthwhile checking with IETF Netconf WG whether they are real...

@y-higuchi - You are correct that RESTCONF ∈ REST API The term REST API does not fully qualify the wire-protocol and therefore some API specification is needed REST APIs may...

Based on this discussion, I think that a more factual statement would be: > Implementations may use any flavor of REST APIs as long as they are based on the...

**Notes from the T-API call (January 10, 2017):** We agreed to that the _lpTransition package is applicable only to Transitional Links and to update its cardinality to [0..1] @karthik-sethuraman :...

**Notes from the T-API call (January 10, 2017):** We agreed that the order in the transitionedLayerProtocolName is describing which layer is the client and which is the server. Therefore its...

**Notes from the T-API call (January 10, 2017):** Remaining issues for further discussion: - _nodeEdgePoint list in the pac – is it needed? - How does the layerProtocolName list in...

While reporting the notes of the latest call, I have noted that we have not summarized previous discussion about the Total Pool Capacity, supported granularity and Max # instances attributes...

If there is no need to support multiple layer transitions, then I think the cardinality of the transitionedLayerProtocolName attribute should become [2] instead of [2..*]