Subject: [rtcweb] Comments on draft-ietf-rtcweb-stun-consent-freshness-06

From: Rajmohan Banavi <[email-masked]>
Date: Sat, 13 Sep 2014 17:17:35 +0530

Comments on draft-ietf-rtcweb-stun-consent-freshness-06

   1. Sec 4.1 mentions that the stun binding request should regenerate a
   new cryptographically random [RFC4086] STUN transaction ID. Since consent
   is another STUN usage, the mechanism on how the transaction id is generated
   for every new transaction is specified in the STUN RFC 5389. So is it
   necessary to specify here? Further, STUN RFC does not reference [RFC4086].
   2. Sec 4.1 mentions that "During ICE restart consent MUST continue to be
   sent on previously validated pair". It is possible that there might be
   multiple valid pairs especially in case of aggressive nomination. It make
   sense to make use of "nominated pair" instead of "validated pair".
   3. Trivial one - It is often mentioned that consent must be performed by
   WebRTC implementations. Is there any limiting it to WebRTC?
   4. Sec 2 - It is mentioned that consent and consent freshness are sent
   to "certain" transport address. It should be peer transport address. In
   other sections within the doc, it is properly mentioned as "peer" transport
   address.

Cheers,
Rajmohan

---

From: Muthu Arul Mozhi Perumal <[email-masked]>
Date: Mon, 15 Sep 2014 10:37:29 +0530

Thanks for the comments. Please see inline..

On Sat, Sep 13, 2014 at 5:17 PM, Rajmohan Banavi <[email-masked]>
wrote:

> ​I see no harm. Also, I think RFC5389 missed to reference RFC4086 ​on the
cryptographic randomness of the transaction ID (should probably go into
ICE-bis), as can be seen from all references to RFC4086:
http://datatracker.ietf.org/doc/rfc4086/referencedby/?full=True

>
>    1. Sec 4.1 mentions that "During ICE restart consent MUST continue to
>    be sent on previously validated pair". It is possible that there might be
> ​Agree.​

>
>    1. Trivial one - It is often mentioned that consent must be performed
>    by WebRTC implementations. Is there any limiting it to WebRTC?
>
> ​This was discussed earlier and we are addressing it in the next revision.​

>
>    1. Sec 2 - It is mentioned that consent and consent freshness are sent
> ​This the terminology section and I see no harm in the terminology being
slightly generic..

Muthu​

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