Subject: Re: [MEDIACTRL] AD review: draft-ietf-mediactrl-ivr-control-package

From: "McGlashan, Scott" <[email-masked]>
Date: Thu, 2 Jul 2009 15:12:11 +0000

Hi Robert,

Sorry for the delay in responding. Thanks for the comments. 

I'll produce an update version of the document by next week to address these comments. See inline below for responses to your specific points.

Thanks

Scott 

-----Original Message-----
From: Robert Sparks [mailto:[email-masked]] 
Sent: Thursday, June 11, 2009 21:25
To: [email-masked]; [email-masked]; [email-masked]
Subject: AD review: draft-ietf-mediactrl-ivr-control-package

This document is close to ready to proceed. There are a few questions I have before moving the document to IETF LC. We'll most likely need to revise the document after we have the answers so I'm putting the document into a "Revised ID Needed" state.

1) I'm not finding any response to the questions in Ben Campbell's review at http://www.ietf.org/mail-archive/web/rai/current/
msg00195.html. Can you point me to where they are addressed (or address them if you haven't already)?

[Scott] Ben Campbell reviewed version -00. Our response to Ben's comments was discussed in person with Ben at MediaCtrl Meeting at Dublin F2F, IETF 73 (meeting minutes: http://tools.ietf.org/wg/mediactrl/minutes?item=minutes72.html)  and then we published version 01 addressing Ben's comments (see Change Log for version 00 -> 01 for details).  

2) Was there any discussion around the security issues associated with pointing to an external resource for a dialog document?  (How do you know you got the document you meant to get vs content an attacker wants played. How does the thing that's serving the document control access to it, etc.) If so, has that discussion been captured anywhere?

[scott] Yes. We had an internal security review led by Dan York (http://www.ietf.org/mail-archive/web/mediactrl/current/msg01061.html) and these issues were addressed in -03, especially the Security Considerations (see change log, version 02 -> 03 for details). Donald Eastlake performed a security review of version -03 (http://www.ietf.org/mail-archive/web/secdir/current/msg00330.html). Related to your specific questions, we secure the control channel to ensure that the URI for the resources isn't tampered with, and the connection between the MS and HTTP server can be secured. I now see that we don't mention authentication for dialog documents, but do for media resources. I will correct the definition of src attribute in <dialogprepare> and <dialogastart> (and grammar) so that it mentions authentication information. I will also add a sentence in the Security Considerations indicating that document and resource retrieval should be secured. 

3) Is it clear what's supposed to happen when an MS receives a document with a <subscribe> with no child elements?

[scott] Intended to be equivalent to a document without a <subscribe> element - i.e. there may be a <subscribe> element but no actual subscriptions are specified. I can check on the list if anyone finds this unclear. 

4) Why does the document reserve the remaining single digit status codes?

[scott] To allow future versions of this package to add new status codes for additional functionality they introduce. 

5) 4.3.1.3.1 - Please confirm that the example containing <grammar><grammar>...<grammar/><grammar/> conforms to the appropriate schemas.

[scott] Yes, this conforms. The parent <grammar> is the msc-ivr element and the child <grammar> element is from the W3C SRGS namespace. The msc-ivr <grammar> allows a child <grammar> due to its definition:

	<xsd:any namespace="##other" minOccurs="0"
				maxOccurs="unbounded" processContents="lax" /> 

6) There is a problem with the recommendation for recovery from a 406 error in table 1. If dialogids are intended to be unique across the whole MS, and audit results are scoped only to those dialogids created by this control channel, the recommendation won't lead to recovery.  
What should the recovery suggestion say instead?

[scott] Right. The recovery action should indicate that the AS can always recover by not specifying the id in the creation command and let the MS generate a unique id in the response.

7) I'm not seeing a request for types review for application/msc-ivr 
+xml. Could you please provide a pointer into the archives or have the
shepherd send the request?

[scott] Eric has sent the request: http://www.ietf.org/mail-archive/web/mediactrl/current/msg01309.html

8) Why isn't the document creating a response code registry?

[scott] I wasn't aware that we should do so - let us know if we should do this.  Since the response codes are specific to a package, such a registry would be required for each package and this type of requirement should probably be addressed in the control channel framework.    

9) What is the motivation for the reserved response codes?

[scott] To provide specific error codes related to the functionality described in this package. Such error codes could be used for development and debugging. 

Some nits to fix when the draft is revised next.

a) Please delete the To: and Subject: header fields from 8.1.

b) On page 8: "executed successful," should probably be "executed successfully"

c) On page 14: There is a spurious ')' at "Section 7 )."

RjS

---

From: Robert Sparks <[email-masked]>
Date: Tue, 7 Jul 2009 10:52:24 -0500

Thanks for the reply - There are a couple of spots to follow up on now:

On Jul 2, 2009, at 10:12 AM, McGlashan, Scott wrote:

> [scott] To allow future versions of this package to add new status  
> codes for additional functionality they introduce.
>

To make sure everyone knows what we're talking about, this is the  
status code contained in the <dialogexit>
(Section 4.2.5.1), which is different from the status codes we'll be  
talking about later in this message.

This looks like a place where you're headed into an interoperability  
problem.
Is it your intent that MSs and ASs are free to make up these status  
codes (of 2 digits or more) and
decide amongst themselves what they mean? (If so, you are saying it's  
ok for systems to fail if you
plug two things that have decided to use 15 to mean different things  
together. If not, you really meant
to make this a standards controlled space and probably should consider  
using a registry).

A side note: We're going to have to be very explicit in the next few  
rounds in this conversation to not
confused (or worse conflate) the above conversation with the below  
conversation.

> [scott] I wasn't aware that we should do so - let us know if we  
> should do this.  Since the response codes are specific to a package,  
> such a registry would be required for each package and this type of  
> requirement should probably be addressed in the control channel  
> framework.
>
> [scott] To provide specific error codes related to the functionality  
> described in this package. Such error codes could be used for  
> development and debugging.
That answered why you made the field extensible, not why you reserved  
codes.

This appears to have the same kind of interop problem I was pointing  
to above.

The group should make an explicit choice on whether and how this  
extensibility should be controlled.

There are a wide range of choices for that how - registries are  
typical, but not necessary.
If you really don't expect extensions in the future, creating a  
registry is work that won't have much payback,
but if you expect there will be even a few, it's probably worth the  
effort.

If you don't expect extensions, a typical pattern is to reserve _all_  
the undefined points and declare that
something formal (like an RFC) is needed to add a new one. Then if you  
are surprised by an extension
later, you can create a registry at that time.

RjS

---

From: "McGlashan, Scott" <[email-masked]>
Date: Tue, 21 Jul 2009 18:42:46 +0000

Hi Robert,

Following WG discussion, there is WG consensus to address these issues by not creating registries for either types of status code at this stage since we don't think there will extensions without a new version of the specification (1.1, 2.0, etc). We've added a statement for both that all undefined codes are reserved for future use and that a standards-track RFC is required to defined new codes. See the attached draft (and diffmarks with the previous version) which addresses these points as well as other you have made (section 9 lists all the changes). Thanks for your review - appreciated.

Let us know if there any other issues to address (apart from the dependency on the next version of the framework document!).

Thanks 

Scott

WG request for WG consensus on approach: 
http://www.ietf.org/mail-archive/web/mediactrl/current/msg01327.html

WG replies, all agreeing: http://www.ietf.org/mail-archive/web/mediactrl/current/msg01329.html, http://www.ietf.org/mail-archive/web/mediactrl/current/msg01331.html, http://www.ietf.org/mail-archive/web/mediactrl/current/msg01332.html, http://www.ietf.org/mail-archive/web/mediactrl/current/msg01337.html

-----Original Message-----
From: Robert Sparks [mailto:[email-masked]] 
Sent: Tuesday, July 07, 2009 17:52
To: McGlashan, Scott
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: AD review: draft-ietf-mediactrl-ivr-control-package

RjS