Re: [Taps] RFC 6458 etc. in draft-welzl-taps-transports

HI Joe,

Yes I agree. But still there are finer features and BCP for api
and protocol implementations that have appeared from the api's defined
outside of the IETF and for which one need to look outside of RFC docs.

Or for PUSH bit one can also look at RFC1122 which describes it as
optional.

BR, Karen

> -----Original Message-----
> From: Taps [mailto:taps-bounces@ietf.org] On Behalf Of Joe Touch
> Sent: 4. november 2015 02:44
> To: gorry@erg.abdn.ac.uk; Michael Welzl <michawe@ifi.uio.no>
> Cc: taps WG <taps@ietf.org>; touch@isi.edu
> Subject: Re: [Taps] RFC 6458 etc. in draft-welzl-taps-transports
>
>
>
> On 11/3/2015 5:33 AM, gorry@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