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

[Michael Welzl]

Dear all,

Sorry for not being able to attend the TAPS meeting on site or even remotely. I 
just finished watching the recording, and I noticed that the question of RFC 
6458  - "why is the SCTP part of draft-welzl- ..  based on only RFC 4960 and 
not on RFC 6458?" - was brought up several times. I'd like to provide an answer 
and start a discussion about this.

There are two reasons why RFC 6458 wasn't used in 
draft-welzl-taps-transports-00: a very mundane one, and a more serious one. 
I'll list them both and hope we can discuss the second reason.

1) Reason one: RFC 6458 is quite long, and I wanted to limit the amount of work 
I'm putting into the -00 version, given that the point was to show people the 
procedure and the idea and see what they think, and not to fully cover 
everything 100% correctly yet. Basically, I didn't want to risk writing out all 
the stuff from RFC 6458 and then have people tell me to go away  :-)

2) Reason two, more serious: RFC 6458 is Informational, and my understanding 
was that this is just one description of one API implementation, not a 
recommendation or even prescription of what all SCTP implementations must 
provide. However, my decision for draft-welzl-taps-transports was to *exclude* 
things that are only optional to implement - I don't think we want to end up 
with a TAPS system that provides services that, alas, on Operating System XY 
are not available because here only a subset of the API is implemented. 
Therefore I went with a minimal set of functions that I thought we can assume 
are implemented everywhere (well, at least in every system that claims to 
"follow the spec").  Can we assume that every system that claims to implement 
SCTP in accordance with the spec fully implements RFC 6458?



A side note about TCP, because Karen made a comment about the TCP API too:  a 
similar logic applies here, irrespective of whether the API is old or not: I 
think we should cover whatever a system claiming to "implement the protocol in 
accordance with the spec" has to cover. Going down the path of looking at 
actual socket API implementations is dangerous in that we end up in "only 
implemented here, not there" - land. We want a minimal set of mechanisms that 
are (or at least really should be! for that, what else can we use as a basis 
than our own recommendations?!) available everywhere. Karen, you specifically 
mentioned URG and PSH and how they are implemented; what is it in 
draft-welzl-.. about these two mechanisms that you don't agree with?

Cheers,
Michael

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

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

[gorry]

A note just on the INFO status of SCTP APIs (below):
>
> Dear all,
>
> Sorry for not being able to attend the TAPS meeting on site or even
> remotely. I just finished watching the recording, and I noticed that the
> question of RFC 6458  - "why is the SCTP part of draft-welzl- ..  based on
> only RFC 4960 and not on RFC 6458?" - was brought up several times. I'd
> like to provide an answer and start a discussion about this.
>
> There are two reasons why RFC 6458 wasn't used in
> draft-welzl-taps-transports-00: a very mundane one, and a more serious
> one. I'll list them both and hope we can discuss the second reason.
>
> 1) Reason one: RFC 6458 is quite long, and I wanted to limit the amount of
> work I'm putting into the -00 version, given that the point was to show
> people the procedure and the idea and see what they think, and not to
> fully cover everything 100% correctly yet. Basically, I didn't want to
> risk writing out all the stuff from RFC 6458 and then have people tell me
> to go away  :-)
>
> 2) Reason two, more serious: RFC 6458 is Informational, and my
> understanding was that this is just one description of one API
> implementation, not a recommendation or even prescription of what all SCTP
> implementations must provide. However, my decision for
> draft-welzl-taps-transports was to *exclude* things that are only optional
> to implement - I don't think we want to end up with a TAPS system that
> provides services that, alas, on Operating System XY are not available
> because here only a subset of the API is implemented. Therefore I went
> with a minimal set of functions that I thought we can assume are
> implemented everywhere (well, at least in every system that claims to
> "follow the spec").  Can we assume that every system that claims to
> implement SCTP in accordance with the spec fully implements RFC 6458?
>
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.
>
>
> A side note about TCP, because Karen made a comment about the TCP API too:
>  a similar logic applies here, irrespective of whether the API is old or
> not: I think we should cover whatever a system claiming to "implement the
> protocol in accordance with the spec" has to cover. Going down the path of
> looking at actual socket API implementations is dangerous in that we end
> up in "only implemented here, not there" - land. We want a minimal set of
> mechanisms that are (or at least really should be! for that, what else can
> we use as a basis than our own recommendations?!) available everywhere.
> Karen, you specifically mentioned URG and PSH and how they are
> implemented; what is it in draft-welzl-.. about these two mechanisms that
> you don't agree with?
>
> Cheers,
> Michael
>
> ___
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps
>
Gorry

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

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

[Joe Touch]

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

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

[Joe Touch]

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 
>> Cc: taps WG ; 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

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

[Karen Elisabeth Egede Nielsen]

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-boun...@ietf.org] On Behalf Of Joe Touch
> Sent: 4. november 2015 02:44
> To: go...@erg.abdn.ac.uk; Michael Welzl 
> Cc: taps WG ; 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