On 11/3/2015 10:37 PM, Karen Elisabeth Egede Nielsen wrote: > 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.
Oh, I was certainly not claiming that IETF specifications are always complete. The key is to derive the abstract API requirement from the implementation extensions (and update the spec, ultimately). > Or for PUSH bit one can also look at RFC1122 which describes it as > optional. RFC1122 is a standards track doc that clearly updates RFC793, even though that sort of marking was not part of IETF process when it was issued. Joe > > BR, Karen > >> -----Original Message----- >> From: Taps [mailto:taps-boun...@ietf.org] On Behalf Of Joe Touch >> Sent: 4. november 2015 02:44 >> To: go...@erg.abdn.ac.uk; Michael Welzl <mich...@ifi.uio.no> >> Cc: taps WG <taps@ietf.org>; to...@isi.edu >> Subject: Re: [Taps] RFC 6458 etc. in draft-welzl-taps-transports >> >> >> >> 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 _______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
