Subject: [clue] FW: New Version Notification fordraft-hansen-clue-protocol-choices-evaluation-00.txt

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Thu, 17 Nov 2011 03:03:45 -0800

Looking forward to hearing comments-

A new version of I-D, draft-hansen-clue-protocol-choices-evaluation-00.txt has been successfully submitted by Allyn Romanow and posted to the IETF repository.

Filename:	 draft-hansen-clue-protocol-choices-evaluation
Revision:	 00
Title:		 Evaluation of using SIP or an independent protocol for CLUE messaging
Creation date:	 2011-11-17
WG ID:		 Individual Submission
Number of pages: 8

Abstract:
   This document evaluates the advantages and disadvantages of using SIP
   or an independent protocol for conveying CLUE messages/

The IETF Secretariat

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 17 Nov 2011 22:23:41 +0800

> Looking forward to hearing comments-

Ask and ye shall receive:

Section 3:

"For these reasons we would recommend using UDP over TCP for an 
independent protocol"

I think you must mean TCP over UDP.

But, for something serial over UDP, we would be well advised to look at 
what RTCWEB is doing for its data channel. (TCP over UDP is one 
possibility, more or less, and SCTP over UDP is another.)

Moreoever, based on comments in joint ad hoc today, we may need to 
constrain ourselves to using *precisely* what RTCWEB uses so that its 
possible to have an RTCWEB-based endpoint in a CLUE sesssion.

Section 5:

   "for an independent protocol standard libraries can be used for the
    transport protocol, and it would even be possible to create a CLUE
    protocol library that could then be distributed, making adoption very
    straightforward."

The options being explored by rtcweb don't all have this property, at 
least not yet, though it is desired. And unfortunately there is no 
guarantee of that improving. (IIUC, Each browser implementation will 
provide an API for web apps. But its possible there won't be a common 
library used for the implementation in the browser.)

Section 7:

The issue of intermediaries inadvertently breaking things should not be 
such a big problem if an appropriate manner of conveying the data in sip 
is chosen. E.g. if an INFO package is used it should not be a problem.

OTOH, intermediaries may well advertently break the usage. But if so its 
most likely at the specific direction of whoever configured the 
intermediary. In that case the solution is "if it hurts, don't do it". 
The intermediary can break any technique if it feels it should.

An important issue is not mentioned: sending potentially large messages 
through the sip signaling path can load down all the servers on the path.

	Thanks,
	Paul

---

From: Robert Hansen <[email-masked]>
Date: Fri, 18 Nov 2011 18:29:49 +0000

> I think you must mean TCP over UDP.

As Mark Duckworth pointed out this was poor choice of words on my part, 
and I did indeed mean UDP *as opposed to* TCP.

 > library used for the implementation in the browser.)

Being able to provide a complete protocol library would obviously be 
desirable, though the messaging portion of the current CLUE protocol is 
relatively straightforward and should be relatively simple to implement 
(though that'll depend somewhat on exactly how the messages are encoded 
- ASN.1 will be harder to adopt than XML).

 > The intermediary can break any technique if it feels it should.

I obviously agree that if the intermediary device is configured to not 
allow something it should be able to prevent it; this is possible both 
if CLUE messages are conveyed in SIP itself, or if they are only 
negotiated in SIP.

However, the problem occurs when B2BUAs won't or can't pass through 
things they don't recognise. How problematic things are likely be be 
will depend on the SBC and how the CLUE messages are put into SIP; 
putting CLUE messages in INVITE/UPDATE is particularly likely to run 
into such issues, in my experience.

 > through the sip signaling path can load down all the servers on the path.

That's true, and not something I mentioned.

Rob

On 17/11/2011 14:23, Paul Kyzivat wrote:
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue