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

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 27 February 2019 16:50 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: 104all@ietfa.amsl.com
Delivered-To: 104all@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 148BC130FEC; Wed, 27 Feb 2019 08:50:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 NDH1_wJFWNro; Wed, 27 Feb 2019 08:50:00 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86831130EED; Wed, 27 Feb 2019 08:50:00 -0800 (PST)
Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id A37A8380BE; Wed, 27 Feb 2019 11:49:54 -0500 (EST)
Received: by sandelman.ca (Postfix, from userid 179) id 1218355C; Wed, 27 Feb 2019 11:49:59 -0500 (EST)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 0F82B556; Wed, 27 Feb 2019 11:49:59 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Tom Pusateri <pusateri@bangj.com>
cc: Fred Baker <fredbaker.ietf@gmail.com>, Working Group Chairs <wgchairs@ietf.org>, IETF <ietf@ietf.org>, recentattendees@ietf.org, 104all@ietf.org
In-Reply-To: <8A1CA67F-C9AA-4FF0-A678-F5D4B038D1FF@bangj.com>
References: <155089851917.5347.209761560453230605.idtracker@ietfa.amsl.com> <23D062E4-4464-48C2-9464-61697C2351D6@cooperw.in> <A7B3EF23-DE19-4330-A660-D27744B95A34@gmail.com> <3a201a22-6ed2-ab83-5205-a28af7ba49d7@labn.net> <ea13d9b6-78bb-8067-d8f2-a7b98c5de307@pi.nu> <EE41BDFB-ED4E-4944-9E87-5E56766FAE37@cooperw.in> <8EB337F5-D68B-4160-A26C-E8C7693E13F2@gmail.com> <9DE19647-BA11-4ACD-B57B-FE49D760F255@gmail.com> <8A1CA67F-C9AA-4FF0-A678-F5D4B038D1FF@bangj.com>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Wed, 27 Feb 2019 11:49:59 -0500
Message-ID: <12420.1551286199@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/104all/psKuGyi-WAb4ZlwIqiLcADdTOuQ>
X-Mailman-Approved-At: Wed, 27 Feb 2019 14:33:00 -0800
Subject: Re: [104all] [Recentattendees] Further Clarification Re: IETF 104 Preliminary Agenda
X-BeenThere: 104all@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Official Communication about IETF 104 <104all.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/104all>, <mailto:104all-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/104all/>
List-Post: <mailto:104all@ietf.org>
List-Help: <mailto:104all-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/104all>, <mailto:104all-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Feb 2019 16:50:03 -0000

Tom Pusateri <pusateri@bangj.com> wrote:
    >>> On Feb 24, 2019, at 11:34 PM, Stewart Bryant <stewart.bryant@gmail.com> 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 :-)

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-