Re: [BEHAVE] Review of draft-ietf-behave-stun-test-vectors-03

" Rémi Denis-Courmont" <remi.denis-courmont@nokia.com> Thu, 06 November 2008 14:47 UTC

Return-Path: <behave-bounces@ietf.org>
X-Original-To: behave-archive@optimus.ietf.org
Delivered-To: ietfarch-behave-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F15A3A6A53; Thu, 6 Nov 2008 06:47:47 -0800 (PST)
X-Original-To: behave@core3.amsl.com
Delivered-To: behave@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E355B3A6A53 for <behave@core3.amsl.com>; Thu, 6 Nov 2008 06:47:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level:
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MAJhzf6Z9SBJ for <behave@core3.amsl.com>; Thu, 6 Nov 2008 06:47:46 -0800 (PST)
Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id CA3AC3A69DB for <behave@ietf.org>; Thu, 6 Nov 2008 06:47:45 -0800 (PST)
Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id mA6ElGEZ018896; Thu, 6 Nov 2008 16:47:21 +0200
Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Nov 2008 16:46:56 +0200
Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Nov 2008 16:46:56 +0200
Received: from esdhcp041160.research.nokia.com ([172.21.41.160]) by vaebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Nov 2008 16:46:55 +0200
From: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
Organization: Maemo Software - Nokia Devices R&D
To: ext Christian Vogt <christian.vogt@ericsson.com>
Date: Thu, 06 Nov 2008 16:46:55 +0200
User-Agent: KMail/1.9.10
References: <1D477AEC-F24A-4C34-A9C7-F4BE37EB522E@ericsson.com>
In-Reply-To: <1D477AEC-F24A-4C34-A9C7-F4BE37EB522E@ericsson.com>
MIME-Version: 1.0
Content-Disposition: inline
Message-Id: <200811061646.55550.remi.denis-courmont@nokia.com>
X-OriginalArrivalTime: 06 Nov 2008 14:46:55.0755 (UTC) FILETIME=[83950DB0:01C9401E]
X-Nokia-AV: Clean
Cc: Behave Mailing List <behave@ietf.org>
Subject: Re: [BEHAVE] Review of draft-ietf-behave-stun-test-vectors-03
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: behave-bounces@ietf.org
Errors-To: behave-bounces@ietf.org

On Thursday 06 November 2008 16:41:26 ext Christian Vogt, you wrote:
> Remi,
>
> I was asked to do a review of draft-ietf-behave-stun-test-vectors-03 for
> IESG evaluation, and I found the document to be ready for publication:
>
> This document provides samples of STUN messages that have been found to
> cause interoperability problems across implementations.  The goal is to
> help making implementations standard-conform and interoperable.
> Overall, the document is certainly ready for publication.  Just a minor
> editorial improvement suggestion below.
>
> In section 2, the document states:
>
>      In this document, ASCII white spaces (U+0020) are used for padding
>      within the first three messages - this is arbitrary.  Similarly,
>      the last message uses nul bytes for padding. [...]
>
> For the sake of clarity, there should be a statement about the possible
> values that a padding byte may take.

RFC3489bis section 15 already states:

 Since
   STUN aligns attributes on 32 bit boundaries, attributes whose content
   is not a multiple of 4 bytes are padded with 1, 2 or 3 bytes of
   padding so that its value contains a multiple of 4 bytes.  The
   padding bits are ignored, and may be any value.

-- 
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D
_______________________________________________
Behave mailing list
Behave@ietf.org
https://www.ietf.org/mailman/listinfo/behave