Subject: [babel] A quick summary of babel@ietf

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 23 Jul 2016 23:47:11 +0200

Dear all,

IETF is over, we've had the first meeting of the Babel WG.  It went
pleasantly smoothly.  You'll find the full recording of the meeting[1],
the minutes, as well as all the meeting materials, including slides[2].

[1] http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF96_BABEL&chapter=chapter_1
[2] https://datatracker.ietf.org/meeting/96/materials.html#babel

In short:

  - the chairs said some things;
  - I gave a talk about my plans for evolving the protocol, the audience
    seemed to agree;
  - Barbara Stark gave a talk about her proposed management information
    model, in which she notably recommended to debloat the model; there
    was a short misunderstanding between her and Margaret Cullen, which
    was quickly cleared up;
  - Dave gave a talk about routing with hackerboards, a talk that was not
    specific to Babel but was well-received and appeared to me to be
    eye-opening to at least some audience members.

My feeling right now -- unless we f*ck up really badly, this is going to
be a productive and fun working group.

-- Juliusz

---

From: Alia Atlas <[email-masked]>
Date: Sat, 23 Jul 2016 22:32:58 -0400

The meeting went very well.   There was energy,  good discussion,  and
engagement from those wanting to use it & implement.   It was an excellent
start.

Regards,
Alia

On Jul 23, 2016 5:47 PM, "Juliusz Chroboczek" <[email-masked]>
wrote:

> [1]
> http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF96_BABEL&chapter=chapter_1
> _______________________________________________
> babel mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/babel
>

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Mon, 25 Jul 2016 14:31:14 +0200

> be a productive and fun working group.

I agree. One thing that I would like to emphasise from the meeting was
the direction Juliusz set out for the working group (the "traditions"
part of his talk, for those looking it up in the slides/video). I
believe this is especially important for bridging the existing Babel
open source community to the IETF process and working group.

The two most important points in this were "work happens on the mailing
list" and "running code required". While it was later clarified that
there is no formal IETF rules imposing any of these on the working
group, I believe they are fundamental for the kind of work we want to do
here. So I will heartily endorse these principles and hope that we can
build a working group tradition that builds upon them.

-Toke

---

From: Alia Atlas <[email-masked]>
Date: Mon, 25 Jul 2016 09:48:55 -0400

Hi Toke,

> build a working group tradition that builds upon them.

I agree that it was useful to have an open discussion about how we'd like
the WG culture to be and  have the WG run.  I found it useful to have.

I'd like to clarify a couple points here, however, since there are a few
subtleties.

First, in at least theory in the IETF, work always happens on the mailing
list for
working groups.  This is part of the formal IETF process.  Specifically,
all consensus
calls and decisions have to be done or at least re-done/confirmed on the
mailing list.
Juliusz did a fine job of emphasizing why that is the case - to encourage
participation of those who aren't
traveling, to allow those whose written English is more persuasive or clear
than
their spoken to more easily participate, to let technical points be seen
clearly
without regard to presentation skills, and so on.

Second, running code is great - but its lack shouldn't stand as a barrier
to writing
a draft or suggesting an idea.  A long time ago, the IETF Routing Area
required that
any standards-track draft have two independent implementations in order for
work to
proceed.   Bill Fenner and Alex Zinin wrote an RFC that removed that
requirement,
but it is still up to the Working Group Chairs to set policy for their WGs
as to when
drafts can progress out of the WG.  For instance, in IDR, it is still
required that there
are two implementations.  BESS just recently added a requirement for at
least one
implementation.

There can be a bit of a cycle where putting a feature in code makes it
harder to be
willing to change or update a draft based upon others' technical concerns.
It can
also be faster to write a draft, get improvements and agreement on the
idea, and then
go write code.  How this works can vary.

In the Babel WG, I think that there are enough motivated people that
testing ideas
out in code and discussing them will likely happen.  This is where setting
the culture
of the WG comes in.

Regards,
Alia