Subject: [104all] Further Clarification Re: IETF 104 Preliminary Agenda

From: IETF Agenda <[email-masked]>
Date: Fri, 22 Feb 2019 21:08:39 -0800

Hi everyone,

Our message earlier today announcing the preliminary agenda [1] was missing some further context. As previously mentioned by Alissa after IETF 103 [2], the IESG wanted to continue the unstructured time experiment at IETF 104.

Wednesday's schedule has regular sessions until 13:20, unstructured time in the afternoon, and the plenary in the evening at 17:10. This leaves almost four hours of unstructured time for attendees to reserve for side meetings. During this period, there will also be one unique Technology Deep Dive session with the acronym WGTLGO [3].

Monday through Friday, we will have two rooms available for attendees to reserve for side meetings as usual. On Wednesday afternoon, we will have five rooms available for side meetings. Further details about how to sign up for these rooms will be announced shortly. 

Thanks,
IETF Secretariat

[1]  https://mailarchive.ietf.org/arch/msg/ietf-announce/_JeP2fQ7rHPosZWpNtpl8I_uL5U
[2]  https://mailarchive.ietf.org/arch/msg/ietf-announce/H64AuTYhxsGqM1a8BfTkszCZyso
[3]  https://www.ietf.org/blog/ietf104-bofs/

---

From: Loa Andersson <[email-masked]>
Date: Tue, 26 Feb 2019 09:33:55 +0800

Ted,

On 2019-02-25 23:30, Ted Lemon wrote:
> On Feb 25, 2019, at 6:11 AM, Loa Andersson <[email-masked] 
> <mailto:[email-masked]>> wrote:
>> My advice would be to scratch the agenda, start over, leave the
>> experiment out and optimize to avoid conflicts!
> 
> How would they do that?   What information do they have now that they 
> didn’t have before they published the agenda?

I didn't say there is new any new information AFTER the agenda was
posted. The new info is the preliminary agenda itself! I you look at
MPLS and LSR meeting across the lunch slot on Wednesday, we have some
key participants of the MPLS wg, required to be in the LSR wg meeting.

I'm really unhappy about the current agenda.

What I said was that IESG should refocus in the light of the many
conflicts and redo the agenda with the objective to avoid conflicts.

/Loa
> 
> I ask because in fact, this agenda is the least conflicted one /for 
> me/ that I have seen in a long time.   I’m /really/ happy with the 
> current agenda, and can really only lose from a re-do.   This is not to 
> say that a re-do is not the right thing to do.   What I’m saying is that 
> the fact that a couple of people have griped about conflicts and about 
> an over-full agenda is /not data./   It is /anecdata/.
> 
> As Stewart has said, if we want to do better at this, we need /data, 
> /not /anecdata./
> /
> /

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert
Bronze Dragon Consulting             phone: +46 739 81 21 64

---

From: Michael Richardson <[email-masked]>
Date: Tue, 26 Feb 2019 07:48:29 -0500

Ted Lemon <[email-masked]> wrote:
    > they have good data. I’m saying they don’t have good data. The fact
    > that you have a conflict is not good data. It’s an anecdote. I don’t
    > have a conflict.
    > That’s also an anecdote. Anecdotes aren’t useful guidance here.

I also think that the RTG area has had very good conflict resolution in the
past, and that they don't have a lot of cross-area participants.  That is,
this agenda, which for many of us, is average for conflicts, is very
surprising for some RTG area people, because they suddendly are experiencing
what the rest of us have experienced for a decade.

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

---

From: Василий Долматов <[email-masked]>
Date: Wed, 27 Feb 2019 10:35:20 +0300

Agreed…

There are number of options for side meetings which can be used and IETF could assist in organizing it.

For instance - to reserve rooms on Saturday-Sunday-Friday_afternoon_ for possible use for side meetings.

I agree that IETF time should be used for IETF mostly and any modifications in the schedule should lower number of conflicts between IETF WG meetings.

dol@

> 25 февр. 2019 г., в 18:29, Greg Mirsky <[email-masked]> написал(а):
> 
> Dear All,
> I'm disappointed to find that the number of conflicts for me at IETF-104 is as high as in Bangkok which was two times higher than at any meeting before. I'm stressed that I'll have to run from DetNet to BFD to deliver presentations on work being done, forget being able to follow the discussion adequately. If that's the new normal, then why to come to the meeting at all. 
> I strongly encourage IESG to let us use all available time for WG sessions and let attendees use their time for "corridor talks".
> 
> Regards,
> Greg
> 
> 
> 
> 
> On Fri, Feb 22, 2019 at 9:08 PM IETF Agenda <[email-masked] <mailto:[email-masked]>> wrote:
> Hi everyone,
> 
> [1]  https://mailarchive.ietf.org/arch/msg/ietf-announce/_JeP2fQ7rHPosZWpNtpl8I_uL5U <https://mailarchive.ietf.org/arch/msg/ietf-announce/_JeP2fQ7rHPosZWpNtpl8I_uL5U>
> [2]  https://mailarchive.ietf.org/arch/msg/ietf-announce/H64AuTYhxsGqM1a8BfTkszCZyso <https://mailarchive.ietf.org/arch/msg/ietf-announce/H64AuTYhxsGqM1a8BfTkszCZyso>
> [3]  https://www.ietf.org/blog/ietf104-bofs/ <https://www.ietf.org/blog/ietf104-bofs/>
> 
> -- 
> 104all mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/104all <https://www.ietf.org/mailman/listinfo/104all>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 27 Feb 2019 11:49:59 -0500

Tom Pusateri <[email-masked]> wrote:
    >>> On Feb 24, 2019, at 11:34 PM, Stewart Bryant <[email-masked]> wrote:
    >>>
    >>> A better approach might be to ask people at registration what sessions they needed to attend.
    >>
    >> An even better approach, although it delays feedback by one meeting,
    >> would be to look into the IETFers Application data. People list what
    >> they want to attend for the purpose of calendar maintenance. That would
    >> inform the next meeting's agenda development.

    > While a neat idea, it’s not currently possible because I don’t save any
    > private data. And while no user is associated with that data, (I don’t
    > even create users), it is something that could be collected anonymously
    > in the future. There’s a lot that could be done with anonymous
    > statistics or even creating actual users (like automatic blue sheet
    > sign in using Bluetooth LE Proximity sensors or locating colleagues or
    > subscribing to notifications), but I haven’t had time to think through
    > the GDPR implications.

Your GDPR concerns are a good point.
I don't think we need to go to BTLE to see if you are actually there.
In particular, that fails to catch the case where people wanted to be there.

Among those of us that don't use your app, but rather use the datatracker ics
creation tool, we should have data in the logs about what people selected.
Alas, Google calendar does not you edit the calendar URL, so it's hard to
update what you want to add/remove items.  So I added a layer of indirection:

cd /ssw/docs/SSW/ietf/meeting/ietf104

curl -s >agenda.ics 'https://datatracker.ietf.org/meeting/104/agenda.ics#6lo,6man,6tisch,dnssd,homenet,lwig,gaia,hrpc,v6ops,opsawg,netconf,dnsop,anima,babel,bier,roll,tokbind,teep,suit,secevent,secdispatch,rats,ipsecme,ace,acme,dots,lamps,core,cbor,capport,cacao,ksk,smart'

and I add this agenda.ics file to my calendar program(s).
agenda.html takes the WG names as #foo,bar, while agenda.ics takes them as ?foo,bar)

What this does *not* tell you is which items I added for "like", and which
ones I added because it's a must attend.  Also I admit that this time I just
copy and pasted from last time, and added a few things.

In particular, part of this exercise is for me to see what conflicts I have.
I wish I could intelligently subscribe to a calendar entry such that I'd get
updates if it moved, but actually have it in my calendar, not have a new
calendar.  Instead, I'm force to copy entries to my calendar to remember how
I've decided to resolve the conflict, and that breaks the updates (such as
room changes).  I suppose I should use your app and star things, but it's
just too many moving parts :-)