IETF Logo Mail Archive

Re: [tram] Genart telechat review of draft-ietf-tram-stunbis-16

Marc Petit-Huguenin <petithug@acm.org> Mon, 14 May 2018 20:23 UTC

Return-Path: <petithug@acm.org>
X-Original-To: tram@ietfa.amsl.com
Delivered-To: tram@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 342C7124319; Mon, 14 May 2018 13:23:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.442
X-Spam-Level:
X-Spam-Status: No, score=-0.442 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ASZhzWJ3s0Tx; Mon, 14 May 2018 13:23:27 -0700 (PDT)
Received: from implementers.org (unknown [IPv6:2001:4b98:dc0:45:216:3eff:fe7f:7abd]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 835D31277BB; Mon, 14 May 2018 13:23:27 -0700 (PDT)
Received: from [IPv6:2601:648:8300:e8a:d578:c438:f732:cb38] (unknown [IPv6:2601:648:8300:e8a:d578:c438:f732:cb38]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 57AC9AE8D8; Mon, 14 May 2018 22:23:25 +0200 (CEST)
To: "Dale R. Worley" <worley@ariadne.com>
Cc: gen-art@ietf.org, draft-ietf-tram-stunbis.all@ietf.org, ietf@ietf.org, tram@ietf.org
References: <87d0yc434c.fsf@hobgoblin.ariadne.com>
From: Marc Petit-Huguenin <petithug@acm.org>
Message-ID: <387eea8b-6f77-c94e-d67e-180ef17cd0f0@acm.org>
Date: Mon, 14 May 2018 13:23:22 -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: <87d0yc434c.fsf@hobgoblin.ariadne.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="mZpx5RTOsvVcpHlTMom89lNGd724M9hye"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/-CB8RX-NOK5QP4n4bHcf-1ROKwY>
Subject: Re: [tram] Genart telechat review of draft-ietf-tram-stunbis-16
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." <tram.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tram>, <mailto:tram-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tram/>
List-Post: <mailto:tram@ietf.org>
List-Help: <mailto:tram-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tram>, <mailto:tram-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 May 2018 20:23:29 -0000

Thank you.  See inline.

On 05/03/2018 06:32 PM, Dale R. Worley wrote:
> Marc Petit-Huguenin <marc@petit-huguenin.org> writes:
>> Because we believe that this is a problem that will become more and
>> more frequent, we decided to fix it, at least for new implementations.
>>
>> Please have a look at -17 and let us know what you think of it.
> 
> It looks like you've handled the problem of a NAT that changes the
> address family of the request as well as can be done.
> 
> You've clarified the question of how the security feature bits are
> assigned, although I note that -16 and -17 assign the bits differently
> than versions -7 through -15 do.
> 
> That completes all of the significant issues from my review of -16.
> 
> And there are some nits:
> 
> 6.2.1.  Sending over UDP or DTLS-over-UDP
> 
>    SHOULD be greater or equal than 500 ms.
> 
> s/equal than/equal to/.

Applied.

> 
> 6.2.3.  Sending over TLS-over-TCP or DTLS-over-UDP
> 
>    To do that, it follows the
>    identification procedures defined in [RFC6125], with a certificate
>    containing an identifier of type DNS-ID or CN-ID, eventually with
>    wildcards, but not of type SRV-ID or URI-ID.
> 
> The meaning of "eventually" here is not clear.

Rephrased as:

   [...]
   containing an identifier of type DNS-ID or CN-ID, eventually with a
   wildcard character as leftmost label, but not of type SRV-ID or URI-
   [...]

> 
> 14.  STUN Attributes
> 
>    The
>    padding bits MUST be set to zero on sending and must be ignored by
>    the receiver.
> 
> I assume the latter "must" is supposed to be "MUST".

Fixed.

> 
> 14.13.  UNKNOWN-ATTRIBUTES
> 
>    Note:  In [RFC3489], this field was padded to 32 by duplicating the
>       last attribute.  In this version of the specification, thPetriNet
>       m --> PetriNet m --> e normal padding rules for attributes are
>       used instead.
> 
> I assume that "thPetriNet m --> PetriNet m --> e" is intended to be
> "the".

Fixed.

> 
> Appendix C.  Release notes
> 
> Section C.8 has the same contents as section C.9, but section C.9 has
> the same title as section C.10.  (Although section C will be removed
> before publication, so it's not important.)

Fixed.

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

v2.23.0 | Report a Bug | By Email