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

Karen Elisabeth Egede Nielsen <karen.nielsen@tieto.com> Wed, 04 November 2015 06:37 UTC

Return-Path: <karen.nielsen@tieto.com>
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA901ACE33 for <taps@ietfa.amsl.com>; Tue, 3 Nov 2015 22:37:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level:
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HnIwUFERGrtW for <taps@ietfa.amsl.com>; Tue, 3 Nov 2015 22:37:43 -0800 (PST)
Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 972C61ACE30 for <taps@ietf.org>; Tue, 3 Nov 2015 22:37:43 -0800 (PST)
Received: by igbhv6 with SMTP id hv6so29259415igb.0 for <taps@ietf.org>; Tue, 03 Nov 2015 22:37:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc:content-type; bh=D/KYh2wgkw5Zy4TYmAope6V2DIY9ZZjF30F+eoD9fak=; b=5r9imqC1RtLmKlIU1jt+Topt7LNh5gC38Q/ddiP7rYPKbc+IZdJTO05oB7WVk76YtO AgkxeQHwnI3txPcqOVYR/d2st5OisJ0QUlS4m2UHQdTA6zNl/ETJ/3zWE8iz3gk1OMkK 4w1yfsX7FGQyPxS/AyrV9QsHZrEq9d6/GUPnY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc:content-type; bh=D/KYh2wgkw5Zy4TYmAope6V2DIY9ZZjF30F+eoD9fak=; b=fw9H8tkHj4WroUqwLUD+PIbv0IMmMWQSQP8ckhV/CF3tQ0OafjD1BiQN1M+z3Vb8IU NLZ8H5joy1I8lbhTiRZfzfsnp2Q5haZwfQQoiRuMagptZW/k5pVCPOma6vFGAEds5zzz vitxnFNGw9tKkoGqKLGTPrkkrRJi6jDBTsEi9Y7aKfQmoe2JY5wa97WUyTi5wxrsrUsi +uPOJfVWXX2buWujjfz7rulMB8dhqyrOW/AaePjmy80pgUDc88+cvQCN2/DnCQye1D3R CjLJHLZrcNDerls1EQot1a83JNGBp69HgWZWIVSGPMXzAanST+ad/pkQvNzEk64p3Zlm oClg==
X-Gm-Message-State: ALoCoQl/HYCVNVK9uUlJDv+3jnAwaR5x/F8oqgQDgtLKC4S1jMCtCeCOxXMoxq0sa3hXj8oV7zLld2qk6jnknOTW4SUVKG7ShjIOYQj0nUedOTGukUUC9+0=
X-Received: by 10.50.55.72 with SMTP id q8mr11865103igp.2.1446619062942; Tue, 03 Nov 2015 22:37:42 -0800 (PST)
From: Karen Elisabeth Egede Nielsen <karen.nielsen@tieto.com>
References: <945E755A-3EB4-4325-8257-9ECC2EE3FC4B@ifi.uio.no> <6f6d07994fde18062e39ced796f199a9.squirrel@erg.abdn.ac.uk> <5638F272.8000507@isi.edu>
In-Reply-To: <5638F272.8000507@isi.edu>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQLqPZ7YNAMdgKXUwCSqRxv62pP6+wJmZ4dkAtnyCyGcLxfesA==
Date: Wed, 4 Nov 2015 15:37:44 +0900
Message-ID: <92d887c7d587ff05d9ca04dcddb17f4a@mail.gmail.com>
To: Joe Touch <touch@isi.edu>, gorry@erg.abdn.ac.uk, Michael Welzl <michawe@ifi.uio.no>
Content-Type: text/plain; charset=UTF-8
X-DomainID: tieto.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/taps/brwHsir8V_Ce_Ax67Ac5tVMGAAM>
Cc: taps WG <taps@ietf.org>
Subject: Re: [Taps] RFC 6458 etc. in draft-welzl-taps-transports
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussions on Transport Services <taps.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/taps>, <mailto:taps-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/taps/>
List-Post: <mailto:taps@ietf.org>
List-Help: <mailto:taps-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/taps>, <mailto:taps-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Nov 2015 06:37:45 -0000

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>rg>; 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