[pntaw] FW: [rtcweb] Query/Comment on draft-ietf-rtcweb-use-cases-and-requirements-12

"Chenxin (Xin)" <hangzhou.chenxin@huawei.com> Wed, 22 January 2014 11:56 UTC

Return-Path: <hangzhou.chenxin@huawei.com>
X-Original-To: pntaw@ietfa.amsl.com
Delivered-To: pntaw@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 202AE1A0444 for <pntaw@ietfa.amsl.com>; Wed, 22 Jan 2014 03:56:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.736
X-Spam-Level:
X-Spam-Status: No, score=-4.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] 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 quyWmfjwERLn for <pntaw@ietfa.amsl.com>; Wed, 22 Jan 2014 03:56:23 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 975D21A043E for <pntaw@ietf.org>; Wed, 22 Jan 2014 03:56:21 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCU19237; Wed, 22 Jan 2014 11:56:20 +0000 (GMT)
Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 22 Jan 2014 11:55:16 +0000
Received: from SZXEMA406-HUB.china.huawei.com (10.82.72.38) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 22 Jan 2014 11:56:18 +0000
Received: from SZXEMA504-MBX.china.huawei.com ([169.254.7.191]) by SZXEMA406-HUB.china.huawei.com ([10.82.72.38]) with mapi id 14.03.0158.001; Wed, 22 Jan 2014 19:56:13 +0800
From: "Chenxin (Xin)" <hangzhou.chenxin@huawei.com>
To: "pntaw@ietf.org" <pntaw@ietf.org>
Thread-Topic: [rtcweb] Query/Comment on draft-ietf-rtcweb-use-cases-and-requirements-12
Thread-Index: AQHPEdt4BmafjBJA1EK1NoxWhueV6ZqQq+Cw
Date: Wed, 22 Jan 2014 11:56:12 +0000
Message-ID: <9E34D50A21D1D1489134B4D770CE0397680AA8B2@SZXEMA504-MBX.china.huawei.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.173.17.195]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "magnus.westerlund@ericsson.com" <magnus.westerlund@ericsson.com>, "Hutton, Andrew" <andrew.hutton@unify.com>, Parthasarathi R <partha@parthasarathi.co.in>, Christer Holmberg <christer.holmberg@ericsson.com>
Subject: [pntaw] FW: [rtcweb] Query/Comment on draft-ietf-rtcweb-use-cases-and-requirements-12
X-BeenThere: pntaw@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion list for practices related to proxies, NATs, TURN, and WebRTC" <pntaw.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pntaw>, <mailto:pntaw-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pntaw/>
List-Post: <mailto:pntaw@ietf.org>
List-Help: <mailto:pntaw-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pntaw>, <mailto:pntaw-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jan 2014 11:56:26 -0000

 I find it lost in rtcweb mailing list, so I forward it to pntaw list, I think the guys following this group will be interested in this change proposal. I do not like silence too and I hope the usecase and requirement could be published ASAP.

 The change proposal is related to the discussion on pntaw. Also ,I hope the words could be more accurate and the requirement could be clearer.

 So ,any ideas about it?

 To Magnus:
    What will happen if there is no response?

Best Regards,
     Xin 


-----Original Message-----
From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] 
Sent: Wednesday, January 15, 2014 6:20 PM
To: Chenxin (Xin); Hutton, Andrew; Christer Holmberg; Parthasarathi R; rtcweb@ietf.org
Subject: Re: [rtcweb] Query/Comment on draft-ietf-rtcweb-use-cases-and-requirements-12

WG,

It has been quite some time since the WG last call ended and a new
revision was submitted. As Document Shepherd I want to push this
document to publication request.

Chenxin proposed below three different sets of changes to the document.
Does the WG support making these changes? Please indicate within the
next week if you support or want to reject these changes.

Thanks

Magnus


On 2013-10-17 12:23, Chenxin (Xin) wrote:
> Hi Andy,
> 
>  
> 
>   I think you means F29 not F27:). When I read it , I realize that there
> is cross and ambiguous between 3.3.2 and 3.3.3
> 
>  
> 
>   More details:
> 
>  
> 
>   The topic of 3.3.2 is "Simple Video Communication Service, *NAT/FW*
> that blocks UDP". But in the description and requirement, only *NAT* is
> considered.
> 
>   The topic of 3.3.3 is "Simple Video Communication Service, FW that
> only allows http", But only *http proxy* deployed scenarios is considered.
> 
>  
> 
>   There are other usecases " FW block UDP, incoming TCP, Http allowing
> FW without http proxy deplolyed under the permission of FW policy" ,
> which is lost in the description. If we need consider these usecases , I
> suggest to make some change to the description.
> 
>  
> 
>   Proposal 1 :
> 
>  
> 
>   add FW related words to section 3.3.2
> 
> -------------------------------------------------
> 
> 3.3.2.  Simple Video Communication Service, NAT/FW that blocks UDP
> 
>  
> 
> 3.3.2.1.  Description
> 
>  
> 
>    This use-case is almost identical to the Simple Video Communication
> 
>    Service use-case (Section 3.3.1).  The difference is that one of the
> 
>    users is behind a NAT*/FW* that blocks UDP traffic.
> 
> .
> 
>  
> 
> 3.3.2.2.  Additional Requirements
> 
>  
> 
>    F29     The browser must be able to send streams and
> 
>            data to a peer in the presence of NATs *and FWs* that
> 
>            block UDP traffic ,* when FW policy allows WebRTC traffic*.
> 
> -------------------------------------------------------
> 
>    Proposal 2: If the" Http allowing FW without http proxy deployed"
> case is impliedly included in F29. I suggest to change the topics of
> 3.3.3 to "Simple Video Communication Service, FW that only allows
> traffic via a http proxy". So the 3.3.3 is a specific case.
> 
>  
> 
>     Proposal 3: If " Http allowing FW without http proxy deployed" case
> need to be explicitly mentioned. I suggest to add some descriptions to 3.3.3
> 
> -----------------------------------------------------------------
> 
> 3.3.3.  Simple Video Communication Service, FW that only allows http
> 
>  
> 
> 3.3.3.1.  Description
> 
>  
> 
>    This use-case is almost identical to the Simple Video Communication
> 
>    Service use-case (Section 3.3.1).  The difference is that one of the
> 
>    users is behind a http allowing FW or a FW that only allows traffic
> via a HTTP Proxy.
> 
>  
> 
> 3.3.3.2.  Additional Requirements
> 
>  
> 
>    F37     The browser must be able to send streams and
> 
>            data to a peer in the presence of http allowing FWs or FWs
> that only
> 
>            allows traffic via a HTTP Proxy, when FW policy
> 
>            allows WebRTC traffic.
> 
> -------------------------------------------------------------------
> 
>  
> 
>  
> 
> Best Regards,
> 
>      Xin
> 
>  
> 


-- 

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------