Subject: [RAI] RAI Review of draft-ietf-mediactrl-sip-control-framework-02

From: Ben Campbell <[email-masked]>
Date: Mon, 19 May 2008 22:36:09 -0500

I am the assigned RAI-ART reviewer for draft-ietf-mediactrl-sip- 
control-framework-02

For background on RAI-ART, please see the FAQ at <http://www.softarmor.com/rai/art/rai-art-FAQ.html 
 >.

Please resolve these comments along with any other comments you may  
receive.

Summary:

My overall review is that this document is either "on the right track  
with open issues", or "has serious issues and should be rethought",  
depending on the response to a couple of critical concerns.

--Critical Concerns:

1) It is not clear to me why the media control protocol needs to be  
negotiated via SIP. SIP primarily offers rendezvous and media  
negotiation. I'm not sure why this protocol needs either. There are  
several mentions of rendezvous, but no discussion of why it is needed.  
Are application servers or media servers likely to move around, or  
have dynamically assigned IP addresses, etc? Do we need registration,  
forking, etc? Or more to the point, why can't a media control client  
just open the connection to the server directly, rather than going  
through an SDP offer/answer? What makes it different from thousands of  
other protocols that get by just fine without SIP?

I'd like to at least see motivation for this discussed in the draft.

2) Why do we need an entirely new protocol for this? Could this not  
have been done with one of many existing protocols that allow us to  
send requests with MIME bodies and get responses? (e.g. HTTP)? I  
assume the work group thought about this, and has good reasons. It  
would help to have the reasoning documented in the draft.

--Lesser Substantive Comments:

Section 1, paragraph 1:

"It is intended that the framework contained in this document will be  
applicable for a variety of device control scenarios."

That's very open ended. Can the scope be defined more clearly? I hope  
that requirements were not added for this framework simply because  
some device control scenario might someday need them.

paragraph 2:

"This document does not define a SIP based extension that can be used

    directly for the control of external components.  The framework

    mechanism must be extended by other documents that are known as

    "Control Packages" "

  I'm confused by the words "SIP based" in this paragraph.

paragraph 4:

"Application servers traditionally use SIP third party call control

    [RFC3725] to establish media sessions from SIP user agents to a  
media

    server."

Some do, some don't. Is this attempting to suggest that they should  
use 3PCC, or merely acknowledging it? I propose striking the paragraph.

Section 2, definition of Transaction-Timeout:

Is it safe to hard-code the transaction timeout? How was this value  
chosen?

Section 3, paragraph 1:

Is the requirement here really for SIP, or for SDP offer/answer? I  
know the answer might be that there aren't many such protocols, but  
for example we went to some trouble in the MSRP work to avoid making  
it SIP specific.

Also, the sentence structure is easily read to imply you mean to use  
SIP to control an external server, rather than use SIP to establish a  
channel to control the external server.

Section 3, List of arguments for SIP

3rd bullet:

This spec talks later about auditing parameters using _this_ protocol-- 
how does SIP contribute to that?

Section 4.1:

"(   The UAC MAY include a valid session description (an 'offer' as  
defined in [RFC3264]) in an INVITE request using the Session  
Description Protocol defined in [RFC4566] (*note - SIP also allows an  
'offer-less' INVITE which is also maintained by this specification)."

While SIP allows this, it a common source of interop orbits. Unless  
there is a a specific need otherwise, I suggest the MAY should be a  
SHOULD.

"[cfw-id] MUST contain an appropriately random value that will not  
clash with other offer/answer exchanges that will take place and is  
globally unique over space and time."

Can you provide more precise guidance on what level of randomness is  
needed? (i.e. how many bits of randomness, etc.)

"The client generating the offer should act as it would normally on  
receiving this response, as per [RFC3261]."

Should that be normative? (I think you just stated a requirement that  
the client does what the client does.)

"Media streams can also be rejected by setting the port to "0" in the  
"m=" line of the session description."

Need to be explicit that this is in the _answer_. (In general, watch  
for imprecise language around offers and answers.)

" A client using this specification should be prepared to receive an  
answer where the "m=" line it inserted for using the Control Framework  
has been set to "0"."

How should it behave when this happens?

Section 6, second bullet point:

Is the dialog-id correlated with a dialog, or a media description? Can  
we have more than one dialog-id values in a single SDP document?

Section 6.1, first paragraph:

You need more guidance on the uniqueness requirements for the  
transaction identifiers.

Paragraph 4:

What does a client do when a transaction times out? Is that specific  
to the package?

Section 6.2, last paragraph:

The draft should say more than "might result in a resubmission". Who  
gets to decide? Is this package specific?

Section 6.3, 2nd paragraph:

Need a little more about how extension methods are handled. Are they  
package specific? What does a device do if it gets a method it does  
not understand.

6.2.1, first paragraph:

What goes in Content-Type? Does it use MIME media types? Do we need to  
allow other MIME headers than Content-Type and Content-Length?

6.3.2.1, paragraph 2:

What if a client does not want to wait as long as is indicated in the  
202? Does it have any recourse?

paragraph 3: Do the range suggestions for Timout in REPORT also apply  
to the value in a 202 response?

paragraph 5: Is there any use for a terminating REPORT message without  
a body? Is there a header where it can put the results of the original  
request?

6.3.3, first paragraph:

  Is support of the outbound keep-alive mechanism a requirement for  
devices implementing this framework?

2nd paragraph:

How would you indicate support for such future  keep-alive mechanisms?

6.4.3.1:

Isn't it true that the "active" participant always sends the sync? If  
so, then this list could be greatly simplified by simply saying  
something to the affect that "The active party as negotiated via  
COMEDIA sends the SYNC..."

7.2.2:

ben: Is the "completion of a successful transaction" part really true?  
Can we have responses along the line of "Trying...still trying...oops,  
that failed"?

7.9

"Recipient already has a transaction with the same transaction ID."

7.10

Is the first type of 481 response only for REPORT requests?

7.11:

How is 500 as defined practically different from 400?

8.1

What is the practical use of the version number? I don't recall  
mention of version numbers in the package support negotiation.

8.3:

This section seems to need elaboration. What do you mean by media  
dialog and Conference reference? Also, need more elaboration on what  
sort of MUST strength statements.

8.4:

Does the Control message body section need to discuss MIME media types?

8.6:

Can you define what you mean by the auditing of a control package  
properties? And how is this different from defining any other  
operation in a package?

9.1:

Is Content-Length missing from the expansion of "header-name"?

11.1:

Need more here--what are you actually recommending? Also, need to  
address the fact that the id parameter in the SDP is crucial to  
determining that the correct host is connecting.

11.2, last paragraph:

Need to talk more about TLS authentication here. What is actually  
being authenticated? What certificate fields are checked? Can you use  
self-signed certs (maybe with fingerprints sent in SIP)

11.3

In my opinion, section 12.3 needs a complete rewrite. I really cannot  
tell what it attempts to say other than something to the effect of  
"You can authorize particular actions based on the authenticated  
identity of the sender, and send 403 if an action is not allowed.

--Nits and Editorial Comments:

Global:

There's lots of use of passive-voice language that obscures which  
device is responsible for some particular action. For example, "...  
the control-channel is terminated" would be better phrased as "The  
[UAC or UAS] terminates the control channel.

All of the bullet lists are missing white space between entries. This  
makes them hard to read, at least for me.

Section 1, paragraph 1:

It would help to elaborate on what you mean by "logic" and  
"processing" and why they are different.

Section 4.1, first paragraph:

Sentence is a little confusing. I assume you mean to say something to  
the effect of "when a UAC wishes to establish a control channel, it  
MUST construct and transmit INVITE..."

"A non-2xx class error (4xx, 5xx and 6xx) SIP response received for

    the INVITE request indicates that no SIP dialog has been created and

    is treated as specified [RFC3261]"

s/error/"final response"

4.2, general

I think this section would be more clear if written in terms of SDP  
offers and answers, rather than SIP messages, given that the offers  
and answers do not always show up in the same SIP messages.

"  If the UAS does not support the extension defined in this document,

    as identified by the media contained in the Session Description, it

    SHOULD respond as detailed in [RFC3261] with a "SIP 488" response

    code.  If multiple media descriptions exist it MAY choose to  
continue

    processing the request and mark the port field equal to "0"."

You can't really put normative requirements on devices that _don't_  
implement this protocol. This would be better written as a non- 
normative statement of what SIP devices that do not implement this  
spec would do.

Section 5, second paragraph:

It's not clear to me what the "(B2BUA functionality)" means in context.

Third paragraph:

I don't understand this paragraph. Can you rephrase?

Section 6.2, paragraph 2, 2nd sentence:

The sentence is hard to follow.

"...will return a 202 status code..."

s/return/"result in"

Section 6.2, first sentence:

s/messages/requests

6.3.4.2, third paragraph:

I assume the 422 response means there is no package supported  
_in_common_, not that no package is supported at all, right?

9.1:

The ABNF is inconsistent in handling of literal strings. For example,  
method names are spelled out in text, but header names are not.

10, step 6:

Didn't the TCP connection get opened in step 4?

11.3: paragraph 1:

I don't recall a discussion of failover and redundancy.

12.1:

What RFC tracks are appropriate for package definitions?

12.4:

Is "Content-Length" missing?

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

---

From: Joerg Ott <[email-masked]>
Date: Tue, 20 May 2008 10:53:45 +0300

> other protocols that get by just fine without SIP?

I could not agree more.  I raised this issue already in one of the
very first MEDIACTL WG (or BoF?) meetings, I think in Prague.  The
answer was that the players felt like it, it was already partly
spec'ed and implemented elsewhere.

The discovery of devices owned by a service provider feels more like
service location problem and one can surely argue whether SIP should
be stretched that far.  (Yes, you can also argue that this is a
rendezvous function but, then, there are many rendezvous protocols.)

> I'd like to at least see motivation for this discussed in the draft.

I am not sure that this makes it a better or more valid solution.
That said, it will probably work, but architecturally this seems
wrong.

I gave up on this since, thinking of networking truth #3,
"With sufficient thrust, pigs fly just fine." [RFC 1925]

Joerg

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 20 May 2008 13:44:56 -0500

Isn't it a bit late for these types of comments? 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Joerg Ott
> Sent: Tuesday, May 20, 2008 00:54
> To: Ben Campbell
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [RAI] RAI Review of 
> draft-ietf-mediactrl-sip-control-framework-02
> 
> > --Critical Concerns:
> > 
> I could not agree more.  I raised this issue already in one 
> of the very first MEDIACTL WG (or BoF?) meetings, I think in 
> Prague.  The answer was that the players felt like it, it was 
> already partly spec'ed and implemented elsewhere.
> 
> The discovery of devices owned by a service provider feels 
> more like service location problem and one can surely argue 
> whether SIP should be stretched that far.  (Yes, you can also 
> argue that this is a rendezvous function but, then, there are 
> many rendezvous protocols.)
> 
> That said, it will probably work, but architecturally this 
> seems wrong.
>

---

From: Ben Campbell <[email-masked]>
Date: Tue, 20 May 2008 15:39:18 -0500

> Isn't it a bit late for these types of comments?

The original post in this thread was from me, as an RAI-ART reviewer.  
The intent of such a review is to, among other things, point out any  
basic architectural issues in the use of RAI protocols, etc. I have  
not followed mediactrl prior to being asked to perform this review.

Unfortunately the link to the RAI-ART FAQ in the review template  
appears to be broken. I found an alleged FAQ at http://www.softarmor.com/rai/art/FAQ.html 
  , but I cannot speak for its "officiality"

It is, also unfortunately, the nature of area review team reviews to  
come later in the process than might be most efficient.

---

From: Joerg Ott <[email-masked]>
Date: Tue, 20 May 2008 22:29:48 +0300

Obviously, my comments were *not* late (as I stated below).

>>>several mentions of rendezvous, but no discussion of why it 
>>
>>is needed.
>>
>>>have dynamically assigned IP addresses, etc? Do we need 
>>
>>registration, 
>>
>>>forking, etc? Or more to the point, why can't a media 
>>
>>control client 
>>
>>>through an SDP offer/answer? What makes it different from 
>>
>>thousands of 
>>

---

From: "Mary Barnes" <[email-masked]>
Date: Wed, 21 May 2008 09:36:21 -0500

The advantage of getting these sorts of comments now is that if Ben has
these questions, it's very likely that other reviewers (e.g., gen-art,
security directorate, etc.) and members of the IESG will have similar
questions. So, it's far better for the WG to address the concerns now
rather than during IETF Last Call. 

Mary. 
--who has fixed the bad links on the rai review page --

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ben Campbell
Sent: Tuesday, May 20, 2008 3:39 PM
To: Audet, Francois (SC100:3055)
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [RAI] RAI Review of
draft-ietf-mediactrl-sip-control-framework-02

The original post in this thread was from me, as an RAI-ART reviewer.  
The intent of such a review is to, among other things, point out any
basic architectural issues in the use of RAI protocols, etc. I have not
followed mediactrl prior to being asked to perform this review.

Unfortunately the link to the RAI-ART FAQ in the review template appears
to be broken. I found an alleged FAQ at
http://www.softarmor.com/rai/art/FAQ.html
  , but I cannot speak for its "officiality"

>> From: [email-masked] [mailto:[email-masked]] On Behalf Of

>> Joerg Ott
>> I gave up on this since, thinking of networking truth #3, "With 
>> sufficient thrust, pigs fly just fine." [RFC 1925]
>>
>> Joerg