Subject: [113attendees] HotRFC at IETF-113 -- 2nd call for participation

From: Aaron Falk <[email-masked]>
Date: Mon, 14 Mar 2022 09:50:11 -0400

*Do you have an idea, problem space, or proposal that IETFers should hear
about?*
*Do you want to propose IETF or IRTF work but aren’t sure if your idea is
ready or who will be interested?*

Agenda requests are now being accepted for the Request for Conversation
(HotRFC) lightning talk session. Presenters will have 4 minutes to make
their case for collaboration. Interested folks can continue the discussion
after the session. Goals include encouraging brainstorming conversations,
helping new work proposals find collaborators, raising awareness of
relevant work going on elsewhere, and promoting BarBoFs. Past HotRFC topics
covered a broad range of topics:

*Collaboration:* proposals for new standards work or new research topics
that haven't been discussed elsewhere, potentially relevant research that
may be ready for the IETF
*Notification:* new topics on the agenda in a working group or research
group, cross-area IETF work
*Enlightenment:* updates on relevant technologies, industry advances that
could affect IETF participants.

With strict time limits, concise talks will give viewers a sense of whether
they’d like to know more and, importantly, coordinates on how to do so.

With the hybrid meeting we’re going to keep things rather simple and permit
only live presentations, either on-site or remote via MeetEcho.  Slides
must be submitted in advance. Video of the session will be recorded for
later viewing.

   - To request a slot, submit a short abstract to [email-masked] no later
   than Friday, March 18th, 2400 UTC that includes the following
      - Talk title
      - Presenter, Affiliation
      - Short topic abstract (topics should be IETF-related in some way)
      - Coordinates to learn more, contact those involved, &/or relevant
      formal or side meetings
   - All talks will be presented live, whether in-person or MeetEcho
      - Slides (ppt or pdf) must be submitted to [email-masked] no later
      than Saturday, March 19th, 2400 UTC.
      - TALKS MUST BE NO MORE THAN 4 MINUTES IN LENGTH.  *At four minutes
      exactly, we cut the microphone and transition to the next speaker.*
   - The session will be on *Sunday, March 20th at TIME_TBD*, (expected to
   be during or after the IETF Welcome Reception)

Talk abstracts will be posted on the meeting agenda and will be updated as
requests come in.

Thanks to Spencer Dawkins who will be chairing the session on-site.  I hope
you’ll tune in.

--aaron & Spencer

---

From: nanic <[email-masked]>
Date: Tue, 15 Mar 2022 08:59:55 +0200

Hi,

at least on iOS 15.4, out since yesterday, you can easily add your digital certificate

https://support.apple.com/en-gb/guide/iphone/iph7f2865325/ios

and there are a number of sites to make it easier, such as for example

https://covidpass.marvinsextro.de/

It pitched up on my (also updated) Watch.

I have not found a convenient way to display ID, probably a credit card sized holder with lanyard where you can put in a printout of the QR code and the ID card facing the other way.

Then there is the IATA Travel Pass app to consider which may make life easier at check in.

greetings, el

—
Sent from Dr Lisse’s iPhone/iPad

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 22 Mar 2022 00:29:18 +0100

I wanted to follow up on this while HotRFC is still on my mind.

Aaron did a fabulous job of backstage preparation, and Liz Flynn with the
Secretariat and the Meetecho team provided fabulous last-minute support to
make this happen, even when Aaron was moving from Boston to LA, with little
or no Internet access this past weekend.

We had about 50 attendees in Meetecho, and I'd guess about 30 people in the
room, which isn't a bad turnout.

We had 8 speakers, at least two of whom were first-time attendees. IIRC,
four were in the room, and four were remote via Meetecho.

I'm not impartial, but I think HotRFC is one of the best things that the
IESG put in place while I was on the IESG.

CoViD-19 was not kind to us - we didn't have a HotRFC from IETF 107 to IETF
111, and Aaron and Alexa did a great job of putting SOMETHING in place for
IETF 112, using Gather. At IETF 113, we were back to Aaron's original
format, except that we also had remote presenters this time.

I'd like for the IESG to think a bit about how the IETF can use HotRFC more
effectively. Most of the work behind HotRFC has been done by people who
weren't on the IESG, so I'm talking about making sure that we don't forget
to think about when to schedule it, who should be hosting it, and how to
publicize it - given that, the rest of HotRFC is easy.

Even making it visible to people who might not arrive early for the
Hackathon or for tutorials, but would want to arrive early for HotRFC,
before they make their travel arrangements would be helpful.

I haven't talked with Aaron about any of this (when he unpacks, he would
likely have opinions), or with any of the presenters or participants, but
they can reply here, and tell you what they think as well.

Best,

Spencer

p.s. thanks to Alia Atlas and Deborah Brungard, who helped think HotRFC up
in a bar in Singapore. Always spend time in bars at IETF meetings. 😉

---

From: Michael Richardson <[email-masked]>
Date: Tue, 22 Mar 2022 10:57:21 +0100

Spencer Dawkins at IETF <[email-masked]> wrote:
    > I'd like for the IESG to think a bit about how the IETF can use HotRFC
    > more effectively. Most of the work behind HotRFC has been done by
    > people who weren't on the IESG, so I'm talking about making sure that
    > we don't forget to think about when to schedule it, who should be
    > hosting it, and how to publicize it - given that, the rest of HotRFC is
    > easy.

This was my first HotRFC.  I have mostly chosen to take that time as away/me-time.
But, it worked out for me, and I joined in person.

I think that the best part of HotRFC is that the time is limited, and that no
questions are permitted.  This avoids any kind of debate, and really forces
presenters to focus on their key message.

The lack of debate likely also lowers the barrier: if you know you can't get
attacked in the mic line, it may be less intimidating.

I tried the HotRFC last time, via gather.town, with the recorded videos and
questions on the floor.  It's entirely a different thing, and I think that
actually, it is usefully complementary.

I will note that *DISPATCH is also become more of a thing.

While previously we often had a 1st non-WG forming BOF followed by ML and charter
discussions, we now have:
      HotRFC -> *DISPATCH -> WG-forming BOF

That's okay with me, but it goes to the RFC2026 is wrong debate, and we
should probably tell people about this more explicitely.  That doesn't mean
we have to freeze this process: but we do need to tell people it's happening.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: John C Klensin <[email-masked]>
Date: Tue, 22 Mar 2022 07:14:28 -0400

--On Tuesday, March 22, 2022 10:57 +0100 Michael Richardson
<[email-masked]> wrote:

>...
> I tried the HotRFC last time, via gather.town, with the
> recorded videos and questions on the floor.  It's entirely a
> different thing, and I think that actually, it is usefully
> complementary.

> While previously we often had a 1st non-WG forming BOF
> followed by ML and charter discussions, we now have:

> That's okay with me, but it goes to the RFC2026 is wrong
> debate, and we should probably tell people about this more
> explicitely.  That doesn't mean we have to freeze this
> process: but we do need to tell people it's happening.

I actually don't think it interacts much with 2026 although I do
wonder whether how much introducing additional steps into the
process --whether they involve 

	a non-WG-forming BOF -> ML discussion -> charter
	proposal -> a WG-forming BOF -> more discussion and
	charter revision -> chartering

or

	discussion, *DISPATCH, -> WG-forming BOF -> charter
	discussion -> chartering

(with the initial discussion in the second case taking many
forms) -- is contributing to general delays and some people's
sense that it is impossible to get real work done in the IETF in
any efficient and timely way.

While, as work-proposing mechanisms, the tone is certainly
different (especially along the fear of being attacked dimension
you mention), I'm not sure whether HotRFC is significantly
different from the BarBOFs of yesteryear.

    john

---

From: "Border, John" <[email-masked]>
Date: Tue, 22 Mar 2022 11:29:09 +0000

It is more like a convenient, centralized place to announce Bar BOFs...

-----Original Message-----
From: 113attendees <[email-masked]> On Behalf Of John C Klensin
Sent: Tuesday, March 22, 2022 7:14 AM
To: Michael Richardson <[email-masked]>
Cc: IRTF Discuss <[email-masked]>; WG Chairs <[email-masked]>; 113 attendees <[email-masked]>; IESG <[email-masked]>; IETF Discussion <[email-masked]>
Subject: Re: [113attendees] HotRFC at IETF-113 -- 2nd call for participation

**EXTERNAL EMAIL** 

--On Tuesday, March 22, 2022 10:57 +0100 Michael Richardson <[email-masked]> wrote:

>...
> I tried the HotRFC last time, via gather.town, with the  recorded 
>videos and questions on the floor.  It's entirely a  different thing, 
>and I think that actually, it is usefully  complementary.

> While previously we often had a 1st non-WG forming BOF followed by ML 
> and charter discussions, we now have:

> That's okay with me, but it goes to the RFC2026 is wrong debate, and 
> we should probably tell people about this more explicitely.  That 
> doesn't mean we have to freeze this

I actually don't think it interacts much with 2026 although I do wonder whether how much introducing additional steps into the process --whether they involve 

or

(with the initial discussion in the second case taking many
forms) -- is contributing to general delays and some people's sense that it is impossible to get real work done in the IETF in any efficient and timely way.

While, as work-proposing mechanisms, the tone is certainly different (especially along the fear of being attacked dimension you mention), I'm not sure whether HotRFC is significantly different from the BarBOFs of yesteryear.

    john

--
113attendees mailing list
[email-masked]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/113attendees__;!!Emaut56SYw!ns3s2cRVvygXRTSlQ4Jl0eVwnu3vQnQTmodGTvmEhTPw34vtRcS6pUwM9FAO0TV-8g$

---

From: Michael Richardson <[email-masked]>
Date: Tue, 22 Mar 2022 14:24:31 +0100

John C Klensin <[email-masked]> wrote:
    > I actually don't think it interacts much with 2026 although I do wonder

It's not so much that it interacts with 2026,etc. so much as that those
documents are wrong.

    > is contributing to general delays and some people's sense that it is
    > impossible to get real work done in the IETF in any efficient and
    > timely way.

I would say that it's contributing to a sense that people don't know what the
flavour of the day is.

    > While, as work-proposing mechanisms, the tone is certainly different
    > (especially along the fear of being attacked dimension you mention),
    > I'm not sure whether HotRFC is significantly different from the BarBOFs
    > of yesteryear.

Actual BarBOFs, in bars with napkins and beer (and no remote things to get in
the way), would be before HotRFC :-)

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 22 Mar 2022 16:07:31 +0100

I should say that I'm still acting as the Aaron Interpreter, but
only because he's now arrived at his new home in LA, and is using a cell
phone until his Internet service is installed. He can chime in anytime, and
start an email with "what Spencer MEANT to say, was ..."

But, moving on ...

On Tue, Mar 22, 2022 at 2:25 PM Michael Richardson <[email-masked]>
wrote:

> wonder

Aaron has taken suggestions from other people, but the format we used for
HotRFC this week was almost unchanged from what Aaron proposed to the IESG
before IETF 102.

I said in the chair slides that HotRFC presentations are Requests For
Conversations, and people can have *many *reasons to want to talk for four
minutes.

If people are trying to figure out where a HotRFC talk fits into our
documented process and our published guidance about "bringing new work into
the IETF", that's probably not going to be the same place for every person
and every proposal.

Would it be good to write that down, so that people could understand that
clearly? Probably ... 🙂

Best,

Spencer