Re: Rechartering QUIC for Post Version 1 Work
Magnus Westerlund <magnus.westerlund@ericsson.com> Fri, 29 January 2021 16:22 UTC
Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 953AC3A1117 for <quic@ietfa.amsl.com>; Fri, 29 Jan 2021 08:22:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.351
X-Spam-Level:
X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.25, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
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 QhzkbG-6a3E3 for <quic@ietfa.amsl.com>; Fri, 29 Jan 2021 08:21:58 -0800 (PST)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130050.outbound.protection.outlook.com [40.107.13.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B14E03A1128 for <quic@ietf.org>; Fri, 29 Jan 2021 08:21:56 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IF/4Ee/umDftNfG8aM1R+URRYWFfpk5crMmEqzHNUNndLhuea3SM/A02OLnpnAZUrvBPwi9Kr2JnhKEev1ECJuUMoFkA/ttC9dwTBWOYJZdY9Se1+tkHSPDOEzFG3+NIeruPn2XFrXD5Z1yP68GQ7fUr38ceeHzGxheHEt3lapypRgXGqYU7os6h2DOglu6VM5Erv95Lv1oluMflFXBUAYLwsEHCnymL3lKfr0+HqbvhQvhNaoTMTiFCcw+yZNQ/CfhaAcdpEz4/tdGdpETCqUE7QJCgnOMI3q417oAXmWvlmV3HQJsjlzfNJc9fhjizhe9SmX9G5VaEoRKefBsixw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+nLbDC1RmWYMbFz8EfwejQ8WuIwZJGYDvXgppG01TcY=; b=Y6zM7wRcduLD6icEbGZ2oCkSxRKK3kp24w7sT/AoLdGafIYqXhOB9yFVL03RFOOHeVjBsDu93pFlk0a4JlZ1ZVwrkqkN/i3KJAr7ZJej3pV3kjABObIo1XXn0vKsmpxcyLOfyvo9hoKY9wtWeD9adkgQjEh55qyirtEV1HLFaB5bEhXtZ9vwPgSQENMOMWzIA/rp1meXe2aDaLUQdZiaUafVBPhYxuiJ6Eq8KosIfRU2CP4nsX42yRaRLnZ+k6KGsqLRLFhvnFsy+kqedZm/d4wS/MHZQYqqK4pE8vhgdnC7kexvxszVDMeYuLXa7jfxLZ9lpSh9DXNkifwUfhvjeA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+nLbDC1RmWYMbFz8EfwejQ8WuIwZJGYDvXgppG01TcY=; b=bKhcoLzUdWy3ZhSqTWfY3mzpmoyJHCRjE+m313ZHWt9iMJGiuTFsxLftP2BOLOnYC6UgkOYQf8AQl+bZrEq6hWJnNA9mr2WplSizM+uDE3xlnI7M+QfnleS1a4dpSDwlZA7B0b/aZouXYy3gRBtfpbSRZL+CleBTWosB7M3owUE=
Received: from (2603:10a6:803:10::30) by VI1PR07MB3071.eurprd07.prod.outlook.com (2603:10a6:802:1f::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3825.8; Fri, 29 Jan 2021 16:21:53 +0000
Received: from VI1PR0702MB3775.eurprd07.prod.outlook.com ([fe80::6cd2:247d:3389:381]) by VI1PR0702MB3775.eurprd07.prod.outlook.com ([fe80::6cd2:247d:3389:381%6]) with mapi id 15.20.3805.007; Fri, 29 Jan 2021 16:21:53 +0000
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
To: "lucaspardue.24.7@gmail.com" <lucaspardue.24.7@gmail.com>, "dschinazi.ietf@gmail.com" <dschinazi.ietf@gmail.com>
CC: "quic@ietf.org" <quic@ietf.org>
Subject: Re: Rechartering QUIC for Post Version 1 Work
Thread-Topic: Rechartering QUIC for Post Version 1 Work
Thread-Index: AQHW9AK1U/gwnJMsTECDUP3OtA6Nxao6IZAAgAAA4oCAAAGPAIAABO+AgAAWpoCAACTlAIAADsUAgAAzLICAAAbsgIAEIFeA
Date: Fri, 29 Jan 2021 16:21:53 +0000
Message-ID: <bb706327343136d8a6c38e56164df72247f84b86.camel@ericsson.com>
References: <CALGR9oaXpZp87ujmkDAO6Tuy=m-s8qKDY9-azpm_PhVAMfkq9A@mail.gmail.com> <20210126170048.GB364092@okhta> <D01160E4-C89E-4DF5-B0A7-C5138E33D9C1@eggert.org> <20210126170932.GC364092@okhta> <CALGR9oaO8Q7TC9zyajM20gZkZPR1cRDSv-SeDqo0MfaQbgfAjg@mail.gmail.com> <20210126184815.GD364092@okhta> <CAKcm_gNXkCko=H3VofwnubMDctCN7Smx0LDbH-ruYcTk7S4kTg@mail.gmail.com> <CAPDSy+4kVyrvmkd8vDOzASV36Y2iR2HEGzrSkxXJaMmED6JDww@mail.gmail.com> <CALGR9oZ6i2jzk6YWRhOnSfcH7hZugy5Juzhkc7U0iNSVrC77Yg@mail.gmail.com> <CAPDSy+5thdVV5uzBPuud6u4RmaGkCO-U5oiudxLr6Ysyk76EEg@mail.gmail.com>
In-Reply-To: <CAPDSy+5thdVV5uzBPuud6u4RmaGkCO-U5oiudxLr6Ysyk76EEg@mail.gmail.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-mailer: Evolution 3.28.5-0ubuntu0.18.04.2
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [158.174.130.243]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: e5d5f218-12d8-4735-3afe-08d8c471fd69
x-ms-traffictypediagnostic: VI1PR07MB3071:
x-microsoft-antispam-prvs: <VI1PR07MB30714A8C3F411339FDD4E6CC95B99@VI1PR07MB3071.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: M55TIzHudqQ85o/L1wB6HWlfe3aNZxgF02iBVJ/Ik2srsDVcKJKwAg2lZ8QEwzkVFDZvZms9pJlat0EnS8c1zZlNO6KmFvvRMUfh0LtxmkjTXy2VHsO5ii6LwHRDmsflgCXaqmeW+jlQf2cOXaKM76fI18fx568ZyFJvwvapkGWdNf9JEfdxh0vsB+zC0ARaeeBZFTqoYNY7px0VzQEbOt59gLjYrFPecd48a1TtsjQCssbgzrxjWhZILd0bdyPBefz9xH6f51KzYFWJknyAuqAuHoPR2UvQ2q16nVWw/y/hFwW+SqUrwAsIj0oKvbmv3kAge4pVVC1SsXPjv02Kxo/mhyw/K/Ls7GhXtBOYm9IFoBN9wLpvHELo5/F8s6BxkdMuRJVogDqPST9AX0sJhBrOf83fwszpsPZZwz9HB59pHrZXemX1mVy+eKu2MabPotvAsonfVAKTqi1q5Dvhx1wSzsbA72ZtmZ21nR7rUUTEvv+AOoALAGnRUJOYJ4eI4id263zLiJ8BvYa3cGCybJinyNK/QA69TRjtDvsXacraY6sAeLcZdp6Og80FXoNP
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR0702MB3775.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(346002)(376002)(396003)(136003)(366004)(66946007)(86362001)(64756008)(66446008)(66616009)(71200400001)(26005)(2616005)(66556008)(66476007)(6506007)(53546011)(44832011)(91956017)(99936003)(316002)(186003)(478600001)(110136005)(76116006)(5660300002)(8676002)(83380400001)(4326008)(6512007)(8936002)(6486002)(36756003)(2906002)(99106002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: a/xUPqbz/LLAasxfgXAM8qpruGkNrzk60XQyHg2cglfh63JblJJBYx9SA/eNFcRwJyd/re0S1LugU4F2CLyibw1wszY98NLo8oZGbh3uYmL3jGh/EDt8QEkpNO5bNud9JzR7LaFSyyDK2XkqNQlcGrvDcOakTL+v4nyNZy+tFGFj/MEFMjcFZeC5BbleMfMJWeXFr7g5jedJjI0HUcYt+s7jTxKkWOuZcACnySGtd2Jl5sRL4U7BFV42Ccmb/NGSs+irLJGHLT1tbB+MeFu1/U9xsVlkIsUTPk9XeaKlFIEqDRdi36/TxETsa7GhYFDh5wnZ4cf6jEiMPLnGxq1ZOsc41xNwmps+LeYKaH3Ugpaj0wxJftXyuSlS/QSg8NBgtc4ZYiS5f9iPc6twrCKI05Dnajz97KRb4FevcvR5C5nv7cKgg0lA6XjYo+GWYHXFQmRtTnn67x+i5mdkHiWMFUL7xBvqLcm6uxfNS3g/X3NBnMGFuxpJV+TbZ3mhn1evpO4NA7F0rcGuhxhL94KfKVqSTlgiq3IP3VeBEqHQaXAfP/UG/j0bxrOFTvQ2jk0wm5j4yLmoIAEC58EOI3cS3ZoCPRMqKS4Z7sDfeOvSiv8k3Py8AXRFhcu/nTQqVvWuO2GLYG4HYi147mxPESwKRdLxhrJcTHBrLq4flO0xRxIkMWh9gfXL/Em+m/6JNKTZjcJ+mXeebq0vdLK2w2ihlvLgHqPmQj4ZEl090MbJimZC7UWeJU9Q8FOBrY4Hm9x0uWt41TP6AkrEmV2kRh+2uZPZ33pjU8S5vmfSmQY0HYRjHnFSgrmBEMqG8needgLrxVWp8pN/OWHTbOldIYliX9/UbYBCiYXWffDHhUZiMuB/tj3VcAHYnTEMPsLcRl/Pi6L15KKc45D732nxf7DM2P33BhKnhzBp9BefCfBUUiAhv8HUDEfhPW33iZiWdeQR0ZQ8J9zuuhAzVYO4WCIPZyu43TSQeBQ9D7YrsuHURdE0u5YwKYGLRAQ9pmNvUuLLKVqXvvOsDKc6/FHaTy29rm5Z29PMy4mqhAy3TlAwfeuEim+ngATBRRDGzaul+hqHJdVzPRvIn1DjpMacWiq04w==
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-zr8pPzRz8LIaSdsfvdKx"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: VI1PR0702MB3775.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e5d5f218-12d8-4735-3afe-08d8c471fd69
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jan 2021 16:21:53.4176 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: SjJdROeZ4rEJl1wkmcWAz4TmgjaZtscGkqKvhWrue9B2TwLe46HmqJROtMKP7cn6k3awbhHTyxx+pVm5uk8av6NFE13BnDThwxUApYSFfM8=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB3071
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/kWpT0OmrfOE8zy1gpmgwJoOexiY>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Jan 2021 16:22:01 -0000
Hi, So yes this charter is a significant departure from previous QUIC charters. It goes from be very specific for exactly what the WG should work with to be much wider paint the allowed scope for the WG. The main reason for this change is to force a recharter for every individual document the WG main want to adopt and work on. On Tue, 2021-01-26 at 17:21 -0800, David Schinazi wrote: > Thanks for your reply, Lucas. Responses inline. > > On Tue, Jan 26, 2021 at 4:56 PM Lucas Pardue <lucaspardue.24.7@gmail.com> > wrote: > > Hi David, > > > > Thanks for the feedback. I've responded in-line, and some of that text > > responds to points Ian raised too. > > > > On Tue, Jan 26, 2021 at 9:54 PM David Schinazi <dschinazi.ietf@gmail.com> > > wrote: > > > I'm supportive of the overall direction of this rechartering, with some > > > concerns though: > > > > > > 1) multipath is not mentioned in this charter - based on the conversations > > > we've had over the past months, I think we should be explicit about > > > whether multipath is in or out of scope > > > > > > > The intention was that the new charter would allow the group, as the focal > > point for QUIC-related things, to consider work such as multipath QUIC. The > > guidance for discussion of multipath is still the same as Lars' sent to the > > WG in November [1]. To borrow a bit of that, we still feel it premature to > > adopt an proposal as a work item. > > > > I see your point, I'm OK with not precluding multipath as long as the guidance > from November still holds. But then again, a recharter could be seen as > invalidating prior charter-related decisions so being explicit could be useful > here. To be explicit, from my perspecitve this charter will allow the WG to adopt work on multipath extensions for QUIC. > > > There's an interesting contrast between this point and your second point. It > > seems there's a balance between being specific and appearing not open to new > > ideas. > > > > From my perspective, multipath was important enough of a topic to warrant its > own interim a few months back which isn't true of any of our extensions - so I > guess that's where I'd draw the line in terms of mentioning something or not? > > > > 2) +1 to Ian and Dmitri's comments about mentioning current examples in a > > > way that seems to preclude other extensions, we could remove the examples > > > to help clarify > > > > > > > (previously I commented as an individual, but now with a chair hat on) If 3 > > people have the same comment, it's likely a sign that some polishing up of > > the text would help. Specific suggestions always appreciated. > > > > I liked Dmitri's proposal to remove the examples. If we want to include > examples that are in scope, I'd suggest also including examples of what's not > in scope to make it clear that neither list is exhaustive. Will think about this. Listing things that we know the wg will work on at this stage is easy. List things that would be out of scope but not that far out of scoep that it is to obvious is not necessarily easy. > > > > 3) I was surprised by "Extensions intended for Standards Track need to > > > have general applicability to multiple application protocols." and I don't > > > think our charter should preclude these. We shouldn't ban standard-track > > > protocols that require a QUIC extension to function properly. Perhaps > > > another way we could phrase this would be to say that "The QUIC WG is only > > > chartered to work on extensions that have general applicability to > > > multiple application protocols. Extensions that are specific to an > > > application protocol should be defined in the WG responsible for that > > > protocol, in consultation with the QUIC WG." -- without stating anything > > > about Standards track. > > > > > > > I'd like Lars or Magnus to respond to this point too. IIUC the intention of > > the text is to say that QUIC transport extensions that wish to be adopted by > > this group under Standards Track, should apply broadly. An extension > > designed for only one specific use, and which the authors do not wish to > > spend time considering design changes that would permit more-general usage, > > isn't a great use of the WGs time trying to standardise. However, the QUIC > > WG is a good venue to catalog such work as Informational or Experimental. I > > don't believe we want to prevent QUIC extensions that are specific to a use > > from being developed as Standards Track elsewhere in the IETF. > > > > I love bikeshedding document tracks as much as the next person, but I don't > think that needs to be litigated in the charter - the charter should help us > decide what we allocate WG time for - if an extension is not seen as valuable > by the WG, I don't think it's worth it to spend WG time to publish it as > experimental or informational. Either we care about the extension or we don't, > right? I think there was a point of making it clear that an experimental specification for an extension could make sense when it is not obvious that this is the best choice and where maybe more wide implementation experience is needed. In these cases experimental specs can be good. I don't necessarily think informational for proprieatary extensions is necessary worth the WG effort. QUIC and its code point registries are flexible enough that for most proprietary extensions can publish it where where they desire and register the code points. > > > > 4) It seems off to me to simultaneously declare HTTP/3 logging in-scope > > > and HTTP/3 out-of-scope. I think qlog is useful, but if we want to use it > > > outside of the QUIC transport protocol then maybe it should live in > > > another WG. > > > > > > > That's one (fair) interpretation. The intent here is to make it clear that > > the QUIC WG no longer owns the HTTP/3 application mapping, as always > > intended. qlog doesn't change protocols so working on that falls into the > > deployment working area. I expect a large part of the QUIC WG population, to > > start with, will be made up of deployers of HTTP/3. So while there has been > > some discussion on the most suitable home for qlog and splitting the drafts > > up [2], keeping them developed in a single WG would seem like the best way > > to channel effort and attention of active deployers. If others have a strong > > sense that is not the case they should speak up. > > > > Members of the QUIC implementers community have been attending other QUIC- > adjacent working groups, so I don't think placing them in QUIC will impact > implementation energy. I'd even argue that placing these in QUIC might > constrain them to QUIC instead of also encouraging other protocols. If someone > were to write a draft about how to use qlog with SCTP, would it belong in the > QUIC WG? So I have considered this a fair amount what to do with QLOG. It is obious that the format could be generally applicable to many protocols. However, where it has significant usage and experience is with QUIC. We have asked around a bit, and my conclusion so far is that it is not worth spending a year running BOFs and trying to figure out if this is needs its own WG or not, and which protocol actually want to define events for the general format. Thus, I think the road to most easily get a general format and a QUIC event description for it is to just simply start doing it. That way if someone wants to do an SCTP next year, they can do it in TSVWG and just reference the format spec done by QUIC. I hope that answers that question. > > > > 5) "Maintenance and evolution of the QUIC base specifications" isn't very > > > clear to me - does that mean that working on future versions of QUIC is in > > > or out of scope? > > > > > > > The full paragraph states: > > > > " Maintenance and evolution of the QUIC base specifications that describe > > its invariants, core transport mechanisms, security and privacy, loss > > detection and recovery, congestion control, version and extension > > negotiation, etc. This includes the specification of new versions of QUIC, > > if necessary." > > > > I think that's clear but if you have some suggestions to improve it we'll > > take a look. > > > > Nope, that is very clear - I must have missed it which is my fault. Apologies. > > But now I'm realizing that the "if necessary" in that last sentence might be > interpreted differently by various folks when we start wondering what features > should go into QUIC v2. I'd suggest just removing the "if necessary". Okay, I think we can remove those two words. Cheers Magnus Westerlund
- Rechartering QUIC for Post Version 1 Work Lucas Pardue
- Re: Rechartering QUIC for Post Version 1 Work Dmitri Tikhonov
- Re: Rechartering QUIC for Post Version 1 Work Lars Eggert
- Re: Rechartering QUIC for Post Version 1 Work Dmitri Tikhonov
- Re: Rechartering QUIC for Post Version 1 Work Lucas Pardue
- Re: Rechartering QUIC for Post Version 1 Work Dmitri Tikhonov
- Re: Rechartering QUIC for Post Version 1 Work Ian Swett
- Re: Rechartering QUIC for Post Version 1 Work David Schinazi
- Re: Rechartering QUIC for Post Version 1 Work Lucas Pardue
- Re: Rechartering QUIC for Post Version 1 Work David Schinazi
- Re: Rechartering QUIC for Post Version 1 Work Matt Joras
- Re: Rechartering QUIC for Post Version 1 Work Roberto Peon
- Re: Rechartering QUIC for Post Version 1 Work Behcet Sarikaya
- Re: Rechartering QUIC for Post Version 1 Work Lars Eggert
- Re: Rechartering QUIC for Post Version 1 Work Ian Swett
- Re: Rechartering QUIC for Post Version 1 Work David Schinazi
- Re: Rechartering QUIC for Post Version 1 Work Roberto Peon
- Re: Rechartering QUIC for Post Version 1 Work Spencer Dawkins at IETF
- Re: Rechartering QUIC for Post Version 1 Work Spencer Dawkins at IETF
- Re: Rechartering QUIC for Post Version 1 Work Lars Eggert
- Re: Rechartering QUIC for Post Version 1 Work Lars Eggert
- Re: Rechartering QUIC for Post Version 1 Work Magnus Westerlund
- Re: Rechartering QUIC for Post Version 1 Work Christian Huitema
- Re: Rechartering QUIC for Post Version 1 Work Roberto Peon
- Re: Rechartering QUIC for Post Version 1 Work Magnus Westerlund
- Re: Rechartering QUIC for Post Version 1 Work Sean Turner
- Re: Rechartering QUIC for Post Version 1 Work Behcet Sarikaya
- Re: Rechartering QUIC for Post Version 1 Work Lars Eggert
- Re: Rechartering QUIC for Post Version 1 Work Sean Turner
- Re: Rechartering QUIC for Post Version 1 Work Lars Eggert