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

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Mirja,

On Tue, Jul 30, 2019 at 5:34 AM Mirja Kuehlewind <[e-mail]>
wrote:

> Hi Carsten, hi Spencer,
>
> > On 25. Jul 2019, at 20:59, Spencer Dawkins at IETF <
> [e-mail]> wrote:
> >
> > 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 :-)
>
> Yes, it would be possible to charter without another BoF a small and
> well-scoped group, however, it also would be possible to work on small and
> well-defined pieces of work without a new working group. This was one of
> the reasons why this was not a non-wg-forming BoF because it is not clear
> yet if a new group is needed or the resulting pieces of standardization
> work are small enough to fit into an existing group.
>
> Therefore, I really recommend focus on defining the standardising work
> items that you think are needed rather than trying to do any word-smithing
> of a potential charter (that eventually is not needed).
>

Thanks for giving me the chance to clarify - I really was talking about
chartering work, not just chartering a working group, but that wasn't clear
from my note. As you said, knowing what the work is, in more detail, will
help you and Magnus know what to do next.

So, my suggestion for the interested community is to nail down

   1. In order to "do LOOPS", what already exists, that can be used without
   changes?
   2. what already exists, but needs to be extended for LOOPS?
   3. what needs to be created, because nothing exists that meets the needs?

 I'm not a LOOPS proponent (the ADs asked me to chair the BOF about a month
before IETF 105), but speaking as someone who hasn't been involved in
depth, I wonder about

   1. How a sender tunes FEC dynamically - is that automatic, based on FEC
   mechanisms people are thinking about, or is there work to do there?
   2. How a sender knows whether to do FEC, retransmission, or both FEC and
   retransmission, dynamically?
   3. How a sender knows that it shouldn't be doing anything, because
   anything it does won't help ("first, do no harm")?

Does everyone know how to do those three things, except me? :-)

Pointers to specifications would be awesome ...

Spencer


> Mirja
>
>
>
>