On 11/3/2015 5:33 AM, go...@erg.abdn.ac.uk wrote:
> GF: From a TSVWG Chair perspective, beware here... *ALL* more recent IETF
> SCTP API work from TSVWG is INFO. Each SCTP RFC is expected to have an
> informative section that describes the API together with the normative
> protocol spec. That is not because there are expected to be alternatives
> to choose from: It's because, as I understand, the IETF is not the formal
> standards body for specification of such normative APIs.
That has been a serious misinterpretation of how a protocol definition
works, which the IETF has propagated over the years.
The abstract APIs - above and below - of a protocol are a key part of a
protocol specification. More directly, a protocol definition is a FSM
that consists of:
- a finite state machine
- upper layer events (in/out)
i.e., the upper layer abstract API
the services that a protocol "creates"
- lower layer events (out/in)
i.e., the services on which the protocol relies
- time events
- rules that relate the items above
The way in which an abstract API is implemented as Unix sockets might be
informative to the IETF (but not, e.g., to the POSIX community), but the
abstract API cannot be. It has to be a normative part of the definition
of the protocol.
Otherwise, you end up with a protocol with no upper layer events or
actions, i.e., a tree falling in the woods with nobody to hear.
Joe
_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps
