Re: [LOOPS] BOF co-chairs thinking on LOOPS next steps

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Thu, 25 July 2019 18:59 UTC

Return-Path: <spencerdawkins.ietf@gmail.com>
X-Original-To: loops@ietfa.amsl.com
Delivered-To: loops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EEB51201C9 for <loops@ietfa.amsl.com>; Thu, 25 Jul 2019 11:59:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 6ImOn-T6pYSM for <loops@ietfa.amsl.com>; Thu, 25 Jul 2019 11:59:38 -0700 (PDT)
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA6531201B3 for <loops@ietf.org>; Thu, 25 Jul 2019 11:59:37 -0700 (PDT)
Received: by mail-lf1-x12e.google.com with SMTP id q26so35322279lfc.3 for <loops@ietf.org>; Thu, 25 Jul 2019 11:59:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EtpY0ZSR2WxDCgxFTUAz122BwJGtwVszrFKpIbTK9/Y=; b=KiNCFs8S4k1VN523epad0DBmxJN3Us4B6bQbXR5mzXq3e3RTKnt0XRAW4ICzR0z/vC Gd8wwAi8Bav/DR+dKtt6oE4bp+fjquF+Obw8dG+6XRN+7/aaeK8hH8gkj+8kbG74IQax 7UuTmVEy9xMtBQ0QeFWjwmX3qhuUMJkNqMz8GFiM6cVilI+XHRZIV5i848iQZYahQ1Cp xp7D/Lw2iF+Nx9JNBSPeLx5m1728EpvIKyy5nSSwT0HZ+2yziswzgVcnNUnD9HFZQ/0k 5cH2ZBI0Rk9511x0NEcYNtxuG7O9kSCt1xOrCIthuOnP1F/LGsApO+FBL9Mh/NJb2GuW wQsw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EtpY0ZSR2WxDCgxFTUAz122BwJGtwVszrFKpIbTK9/Y=; b=atMbNZYO2TBEcrgkTz5ef8M92dbErUfBmqINuhygIVx+LBcQ1hzDv0d2adxI2NkpZC /dz5dgZJusX1YDGOtYsviMcRA7OKDWZjpXoWH51EFvQ8S+i1lHeuDnGjxM6Q6qe4L2MX r+shJLiYWbZ2XREXKWwdCDme0KAtscefCfad5r4uysyGmaNlUx7ZLjNyko24YI+ofy8I MvNb+x+rJC02prx5/hVnq8bPeJw3OV8Fc2BmZ0X6inJvTKiJLAyjGrkS0+4AJFMC/6GH m9h8WrP3srZJz6nqC2quO0h4fVWrsvy3SWZ7uvaEySWmxXBvmy5iqkzR01/GpPR4htnn k3oQ==
X-Gm-Message-State: APjAAAVSI9kaI8LFWHYGML5w4did+Fwa9zR8gF8RbFIHWqatdiDS1snp 4DfPVNMdaG+X2XMZisvLlIld05Qt2uuJ/obWdZg=
X-Google-Smtp-Source: APXvYqw/7ypIlD6iqTSwjAAMyHuJw+IntI2nfPzbiQqFaXyqt/xADq+MI/74bg6GAYZIEPtbtFyYYcWLj+xXFs48YkM=
X-Received: by 2002:a19:f806:: with SMTP id a6mr28856900lff.102.1564081175842; Thu, 25 Jul 2019 11:59:35 -0700 (PDT)
MIME-Version: 1.0
References: <CAKKJt-eRGJe+9PtEC7xgFz+HA0zsr_sR0NUgKRmJ-P5Q3XBg-A@mail.gmail.com> <CAPjWiCSbPioTHkYBpX73qxzO=H1sJDZpCMCKzBKoU4rZLLhwMQ@mail.gmail.com> <E6659E42-D6D7-4033-B4D6-9305823063D2@tzi.org>
In-Reply-To: <E6659E42-D6D7-4033-B4D6-9305823063D2@tzi.org>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Thu, 25 Jul 2019 14:59:10 -0400
Message-ID: <CAKKJt-c24RdPyZRoK-B6fXuN0xABUsU=p7Y6UFwAcENfjE3oOQ@mail.gmail.com>
To: Carsten Bormann <cabo@tzi.org>
Cc: Marie-Jose Montpetit <marie@mjmontpetit.com>, Magnus Westerlund <magnus.westerlund@ericsson.com>, Mirja Kuehlewind <ietf@kuehlewind.net>, loops@ietf.org, Suresh Krishnan <suresh@kaloom.com>
Content-Type: multipart/alternative; boundary="000000000000e2d3df058e860618"
Archived-At: <https://mailarchive.ietf.org/arch/msg/loops/9TBFm5XmlgPQHoWKNGaqLUK7phQ>
Subject: Re: [LOOPS] BOF co-chairs thinking on LOOPS next steps
X-BeenThere: loops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Local Optimizations on Path Segments <loops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/loops>, <mailto:loops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/loops/>
List-Post: <mailto:loops@ietf.org>
List-Help: <mailto:loops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/loops>, <mailto:loops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jul 2019 18:59:52 -0000

Still wearing no hats, because I no longer have any dots ...

On Thu, Jul 25, 2019 at 12:56 AM Carsten Bormann <cabo@tzi.org> wrote:

> On Jul 24, 2019, at 18:17, Marie-Jose Montpetit <marie@mjmontpetit.com>
> wrote:
> >
> > Standardisation of what? The architecture? The protocols (beware there
> is already FECFRAME and others)? The proxies?
>
> Hi Marie-José,
>
> details of the thinking that was developed in the side meetings that
> happened at the previous two IETF meetings can be found at
>
> https://github.com/loops-wg/charter
>
> The BOF actually added one piece of information I didn’t previously
> perceive that way:
> People seem to really want to tackle the host-to-node case (as needed,
> e.g., for going through WiFi access clouds) right away, not just the
> in-network (node-to-node) case.  That would be the one thing I would change
> based on my recollection of the BOF.  But of course there may be other
> things; it may be worth to now have another round of discussion of the
> proposed charter.
>

Communication is good, but one thing I mentioned in my summary of my chat
with the ADs was

   - Here's a hint from the ADs - if the proponents can come up with a
   clear charter, limited in scope, that will make their lives easier, and
   make it easier for them to charter this work :D

So, it's reasonable for the LOOPS community to consider adding
host-to-node, but it's worth checking whether this would expand the scope
of the requested charter, and whether excluding host-to-node makes the
initial work easier to complete.

My impression, and Magnus might say I'm insane, was that Magnus is right on
the edge of whether this work can be chartered without a second, working
group-forming BOF. If the LOOPS community can't live without host-to-node,
the community should add it. If the community can make use of LOOPS without
host-to-node and add it later, the community might consider whether that
reduces the scope of the initial proposed charter enough to help Magnus
approve it :-)

Best wishes,

Spencer