IETF Logo Mail Archive

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

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Thu, 13 December 2018 14:27 UTC

Return-Path: <spencerdawkins.ietf@gmail.com>
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 25DBB124C04; Thu, 13 Dec 2018 06:27:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 yXADxSXkP72Y; Thu, 13 Dec 2018 06:27:39 -0800 (PST)
Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32729124BF6; Thu, 13 Dec 2018 06:27:39 -0800 (PST)
Received: by mail-lj1-x230.google.com 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; d=gmail.com; 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; d=1e100.net; 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: <153834237082.13405.1228259718885034461.idtracker@ietfa.amsl.com> <CAKKJt-fouMOJa+eGUwEmQL+Uv5Fqe5KNM_fC0YxmhYojpFNzaA@mail.gmail.com> <CA447D15-2E65-4340-9FF5-4700A53335ED@logmein.com> <CAKKJt-cG=R5ide_qHx5hNKbYwxhDKmwk0tOQutNPYBJp8L7HUA@mail.gmail.com> <MWHPR15MB1200F7BE766A80509FBFBE75FAA00@MWHPR15MB1200.namprd15.prod.outlook.com>
In-Reply-To: <MWHPR15MB1200F7BE766A80509FBFBE75FAA00@MWHPR15MB1200.namprd15.prod.outlook.com>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Thu, 13 Dec 2018 08:27:26 -0600
Message-ID: <CAKKJt-eXBSJQeKkvNDhhFrpoOkwZvO=GYsZshh6=50htiHKnGw@mail.gmail.com>
To: Simon Perreault <Simon.Perreault@logmein.com>
Cc: Adam Roach <adam@nostrum.com>, IESG <iesg@ietf.org>, "tram-chairs@ietf.org" <tram-chairs@ietf.org>, "draft-ietf-tram-stun-pmtud@ietf.org" <draft-ietf-tram-stun-pmtud@ietf.org>, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>, "Asveren, Tolga" <tasveren@rbbn.com>, "tram@ietf.org" <tram@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c4f1f1057ce81ddb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/I1BZomPbYSslPr6q8dpt-3APwIk>
Subject: Re: [tram] Adam Roach's Discuss on draft-ietf-tram-stun-pmtud-10: (with DISCUSS and COMMENT)
X-BeenThere: tram@ietf.org
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." <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: Thu, 13 Dec 2018 14:27:42 -0000

Hi, Simon,

On Thu, Dec 13, 2018 at 7:12 AM Simon Perreault <Simon.Perreault@logmein.com>
wrote:

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

Thanks,

Spencer

>
>
> Simon
>

v2.8.7 | Report a Bug | By Email