Re: [btns] WG Action: Conclusion of Better-Than-Nothing Security (btns)

"Laganier, Julien" <> Tue, 16 March 2010 20:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3B2D73A69D0 for <>; Tue, 16 Mar 2010 13:02:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.566
X-Spam-Status: No, score=-106.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id b2G5egHMQGch for <>; Tue, 16 Mar 2010 13:02:53 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id DCCAA3A699F for <>; Tue, 16 Mar 2010 13:02:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=qcdkim; t=1268769783; x=1300305783; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20<> |To:=20""=20<>|CC:=20Nicolas=20 Williams=20<>,=20"lha@stacken.kth .se"=0D=0A=09<>,=20"Polk,=20William=20T ."=20<>|Date:=20Tue,=2016=20Mar=2020 10=2013:02:19=20-0700|Subject:=20RE:=20[btns]=20WG=20Acti on:=20Conclusion=20of=20Better-Than-Nothing=20Security=0D =0A=20(btns)|Thread-Topic:=20[btns]=20WG=20Action:=20Conc lusion=20of=20Better-Than-Nothing=20Security=0D=0A=20(btn s)|Thread-Index:=20AcrFOTPzarpigjGYTTyOglsz1XlPtgACD2Kg |Message-ID:=20<BF345F63074F8040B58C00A186FCA57F1C6AA5637>|References:=20<20100316183>=0D=0A=20<20100316184333.G O14993@Sun.COM>|In-Reply-To:=20<20100316184333.GO14993@Su n.COM>|Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=+yeHeZ++efDcqTZ33m9DYNx91EMSBPoI5xExZ/8YCq4=; b=aS9XtYj9bdQPzn/E/iwSZBOO3Rdb3mSNh/cVo247XiA58HNJ2JnlySzG fZV7DwWT8qpIbYQCp0oRYX662tPitAkBIwtwW/7BEFHp2quL6/C5/OlaH +Ki6My3CbBjQJo7mRCW1zfBpi6L7JmbJzrfTLrzd05n2Ogt5O/dehhsIz 4=;
X-IronPort-AV: E=McAfee;i="5400,1158,5922"; a="36521646"
Received: from ([]) by with ESMTP; 16 Mar 2010 13:03:02 -0700
X-IronPort-AV: E=Sophos;i="4.49,650,1262592000"; d="scan'208";a="53702204"
Received: from unknown (HELO ([]) by with ESMTP/TLS/RC4-MD5; 16 Mar 2010 13:03:02 -0700
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Tue, 16 Mar 2010 13:02:23 -0700
Received: from ([]) by ([]) with mapi; Tue, 16 Mar 2010 13:02:23 -0700
From: "Laganier, Julien" <>
To: "" <>
Date: Tue, 16 Mar 2010 13:02:19 -0700
Thread-Topic: [btns] WG Action: Conclusion of Better-Than-Nothing Security (btns)
Thread-Index: AcrFOTPzarpigjGYTTyOglsz1XlPtgACD2Kg
Message-ID: <>
References: <> <20100316184333.GO14993@Sun.COM>
In-Reply-To: <20100316184333.GO14993@Sun.COM>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "Polk, William T." <>, Nicolas Williams <>, "" <>
Subject: Re: [btns] WG Action: Conclusion of Better-Than-Nothing Security (btns)
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Better-Than-Nothing-Security Working Group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 16 Mar 2010 20:02:55 -0000

Nicolas Williams wrote:
> On Tue, Mar 16, 2010 at 11:39:18AM -0700, IESG Secretary wrote:
> > The ADs would like to thank everyone who has been involved in the
> > BTNS specification work, the chairs, Sam Hartman who was the responsible
> > AD when the BTNS working group was formed, and various reviewers who
> > helped greatly improve the BTNS specifications.
> I second this, and also thank the current security ADs.


And let me add that while I am bit disappointed that we couldn't conclude the API documents, I think it is fair to say that the most important deliverables are there: the unauthenticated IPsec mode (RFC 5386), and the IPsec connection latching (RFC 5660.)

Hopefully these two useful pieces of work get implemented and leveraged on by applications in a near future. When that happens, the chances to document a proven API will IMHO greatly increase. In my experience it has never been easy to work on APIs within the IETF, especially in cases such as this where there isn't a lot of hands-on experience with interfacing applications to the network mechanism.

Thanks again to everybody that got involved in this.