Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13
"Black, David" <david.black@emc.com> Fri, 29 May 2015 18:12 UTC
Return-Path: <david.black@emc.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47DFE1B2B50; Fri, 29 May 2015 11:12:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.31
X-Spam-Level:
X-Spam-Status: No, score=-4.31 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 4kQIQ1MGm_nA; Fri, 29 May 2015 11:11:59 -0700 (PDT)
Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 712C31B2B44; Fri, 29 May 2015 11:11:59 -0700 (PDT)
Received: from maildlpprd51.lss.emc.com (maildlpprd51.lss.emc.com [10.106.48.155]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t4TIBkDF031285 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 29 May 2015 14:11:49 -0400
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com t4TIBkDF031285
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1432923110; bh=aQD6Ce30m6R/qs2+4eGSQG3TYVw=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=gnlR60pk4xff5jSgnJAMPkcD05F5+FyvXc1W9xWHJpqv06+0fo4orVzqjub4vpqtw yjBWW1P5O0g0GRWnEuA2nKD+GEtFyir04fVdDCDPiFLaM1P2Joe9uMgInNUi5hQGox RY5DnhN2wXru0dvNQFTr6qrwCA7l2jIMOLpzwsdQ=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com t4TIBkDF031285
Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd51.lss.emc.com (RSA Interceptor); Fri, 29 May 2015 14:10:56 -0400
Received: from mxhub01.corp.emc.com (mxhub01.corp.emc.com [10.254.141.103]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t4TIBTNB014798 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 29 May 2015 14:11:29 -0400
Received: from MXHUB203.corp.emc.com (10.253.68.29) by mxhub01.corp.emc.com (10.254.141.103) with Microsoft SMTP Server (TLS) id 8.3.327.1; Fri, 29 May 2015 14:11:28 -0400
Received: from MX104CL02.corp.emc.com ([169.254.8.77]) by MXHUB203.corp.emc.com ([10.253.68.29]) with mapi id 14.03.0224.002; Fri, 29 May 2015 14:11:29 -0400
From: "Black, David" <david.black@emc.com>
To: "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com>, Christer Holmberg <christer.holmberg@ericsson.com>, Ted Hardie <ted.ietf@gmail.com>
Thread-Topic: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13
Thread-Index: AQHQmbLQj9rK05idUkWAIovS2YdbXZ2Sd9wAgAAUeACAALWgYA==
Date: Fri, 29 May 2015 18:11:28 +0000
Message-ID: <CE03DB3D7B45C245BCA0D243277949364CB73D@MX104CL02.corp.emc.com>
References: <CE03DB3D7B45C245BCA0D243277949364C76E4@MX104CL02.corp.emc.com> <CE03DB3D7B45C245BCA0D243277949364C9187@MX104CL02.corp.emc.com> <CABkgnnXr4iCgwzKSTGhJUW3-99XXPjVjh1iyOX0H96C2vV_hWA@mail.gmail.com> <CE03DB3D7B45C245BCA0D243277949364CAE88@MX104CL02.corp.emc.com> <CA+9kkMC6MMTFFObbF51-iUaRA8CUdvK5xk6SC8UasCQAHa51YQ@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1D86E037@ESESSMB209.ericsson.se> <913383AAA69FF945B8F946018B75898A47861342@xmb-rcd-x10.cisco.com> <7594FB04B1934943A5C02806D1A2204B1D86E2ED@ESESSMB209.ericsson.se> <913383AAA69FF945B8F946018B75898A47861447@xmb-rcd-x10.cisco.com>
In-Reply-To: <913383AAA69FF945B8F946018B75898A47861447@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.13.35.216]
Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D243277949364CB73DMX104CL02corpemcc_"
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com
X-RSA-Classifications: public
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/OjUoGYwGQNfYua6RPDA2x-35pG8>
Cc: joel jaeggli <joelja@bogus.com>, "ops-dir@ietf.org" <ops-dir@ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>, "rtcweb-chairs@tools.ietf.org" <rtcweb-chairs@tools.ietf.org>
Subject: Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 May 2015 18:12:05 -0000
That also works for me, and neatly sidesteps the concern about whether RFC 5245 is being updated. Thanks, --David From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] Sent: Thursday, May 28, 2015 11:20 PM To: Christer Holmberg; Ted Hardie; Black, David Cc: joel jaeggli; ops-dir@ietf.org; rtcweb@ietf.org; rtcweb-chairs@tools.ietf.org Subject: RE: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13 From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Friday, May 29, 2015 7:37 AM To: Tirumaleswar Reddy (tireddy); Ted Hardie; Black, David Cc: joel jaeggli; ops-dir@ietf.org<mailto:ops-dir@ietf.org>; rtcweb@ietf.org<mailto:rtcweb@ietf.org>; rtcweb-chairs@tools.ietf.org<mailto:rtcweb-chairs@tools.ietf.org> Subject: RE: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13 Hi, >Good point. We discuss the following point in section 4.1 of the draft about keepalives: > > An endpoint that is not sending any application data does not need to > maintain consent. However, not sending any traffic could cause NAT > or firewall mappings to expire. Furthermore, having one peer unable > to send is detrimental to many protocols. Absent better information > about the network, if an endpoint needs to ensure its NAT or firewall > mappings do not expire, it can be done using keepalive or other > techniques (see Section 10 of [RFC5245]<http://tools.ietf.org/html/rfc5245#section-10> and see [RFC6263<http://tools.ietf.org/html/rfc6263>] > > So there is no need to send keepalives because of the media traffic as it is pointed out in Section 20.2.3 of RFC 5245 > irrespective of whether consent is used or not. I think we can remove the following line in “If consent is performed then > there is no need to send keepalive messages." and avoid the confusion of updating RFC 5245. I agree that the current text can confuse people, but I still think it would be good to have explicit text saying that keepalives are not sent. Perhaps something like: “From a keepalive perspective, consent requests are considered media traffic. Because of that, dedicated keepalives (e.g. STUN binding requests) are not sent on candidate pairs where consent requests are sent, in accordance with Section 20.2.3 of [RFC5245].” Works for me (Replaced STUN binding requests with STUN Binding Indications in the above line). Cheers, -Tiru Regards, Christer From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: Friday, May 29, 2015 6:54 AM To: Ted Hardie; Black, David Cc: joel jaeggli; ops-dir@ietf.org<mailto:ops-dir@ietf.org>; rtcweb@ietf.org<mailto:rtcweb@ietf.org>; rtcweb-chairs@tools.ietf.org<mailto:rtcweb-chairs@tools.ietf.org> Subject: Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13 Hi, Section 20.2.3 of RFC 5245 says: “STUN keepalives (in the form of STUN Binding Indications) are sent in the middle of a media session. However, they are sent only in the absence of actual media traffic.” So, in the consent draft we could say that, from a keepalive perspective, consent requests are considered media traffic. That would then implicitly mean that actual keepalives aren’t sent when consent is used. That way, the consent spec would be compliant to 5245, and there would be no need for any update etc… Regards, Christer From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ted Hardie Sent: 28 May 2015 23:26 To: Black, David Cc: rtcweb-chairs@tools.ietf.org<mailto:rtcweb-chairs@tools.ietf.org>; joel jaeggli; ops-dir@ietf.org<mailto:ops-dir@ietf.org>; rtcweb@ietf.org<mailto:rtcweb@ietf.org> Subject: Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13 Hi David, On Thu, May 28, 2015 at 12:36 PM, Black, David <david.black@emc.com<mailto:david.black@emc.com>> I'd expect that even overriding RFC 5245 counts as an Update, because the result would be that the original RFC 5245 "MUST" requirement is no longer globally applicable to all uses of RFC 5245. In other words, overriding RFC 5245 effectively rewrites the "MUST" to become "MUST, except as further specified by the consent RFC." So I agree with you that this must be called out, but I think "Updates" is wrong for the draft's current intent. I think what Martin has said amounts to "We have chosen to follow RFC 5245 except as detailed in sections X and Y, where we use a different set of messages to optimize the combination of heartbeat and consent." We are not updating RFC 5245 thereby, because we are neither changing its core semantics nor offering to add a new, general semantic to RFC 5245 (we could have made that choice, but are not doing so now). Instead of updating RFC 5245, in other words, we are limiting our reference to it. That should be done explicitly, and I think it should be called it suffiiciently that a new spin of the draft likely needs a new round of review. But I don't think we are required to update RFC 5245 to get that done. I've referred the matter to our friendly AD, and we await her reading on next steps on this. In either approach, however, this will get called out. regards, Ted HArdie
- [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun… Black, David
- Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-… joel jaeggli
- Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-… Ram Mohan R (rmohanr)
- Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-… Black, David
- Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-… Black, David
- Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-… Tirumaleswar Reddy (tireddy)
- Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-… Tirumaleswar Reddy (tireddy)
- Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-… Harald Alvestrand
- Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-… Harald Alvestrand
- Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-… Tirumaleswar Reddy (tireddy)
- Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-… Tirumaleswar Reddy (tireddy)
- Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-… Martin Thomson
- Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-… Tirumaleswar Reddy (tireddy)
- Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-… Black, David
- Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-… Ted Hardie
- Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-… Christer Holmberg
- Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-… Tirumaleswar Reddy (tireddy)
- Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-… Christer Holmberg
- Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-… Ram Mohan R (rmohanr)
- Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-… Tirumaleswar Reddy (tireddy)
- Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-… Ram Mohan R (rmohanr)
- Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-… Black, David
- Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-… Black, David
- Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-… Harald Alvestrand
- Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-… Bernard Aboba
- Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-… Christer Holmberg
- Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-… Ram Mohan R (rmohanr)
- Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-… Tirumaleswar Reddy (tireddy)
- Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-… Christer Holmberg
- Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-… Tirumaleswar Reddy (tireddy)
- Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-… Muthu Arul Mozhi Perumal
- Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-… Tirumaleswar Reddy (tireddy)
- Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-… Black, David