[Ace] Fwd: [saag] IETF#89 ACE Summary

Hannes Tschofenig <hannes.tschofenig@gmx.net> Wed, 05 March 2014 16:59 UTC

Return-Path: <hannes.tschofenig@gmx.net>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 923C11A01EB for <ace@ietfa.amsl.com>; Wed, 5 Mar 2014 08:59:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level:
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham
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 XvTvcVroa9pU for <ace@ietfa.amsl.com>; Wed, 5 Mar 2014 08:59:23 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id BD3A81A00E9 for <ace@ietf.org>; Wed, 5 Mar 2014 08:59:22 -0800 (PST)
Received: from [192.168.10.133] ([31.133.156.1]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0ML72n-1WKy2x2Qi1-000Kvu for <ace@ietf.org>; Wed, 05 Mar 2014 17:59:18 +0100
Message-ID: <531757E4.9050408@gmx.net>
Date: Wed, 05 Mar 2014 17:59:16 +0100
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: "ace@ietf.org" <ace@ietf.org>
References: <5317576C.6090400@gmx.net>
In-Reply-To: <5317576C.6090400@gmx.net>
X-Enigmail-Version: 1.5.2
X-Forwarded-Message-Id: <5317576C.6090400@gmx.net>
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="np2udL4hVgo4mQwwMndHBabhlugJ0DlEE"
X-Provags-ID: V03:K0:Id1Z23V0uzP6rCpTp2mV0iVSNIsVPB/ULC1pJajKfuoGUMwx1ri RBiUStyzyH5fkQd4VCiOc1J0X5zJc4fuxNLgshAtddULPaZwxXC/fYFBD8GuIQ2VJJpKYTD Z9rUFN2Rsc1YDK4vJqPkGqpakNC9+8aVyqxLnxl4WkbnKTS+OUOW9W5lcGiMwKlYsgHZ0GV CEwIT5mFZhFWNesxNYF8Q==
Archived-At: http://mailarchive.ietf.org/arch/msg/ace/r4yP_x_bAJF02a0KtX-FO7soSqk
Subject: [Ace] Fwd: [saag] IETF#89 ACE Summary
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Mar 2014 16:59:24 -0000

FYI: Here my short summary from the BOF (as a write-up for the SAAG).


-------- Original Message --------
Subject: [saag] IETF#89 ACE Summary
Date: Wed, 05 Mar 2014 17:57:16 +0100
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
To: saag@ietf.org

We held the ACE BOF this morning from 9am to 11:30am.

We started with a presentation about what constrained node networks are,
explained use cases & requirements and discussed design choices. We
concluded with a gap analysis.

There was good support for doing the work in the IETF and there was a
fair amount of feedback from the audience regarding the charter text.
About 30 persons indicated that they are willing to review
specifications and 15 persons said that they will be contributing
documents.

The feedback from the audience included:

- Scope of the work

Should it be focused on CoAP / DTLS only? In particular, the question
about the suitability of the developed solutions for HTTP and SMS
transport was raised.

- Assumptions

What assumptions are being made by the use cases in terms of requirement
for a clock, interworking with existing infrastructure, interaction with
proxies, and intermittent connectivity of different parties (off-line
use cases).

- Provisioning of credentials and other configuration parameters

Participants suggested to consider looking at the entire life cycle of
these IoT devices to prevent problems later with provisioning. While
those do not necessarily be standardized in this group there was a
desire to avoid later problems.

As next steps the charter discussions will have to continue to resolve
some of the raised questions. The BOF chairs encouraged the audience to
develop strawman proposals to gain further experience about the
underlying assumptions.

Ciao
Hannes