Re: [nbs] setsockopt() is bad.

Toerless Eckert <eckert@cisco.com> Mon, 08 November 2010 10:03 UTC

Return-Path: <eckert@cisco.com>
X-Original-To: nbs@core3.amsl.com
Delivered-To: nbs@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 547F83A6939 for <nbs@core3.amsl.com>; Mon, 8 Nov 2010 02:03:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.599
X-Spam-Level:
X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FAKE_REPLY_C=2.012, FRT_STOCK2=3.988, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ro4gDpEdmNnP for <nbs@core3.amsl.com>; Mon, 8 Nov 2010 02:03:41 -0800 (PST)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 85E5E3A693A for <nbs@ietf.org>; Mon, 8 Nov 2010 02:03:41 -0800 (PST)
Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAKVZ10yrR7Hu/2dsb2JhbACiBHGhFJp3DYU7BIRYhX0
X-IronPort-AV: E=Sophos;i="4.58,313,1286150400"; d="scan'208";a="378542345"
Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 08 Nov 2010 10:04:02 +0000
Received: from pita (pita.cisco.com [171.71.177.199]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id oA8A427E009534; Mon, 8 Nov 2010 10:04:02 GMT
Date: Mon, 08 Nov 2010 02:03:30 -0800
From: Toerless Eckert <eckert@cisco.com>
To: Javier Ubillos <jav@sics.se>
Message-ID: <20101108100330.GH17818@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.4i
Cc: Name-based Sockets List nbs <nbs@ietf.org>
Subject: Re: [nbs] setsockopt() is bad.
X-BeenThere: nbs@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Name based sockets discussion list <nbs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/nbs>, <mailto:nbs-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nbs>
List-Post: <mailto:nbs@ietf.org>
List-Help: <mailto:nbs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nbs>, <mailto:nbs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Nov 2010 10:03:42 -0000

See rfc3678, that's the rfc for IGMP Dave was referring to.
The type-safe API are explicitly defined such as
getsourcefilter/setsourcefilter as opposed to the generic socket APIs
ioctl/setsockopt.

But i think the main point Dave tried to make is to avoid bothering
with the details of an actual API such as those from rfc3678 initially
in the IETF effort and start defining abstract APIs like the one in 
rfc2743.

Then go to some actual standards organization for concrete APIs like the
austin group (POSIX) present the abstract API there and work with them
towards the concrete API.

On Mon, Nov 08, 2010 at 04:13:44PM +0800, Javier Ubillos wrote:
> Dave.
> 
> You spoke during todays bof (and just now at the MPTCP group) about your
> previous experience where setsockopt()s where not a great way to go.
> 
> What did you end up doing (other than moving the setsockopt()s to the
> appendix).
> 
> What was the right way to do it then?
> 
> // Javier



> _______________________________________________
> nbs mailing list
> nbs@ietf.org
> https://www.ietf.org/mailman/listinfo/nbs