[tram] SSODA in TURN-bis

"Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com> Thu, 08 January 2015 02:02 UTC

Return-Path: <tireddy@cisco.com>
X-Original-To: tram@ietfa.amsl.com
Delivered-To: tram@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47F2B1A0072 for <tram@ietfa.amsl.com>; Wed, 7 Jan 2015 18:02:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wM8HgC3VWfaC for <tram@ietfa.amsl.com>; Wed, 7 Jan 2015 18:02:49 -0800 (PST)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 906971A036F for <tram@ietf.org>; Wed, 7 Jan 2015 18:02:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3477; q=dns/txt; s=iport; t=1420682569; x=1421892169; h=from:to:subject:date:message-id:mime-version; bh=R64TorCSsDcEYbbRjelZbwnCD7KTvI2uZFHSLflIKzo=; b=JomXZTqZxWPH1v9y7R+rjagx2PT4RaducJ3zq0WkHanG67cqOjlt5XRM wlA/9WRcy4CrMU5/1I+xXjtvnNe3LDaY04UzsGe6nwh6lC/4xDkr5aC/q dez2uMkChQU90guycXFSan7pr0Z1Fi21+wo5BpIAhbF6d8rxrhDJdwPEL c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ag0FABXlrVStJA2M/2dsb2JhbABcgkNDUlzDU4IlhXMCgRFDAQEBAQF9hA4BBC1eAQweViYBBBuIJA2hI6MHAQEBAQEBAQMBAQEBAQEYBI9HLYMhgRMFji6DQ4ZLgm6NaCKDboI0fgEBAQ
X-IronPort-AV: E=Sophos;i="5.07,719,1413244800"; d="scan'208,217";a="382084464"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-1.cisco.com with ESMTP; 08 Jan 2015 02:02:28 +0000
Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t0822Sa5017071 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <tram@ietf.org>; Thu, 8 Jan 2015 02:02:28 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.160]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Wed, 7 Jan 2015 20:02:28 -0600
From: "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com>
To: "tram@ietf.org" <tram@ietf.org>
Thread-Topic: SSODA in TURN-bis
Thread-Index: AdAq5yRwxEi4Jbc7TpCKn/lLZn1lew==
Date: Thu, 08 Jan 2015 02:02:27 +0000
Message-ID: <913383AAA69FF945B8F946018B75898A35527E46@xmb-rcd-x10.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.65.55.119]
Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A35527E46xmbrcdx10ciscoc_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tram/xSvIteRlWABlM4fzXu7U-41bdMI
Subject: [tram] SSODA in TURN-bis
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." <tram.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tram>, <mailto:tram-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tram/>
List-Post: <mailto:tram@ietf.org>
List-Help: <mailto:tram-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tram>, <mailto:tram-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Jan 2015 02:02:51 -0000

Hi all,

We are working on incorporating RFC6156 and SSODA into TURN-bis. During IETF-91 meeting there was discussion if the technique proposed in https://tools.ietf.org/html/draft-martinsen-tram-ssoda-01 would break existing TURN server implementations.  Pal had mentioned testing with four implementations and did not face any problem.

Please let us know if there are any concerns with the existing proposal of conveying two REQUESTED-ADDRESS-FAMILY attributes with different attribute values in Allocate request ?

Cheers,
-Tiru