Subject: [tram] Ben Campbell's No Objection on draft-ietf-tram-stunbis-16: (with COMMENT)

From: Ben Campbell <[email-masked]>
Date: Mon, 16 Apr 2018 19:11:03 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-tram-stunbis-16: 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-tram-stunbis/

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

Hi, thanks for this work. For the record, I have mainly reviewed the diff.

General: I think Peter's ART-ART review has some points worth addressing.

§1, last paragraph: This seems out of place. Also, I wonder if it should be
stated more strongly, perhaps with a SHOULD or even MUST.

§3: RFC 8174 offers it's own recommended boilerplate; is there a reason not to
use it?

§6.2.1, third paragraph: " The value SHOULD be considered stale and discarded
after
   10 minutes without any transactions to the same server. "
This is a bit ambiguous. I think it means the value is stale if no transactions
have occurred in the last 10 minutes, But I think it could be read to say that
there should be no transactions to the same server once one considers the value
as stale.

§9.1.4: Does it make sense to signal that "an attack took place" rather than
signaling "integrity protection was violated" and let the human operators
decide if that implies an attack?

§14.3: "A compliant implementation MUST
   be able to parse UTF-8 encoded sequence of less than 763."

763 whats?

§15.3, 2nd bullet: I'm not sure I understand what is meant by "get an updated
external mechanism"

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sun, 22 Apr 2018 14:31:46 -0700

Hi Ben,

Thanks for the review, please see my responses inline.

> draft-ietf-tram-stunbis-16: No Objection

[...]

I think I addressed all of Peter's comments.

> stated more strongly, perhaps with a SHOULD or even MUST.

Already fixed following a previous review.

> §3: RFC 8174 offers it's own recommended boilerplate; is there a reason not to

Already fixed following a previous review.

> there should be no transactions to the same server once one considers the value

The new text reads:

   The value SHOULD be considered stale and discarded if no
   transactions have occurred to the same server in the last 10 minutes.

> decide if that implies an attack?

Applied.

>    be able to parse UTF-8 encoded sequence of less than 763."

Already fixed following a previous review.

> §15.3, 2nd bullet: I'm not sure I understand what is meant by "get an updated

New text:

   o  STUN Client and Server using the Short Term Credential Mechanism
      will need to update the external mechanism that they use to signal
      what message-integrity attributes are in use.

-- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug