Re: [btns] Q: How to deal with connection latch breaks?

"Mike Eisler" <mre-ietf@eisler.com> Thu, 30 July 2009 10:41 UTC

Return-Path: <mre-ietf@eisler.com>
X-Original-To: btns@core3.amsl.com
Delivered-To: btns@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92E493A6857 for <btns@core3.amsl.com>; Thu, 30 Jul 2009 03:41:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.816
X-Spam-Level:
X-Spam-Status: No, score=-1.816 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, J_CHICKENPOX_15=0.6]
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 ZwOsoLQ1q27x for <btns@core3.amsl.com>; Thu, 30 Jul 2009 03:41:17 -0700 (PDT)
Received: from webmail6.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) by core3.amsl.com (Postfix) with ESMTP id 385773A67D7 for <btns@ietf.org>; Thu, 30 Jul 2009 03:41:17 -0700 (PDT)
Received: from webmail.eisler.com (localhost [127.0.0.1]) by webmail6.dreamhost.com (Postfix) with ESMTP id 8E86C60559 for <btns@ietf.org>; Thu, 30 Jul 2009 03:41:18 -0700 (PDT)
Received: from 216.240.24.140 (proxying for 216.240.24.140) (SquirrelMail authenticated user mre-ietf@eisler.com) by webmail.eisler.com with HTTP; Thu, 30 Jul 2009 03:41:19 -0700
Message-ID: <a0459a6daa0f2f67ff64eb0b2e328a58.squirrel@webmail.eisler.com>
In-Reply-To: <9481.1248714083@marajade.sandelman.ca>
References: <e2cf27e98757db0c8561baadfb3ca335.squirrel@webmail.eisler.com> <20090726221331.GS1020@Sun.COM> <9481.1248714083@marajade.sandelman.ca>
Date: Thu, 30 Jul 2009 03:41:19 -0700
From: "Mike Eisler" <mre-ietf@eisler.com>
To: btns@ietf.org
User-Agent: SquirrelMail/1.4.19
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Subject: Re: [btns] Q: How to deal with connection latch breaks?
X-BeenThere: btns@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Better-Than-Nothing-Security Working Group discussion list <btns.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/btns>, <mailto:btns-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/btns>
List-Post: <mailto:btns@ietf.org>
List-Help: <mailto:btns-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/btns>, <mailto:btns-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jul 2009 10:41:18 -0000

On Mon, July 27, 2009 10:01 am, Michael Richardson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>>>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams@sun.com> writes:
>     >> My conclusion is that the API ought to provide information for
>     >> the application about the connection latching, and it just does
>     >> not seem to be there.  If you can point me to a discussion of
>     >> this topic on the WG mail list, then I'll clear.  I'm not trying
>     >> to alter consensus, but I do want to make sure that this topic
>     >> was considered.
>
>     Nicolas> APIs are nice, but existing apps won't use them until
>     Nicolas> updated, and anyways, connection latching adds value even
>     Nicolas> without adding APIs, which means we need a default response
>     Nicolas> to latch breaks in the absence of new APIs (either because
>     Nicolas> not implemented or not used).
>
>   So, errno value from write(2) is not a new API.
>   A new errno value should provide enough information, I think.
>
>   However, an application might know what to do with ETIMEOUT, while it
> would not know what to do with EUNLATCHED or some such....

Isn't the application the entity that decided to enable latching?  If so,
the application (or its author) needs to be prepared to deal with new
error indication.

If not, what is the model for enabling latching?
>
> - --
> ]     Y'avait une poule de jammé dans l'muffler!!!!!!!!!        |
> firewalls  [
> ]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net
> architect[
> ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device
> driver[
> ]    h("Just another Debian GNU/Linux using, kernel hacking,    ruby
> guy");  [
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Finger me for keys
>
> iQEVAwUBSm3dYoCLcPvd0N1lAQLnNQf8CNCa4TWJY5I/TvtAH4+eyLbHzyO+I/dp
> /l5Zcs3Ld16qhYh9OeWogBT2wCeicdx3cL1PdoyibTOfMw/PPxUSY+HKWyR78Ky5
> afHA8JxRypvpLqULU7i2jCfwNJZbQi4wojPYl9oeQGAKKmwX3hsBQxKtWY5OWLh+
> ExHXfZpGfvauG+LVYHMSNATJEveESpgqRXQyxUqGEChblWVFANHjX/OLJTRCZ7vQ
> xXhI2rGIlBOwl9ssAx4vejDR0js8vQ98RXy7XiVJhGZq6+hklOuZfmW44T4iHUNk
> emB7EpEWwO7MshVPRCxARIXjICaG2xnQ0XR9ZwSvbtNMsS1vCGVeVg==
> =5max
> -----END PGP SIGNATURE-----
> _______________________________________________
> btns mailing list
> btns@ietf.org
> https://www.ietf.org/mailman/listinfo/btns
>


-- 
Mike Eisler, Senior Technical Director, NetApp, 719 599 9026,
http://blogs.netapp.com/eislers_nfs_blog/