Subject: Re: [Perc] Confirmation of Consensus on PERC Double from IETF 99

From: Suhas Nandakumar <[email-masked]>
Date: Sun, 6 Aug 2017 13:42:25 -0700

Hello All

   Following up on the consensus confirmation email, the chairs have
considered all the inputs received from the people in the room and the
inputs from people on the email list and determined there is consensus for
the following 2 items.

1.   Allow MD to modify the 'M' (marker) bit.

2. Includes all the below
    - Move the OHB information from header extension to payload
    - RTX, RED and FlexFEC ordering : use the ordering of applying repair
on the double-encrypted packet. (Option 'A' in the slides)
    - DTMF : PERC will only support E2E DTMF and MD will not be able to
read DTMF info sent as media

Thanks for your inputs.

Cheers
Chairs

On Thu, Jul 27, 2017 at 10:14 AM, Suhas Nandakumar <[email-masked]>
wrote:

>
> Hi All,
>
> At the IETF 99 meeting, we took hum on the following proposals and there
> was a strong consensus in the room in their favor, but we wish to gather
> any additional inputs on the list.
> So, if there are any additional inputs that was not expressed in the room,
> please send them to the list by *4th August.*
>
> First Consensus Call:
>    Allow MD to modify the 'M' (marker) bit.
>
> Second Consensus called made includes all the following 3 proposals as a
> singleton:
>     - Move the OHB information from header extension to payload
>     - RTX, RED and FlexFEC ordering : use the ordering of applying repair
> on the double-encrypted packet. (Option 'A' in the slides)
>     - DTMF : PERC will only support E2E DTMF and MD will not be able to
> read DTMF info sent as media
>
> Here are the notes from the meeting:
>   https://www.ietf.org/proceedings/99/minutes/minutes-99-perc-01.txt
>
> Here are the slides corresponding to the above proposals :
>   https://www.ietf.org/proceedings/99/slides/slides-99-perc-double-01.pdf
>
>
> Thanks
> Perc Chairs
>

---

From: Emil Ivov <[email-masked]>
Date: Sun, 6 Aug 2017 16:26:30 -0500

Come again?

Regarding point 2, the only mail you received in response to your
request for confirmation were actually expressing the opposite.

Is this working group really becoming that much of a joke?

On Sun, Aug 6, 2017 at 3:42 PM, Suhas Nandakumar <[email-masked]> wrote:
>     - RTX, RED and FlexFEC ordering : use the ordering of applying repair on
> the double-encrypted packet. (Option 'A' in the slides)
>     - DTMF : PERC will only support E2E DTMF and MD will not be able to read
> DTMF info sent as media
>
> Thanks for your inputs.
>
> Cheers
> Chairs
>
>> was a strong consensus in the room in their favor, but we wish to gather any
>> additional inputs on the list.
>> please send them to the list by 4th August.
>>
>> First Consensus Call:
> _______________________________________________
> Perc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perc
>

-- 
https://jitsi.org

---

From: Roni Even <[email-masked]>
Date: Mon, 7 Aug 2017 06:57:30 +0000

Hi,
I do not have a strong opinion but I am a bit puzzled about the DTMF issue.
My understating so far was that the MD is the media distribution for a multipoint conferencing application. Typically in this cases the DTMF is for the multipoint application and not to the conference participants (The DTMF may even be suppressed by the conferencing bride) .
So how will such application work without DTMF if it depended on it? I think that there should be some text about it (use DTMF in the signaling when there is a PERC MD e.g. SIP INFO?)

Roni

From: Perc [mailto:[email-masked]] On Behalf Of Suhas Nandakumar
Sent: יום א 06 אוגוסט 2017 23:42
To: [email-masked]
Subject: Re: [Perc] Confirmation of Consensus on PERC Double from IETF 99

Hello All

   Following up on the consensus confirmation email, the chairs have considered all the inputs received from the people in the room and the inputs from people on the email list and determined there is consensus for the following 2 items.

2. Includes all the below
    - Move the OHB information from header extension to payload
    - RTX, RED and FlexFEC ordering : use the ordering of applying repair on the double-encrypted packet. (Option 'A' in the slides)
    - DTMF : PERC will only support E2E DTMF and MD will not be able to read DTMF info sent as media

Thanks for your inputs.

Cheers
Chairs

On Thu, Jul 27, 2017 at 10:14 AM, Suhas Nandakumar <[email-masked]<mailto:[email-masked]>> wrote:

Hi All,

At the IETF 99 meeting, we took hum on the following proposals and there was a strong consensus in the room in their favor, but we wish to gather any additional inputs on the list.
So, if there are any additional inputs that was not expressed in the room, please send them to the list by 4th August.

First Consensus Call:

Second Consensus called made includes all the following 3 proposals as a singleton:
    - Move the OHB information from header extension to payload
    - RTX, RED and FlexFEC ordering : use the ordering of applying repair on the double-encrypted packet. (Option 'A' in the slides)
    - DTMF : PERC will only support E2E DTMF and MD will not be able to read DTMF info sent as media

Thanks
Perc Chairs

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 07 Aug 2017 07:58:41 -0400

Roni,

That particular issue is least concerning to me, since all endpoints I know won't play DTMF into a user's ear.  AFAIK, only users over the PSTN might be affected, but then that suggests there's a gateway in the path and PERC is no longer securing the conference E2E. Thus, gateways need to stay out of PERC conferences.

Paul

-------- Original Message --------
From: Roni Even <[email-masked]>
Sent: August 7, 2017 2:57:30 AM EDT
To: Suhas Nandakumar <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Perc] Confirmation of Consensus on PERC Double from IETF 99

Hi,

Roni

Hello All

Thanks for your inputs.

Cheers
Chairs

Hi All,

First Consensus Call:

Thanks
Perc Chairs

---

From: Roni Even <[email-masked]>
Date: Mon, 7 Aug 2017 12:33:40 +0000

Hi Paul,
I agree that DTMF is not to the end user. On second thought I think that if DTMF will be used by the conference than there may be a separate entity that will handle DTMF. An example is when you call a conference dial-in number and the bridge will ask for conference number and password using voice messages.
I think this may happen also in Webex when you want to join using your phone to dial in, you get prompted for conference ID
Roni

From: Paul E. Jones [mailto:[email-masked]]
Sent: יום ב 07 אוגוסט 2017 14:59
To: [email-masked]; Roni Even; Suhas Nandakumar; [email-masked]
Subject: Re: [Perc] Confirmation of Consensus on PERC Double from IETF 99

Roni,

Paul
________________________________
From: Roni Even <[email-masked]<mailto:[email-masked]>>
Sent: August 7, 2017 2:57:30 AM EDT
To: Suhas Nandakumar <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Perc] Confirmation of Consensus on PERC Double from IETF 99

Hi,

Roni

From: Perc [mailto:[email-masked]] On Behalf Of Suhas Nandakumar
Sent: יום א 06 אוגוסט 2017 23:42
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [Perc] Confirmation of Consensus on PERC Double from IETF 99

Hello All

Thanks for your inputs.

Cheers
Chairs

Hi All,

First Consensus Call:

Thanks
Perc Chairs

---

From: Stephen Botzko <[email-masked]>
Date: Mon, 7 Aug 2017 10:07:12 -0400

>>> [roni]the bridge will ask for conference number and password using
voice messages
I'm not seeing how perc's encryption (as proposed in Prague) supports
either audio prompts from the server to the client or DTMF from the client
to the server.

If there is an adjunct web interface for control, that might not matter -
since audio prompts can be streamed over that interface if that is desired,
and the client can easily use http for replies.  That approach separates
the conference control plane from the media distribution plane.

Though in your use case, another option is to allow an initial media
connection to the server that doesn't use double for the purpose of
voice/response - and once the user selects their conference, then that
media is torn down and replaced by media encrypted with the conference
keys.  That works for conference setup, but not other use cases (announcing
new attendees joining the conference, or warning that the conference ending
time is approaching for example).

Stephen

On Mon, Aug 7, 2017 at 8:33 AM, Roni Even <[email-masked]> wrote:

> Hi Paul,
>
> I agree that DTMF is not to the end user. On second thought I think that
> if DTMF will be used by the conference than there may be a separate entity
> that will handle DTMF. An example is when you call a conference dial-in
> number and the bridge will ask for conference number and password using
> voice messages.
>
> I think this may happen also in Webex when you want to join using your
> phone to dial in, you get prompted for conference ID
>
> Roni
>
>
>
> *From:* Paul E. Jones [mailto:[email-masked]]
> *Sent:* יום ב 07 אוגוסט 2017 14:59
> *To:* [email-masked]; Roni Even; Suhas Nandakumar; [email-masked]
>
> *Subject:* Re: [Perc] Confirmation of Consensus on PERC Double from IETF
> 99
>
>
>
> Roni,
>
> That particular issue is least concerning to me, since all endpoints I
> know won't play DTMF into a user's ear. AFAIK, only users over the PSTN
> might be affected, but then that suggests there's a gateway in the path and
> PERC is no longer securing the conference E2E. Thus, gateways need to stay
> out of PERC conferences.
>
> Paul
> ------------------------------
>
> *From:* Roni Even <[email-masked]>
> *Sent:* August 7, 2017 2:57:30 AM EDT
> *To:* Suhas Nandakumar <[email-masked]>, "[email-masked]" <
> [email-masked]>
> *Subject:* Re: [Perc] Confirmation of Consensus on PERC Double from IETF
> 99
>
>
>
> Hi,
>
> My understating so far was that the MD is the media distribution for a
> multipoint conferencing application. Typically in this cases the DTMF is
> for the multipoint application and not to the conference participants (The
> DTMF may even be suppressed by the conferencing bride) .
>
> So how will such application work without DTMF if it depended on it? I
> think that there should be some text about it (use DTMF in the signaling
> when there is a PERC MD e.g. SIP INFO?)
>
>
>
> Roni
>
>
>
> *From:* Perc [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Suhas Nandakumar
> *Sent:* יום א 06 אוגוסט 2017 23:42
> *To:* [email-masked]
> *Subject:* Re: [Perc] Confirmation of Consensus on PERC Double from IETF
> 99
>
>
>
> Hello All
>
>
>

---

From: Roni Even <[email-masked]>
Date: Wed, 9 Aug 2017 05:19:14 +0000

Hi Steve,
I agree with what you wrote, I just wanted to point out that if we have some text on DTMF in the document it is not enough to say that it is only end to end but maybe mention that usage of DTMF for conference join and control is not handled by the MD.
Roni

From: Stephen Botzko [mailto:[email-masked]]
Sent: יום ב 07 אוגוסט 2017 17:07
To: Roni Even
Cc: Paul E. Jones; [email-masked]; Suhas Nandakumar
Subject: Re: [Perc] Confirmation of Consensus on PERC Double from IETF 99

>>> [roni]the bridge will ask for conference number and password using voice messages
I'm not seeing how perc's encryption (as proposed in Prague) supports either audio prompts from the server to the client or DTMF from the client to the server.

If there is an adjunct web interface for control, that might not matter - since audio prompts can be streamed over that interface if that is desired, and the client can easily use http for replies.  That approach separates the conference control plane from the media distribution plane.

Though in your use case, another option is to allow an initial media connection to the server that doesn't use double for the purpose of voice/response - and once the user selects their conference, then that media is torn down and replaced by media encrypted with the conference keys.  That works for conference setup, but not other use cases (announcing new attendees joining the conference, or warning that the conference ending time is approaching for example).

Stephen

On Mon, Aug 7, 2017 at 8:33 AM, Roni Even <[email-masked]<mailto:[email-masked]>> wrote:
Hi Paul,
I agree that DTMF is not to the end user. On second thought I think that if DTMF will be used by the conference than there may be a separate entity that will handle DTMF. An example is when you call a conference dial-in number and the bridge will ask for conference number and password using voice messages.
I think this may happen also in Webex when you want to join using your phone to dial in, you get prompted for conference ID
Roni

From: Paul E. Jones [mailto:[email-masked]<mailto:[email-masked]>]
Sent: יום ב 07 אוגוסט 2017 14:59
To: [email-masked]<mailto:[email-masked]>; Roni Even; Suhas Nandakumar; [email-masked]<mailto:[email-masked]>

Roni,

Paul

Hi,

Roni

Hello All

Thanks for your inputs.

Cheers
Chairs

Hi All,

First Consensus Call:

Thanks
Perc Chairs

_______________________________________________
Perc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/perc

---

From: Suhas Nandakumar <[email-masked]>
Date: Thu, 10 Aug 2017 08:26:20 -0700

> Is this working group really becoming that much of a joke?

Hello Emil,

For calling the final consensus, the chairs considered the aggregate of
inputs from the in-room consensus call at the IETF-99 and inputs on the
email list. In effect, there were substantially more people in the favor of
the proposal than against it. Hence following the IETF consensus process,
the chairs made the final consensus call as described in

https://mailarchive.ietf.org/arch/msg/perc/4JTYOVGcE9KXXjQ7ks3YRm7LFBI

The WG has heard your concerns, but unless there are new technical
arguments to be made, the consensus stands.

Regards

Chairs

---

From: Emil Ivov <[email-masked]>
Date: Thu, 10 Aug 2017 15:29:25 +0000

Suhas,

I would really appreciate it if you could point me to mails on this list,
sent from the "substantially more people in the favor" that express theor
support?

I am struggling to find any.

Emil

On Thu, 10 Aug 2017 at 10:26, Suhas Nandakumar <[email-masked]> wrote:

>> > On Thu, Jul 27, 2017 at 10:14 AM, Suhas Nandakumar <[email-masked]
>> >
>> > wrote:
>> >>
>> >>
>> >> Hi All,
>> >>
sent from my mobile

---

From: Suhas Nandakumar <[email-masked]>
Date: Thu, 10 Aug 2017 13:24:22 -0700

Hello Emil

   The votes that went to deciding consensus includes *both the  in-room
and on-list responses* towards the proposal.  We had a strong consensus in
the favor of the proposal in the room at the IETF 99 meeting (as reflected
in the minutes and recordings).

Hope this clarifies your question

Cheers
Suhas

---

From: Emil Ivov <[email-masked]>
Date: Thu, 10 Aug 2017 21:35:56 +0000

On Thu, 10 Aug 2017 at 15:24, Suhas Nandakumar <[email-masked]> wrote:

> and on-list responses* towards the proposal.  We had a strong consensus
> in the favor of the proposal in the room at the IETF 99 meeting (as
> reflected in the minutes and recordings).
>

Well no, of course it doesn't. It is unclear from the recording exactly how
much support there was during the meeting and there are no mails in support
of this proposal on the list.

There are some discussing it and some opposing it.

So why you choose to determine consensus in support of this proposal
remains a mystery to me. (Well not really)

Emil

sent from my mobile

---

From: Emil Ivov <[email-masked]>
Date: Sun, 13 Aug 2017 19:26:50 +0000

OK then, I guess we'd have to wait for IETF last call

On Thu, 10 Aug 2017 at 16:35, Emil Ivov <[email-masked]> wrote:

> Well no, of course it doesn't. It is unclear from the recording exactly
> how much support there was during the meeting and there are no mails in
> support of this proposal on the list.
>
>>> I would really appreciate it if you could point me to mails on this
>>> list, sent from the "substantially more people in the favor" that express
>>> theor support?
>>>
-- 
sent from my mobile

---

From: Suhas Nandakumar <[email-masked]>
Date: Mon, 14 Aug 2017 17:25:27 -0700

> remains a mystery to me. (Well not really)
Hi Emil

  The chairs did call for the hum for the proposal in the room of around 25
people on "who strongly or somewhat supports the proposal vs who strongly
objects" and there were considerable support for the former and none for
the latter. The hums and on-list inputs were accounted for making the
consensus call.

Thanks
Perc Chairs