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

Marc Petit-Huguenin <marc@petit-huguenin.org> Sun, 22 April 2018 21:31 UTC

To: Ben Campbell <ben@nostrum.com>, The IESG <iesg@ietf.org>
Cc: draft-ietf-tram-stunbis@ietf.org, Gonzalo.Camarillo@ericsson.com, Tolga Asveren <tasveren@rbbn.com>, tram-chairs@ietf.org, tram@ietf.org
References: <152393106321.26096.12146305230255636553.idtracker@ietfa.amsl.com>
From: Marc Petit-Huguenin <marc@petit-huguenin.org>
Message-ID: <4689aba3-e1a4-b519-079c-2361c422724e@petit-huguenin.org>
Date: Sun, 22 Apr 2018 14:31:46 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <152393106321.26096.12146305230255636553.idtracker@ietfa.amsl.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="ZZqgCpWscOqcmkgxNWBYs253DZbnbC3uR"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/v85RxTEg3jQMKYpq4zF5o461B5o>
Subject: Re: [tram] Ben Campbell's No Objection on draft-ietf-tram-stunbis-16: (with COMMENT)
Precedence: list

Hi Ben,

Thanks for the review, please see my responses inline.

On 04/16/2018 07:11 PM, Ben Campbell wrote:
> Ben Campbell has entered the following ballot position for
> draft-ietf-tram-stunbis-16: No Objection
> 

[...]

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

I think I addressed all of Peter's comments.

> 
> §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.

Already fixed following a previous review.

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

Already fixed following a previous review.

> 
> §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.

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.

> 
> §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?

Applied.

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

Already fixed following a previous review.

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

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: marc@petit-huguenin.org
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug

Attachment: signature.asc

[tram] Ben Campbell's No Objection on draft-ietf-… Ben Campbell
Re: [tram] Ben Campbell's No Objection on draft-i… Marc Petit-Huguenin

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

Attachment: signature.asc