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

From: [email-masked]
Date: Tue, 17 Jun 2014 20:17:26 -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-04.txt
	Pages           : 9
	Date            : 2014-06-17

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-04

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

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: Wed, 18 Jun 2014 03:33:37 +0000

The new revision has:

1) Comments from Christer and Charles incorporated.
2) Incorporated the feedback received in the interim meeting in Section 4
on re-transmissions, revocation of consent
3) Removed the Appendix that had a example as it was no different from
what is mentioned in solution.
4) Updates to section 6 (DiffServ Treatment) based on discussions in the
mailing list.

Please review and provide your feedback.

Regards,
Ram

-----Original Message-----
From: "[email-masked]" <[email-masked]>
Date: Wednesday, 18 June 2014 8:47 am
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: [rtcweb] I-D Action:
draft-ietf-rtcweb-stun-consent-freshness-04.txt

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

---

From: Michael Procter <[email-masked]>
Date: Fri, 27 Jun 2014 11:06:06 +0100

Hi Ram,

I have a couple of comments about the word "inverted".  In section
4.1, the draft says:

   receiving a
   matching, authenticated, non-error ICE binding response from the
   inverted remote peer's Transport Address.

I think this means receiving it from the remote peer's Transport
Address, although the presence of 'inverted' made me wonder.  If the
word is unnecessary, please remove it.  If it is needed, please add
more explanation as to what it means.

Further on, the draft says:

   That is, if a valid STUN binding response [...]
   has not been received from the inverted 5-tuple, [...]

I think this means receiving it from the 5-tuple, but again, the
presence of 'inverted' made me wonder.  Is this a naming issue?  I am
happy to send and receive on the same 5-tuple, and I expect my peer to
do the same.  However, my peer's 5-tuple will be inverted with respect
to mine!

Regards,

Michael

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Sat, 28 Jun 2014 16:52:42 +0000

Hi Michael,

Thanks for your review.

We used inverted to convey that Consent response (STUN binding response)
from remote peer must be  from inverted 5-tuple (source and dest addr
swapped) of the request sent.
I will see how to re-word it.

Regards,
Ram

-----Original Message-----
From: Michael Procter <[email-masked]>
Date: Friday, 27 June 2014 3:36 pm
To: Ram Mohan Ravindranath <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [rtcweb] I-D Action:

>>> This draft is a work item of the Real-Time Communication in
>>>WEB-browsers
>>>Working Group of the IETF.
>>>
>>>http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-stun-consent-freshnes
>>>s-
>>>04
>>>
>>>

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 29 Jun 2014 10:26:11 +0200

> I will see how to re-word it.

I think it will be fine if you just put in a definition for the term.
BTW, I'd like it to be an "inverse" 5-tuple, not an "inverted" one.

---

From: Michael Procter <[email-masked]>
Date: Sun, 29 Jun 2014 13:36:44 +0100

> BTW, I'd like it to be an "inverse" 5-tuple, not an "inverted" one.

Adding a definition would be fine for me.  And "inverse" is better,
too.  I had spent some time peering at stun xor-mapped-addresses
before reading this draft, so I might have been overly sensitive to
the word 'inverted'!

Michael