Subject: [RAI] RAI review of draft-ietf-speechsc-mrcpv2-19

From: Roni Even <[email-masked]>
Date: Tue, 07 Jul 2009 22:40:17 +0300

Hi,

I was assigned to do a RAI review of the draft.  The draft looks ready for
publication to me. I have some comments mostly editorial. 

The only issue I see that is not pure editorial is the issue of the
different parameters like confidence threshold, sensitivity level (see
comments 11, 13, 15, 16 and 17). I think that some clarification on the
semantics and the scale (for example are the values linearly spaced) as well
as when they are useful will be helpful to implementers.

1.       In figure 1 Expand the abbreviations TTS, ASR, SV , SI and how they
are related to the media resource types in 3.1

2.       In figure 1 there is a SIP dialog between the MRCPv2 client and the
media source/sink, what is this dialog, I only saw in section 4 a dialog
between the client and server.

3.       In section 3.2 you have "For example:  <sip:[email-masked]>
sip:[email-masked]" twice one after the other.

4.       In the example in section 4.2 you "a=cmid:1", cmid is specified
later in the document so maybe you can add some reference to where it is
specified

5.       In the example is section 4.2 and in following examples you have
"m=audio 49170 RTP/AVP 0 96" but do not have an rtpmap parameter for mapping
96 (dynamic payload type number) to a media encoding name.

6.       In section 4.3 "Also note that more that one media session can be
associated with a single resource if need be, but this scenario is not
useful for the current set of resources". There is a typo the second "that"
should be "than". I am also not sure if the current syntax in this document
can support the mode.

7.       In section 4.3 "The formatting of the"cmid" attribute in SDP
RFC3388 [RFC4566]". I think you meant SDP grouping and need the reference to
RFC 3388.

8.       In section 5.1 "The message-length field specifies the length of
the message, including the start-line" is the length in Bytes, there is no
unit specified.

9.       In section 6.3.1, typo you have "Verfication " instead of
verification. It appears twice in the section.

10.   In the example in section 7 you have "m=audio 0 RTP/AVP 0 1 3" payload
type 1 was deleted from the IANA registry, maybe have another payload type
number.

11.   In section 9.4.1, 9.4.2 and 9.4.3 you specify confidence threshold,
sensitivity level and speed vs accuracy. What is the scale here; is it
linear between 0 and 1. What is the absolute value of the number, if you
receive the same confidence level from two recognizers are they the same
(e.g. when using context block to switch servers).  For the speed vs
accuracy, how does the client know what is the relation between the value
and the number of available sessions, since this seems to be the reason for
using this parameter.

12.   In 9.4.9 and in 10.4.8, 11.4.11 what are the values for
media-type-value, you also mention audio and video but it looks to me that
this document only discusses voice.

13.   In 9.4.35 and 9.4.36 what is the scale for the consistency here. How
does one know what close means. What is the consistency between different
recognizers.

14.   In section 9.6.3.3 in the example (figure 2) confidence should be 0.75
and not 75

15.   In section 10.4.1 it is not clear how you measure the sensitivity in
order to specify, is it based on some SNR translated to 0 to 1 scale?

16.   In 11.4.6 the same issue with the scale, how does the client know how
to set a value when working with different speaker verification servers.

17.   In 11.5.2.9 you state that the verification-score is not a
probability, so what is it. How can the client decide if, for example, 0 is
a good score for specifying the threshold.  I also noticed that the values
in the example in section 11.5.2.10 are very precise like 0.98514 is this
the expected precision. The examples here and in section 11.11 do not show
the threshold, if the threshold is required for this flow why not show it in
the example?

18.   In section 12.3 the suggestion is to use SRTP as the mandatory
interoperability mode. If the reason for mandating SRTP is for a common mode
you should also decide on a key exchange mechanism. I suggest you look at
http://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory-02 for
discussion on media security.

19.   In section13.7.2 you specify the attribute resource as session level
yet in the example in section 4.2 it is a media level attribute. The same
goes for the channel attribute

Thanks

Roni Even

---

From: Eric Burger <[email-masked]>
Date: Thu, 9 Jul 2009 16:28:04 -0400

The reality is that NO ONE has implemented any security to date. The  
GENART reviewer raised the same issue, and so far the work group has  
the same response: MRCPv2 (the speechsc work group) is not planning on  
figuring out which of the seven key exchange mechanisms to use in  
SIP.  We are counting on the community publishing something, and  
people using it.  After all, we are the "using SIP for media resource  
control" work group, not the "media resource control work group using  
something like SIP for control."

Does this work for you?

On Jul 7, 2009, at 3:40 PM, Roni Even wrote:

> [snip]
> interoperability mode. If the reason for mandating SRTP is for a  
> common mode you should also decide on a key exchange mechanism. I  
> suggest you look athttp://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory-02 
>  for discussion on media security.

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 9 Jul 2009 15:48:56 -0500

Eric,

I think you need to clarify the context of the following statement you 
made: "The reality is that NO ONE has implemented any security to 
date."

Certainly, SRTP is widely implemented and deployed in many environements
(e.g., Enteprise telephony for example).

I am assuming that your comment was specific to MRCPv2?

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Eric Burger
> Sent: Thursday, July 09, 2009 13:28
> To: Roni Even
> Cc: Daniel Burnett; [email-masked]; Saravanan Shanmugham; 
> [email-masked]
> Subject: Re: [RAI] RAI review of draft-ietf-speechsc-mrcpv2-19
> 
> The reality is that NO ONE has implemented any security to 
> date. The GENART reviewer raised the same issue, and so far 
> the work group has the same response: MRCPv2 (the speechsc 
> work group) is not planning on figuring out which of the 
> seven key exchange mechanisms to use in SIP.  We are counting 
> on the community publishing something, and people using it.  
> After all, we are the "using SIP for media resource control" 
> work group, not the "media resource control work group using 
> > suggest you look 
> > athttp://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory-02

---

From: Roni Even <[email-masked]>
Date: Thu, 09 Jul 2009 23:56:21 +0300

Eric,
My comment is that in this case in AVT we say that you do not need to
mandate SRTP but mandate a security mechanism that can be  not only SRTP but
in a different layer like ipsec. This is why I gave a reference to the
srtp-not-mandatory draft

Roni

> From: Eric Burger [mailto:[email-masked]]
> Sent: Thursday, July 09, 2009 11:28 PM
> To: Roni Even
> Cc: Saravanan Shanmugham; Daniel Burnett; [email-masked];
> [email-masked]
> Subject: Re: RAI review of draft-ietf-speechsc-mrcpv2-19
>

---

From: Eric Burger <[email-masked]>
Date: Sat, 11 Jul 2009 21:09:44 -0400

Correct: no one doing MRCPv2, not no one at all.

---

From: "Francois Audet" <[email-masked]>
Date: Sat, 11 Jul 2009 19:03:54 -0700

Danke

On Jul 11, 2009, at 18:09, "Eric Burger" <[email-masked]>  
wrote:

>
> --Apple-Mail-25-618329138
> Content-Type: text/plain;
>    charset=US-ASCII;
>    format=flowed;
>    delsp=yes
> Content-Transfer-Encoding: 7bit
>
>>> Cc: Daniel Burnett; [email-masked]; Sar

---

From: Dan York <[email-masked]>
Date: Tue, 14 Jul 2009 16:16:16 -0400

Roni,

The current text at http://tools.ietf.org/html/draft-ietf-speechsc-mrcpv2-19#section-12.3 
  is:
------
12.3. Media session protection
Sensitive data is also carried on media sessions terminating on MRCPv2  
servers (the other end of a media channel may or may not be on the  
MRCPv2 client). This data includes the user's spoken utterances    and  
the output of text-to-speech operations. MRCPv2 servers MUST support  
SRTP for protection of audio media sessions. MRCPv2 clients that  
originate or consume audio similarly MUST support SRTP. Alternative  
media channel protection MAY be used if desired (e.g. IPSEC).
------

Based on your comments and the srtp-not-mandatory draft (which was  
just revised to http://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory-03 
  ), my understanding would be that you are advocating something more  
like this:

------
12.3. Media session protection
Sensitive data is also carried on media sessions terminating on MRCPv2  
servers (the other end of a media channel may or may not be on the  
MRCPv2 client). This data includes the user's spoken utterances    and  
the output of text-to-speech operations. MRCPv2 servers MUST support a  
security mechanism for protection of audio media sessions. MRCPv2  
clients that originate or consume audio similarly MUST support a  
security mechanism for protection of the audio.
------

Is that an accurate summary of your feedback?  Would that text be  
acceptable?

Regards,
Dan

On Jul 9, 2009, at 4:56 PM, Roni Even wrote:

> _______________________________________________
> RAI mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rai

-- 
Dan York, Director of Conversations
Voxeo Corporation   http://www.voxeo.com  [email-masked]
Phone: +1-407-455-5859    Skype: danyork

Join the Voxeo conversation:
Blogs: http://blogs.voxeo.com
Twitter: http://twitter.com/voxeo  http://twitter.com/danyork
Facebook: http://www.facebook.com/voxeo

---

From: "Roni Even" <[email-masked]>
Date: Tue, 14 Jul 2009 23:55:27 +0300

Dan,

This is the general idea. The major reason is that there are various ways to
protect the data and if you are not mandating one for interoperability then
it can be more general

For example we have the following text when discussing security in the RTP
payloads specifications.

RTP packets using the payload format defined in this specification

   are subject to the security considerations discussed in the RTP

   specification [RFC3550] and any appropriate RTP profile.  The main

   security considerations for the RTP packet carrying the RTP payload

   format defined within this memo are confidentiality, integrity, and

   source authenticity.  Confidentiality is achieved by encryption of

   the RTP payload.  Integrity of the RTP packets is achieved through a

   suitable cryptographic integrity protection mechanism.  Such a

   cryptographic system may also allow the authentication of the source

   of the payload.  A suitable security mechanism for this RTP payload

   format should provide confidentiality, integrity protection, and at

   least source authentication capable of determining if an RTP packet

   is from a member of the RTP session.

   Note that the appropriate mechanism to provide security to RTP and

   payloads following this memo may vary.  It is dependent on the

   application, the transport, and the signaling protocol employed.

   Therefore, a single mechanism is not sufficient, although if

   suitable, usage of the Secure Real-time Transport Protocol (SRTP)

   [RFC3711] recommended.  Other mechanisms that may be used are IPsec

   [RFC4301] Transport Layer Security (TLS) [RFC5246] (RTP over TCP);

   other alternatives may exist.

Roni Even

From: [email-masked] [mailto:[email-masked]] On Behalf Of Dan
York
Sent: Tuesday, July 14, 2009 11:16 PM
To: Roni Even
Cc: 'Daniel Burnett'; [email-masked]; 'Saravanan Shanmugham';
[email-masked]
Subject: Re: [RAI] RAI review of draft-ietf-speechsc-mrcpv2-19

Roni,

The current text at
http://tools.ietf.org/html/draft-ietf-speechsc-mrcpv2-19#section-12.3 is:

------
12.3. Media session protection  
Sensitive data is also carried on media sessions terminating on MRCPv2
servers (the other end of a media channel may or may not be on the MRCPv2
client). This data includes the user's spoken utterances and the output of
text-to-speech operations. MRCPv2 servers MUST support SRTP for protection
of audio media sessions. MRCPv2 clients that originate or consume audio
similarly MUST support SRTP. Alternative media channel protection MAY be
used if desired (e.g. IPSEC).

------

Based on your comments and the srtp-not-mandatory draft (which was just
revised to http://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory-03
), my understanding would be that you are advocating something more like
this:

------

12.3. Media session protection 
Sensitive data is also carried on media sessions terminating on MRCPv2
servers (the other end of a media channel may or may not be on the MRCPv2
client). This data includes the user's spoken utterances    and the output
of text-to-speech operations. MRCPv2 servers MUST support a security
mechanism for protection of audio media sessions. MRCPv2 clients that
originate or consume audio similarly MUST support a security mechanism for
protection of the audio. 

------

Regards,

Dan

Eric,

Roni

-----Original Message-----

To: Roni Even

[email-masked]

Does this work for you?

[snip]

suggest you look athttp://tools.ietf.org/html/draft-ietf-avt-srtp-

not-mandatory-02

--

---

From: Dan York <[email-masked]>
Date: Tue, 14 Jul 2009 17:10:38 -0400

Roni,

So as the RAI reviewer, are you okay with the text I suggested:
------

Or would you prefer this text that includes the recommendation of  
SRTP?  (Which I noticed you did in the RTP payloads spec - and it  
makes sense to me to provide some basic guidance.):
------
12.3. Media session protection
Sensitive data is also carried on media sessions terminating on MRCPv2  
servers (the other end of a media channel may or may not be on the  
MRCPv2 client). This data includes the user's spoken utterances    and  
the output of text-to-speech operations. MRCPv2 servers MUST support a  
security mechanism for protection of audio media sessions. MRCPv2  
clients that originate or consume audio similarly MUST support a  
security mechanism for protection of the audio. If appropriate, usage  
of the Secure Real-time Transport Protocol (SRTP) [RFC3711] is  
recommended.
------

Regards,
Dan

Regards,
Dan

On Jul 14, 2009, at 4:55 PM, Roni Even wrote:

> Dan,
> This is the general idea. The major reason is that there are various  
> ways to protect the data and if you are not mandating one for  
> interoperability then it can be more general
>
> For example we have the following text when discussing security in  
> the RTP payloads specifications.
>
> From: [email-masked] [mailto:[email-masked]] On Behalf  
> Of Dan York
> Cc: 'Daniel Burnett'; [email-masked]; 'Saravanan Shanmugham'; [email-masked]
> Sensitive data is also carried on media sessions terminating on  
> MRCPv2 servers (the other end of a media channel may or may not be  
> on the MRCPv2 client). This data includes the user's spoken  
> utterances and the output of text-to-speech operations. MRCPv2  
> servers MUST support SRTP for protection of audio media sessions.  
> MRCPv2 clients that originate or consume audio similarly MUST  
> support SRTP. Alternative media channel protection MAY be used if  
> desired (e.g. IPSEC).
> ------
>
> Sensitive data is also carried on media sessions terminating on  
> MRCPv2 servers (the other end of a media channel may or may not be  
> on the MRCPv2 client). This data includes the user's spoken  
> utterances    and the output of text-to-speech operations. MRCPv2  
> servers MUST support a security mechanism for protection of audio  
> media sessions. MRCPv2 clients that originate or consume audio  
> similarly MUST support a security mechanism for protection of the  
> audio.
> ------
>

---

From: "Roni Even" <[email-masked]>
Date: Wed, 15 Jul 2009 00:36:08 +0300

Dan,

I prefer the text that recommends SRTP (It is a SHOULD and not a MUST). The
text we currently have is based on the security reviews we got for RTP
payload specifications, and as you can see it addresses the issue of why not
to mandate SRTP.

Roni

From: Dan York [mailto:[email-masked]] 
Sent: Wednesday, July 15, 2009 12:11 AM
To: Roni Even
Cc: 'Roni Even'; 'Daniel Burnett'; [email-masked]; 'Saravanan
Shanmugham'; [email-masked]
Subject: Re: [RAI] RAI review of draft-ietf-speechsc-mrcpv2-19

Roni,

------

------

Or would you prefer this text that includes the recommendation of SRTP?
(Which I noticed you did in the RTP payloads spec - and it makes sense to me
to provide some basic guidance.):

------

12.3. Media session protection 
Sensitive data is also carried on media sessions terminating on MRCPv2
servers (the other end of a media channel may or may not be on the MRCPv2
client). This data includes the user's spoken utterances    and the output
of text-to-speech operations. MRCPv2 servers MUST support a security
mechanism for protection of audio media sessions. MRCPv2 clients that
originate or consume audio similarly MUST support a security mechanism for
protection of the audio. If appropriate, usage of the Secure Real-time
Transport Protocol (SRTP) [RFC3711] is recommended.

------

Regards,

Dan

Regards,

Dan

Dan,

Roni Even

Roni,

The current text at

------

------

------

------

Regards,

Dan

Eric,

Roni

-----Original Message-----

To: Roni Even

[email-masked]

Does this work for you?

[snip]

not-mandatory-02

-- 

 

 

--

---

From: Arsen Chaloyan <[email-masked]>
Date: Tue, 14 Jul 2009 02:44:23 -0700 (PDT)

Hi,
Two small issues left you may want to fix.

- Section 9.4.30
Media type should be "text/plain" instead of "plain/text"
http://www.w3.org/TR/2004/REC-speech-synthesis-20040907/

- Find BARGE-IN-OCCURED replace with BARGE-IN-OCCURRED
There are 3 such occurrences in the text.

Thanks,
Arsen.

________________________________
From: Roni Even <[email-masked]>
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Sent: Wednesday, July 8, 2009 12:40:17 AM
Subject: [Speechsc] RAI review of draft-ietf-speechsc-mrcpv2-19

Hi,
I was
assigned to do a RAI review of the draft.  The draft looks ready for
publication to me. I have some comments mostly editorial. 
The
only issue I see that is not pure editorial is the issue of the different
parameters like confidence threshold, sensitivity level (see comments 11, 13,
15, 16 and 17). I think that some clarification on the semantics and the scale
(for example are the values linearly spaced) as well as when they are useful
will be helpful to implementers.
1.       In figure 1 Expand the abbreviations TTS, ASR, SV , SI
and how they are related to the media resource types in 3.1
2.       In figure 1 there is a SIP dialog between the MRCPv2
client and the media source/sink, what is this dialog, I only saw in section 4
a dialog between the client and server.
3.       In section 3.2 you have “For
example: sip:[email-masked]” twice one after
the other.
 
4.       In the example in section 4.2 you
“a=cmid:1”, cmid is specified later in the document so maybe you
can add some reference to where it is specified
 
5.       In the example is section 4.2 and in
following examples you have “m=audio 49170 RTP/AVP 0 96” but do not
have an rtpmap parameter for mapping 96 (dynamic payload type number) to a
media encoding name.
 
6.       In section 4.3 “Also note that
more that one media session can be associated with a single resource if need
be, but this scenario is not useful for the current set of resources”.
There is a typo the second “that” should be “than”. I
am also not sure if the current syntax in this document can support the mode.

7.       In section 4.3 “The formatting
of the"cmid" attribute in SDP RFC3388 [RFC4566]”. I think you
meant SDP grouping and need the reference to RFC 3388..

8.       In section 5.1 “The message-length
field specifies the length of the message, including the start-line” is
the length in Bytes, there is no unit specified.
 
9.       In section 6.3.1, typo you have
“Verfication “ instead of verification.. It appears twice in the
section.
 
10.   In the example in section 7 you have
“m=audio 0 RTP/AVP 0 1 3” payload type 1 was deleted from the IANA
registry, maybe have another payload type number.
 
11.   In section 9.4.1, 9.4.2 and 9.4.3
you specify confidence threshold, sensitivity level and speed vs accuracy. What
is the scale here; is it linear between 0 and 1. What is the absolute value of
the number, if you receive the same confidence level from two recognizers are
they the same (e.g. when using context block to switch servers).  For the
speed vs accuracy, how does the client know what is the relation between the
value and the number of available sessions, since this seems to be the reason
for using this parameter.
 
12.   In 9.4.9 and in 10.4.8, 11.4.11 what
are the values for media-type-value, you also mention audio and video but it
looks to me that this document only discusses voice.
 
13.   In 9.4.35 and 9.4.36 what is the
scale for the consistency here. How does one know what close means. What is the
consistency between different recognizers.
 
14.   In section 9.6.3.3 in the example
(figure 2) confidence should be 0.75 and not 75
 
15.   In section 10.4.1 it is not clear
how you measure the sensitivity in order to specify, is it based on some SNR
translated to 0 to 1 scale?
 
16.   In 11.4.6 the same issue with the
scale, how does the client know how to set a value when working with different
speaker verification servers.
 
17.   In 11.5.2.9 you state that the
verification-score is not a probability, so what is it. How can the client decide
if, for example, 0 is a good score for specifying the threshold.  I also
noticed that the values in the example in section 11..5.2.10 are very precise
like 0.98514 is this the expected precision. The examples here and in section
11.11 do not show the threshold, if the threshold is required for this flow why
not show it in the example?
 
18..   In section 12.3 the suggestion is to
use SRTP as the mandatory interoperability mode. If the reason for mandating
SRTP is for a common mode you should also decide on a key exchange mechanism. I
suggest you look at http://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory-02 for discussion on media security.
 
19.   In section13.7.2 you specify the attribute
resource as session level yet in the example in section 4.2 it is a media level
attribute. The same goes for the channel attribute
 
Thanks
 
Roni
Even

---

From: "Judith Markowitz" <[email-masked]>
Date: Wed, 15 Jul 2009 12:28:25 -0500

I want to support the position of recommending but not mandating. The
approach used needs to comply with the policies and procedures of an
organization. 

It could very well be that those policies and procedures are far more
stringent than anything that would be mandated by MRCP V2. So, if a
particular approach 

or  technology is mandated the use of MRCP may be rejected because the
security is not adequate or proper. 

Judith Markowitz

J. Markowitz, Consultants

5801 N. Sheridan Rd, #19A

Chicago, IL 60660

773-769-9243

[email-masked]

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Roni Even
Sent: Tuesday, July 14, 2009 4:36 PM
To: 'Dan York'
Cc: [email-masked]; 'Saravanan Shanmugham'; [email-masked]; 'Roni Even'
Subject: Re: [Speechsc] [RAI] RAI review of draft-ietf-speechsc-mrcpv2-19

Dan,

Roni

Roni,

------

------

------

------

Regards,

Dan

Regards,

Dan

Dan,

Roni Even

Roni,

The current text at

------

------

------

------

Regards,

Dan

Eric,

Roni

-----Original Message-----

To: Roni Even

[email-masked]

Does this work for you?

[snip]

not-mandatory-02

-- 

 

 

--