Subject: Registration for remote participation

From: IETF Chair <[email-masked]>
Date: Tue, 9 May 2017 12:01:19 -0700

For remote participants at IETF meetings, registration is currently optional. Remote participants may join a session at an IETF meeting by entering any name or pseudonym of their choice into the current form used for logging in to MeetEcho.

The IESG is soliciting community feedback on a proposal to require registration for remote participants at IETF meetings. The objective of requiring registration for real-time remote participation is to provide better data to the IETF community and leadership about the size and make-up of the remote participant base. As remote participation grows, having more reliable remote participation data will allow the service to be better tailored to those using it and the community as a whole, and will help us understand the potential impact of remote participation on in-person participation. We understand that even with required registration the data collected will not be perfect, complete, or unspoofable, but we believe it would provide a more credible basis for analysis than the data available today.

The proposal is as follows:

Remote participants would be required to register (for free) by providing the information below (* denotes required fields). Registration would be mandatory to access MeetEcho sessions in real time and to join the remote mic queue during a session.

Title
First / Given Name*
Last / Family Name*
Company / Organization
ISO 3166 Country of Residence*
Email*
Gender
Have you attended an IETF meeting in person before?
Have you attended an IETF meeting remotely before?

Upon registering, participants would be issued a registration ID, just as they are today.

To join a session, participants would be asked to input the registration ID. The same email-based facility that is currently available to retrieve a forgotten registration ID would continue to be available. The cookie-based “Remember me” option would also still be available. The only difference from how login works today is that the option to "Join without registration ID" would be removed. Other options for authentication (leveraging a user-chosen password or datatracker credentials) might be explored further in the future.

Remote participation registration data would be stored and secured by AMS and MeetEcho just as it is currently today. As is the case now, no registration or login would be required to access MeetEcho recordings, audio recordings, YouTube videos, or jabber rooms. And no changes are being proposed as to the handling of virtual blue sheets.

We'd like to hear from the community about this proposal. Please send comments to [email-masked] <mailto:[email-masked]>, or exceptionally to [email-masked] <mailto:[email-masked]>, preferably by May 30, 2017.

Thanks,
The IESG

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 9 May 2017 21:08:46 +0100

No major objection but a few minor comments:-

- I'd be happier if there was a re-iteration that we're not going
to charge remote folks until the remote input experience is much
better and the community have agreed to such charging.
- I think there ought be some ack that this policy (if applied)
may be tee-ing up charging remote folks, as something that might
be needed depending on how the remove/on-site ratios evolve. (It
seemed odd to me that charging was not mentioned.)
- IIRC, there were a couple of times in the 2 meetings when I was
remote where I needed to get in to meetecho a 2nd time with a
different ID. While that particular bug may be fixed (or maybe
was on my side, not meetecho's) it'd be a shame if folks could
not do that kind of thing. I'm not sure how that'd best be handled.

Cheers,
S.

---

From: Ted Hardie <[email-masked]>
Date: Tue, 9 May 2017 13:30:30 -0700

Hi Stephen,

> seemed odd to me that charging was not mentioned.)

As someone who argued against mentioning registration fees when Alissa
shared a draft, you can at least partially blame me for the oddity.  I
still don't think it belongs in this message, because what we face at the
moment is data so noisy that we can't tell how many people we're serving at
all nor who and where they are.  Because we can't tell who we're serving,
we can't tell whether the service is fit for the purpose very easily.

If they are primarily folks in the hotel, who can't be in two rooms at
once, we have one set of issues; if they are primarily folks at the end of
low bandwidth, high RTT paths to the venue, we have a very different set of
issues.  We also don't know reliably whether we have a small coterie of
very dedicated remote participants or a wide smattering of folks dipping
their toes in for a session or two.

We need that data first.

Once we have it, there may be many things in the set of ways to support the
service that come to light; since those might be fund raising from external
parties rather than charging, I don't think we ought to anticipate that
stage at this one.

Hope that makes sense,

Ted

> > For remote participants at IETF meetings, registration is currently
> optional. Remote participants may join a session at an IETF meeting by
> entering any name or pseudonym of their choice into the current form used
> for logging in to MeetEcho.
> >
> > The IESG is soliciting community feedback on a proposal to require
> registration for remote participants at IETF meetings. The objective of
> requiring registration for real-time remote participation is to provide
> better data to the IETF community and leadership about the size and make-up
> of the remote participant base. As remote participation grows, having more
> reliable remote participation data will allow the service to be better
> tailored to those using it and the community as a whole, and will help us
> understand the potential impact of remote participation on in-person
> participation. We understand that even with required registration the data
> collected will not be perfect, complete, or unspoofable, but we believe it
> would provide a more credible basis for analysis than the data available
> today.
> >
> > Remote participants would be required to register (for free) by
> providing the information below (* denotes required fields). Registration
> would be mandatory to access MeetEcho sessions in real time and to join the
> remote mic queue during a session.
> >
> > Title
> > First / Given Name*
> > Last / Family Name*
> > Company / Organization
> > To join a session, participants would be asked to input the registration
> ID. The same email-based facility that is currently available to retrieve a
> forgotten registration ID would continue to be available. The cookie-based
> “Remember me” option would also still be available. The only difference
> from how login works today is that the option to "Join without registration
> ID" would be removed. Other options for authentication (leveraging a
> user-chosen password or datatracker credentials) might be explored further
> in the future.
> >
> > Remote participation registration data would be stored and secured by
> AMS and MeetEcho just as it is currently today. As is the case now, no
> registration or login would be required to access MeetEcho recordings,
> audio recordings, YouTube videos, or jabber rooms. And no changes are being
> proposed as to the handling of virtual blue sheets.
> >
> > We'd like to hear from the community about this proposal. Please send
> comments to [email-masked] <mailto:[email-masked]>, or exceptionally to
> [email-masked] <mailto:[email-masked]>, preferably by May 30, 2017.
> >
> > Thanks,
> > The IESG
> >
> >
> >
>
>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 9 May 2017 21:46:51 +0100

> We need that data first.

I agree that getting that data is a good idea and that registering
seems a not horrible mechanism in this case.

> parties rather than charging, I don't think we ought to anticipate that

I guess. OTOH, the first thing I thought when reading the message
was "huh, why no mention of the obvious potential for charging?"
So it might have been better to explicitly say that this is not a
bait and switch, even though I'm perfectly sure it is not that:-)

Cheers,
S.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 10 May 2017 00:22:28 +0300

+1 for better data collection. We do need it.

As for other future charging developments brought up by Stephen, those are perhaps a point to be discussed in the later. For sure the potential for changing the model should be acknowledged. But, I have no reason to doubt that IETF’s community’s wishes wouldn’t be driving whatever direction remote participation may develop into.

Jari

---

From: Yoav Nir <[email-masked]>
Date: Wed, 10 May 2017 01:06:29 +0300

In general, this looks fine to me.  I don’t believe any of the questions are particularly invasive, and I can see the utility of each of them (except Title, but that’s a cultural thing).

A few remarks inline

> Have you attended an IETF meeting remotely before?

The last two questions seem to be about gathering statistics (as is the country of residence). I’m wondering if it wouldn’t make sense to add a question about why the participant is remote (too much travel, too much money, avoids going to country X for whatever reason).

> To join a session, participants would be asked to input the registration ID. The same email-based facility that is currently available to retrieve a forgotten registration ID would continue to be available. The cookie-based “Remember me” option would also still be available. The only difference from how login works today is that the option to "Join without registration ID" would be removed.

Does this mean that unregistered people would not be able to listen/view?  I’m fine with cutting off *participation*, but even before Meetecho we’ve had a live (audio) stream from the room. I wouldn’t want to lose that.  Recordings are good, but by the time you listen to a recording, the conversation may have moved on.

> If they are primarily folks in the hotel, who can't be in two rooms at once, we have one set of issues; if they are primarily folks at the end of low bandwidth, high RTT paths to the venue, we have a very different set of issues.  We also don't know reliably whether we have a small coterie of very dedicated remote participants or a wide smattering of folks dipping their toes in for a session or two.  

I’m not sure you’d be collecting enough data for that. Specifically the country of residence is not enough.  It’s not so much that the US is high bandwidth and Russia is low bandwidth. It’s more that New York, Moscow, and San Francisco get high bandwidth, while Orem, UT and Donetsk might get a lot less.

Yoav

---

From: David Farmer <[email-masked]>
Date: Tue, 9 May 2017 17:30:00 -0500

On Tue, May 9, 2017 at 3:30 PM, Ted Hardie <[email-masked]> wrote:
...

> we can't tell whether the service is fit for the purpose very easily.

Personally, I feel it indirectly and appropriately mentions fees, it says;
"Remote participants would be required to register (for free)"

> their toes in for a session or two.

You mention the "be in two rooms at once" use case, but given the proposed
information to be requested for registration, how would you capture that
use case?  Maybe you should ask that directly, like; "Are you also
attending the meeting in person?"

Country of residence is asked for, but it sounds like you really want to
know where they will be viewing from, not where they live.  For some set of
use cases they will be aligned, but others they won't.

There is another important use case, similar to "be in two rooms at once",
that is a temporary need to leave the meeting site, such as to receive
medical treatment for chronic conditions or simply just other business in
the meeting city.  As someone who has recently began needing treatment
while traveling. You frequently have little choice over when a treatment
slot is made available to you, usually you have to take what they can give
you.  Good remote participation options, make this less burdensome.

Thanks

> parties rather than charging, I don't think we ought to anticipate that
...

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: Ted Hardie <[email-masked]>
Date: Tue, 9 May 2017 15:46:27 -0700

> attending the meeting in person?"

You can identify that by noting that the registration ID used to
participate using the remote tools was that of a user who registered to be
on site. If they picked up their badge, you can then determine that they
were on site.  You can't distinguish someone watching from a hotel room
from someone watching from a different meeting room this way, though.

> regards,

Ted

> Once we have it, there may be many things in the set of ways to support
>> the service that come to light; since those might be fund raising from
>> external parties rather than charging, I don't think we ought to anticipate
>> that stage at this one.
>>
>> Hope that makes sense,
>>
>> Ted
>>
> ...
>
> 2218 University Ave SE        Phone: 612-626-0815 <(612)%20626-0815>
> Minneapolis, MN 55414-3029   Cell: 612-812-9952 <(612)%20812-9952>

---

From: Lou Berger <[email-masked]>
Date: Tue, 9 May 2017 18:49:56 -0400

On 5/9/2017 6:06 PM, Yoav Nir wrote:
> Does this mean that unregistered people would not be able to listen/view?  I’m fine with cutting off *participation*, but even before Meetecho we’ve had a live (audio) stream from the room. I wouldn’t want to lose that.  
+1 - I think continuing to provide unregistered live streaming is
important.  I am sensitive that there is a real cost to this,
particularly if usage increases. Perhaps we can shift this to a youtube
live stream to handle the fanout. 
 
> Recordings are good, but by the time you listen to a recording, the conversation may have moved on.
>
>> If they are primarily folks in the hotel, who can't be in two rooms at once, we have one set of issues; 
I also hope we don't loose the live audio only stream -- I regularly use
this while at the meeting to deal with the 2/3 room at once problem.  Of
course, if no one else uses it -- I loose...

Lou
(no hats)

---

From: Bob Hinden <[email-masked]>
Date: Wed, 10 May 2017 08:20:56 +0300

I support this.  I agree it is useful to collect this data, and think it’s important to know who is participating in the IETF standards process.

I will resit nitpicking as others are doing that just fine :-)

Bob

> On May 9, 2017, at 10:01 PM, IETF Chair <[email-masked]> wrote:
> 
> We'd like to hear from the community about this proposal. Please send comments to [email-masked], or exceptionally to [email-masked], preferably by May 30, 2017.
> 
> Thanks,
> The IESG
> 
>

---

From: John C Klensin <[email-masked]>
Date: Wed, 10 May 2017 08:50:52 -0400

Concur with Bob on both points.  I continue to believe that we
should allow people to anonymously observe/ lurk and to review
archives and stored videos registration but, as soon as someone
starts participating by, e.g., asking questions or making other
Contributions, it is important that they take responsibility for
being involved and possibly influencing decisions and that we
know who they are.

I favor at least a nominal registration fee for the same reason
-- not because I see it as an important revenue source (a rather
different discussion0 but because it helps eliminate Donald Duck
registrations.

    john

--On Wednesday, May 10, 2017 08:20 +0300 Bob Hinden
<[email-masked]> wrote:

> I support this.  I agree it is useful to collect this data,
> and think it's important to know who is participating in the
> IETF standards process.
>

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 10 May 2017 08:40:35 -0700

+1
None of the questions asked are in invasive, while helping us to better understand remote participation dynamics.
I also think adding few questions about "why remote" would help us in the future to make better choices when it comes to organization.

Regards,
Jeff

> On May 9, 2017, at 14:22, Jari Arkko <[email-masked]> wrote:
>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 10 May 2017 13:56:09 -0400

David Farmer <[email-masked]> wrote:
    > Country of residence is asked for, but it sounds like you really want
    > to know where they will be viewing from, not where they live. For some
    > set of use cases they will be aligned, but others they won't.

I think we want country of resident to understand if the travel costs were a
factor.   I think we also want to know their country of citizenship, because
passport/visa issues are also relevant.
I also think we want an IPv4 and IPv6 AS traceroute to their host at the
time of registration.  We also need a log of how many sessions they got to.
In some cases people will register, and then either not attend any sessions
for some reason, or fail to actually connect.

We need to survey people afterwards, and asking the country/visa/etc. issues
afterwards would be better, as would capturing output from something like
ipv6-test.com.

    > There is another important use case, similar to "be in two rooms at
    > once", that is a temporary need to leave the meeting site, such as to
    > receive medical treatment for chronic conditions or simply just other
    > business in the meeting city. As someone who has recently began

I connected to the 11am Friday CORE meeting from the airport departure
lounge at IETF98.  I just couldn't stay longer on Friday and still return in
time for my wife's birthday.  (She has celebrated at least five birthdays
*AT* IETF...)

    > needing treatment while traveling. You frequently have little choice
    > over when a treatment slot is made available to you, usually you have
    > to take what they can give you. Good remote participation options,
    > make this less burdensome.

Good point.
It also might be good if meetecho let us join two meetings at the same time.
(It actually works to open two tabs, although the audio is hard for the brain
to demux...)

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

---

From: Michael Richardson <[email-masked]>
Date: Wed, 10 May 2017 14:04:12 -0400

> Upon registering, participants would be issued a registration ID, just

Are we validating the email address in some way?
If we are not, I don't see the point of the *-required in any of those places.

    > audio recordings, YouTube videos, or jabber rooms. And no changes are
    > being proposed as to the handling of virtual blue sheets.

I suggest:
  1) Add me to the attendeeXX list.

  2) I think we have another list which is more announce and less discuss,
     but I can't recall it, they should be added to it as well.

  3) It would be nice if they they could be asked at registration time which
     WG they will attend (no commitment!), and if this information could be
     relayed to WG chairs.

  4) ask them if we can collect anonymized performance data and
     site/path/latency/jitter information.

I would also love it the meetecho tool could optionally capture
ipv6-test.com-like information during the session.  Maybe the webrtc people
could also tell us how to capture what kind of RTP sessions were required to
be created.  In the after-survey, we need to ask them if they had to do
anything special to participate. For instance:
       a) did they go into the "office" in order to have enough bandwidth?
       b) did they stay *away* from office in order to avoid restrictive firewalls?

Finally, to echo Klensin, I think that we should retain the ability to lurk
anonymously.

---

From: Stephan Wenger <[email-masked]>
Date: Wed, 10 May 2017 19:47:20 +0000

Hi,
Two IPR-motivated things inline:

>If we are not, I don't see the point of the *-required in any of those places.

I’m in favor of validating the address, for example by sending some form of credential to it; without the credential, only listening/reading access is granted.  Doesn’t have to be bullet-proof, but using [email-masked] shouldn’t work.  This is obviously in order to obtain one semi-traceable record of the participant.
>     site/path/latency/jitter information.

And 5) click-through of the Note Well (unless that’s done in some other phase of the remote participation, like when signing-in to meetecho).  Again for--I hope obvious--IPR related reasons.

Stephan

[...]

---

From: John C Klensin <[email-masked]>
Date: Wed, 10 May 2017 16:21:46 -0400

> If we are not, I don't see the point of the *-required in any

Michael (and others),

I'm happy to let the IESG manage this rather than getting into
an orgy of nit-picking and micro-managing, but I think there are
at least two separate reasons for wanting remote participants to
register and that, which the desired information may overlap,
confusing the two is probably not helpful.  The two are:

(1) For reasons related to IPR policy and issues (including the
"Note Well", but remember it is a summary of policies and
pointer to them, not the policies themselves) and in case
questions arise as to who or what is influencing IETF decisions,
we just need to know who is making Contributions and
influencing, or trying to influence, the IETF.  For that
purpose, I believe the information we should be collecting from
remote participants and the mechanisms used to validate that
information should be as nearly identical to the information
obtained from registrants for on-site attendance.  

As I've said earlier, I prefer that we make at least a nominal
charge as part of the verification process.  I also prefer that
we encourage registration in advance of the meeting, possibly
even providing a reduced fee for advanced registration (as we do
for conventional registrations).  I also believe that this is
"one person, one registration" and that separate registrations
for use of the in-person facilities (presumably including access
to cookies) and remote ones are neither desirable nor
appropriate.

Especially if remote registrations are going to continue to be
free and the forms offered when one first tries to access
Meetecho as a participant during a given meeting, the number of
questions asked should be kept to a minimum to avoid forcing
would-be participants in a session to spend any more time than
absolutely necessary filling out forms rather than contribution.

(2) Almost independent of the above, there are lots of reasons
to try to obtain demographic or opinion information from remote
participants.  Information of that type might help to inform
decisions about meeting locations, reasons why people are
participating remotely rather than attending meetings in person,
etc.  If we are not concerned about poll-stuffing, that
information might reasonably be collected anonymously.
Certainly the incentives for being able to identify and
authenticate a participant are different from those above.  It
can also be collected rather more at leisure, including using
post-meeting surveys similar to the used for registrants in the
past.

Again, I'm happy to let the IESG (assisted by staff and the IAOC
as they deem appropriate) sort out the details, but several
recent comments imply that some of the reasons for registering
remote participants are getting confused.

Finally, apologies for singing this song again, but, if we are
going to encourage remote participation hubs in which people
come together at a remote location to participate in (and
contribute to) an IETF meeting going on at the same time, we'd
best be really sure that registration and identification rules
for such participants are clear, consistent, and integrated with
whatever tools are relevant.

best,
   john

---

From: Yoav Nir <[email-masked]>
Date: Thu, 11 May 2017 00:28:02 +0300

> On 10 May 2017, at 15:50, John C Klensin <[email-masked]> wrote:
> 

How does a fee eliminate Donald Duck registrations?  There’s nothing preventing me from registering *now* for the Prague physical meeting as Donald Duck as long as my $700 are good.

Yoav

---

From: John C Klensin <[email-masked]>
Date: Wed, 10 May 2017 20:46:48 -0400

--On Thursday, May 11, 2017 00:28 +0300 Yoav Nir
<[email-masked]> wrote:

>> I favor at least a nominal registration fee for the same
>> reason -- not because I see it as an important revenue source
>> (a rather different discussion0 but because it helps
>> eliminate Donald Duck registrations.
> 
> How does a fee eliminate Donald Duck registrations?  There's
> nothing preventing me from registering *now* for the Prague
> physical meeting as Donald Duck as long as my $700 are good.

Unless things have changed since I was paying active attention,
most registrations, especially those in advance of a meeting,
are paid with credit cards.   If you can get a credit card in
the name of M. Duck, more power to you, but I suggest the effort
required to do that would at least mostly separate those who
have read reasons to want to participate under aliases from
those who were merely being difficult on principle or who were
suffering from an excess of self-indulgent cuteness.

A different way to say the same thing is that, especially with
remote participants, a requirement for strong authentication of
all participants is probably impossible or nearly so.  That
doesn't mean we should avoid making a reasonable best effort and
I believe that requiring some registration payment, even a small
one, is both a useful part of such an effort and a way of
encouraging a modicum of additional seriousness.

YMMD.
    john

---

From: "John Levine" <[email-masked]>
Date: 11 May 2017 04:03:04 +0000

In article <[email-masked]>,
Yoav Nir  <[email-masked]> wrote:
>How does a fee eliminate Donald Duck registrations?  There’s nothing preventing me from registering *now* for
>the Prague physical meeting as Donald Duck as long as my $700 are good.

I believe that the assumption is that few people are likely to waste
$700 each on multiple fake registrations.

Also, if the identity of the person becomes an issue, the credit card
used to pay is an excellent key to use.

R's,
John

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 11 May 2017 07:19:14 +0200 (CEST)

On Tue, 9 May 2017, IETF Chair wrote:

> only difference from how login works today is that the option to "Join 
> without registration ID" would be removed. Other options for

The few times I have tried to use my registration ID to join a session, I 
failed to get it working, and I had to revert to use the clickbox to join 
without registration ID. So if remote participation is going to require 
this ID, this needs to be "bulletproof". The "remember me" button also 
needs to work across the entire week, preferrably so I don't even have to 
put in the registration ID more than once for the entire week (cookies 
etc).

Perhaps we could have one IETF where there is encouragement for everybody 
to test this functionality and make sure all cases of it not working is 
reported to the NOC and fault found? So basically a "dress rehearsal".

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Thu, 11 May 2017 10:18:05 +0300

> On 11 May 2017, at 3:46, John C Klensin <[email-masked]> wrote:
> 
> 
> 
> the name of M. Duck, more power to you,

I don’t know if things have changed, but bank transfers are also accepted. And I usually have my employer’s credit card pay for the meeting, so my name is nowhere on that.

But being able to trace participants to their true identity is one thing. Having their true names appear in blue sheets or Jabber windows is, I think, important for us and one of the points of this exercise.

Yoav

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 11 May 2017 08:14:58 -0400

> I’m in favor of validating the address, for example by sending some form of credential to it; without the credential, only listening/reading access is granted.  Doesn’t have to be bullet-proof, but…

We don't do that for in-person participants, because we no longer even
collect the email address on the blue sheets.  (We do it for meeting
registration, of course, but we don't have a way to pair that with
participation in any given part of the meeting, so the IPR issue is
harder to argue by analogy here.)
 
> And 5) click-through of the Note Well (unless that’s done in some other phase of the remote participation, like when signing-in to meetecho).  Again for--I hope obvious--IPR related reasons.

We _certainly_ don't do that for in-person meetings.  We put the Note
Well up and assume that anyone who is in the room and who makes a
Contribution in any way is aware of it.  Joining the meeting virtually
has the same property, no?

A

-- 
Andrew Sullivan
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Thu, 11 May 2017 10:27:46 -0400

> register and that, which the desired information may overlap,

I'm not arguing against registration, but rather, I want to consciously
say that we are validating the registration!
I'd be quite happy to register via the datatracker, for instance.  A great
use for OAUTH2.

I agree with all your other points.

---

From: Russ Housley <[email-masked]>
Date: Thu, 11 May 2017 13:19:52 -0400

> On May 11, 2017, at 8:14 AM, Andrew Sullivan <[email-masked]> wrote:
> 

Collecting an email address as part of the registration process does not mean that the email address needs to appear in the proceedings.

Russ

---

From: Stephan Wenger <[email-masked]>
Date: Thu, 11 May 2017 17:35:24 +0000

Hi Andrew, please see inline.

>harder to argue by analogy here.)

The question is not whether we collect email addresses.  The question is whether we collect the identification of the individual and its employer, bother with reasonable certainty.  IIRC, one reason for the change from email address to company name was made because, today, many people use non-employer email for IETF work even if they do the work mostly on behalf of their employer and as part of their job, and tracking down the participant’s employer from the email address for things like Noncom eligibility and also IPR related issues didn’t work anymore (if it ever did).  (there were also other motivations, including the handy creation of a SPAM list from IETF archival material such as the proceedings).

For an in-person meeting, we (or a court) have many ways to identify a person who influences the decision process.  For an external person, especially when there is no video, we are more limited.  A non-verified email address is certainly easier to fake than the recollection of a roomful of people during a physical meeting.

>has the same property, no?

Actually, No.  In an in-person meeting, the hurdle of missing a note well is pretty high.  When you are at a physical meeting and get bombarded with a Note Well not only during registration time, but also daily several times at the begin of WG sessions, you and your lawyer would have a hard time to argue that you were not aware of it (and therefore perhaps free of certain obligations you otherwise have per policy).  OTOH, assuming no click-through or similar, a good lawyer could conceivably make the case that his client was not aware of the Note Well and associated policy when influencing an IETF decision process of a certain document, especially if that person is not an IETF regular and dials in only for one WG session (and perhaps a bit late to that).  Then, the good lawyer could conceivably argue that certain obligations (such as the obligation to disclose patents) were not known to that client of his.  And finally, the lawyer could argue that, therefore, the obligations do not apply.  (Note that I didn’t include the word “successful” in the last sentence.)

There has been one fairly prominent case where a company choose to send undercover participants to standards meetings, in order to (so the court found IIRC) circumvent obligations by the standards committee.  We should not facilitate such behavior.  That case and ours are not directly comparable, but IMO not dissimilar in their nature.

Stephan

---

From: Dave Crocker <[email-masked]>
Date: Thu, 11 May 2017 11:38:15 -0600

On 5/11/2017 11:19 AM, Russ Housley wrote:
>> collect the email address on the blue sheets.  (
...
> Collecting an email address as part of the registration process does not mean that the email address needs to appear in the proceedings.

IETF f2f meetings do not even enforce the 'requirement' that one have 
registered.  Anyone /can/ walk in and sit in any of the meeting rooms. 
So the act and fact of registration is by community trust.

And as noted, one can write whatever one wants on the blue sheet.

To the extent that remote participation should approximate what is done 
for f2f, registration should give access, but there should be a 
separate, open-form 'blue sheet' step for the user to complete.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Rich Kulawiec <[email-masked]>
Date: Thu, 11 May 2017 19:05:26 -0400

On Thu, May 11, 2017 at 05:35:24PM +0000, Stephan Wenger wrote:
> (there were also other motivations, including the handy creation of
> a SPAM list from IETF archival material such as the proceedings).

I'm trying to stay out of the rest of this, but let me add two notes
at this point.

First, the proper term is "spam".  "SPAM" is a product of the Hormel
Corporation and has nothing to do with email.  "Spam" is not an acronym
and it is incorrect to present it in all-caps.

Second, there is no point whatsoever in worrying about whether spammers
will acquire addresses from such a list: they already have them, for
a value of "them" somewhere in 9 or 10 digits.  (And any newly-created
ones will be in their hands soon enough, via a variety of methods which
would take many pages to describe.)

---rsk

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 12 May 2017 01:15:44 +0100

FWIW, I personally consider almost all so-called IPR in the IETF's
space to be BS, so I am entirely happy that we ignore such issues to
the fullest possible extent. (While recognising that we do have to
pretend to respect some of that nonsense, sadly.)

I am also personally unhappy when we pander to the pretence that
the relevant output of entities like the USPTO are "inventions."
I base my attitude on my personal perception that a very high five
nines of supposedly relevant patent claims that I have read are
just crap. I do not ask that anyone else (dis)agrees with me.

So, yes, some IETF participants do need to pay attention to that
gibberish, and I'm ok with living with their being impaired in
that manner, but only to the extent that that is a necessary evil.

IOW, let's prefer usability to idiocy.

S.

On 11/05/17 18:35, Stephan Wenger wrote:
>>> Iâ€™m in favor of validating the address, for example by sending some form of credential to it; without the credential, only listening/reading access is granted.  Doesnâ€™t have to be bullet-proof, but using [email-masked] shouldnâ€™t work.  This is obviously in order to obtain one semi-traceable record of the participant.
>>>>
>>
> The question is not whether we collect email addresses.  The question is whether we collect the identification of the individual and its employer, bother with reasonable certainty.  IIRC, one reason for the change from email address to company name was made because, today, many people use non-employer email for IETF work even if they do the work mostly on behalf of their employer and as part of their job, and tracking down the participantâ€™s employer from the email address for things like Noncom eligibility and also IPR related issues didnâ€™t work anymore (if it ever did).  (there were also other motivations, including the handy creation of a SPAM list from IETF archival material such as the proceedings).
> 
>>> And 5) click-through of the Note Well (unless thatâ€™s done in some other phase of the remote participation, like when signing-in to meetecho).  Again for--I hope obvious--IPR related reasons.
>>>
>>
> Actually, No.  In an in-person meeting, the hurdle of missing a note well is pretty high.  When you are at a physical meeting and get bombarded with a Note Well not only during registration time, but also daily several times at the begin of WG sessions, you and your lawyer would have a hard time to argue that you were not aware of it (and therefore perhaps free of certain obligations you otherwise have per policy).  OTOH, assuming no click-through or similar, a good lawyer could conceivably make the case that his client was not aware of the Note Well and associated policy when influencing an IETF decision process of a certain document, especially if that person is not an IETF regular and dials in only for one WG session (and perhaps a bit late to that).  Then, the good lawyer could conceivably argue that certain obligations (such as the obligation to disclose patents) were not known to that client of his.  And finally, the lawyer could argue that, therefore, the obligations do not apply.  (Note that I didnâ€™t include the word â€œsuccessfulâ€ in the last sentence.)
>

---

From: Eliot Lear <[email-masked]>
Date: Fri, 12 May 2017 08:52:08 +0200

> If we are not, I don't see the point of the *-required in any of those places.

Regardless of motivation here, if the tools team were to use our
ietf.org logins for registration one of the benefits of that would be
that many fields could be filled in for us, albeit editable (some of us
need that for tee shirt size, regrettably),  both for in person and
remote participation. 

There is a downside: the secretariat would have to secure that
information.  Personally I think we should offer that as an option as an
exercise to demonstrate how privacy can be done properly, so that we are
eating our own dog food.  The minimum, though, would be a validated IETF
account.  I don't think that's a high bar.

Eliot

---

From: John Leslie <[email-masked]>
Date: Mon, 15 May 2017 09:12:40 -0400

IETF Chair <[email-masked]> wrote:
> registration for remote participants at IETF meetings...
> 
> Registration would be mandatory to access MeetEcho sessions in real
> time and to join the remote mic queue during a session...
> 
> To join a session, participants would be asked to input the
> registration ID.

   These "registration IDs" are hard to remember. That's why I joined so
many sessions "without rugistration ID".

> The same email-based facility that is currently available to retrieve
> a forgotten registration ID would continue to be available.

   This is not practical unless you allow joining enough before the start
of session to complete the process.

> The cookie-based ???Remember me??? option would also still be available.

   Would you believe some of us avoid cookies?

> Other options for authentication (leveraging a user-chosen password or
> datatracker credentials) might be explored further in the future.

   I strongly advise considering them before disallowing registration
without registration ID.

--
John Leslie <[email-masked]>

---

From: John Leslie <[email-masked]>
Date: Mon, 15 May 2017 09:18:41 -0400

> We need that data first.

   There really-should be ways to get it without asking folks to change
the way they access remote participation.

   It would seem to me that providing the name under which you registered
would be sufficient...

---

From: Mark Andrews <[email-masked]>
Date: Tue, 16 May 2017 00:18:39 +1000

> many sessions "without rugistration ID".

When you need to registration ID to participate you will record it,
look it in the registration email or recover it.

	IETF 97 confirmation for Mr. Mark P Andrews

	Registration Type: Remote Participant 

	Your registration number is 97XXXXXXXX 

> of session to complete the process.

The session are open well before the workig group actually starts.
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: John Leslie <[email-masked]>
Date: Mon, 15 May 2017 22:36:41 -0400

> When you need to registration ID to participate you will

   Post-it note on the screen, no doubt...

> look it in the registration email

   Often there are 100 spams I haven't finished dealing with...

> or recover it.

   How?

> 	Your registration number is 97XXXXXXXX 

   I suppose that's "easy enough" assuming I've found the email (on the
same computer I'm using for remote attendance) and can cut&paste. I must
be getting too old to participate in IETF weeks if I ever fail...

>>> a forgotten registration ID would continue to be available.

   Believe it or not, I haven't used that recently...

> The session are open well before the workig group actually starts.

   I've found that time to be variable: sometimes less than two minutes...

>>    Would you believe some of us avoid cookies?

   (Of course, I never avoid the physical cookies when I'm physically
present!)

>> I strongly advise considering them before disallowing registration

BTW, it's not unusual (for me, anyway) to join different sessions from
different computers, not all of which will have all the cookies.

   If you really want to make it harder to join an individual session
(or re-join after a MeetEcho glitch, for that matter), I probably
can't stop you; but I won't consider it a reasonable trade-off for
collecting some information you've already collected that same day.

   Perhaps you'll find volunteers to man the help-lines for folks having
trouble joining sessions...

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 18 May 2017 08:38:44 -0400

Thanks all for the feedback on this proposal thus far. I wanted to provide a couple of reactions:

- No changes are being proposed regarding live audio streams. These would continue to be available to anyone without registration.

- The feedback about other information to solicit or questions to ask of registrants is much appreciated. I'll make sure the IESG, IAOC, secretariat, and MeetEcho team review the suggestions so we can refine the questions on the registration form and perhaps also the post-meeting survey. We should probably do this regardless of whether registration is required or not.

- In the data that MeetEcho already collects, they distinguish between those who join a session while connected to the IETF meeting network and everyone else. This doesn't capture all of the cases mentioned in the thread (e.g., joining from another location nearby the meeting), but it does cover some.

- Regarding charging, it's possible that we could think about charging for remote registration in the future. Or not. Or getting it sponsored, or changing the in-person meeting fee, or changing nothing ... basically it is as Jari said, perhaps a discussion for the future. But from my perspective the important things would be: (1) community discussion of any proposed changes, (2) understanding the remote participant user base, the motivations for charging or not charging, and the expected outcome of any proposed changes, and (3) having confidence in any system we have in place that is predicated on charging (e.g., we don't want people to feel that they are being cheated out of their registration fee because the system is easily circumventable).

- We could potentially do email validation, although for the purposes of getting more accurate data I'm not sure it adds a lot of value. My sense is that the noise in our current data set arises from people inputting different variations of their name when they join without a registration ID. I don't think people are deliberately trying to skew the data, so I wouldn't anticipate that if we require registration that people will register with multiple different email addresses in order to obtain multiple registration IDs, regardless of whether we validate the email addresses. Or, if they are looking to do Donald Duck registrations for an IPR-related purpose, they could still obtain two registration IDs by registering with two different email addresses that both validate. But I completely agree that leveraging datatracker logins could be quite useful going forward. 

- Everyone who registers for a meeting, whether it be in-person or remote, is already presented with the Note Well and asked to acknowledge it as the first step in the registration process (see https://ietf.org/meeting/register.html and https://ietf.org/meeting/remote-registration.html).

- The data that we can currently collect can be quite noisy, which is why we are suggesting to make a slight change in the trade-off between ease-of-access and data quality. For example, at IETF 98, we counted about twice as many unique remote attendees (based on names entered) as registered remote attendees.

Alissa

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 24 May 2017 10:41:46 -0400

I didn't see any response to Eliot's suggestion to use datatracker
credentials for registration, so that (1) we have links to information that
has been previously provided, and (2) we'd have roughly the same level of
verification that we have for anyone who's using the datatracker now.

What are the downsides? I guess Meetecho would need to handle IETF
differently from other customers (who, regrettably, don't use datatracker)?
Are there others?

Spencer

On Fri, May 12, 2017 at 2:52 AM, Eliot Lear <[email-masked]> wrote:

> >     > Upon registering, participants would be issued a registration ID,
> just
> >     > as they are today.
> >

---

From: Yoav Nir <[email-masked]>
Date: Wed, 24 May 2017 19:11:50 +0300

No statistics about this, but there are people who don’t have datatracker credentials.

You can do most things, including submitting drafts without datatracker credentials.

But as yet another option it works fine.

Yoav

On 24 May 2017, at 17:41, Spencer Dawkins at IETF <[email-masked]> wrote:

> I didn't see any response to Eliot's suggestion to use datatracker credentials for registration, so that (1) we have links to information that has been previously provided, and (2) we'd have roughly the same level of verification that we have for anyone who's using the datatracker now.
> 
> What are the downsides? I guess Meetecho would need to handle IETF differently from other customers (who, regrettably, don't use datatracker)? Are there others?
> 
> Spencer
> 
> 
> On Fri, May 12, 2017 at 2:52 AM, Eliot Lear <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> > IETF Chair <[email-masked] <mailto:[email-masked]>> wrote:
> >     > Title
> >     > First / Given Name*
> >     > Last / Family Name*
> >     > Company / Organization
> ietf.org <http://ietf.org/> logins for registration one of the benefits of that would be

---

From: Michael Richardson <[email-masked]>
Date: Wed, 24 May 2017 13:34:40 -0400

Spencer Dawkins at IETF <[email-masked]> wrote:
    > credentials for registration, so that (1) we have links to information
    > that has been previously provided, and (2) we'd have roughly the same
    > level of verification that we have for anyone who's using the
    > datatracker now.

I think that all current DT authentication occurs by database dips (mysql,
port 3306).   To do this nicely, it would have to be OAUTH2, which we do not
have.

    > differently from other customers (who, regrettably, don't use
    > datatracker)? Are there others?

If we provided OAUTH2, then there likely would be a much better match.