Re: [tram] Adam Roach's Discuss on draft-ietf-tram-stun-pmtud-10: (with DISCUSS and COMMENT)

Spencer Dawkins at IETF <> Thu, 13 December 2018 14:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 25DBB124C04; Thu, 13 Dec 2018 06:27:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yXADxSXkP72Y; Thu, 13 Dec 2018 06:27:39 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 32729124BF6; Thu, 13 Dec 2018 06:27:39 -0800 (PST)
Received: by with SMTP id e5-v6so1946129lja.4; Thu, 13 Dec 2018 06:27:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KBpiXALt3KyTNFyXuVGGr9urCxDFyrvE/aqpQhl6ZWE=; b=bGXMyRXX4+IxFTJpMxw948/qFcCxDOuKBOjmQd+x0dmTdSXTMqvWgETu6PDcT5Qp7P jMG3rlQ3f7fUME21xlf55KEVmWjWFmBk207NCs+r7UhgxuX2IKchMfjQcqfk8LQ1AfsI CK1KEfQ90aVOmtVsKEks0rqQs4CyGmhpxygqBVAphyRjKnYR7T0J/C0wInHzHJgOuQT/ 6HbYz8KOTmM0rooD6WBobY20aC/+foZJ9yMKUYVMXWQTKn9rS+zwplQk6aXcZogr/9x5 xP7kPomw+TuD5NbxatPmeDnvX6+owXTmKSsWzY1Cz36w/eopXDwKGgNGhIkneKOvnlTV cU2w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KBpiXALt3KyTNFyXuVGGr9urCxDFyrvE/aqpQhl6ZWE=; b=ii16xaU03sGY8MQmzjuV9lhlbxTS8ouhn9+SRQNR5C//UnNNJ+Qq1xX9huGWFV+Mzk /8EmfGj/WTD9qFI2OleuNKz/ugyqmUerpkDuedfiEINprLKN3hlq4j96sf0opz4wgb6m U79owx9zxcZPD3JgqKu46S7apcD7vGM9qrKq6t5rAMHl6KGVOdcLeBmxncu0Krdw8gts YvO1mXUs5MPqusflPIFkX6Rrc23MTr/g6ypmvy3GoN9P4o4xQLzBWJ2LzJD0FFVe3A// Ei6EvCJDUE5LerVdzjBTaipKCMGFquV9k+F760PgAq+bBasY94zFQZjX2KL/nlfn8qMZ ClxA==
X-Gm-Message-State: AA+aEWbMg3OjJoUJtuIBbXrL6CuEPpWq3R+aBi4leCwdwc3eXrIRRgh0 eQyUNSkon6ZJEwXxrCW2CImpx7M/EotfIQxhse4=
X-Google-Smtp-Source: AFSGD/Wv6XwfJXzyUvK0IED8sy9D6r1XIZ+B6HWSLxd3oCXS9wMjKR8BFjvyT1azu9wB0ILnZSoXgjkSmB/bxeSJWSo=
X-Received: by 2002:a2e:914b:: with SMTP id q11-v6mr14598928ljg.164.1544711257255; Thu, 13 Dec 2018 06:27:37 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Spencer Dawkins at IETF <>
Date: Thu, 13 Dec 2018 08:27:26 -0600
Message-ID: <>
To: Simon Perreault <>
Cc: Adam Roach <>, IESG <>, "" <>, "" <>, Gonzalo Camarillo <>, "Asveren, Tolga" <>, "" <>
Content-Type: multipart/alternative; boundary="000000000000c4f1f1057ce81ddb"
Archived-At: <>
Subject: Re: [tram] Adam Roach's Discuss on draft-ietf-tram-stun-pmtud-10: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 13 Dec 2018 14:27:42 -0000

Hi, Simon,

On Thu, Dec 13, 2018 at 7:12 AM Simon Perreault <>

> - Pull the definition of PADDING into this document. Declare that we've
> gathered sufficient experience with PADDING that it now warrants being
> elevated to Standards Track. That is, it's been proven to work.
> This is plausible. It solves the first-order problem.
> I note that RFC 5780 defined a number of new attributes. Is pulling
> PADDING forward the right thing to do, or are there others that would also
> qualify (so, perhaps a status change for RFC 5780)?
> I don’t think the others have been implemented much, so that’s why I think
> only pulling PADDING makes sense. If I remember correctly, I only
> implemented PADDING in Numb (I don’t have access to the source code anymore
> so can’t be sure).
> Anyone else with an opinion?

That's helpful information.

We should wait for anyone else with information to weigh in, but if it's
correct that the other experimental attributes haven't been implemented and
deployed in a way that would provide guidance for standards-track use, I
think defining PADDING in this document makes more sense to me than adding
a downref to an experimental RFC that we wouldn't consider if the reference
was using anything except PADDING.



> Simon