Subject: [rtcweb] Barry Leiba's No Objection on draft-ietf-rtcweb-stun-consent-freshness-15: (with COMMENT)

From: "Barry Leiba" <[email-masked]>
Date: Tue, 28 Jul 2015 05:35:12 -0700

Barry Leiba has entered the following ballot position for
draft-ietf-rtcweb-stun-consent-freshness-15: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshness/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

A couple of very minor comments only:

FWIW, I think rtcweb-security-arch need only be an informative reference;
it seems only explanatory.  I also think that about RFC 6263.

-- Section 5.1 --

   A full ICE implementation obtains consent to send using ICE.  After
   ICE concludes on a particular candidate pair and whenever the
   endpoint sends application data on that pair consent MUST be
   maintained following the procedure described in this document.

I don't understand the "MUST" here, given that Section 4 says this is "an
optional extension".  Why "MUST", then, rather than "can be"?

---

From: Martin Thomson <[email-masked]>
Date: Tue, 28 Jul 2015 15:04:13 +0200

> optional extension".  Why "MUST", then, rather than "can be"?

The extension might be optional, but we need to be clear about what is
mandatory and not within the mechanism itself.

Note that this *won't* be optional for WebRTC implementations
(browsers, certainly, maybe other classes of implementation too).

---

From: Barry Leiba <[email-masked]>
Date: Tue, 28 Jul 2015 15:07:40 +0200

> mandatory and not within the mechanism itself.

That's why I think the *other* MUSTs and SHOULDs are fine.  But *this*
one says "MUST use the procedure in this document", which doesn't seem
right.  (But, as I said, a minor comment.)

> (browsers, certainly, maybe other classes of implementation too).

Sure, but then those should say "MUST use <this>".

Barry

---

From: Martin Thomson <[email-masked]>
Date: Tue, 28 Jul 2015 15:22:00 +0200

I don't think that we lose anything by changing the "MUST be" to "is":

>    endpoint sends application data on that pair consent is

Axiomatic wins against prescriptive generally for me.