Subject: [vmeet] Fwd: I-D Action: draft-ietf-genarea-rps-reqs-06.txt

From: Robert Sparks <[email-masked]>
Date: Wed, 22 Aug 2012 15:33:16 -0500

Hi Paul -

Thanks for the changes in this revision. I think it's very close to 
ready to ship, but there
are a few things left from my review of -04 that still apply, and I 
don't think I've seen
any response to (apologies if I've missed them). I've updated them for 
this version here.

1) Why don't we have requirements that discuss reusing the
identities we already have with IETF systems (like the tracker login)?

2) 06-41 and 06-42 appear to be in conflict. Is the second sentence of
06-41 not talking about exactly 06-42?

3) 06-65 - Why is this SHOULD and not MUST? Having an easy mechanism for
indexing the audio stream in real-time is a request I've heard for
years, and the suggested uses go beyond noting changes in speaker.

4) In 06-78, Can you expand on what "prepare" means? Do you only mean 
select
which tools will be used, or do you mean also configuring the tools, or 
putting data
in them. If there's something even more you have in mind, it would be 
good to be
explicit. As written, if I were building this system, all I can think to 
do to meet the
requirement is provide a list of checkboxes before the session to know 
which tool
to enable for that session.

5) 06-81 - It should be clearer that this is the "call here to ensure your
voice and video are set up correctly" test. It's testing the client, not the
service.

RjS

-------- Original Message --------
Subject: 	I-D Action: draft-ietf-genarea-rps-reqs-06.txt
Date: 	Thu, 16 Aug 2012 10:43:35 -0700
From: 	[email-masked]
Reply-To: 	[email-masked]
To: 	[email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
  This draft is a work item of the General Area Open Meeting Working Group of the IETF.

	Title           : Requirements for Remote Participation Services for the IETF
	Author(s)       : Paul Hoffman
	Filename        : draft-ietf-genarea-rps-reqs-06.txt
	Pages           : 31
	Date            : 2012-08-16

Abstract:
    The IETF has provided some tools for remote participation in its
    activities for many years, and some IETF participants have also used
    their own tools when they felt the need arise.  The IETF now wishes
    to support enhanced remote participation that is as seamless as
    possible, improving the experience for the remote attendee at the
    IETF regular meetings and interim meetings without degrading the
    experience for the people that are physically present.  Before
    deploying the new tools and services needed for this enhanced remote
    participation, the requirements for such tools and services, and the
    impacts they will make on the current procedures and infrastructure,
    must be defined.  This document is meant to be that definition.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-genarea-rps-reqs

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-genarea-rps-reqs-06

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-genarea-rps-reqs-06

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 22 Aug 2012 13:57:14 -0700

> identities we already have with IETF systems (like the tracker login)?

If we reuse the identities, then the registrant has not done the round-trip required in 06-13. This also allows someone to pick a meeting-specfic email address.

> 06-41 not talking about exactly 06-42?

Err, yes. The second sentence of 06-41 should be all of 06-42. I'll fix this in the -07.

> years, and the suggested uses go beyond noting changes in speaker.

It's a SHOULD because there is no widely-agreed to standard for such indexing. Thus, people should not rely on the first results being stable or even being continued over the long term.

> 4) In 06-78, Can you expand on what "prepare" means? Do you only mean select 
> which tools will be used, or do you mean also configuring the tools, or putting data
> in them. If there's something even more you have in mind, it would be good to be
> explicit. As written, if I were building this system, all I can think to do to meet the
> requirement is provide a list of checkboxes before the session to know which tool

Initially, "prepare" might only mean "select", but there might be some configuration that can be done easily as well. However, we don't know what that is yet.

> voice and video are set up correctly" test. It's testing the client, not the

Good point. Will be clarified in -07.

--Paul Hoffman

---

From: Robert Sparks <[email-masked]>
Date: Wed, 22 Aug 2012 16:15:51 -0500

> If we reuse the identities, then the registrant has not done the round-trip required in 06-13. This also allows someone to pick a meeting-specfic email address.
Are you reading that requirement to say that we must implement it by 
having people join an email list?
That's a reasonable mechanism to consider, but not necessarily the only one.

I could see having a page on the datatracker that once you've logged in 
(which means you've established
credentials), you have the option to sign up as a remote participant for 
an upcoming meeting. That page
could run you through the note-well confirmation, give you the 
opportunity to be added to a meeting-specific email address with 
whatever email address you wanted to provide.

The rps system could then use the datatracker logins for that meeting, 
checking to see if the person had actually registered. One less password 
for people to remember (and perhaps one more reason for people to not 
just share the credentials from one registration).

Alternatively, it could negotiate a new token at the point of 
registration that the user could use as the simple password, but what 
would that extra complexity buy?
> It's a SHOULD because there is no widely-agreed to standard for such indexing. Thus, people should not rely on the first results being stable or even being continued over the long term.
Could you state in the document that this is a frequent feature request? 
I would like to encourage whoever looks at implementing this to ask 
questions.
> Initially, "prepare" might only mean "select", but there might be some configuration that can be done easily as well. However, we don't know what that is yet.
This is a requirement. What requirement do we actually have right now?

---

From: Robert Sparks <[email-masked]>
Date: Wed, 22 Aug 2012 16:25:02 -0500

Typing too fast - typos corrected below. Sorry for any confusion they 
may have caused.

On 8/22/12 4:15 PM, Robert Sparks wrote:
>> If we reuse the identities, then the registrant has not done the 
>> round-trip required in 06-13. This also allows someone to pick a 
>> meeting-specfic email address.
> I could see having a page on the datatracker that once you've logged 
> in (which means you've established
> credentials), you have the option to sign up as a remote participant 
> for an upcoming meeting. That page
> opportunity to be added to a meeting-specific email 
list
>  with whatever email address you wanted to provide.
>
> checking to see if the person had actually registered. One less 
> password for people to remember (and perhaps one more reason for 
> people to not just share the credentials from one registration).
>
>> It's a SHOULD because there is no widely-agreed to standard for such 
>> indexing. Thus, people should not rely on the first results being 
>> stable or even being continued over the long term.
> Could you state in the document that this is a frequent feature 
> request? I would like to encourage whoever looks at implementing this 
> to ask questions.
>>
>> Initially, "prepare" might only mean "select", but there might be 
>> some configuration that can be done easily as well. However, we don't 
>> know what that is yet.
> This is a requirements
document.
>  What requirement do we actually have right now?
>>

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 22 Aug 2012 15:43:40 -0700

On Aug 22, 2012, at 2:25 PM, Robert Sparks <[email-masked]> wrote:

>> Are you reading that requirement to say that we must implement it by having people join an email list?

No, not at all. But the requirement clearly involves an email round trip, not just "use my current credentials".

>> I could see having a page on the datatracker that once you've logged in (which means you've established
>> credentials), you have the option to sign up as a remote participant for an upcoming meeting. That page
>> could run you through the note-well confirmation, give you the opportunity to be added to a meeting-specific email 
> list

That sounds fine, and is not precluded by the current wording.

>> The rps system could then use the datatracker logins for that meeting, checking to see if the person had actually registered. One less password for people to remember (and perhaps one more reason for people to not just share the credentials from one registration).

Sure, but I don't think it is required at all. Think of it this way: if my Datatracker login is [email-masked] and I have a password of "cats", I can use those when registering for the next IETF. I don't need to say "get my email and password from the Datatracker".

>> Alternatively, it could negotiate a new token at the point of registration that the user could use as the simple password, but what would that extra complexity buy?

Lots of things: the ability to change passwords, the ability to change email addresses, and so on.

>> Could you state in the document that this is a frequent feature request? I would like to encourage whoever looks at implementing this to ask questions.

Will do in -07.

>> What requirement do we actually have right now?

The ability for a participant to check ahead of time whether they have the right software to participate. To me, that's "preparing", yes?

--Paul Hoffman

---

From: Robert Sparks <[email-masked]>
Date: Wed, 22 Aug 2012 17:59:02 -0500

> No, not at all. But the requirement clearly involves an email round trip, not just "use my current credentials".
Why does the requirement involve an email round trip? Anything more than 
to make sure an email address works? If we don't already have that with 
creating datatracker accounts, we could add it to the registration step.
Or did you mean there needs to be an explicit act of registration, not 
just "I have credentials for the tracker, therefore I'm registered for 
this meeting." That's not what I was suggesting.

I don't really want to dive too much further into design - I took the 
step I did to challenge the requirement.
I think we _do_ want to integrate with the datatracker's credentials 
system, and I think we should point to it from the requirements document.

> Sure, but I don't think it is required at all. Think of it this way: if my Datatracker login is [email-masked] and I have a password of "cats", I can use those when registering for the next IETF. I…
Username password reuse by copy. Good stuff. :)
> Lots of things: the ability to change passwords, the ability to change email addresses, and so on.
You can do that with the datatracker.

So, part of what I'm anticipating is that the rps tool will need to 
authorize people to do certain things.
We talk about chairs doing stuff. How does the system know a chair from 
a non-chair? We can get that
from the Roles in the datatracker.

> The ability for a participant to check ahead of time whether they have the right software to participate.
06-78 is scoped to chairs, not general participants.
How is what you are describing (if we're talking about chairs) not 
covered already by 06-75?

>   To me, that's "preparing", yes?
>
> --Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 22 Aug 2012 16:36:12 -0700

On Aug 22, 2012, at 3:59 PM, Robert Sparks <[email-masked]> wrote:

> Why does the requirement involve an email round trip? Anything more than to make sure an email address works? If we don't already have that with creating datatracker accounts, we could add it to the registration step.
> Or did you mean there needs to be an explicit act of registration, not just "I have credentials for the tracker, therefore I'm registered for this meeting." That's not what I was suggesting.
> 
> I don't really want to dive too much further into design - I took the step I did to challenge the requirement.
> I think we _do_ want to integrate with the datatracker's credentials system, and I think we should point to it from the requirements document.

I will add this discussion to the -07.

> How is what you are describing (if we're talking about chairs) not covered already by 06-75?

Good catch; I forgot that this was scoped. 06-78 is superfluous after 06-75; I'll nuke it.

--Paul Hoffman

---

From: Robert Sparks <[email-masked]>
Date: Wed, 22 Aug 2012 18:57:28 -0500

Thanks -

I believe that that will address all my comments.

RjS