Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-03.txt

From: [email-masked]
Date: Mon, 19 May 2014 01:38:42 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF.

        Title           : STUN Usage for Consent Freshness
        Authors         : Muthu Arul Mozhi Perumal
                          Dan Wing
                          Ram Mohan Ravindranath
                          Tirumaleswar Reddy
                          Martin Thomson
	Filename        : draft-ietf-rtcweb-stun-consent-freshness-03.txt
	Pages           : 9
	Date            : 2014-05-19

Abstract:
   To prevent sending excessive traffic to an endpoint, periodic consent
   needs to be obtained from that remote endpoint.

   This document describes a consent mechanism using a new STUN usage.
   This same mechanism can also determine connection loss ("liveness")
   with a remote peer.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshness/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-stun-consent-freshness-03

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Mon, 19 May 2014 13:24:27 +0000

The revision has text on

1) Explaining how consent expires and is revoked (sections 4.1 and 4.2).
2) Added an example (non normative) implementation procedure.

Comments are welcome
-Authors

-----Original Message-----
From: "[email-masked]" <[email-masked]>
Date: Monday, 19 May 2014 2:08 pm
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: [rtcweb] I-D Action:
draft-ietf-rtcweb-stun-consent-freshness-03.txt

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

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 20 May 2014 18:33:44 +0000

The updated draft looks good. I have some minor comments and a suggestion
for the question/note in section 6.

Section 1 reads as follows,
"This document describes a new STUN usage with a request and response
   messages which verifies the remote peer's consent to receive traffic,
   and can also detect loss of liveness.²

Suggested text corrects typos and reflects that the request/response
verify liveness. Loss of liveless is detected as by other means, such as
the expiration of a timer while waiting to receive a expected message.

"This document describes a new STUN usage with exchange of request and
response messages to verify the remote peer's consent to receive traffic,
and the absence of which for a period of time indicates a loss of
liveness.²

Several places state "consent to send traffic². I think this is confusing.
The consent is to receive traffic. Consent is provided by the receiver,
and this consent is verified by the sender. For example, section 4.1 reads
as follows, "Explicit consent to send is indicated by². This should read
"Explicit consent to receive is indicated by², or "Explicit permission to
send is obtained by². I prefer the former. If you agree, this should be
changed in several places.

Section 5
s/applications MUST NOT be able to send heartbeats faster than 1 per
second/applications MUST
   NOT send heartbeats at an average rate of more than 1 per second

Section 6
s/ICE connectivity check described/ICE connectivity checks described

As for the DSCP to use when media on transport addresses use multiple
DSCPs, I assume this because the media streams having different
priorities. That being the case, using the same DSCP for the STUN messages
as that used for the highest priority media stream(s) seems appropriate.

Cheers,
Charles

On 5/19/14, 6:24 AM, "Ram Mohan R (rmohanr)" <[email-masked]> wrote:

>>http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-stun-consent-freshness
>>-
>>03
>>
>>

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 20 May 2014 18:43:50 +0000

>as that used for the highest priority media stream(s) seems appropriate.

I should have also stated that this would apply only for cases in which
such use of multiple DSCPs was appropriate, as determined by DART.

Cheers,
Charles

>>> This draft is a work item of the Real-Time Communication in
>>>WEB-browsers
>>>Working Group of the IETF.
>>>
>>>https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshnes
>>>s
>>>/
>>>