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> Mon, 14 January 2019 14:25 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 A724412D4EC; Mon, 14 Jan 2019 06:25:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=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 BJ3bZQmB3OHf; Mon, 14 Jan 2019 06:25:39 -0800 (PST)
Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (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 CFFA112D4ED; Mon, 14 Jan 2019 06:25:38 -0800 (PST)
Received: by mail-lf1-x131.google.com with SMTP id y14so15692021lfg.13; Mon, 14 Jan 2019 06:25:38 -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=OedMRq29x6fRfaq9U+vEGdXxSXHmv5rZiQUD3HKf6yo=; b=t+vySoqtyrRV9FB4l+Tmk/wUvEm2ucikN/Kb9fiW3PKR+ZBs+KxJRvehl9WQuYUbUt IqA7odBjNuLnCjdBtJj1rIseK8ZhdL1VMfbRrsK+/dRiCqIBbpiwTzdN1JESgAGckiuN vWWvGGehArimla5OVEC9ag/1BeV6CplgC1JhmHU9a2qBVMzswacCRrQnMZTJnTAFk1Ud XlVNd0zmeucW+X/CUcPj12/s/pan+hob055s8SJRcgFRYkUTE/U8lUgFpWBvrhwjxZu/ sTWYJkzRFN4h6YZCwD99xRt8mxUdPqXI6fPUpoaICcJ25jXrKUjguLT+VcmKD4Mqlkwt Kwhg==
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=OedMRq29x6fRfaq9U+vEGdXxSXHmv5rZiQUD3HKf6yo=; b=EibGcE/oYGgbC2vm8bNZlzxPNbfLSBIct/g7WHUVVoTVew1wuMQeH/y0IJAAmqOEvM qlorKnFh78Nzg9SAm6TfJm3clSnoTOjvjaimpP2QMnrckeKe7RyOQgu5c9oKEcnQ8AlU LBRILN38t7i1q2Mvb5zitC7mW496XzbJx5jVL0fMqVRr+qgoXttCMEPz2Q6yGBvX79WR ctD63A1VGLjX3FrUkDDeZvbzRKNmSgBkXV+/L3GDAAjYftOWUbklLtu0hfaJ8CGWNQDl lSzeke6xcUQ2Xu3tx8Cyzg5h6ZYZ96IqvUObnwtRYp0++suDzbcV0CIVr5QUEP1ibKhX q7Fw==
X-Gm-Message-State: AJcUukdNx8j53mDyhDu4HXOU4mXfx6d3mWlxg4Q2/mPZRbGNgKWEcSs1 3l0ag9V6e6rRqGvfKfXVyFHbbYKorIbWI/v0MmKpRw==
X-Google-Smtp-Source: ALg8bN4LSmhGtgv2gSwkJzTSoFk6wABBRGMAL7MKnRpe4J011RrM//A1s6Z15WPZgk708i0wELh90Nb9hQh6lrODJ1w=
X-Received: by 2002:a19:a302:: with SMTP id m2mr14460867lfe.108.1547475936896; Mon, 14 Jan 2019 06:25:36 -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> <CAKKJt-eXBSJQeKkvNDhhFrpoOkwZvO=GYsZshh6=50htiHKnGw@mail.gmail.com> <VI1PR07MB61277B1650EE2008D81F0F4E83800@VI1PR07MB6127.eurprd07.prod.outlook.com>
In-Reply-To: <VI1PR07MB61277B1650EE2008D81F0F4E83800@VI1PR07MB6127.eurprd07.prod.outlook.com>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Mon, 14 Jan 2019 08:25:25 -0600
Message-ID: <CAKKJt-ewHuocx7nfohdr0+7V2XDmFxTWOVXLffmKAd_QoOpdmA@mail.gmail.com>
To: Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>
Cc: Simon Perreault <Simon.Perreault@logmein.com>, 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>, "Asveren, Tolga" <tasveren@rbbn.com>, "tram@ietf.org" <tram@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000846caa057f6bd180"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/8Qb4CODfzpS4avbjNcytS-DjCeQ>
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: Mon, 14 Jan 2019 14:25:41 -0000

Hi, Gonzalo,

On Mon, Jan 14, 2019 at 8:05 AM Gonzalo Camarillo <
gonzalo.camarillo@ericsson.com> wrote:

> What is the next step here?
>
> Gonzalo
>
> On 13-Dec-18 16:27, Spencer Dawkins at IETF wrote:
> > Hi, Simon,
> >
> > On Thu, Dec 13, 2018 at 7:12 AM Simon Perreault
> > <Simon.Perreault@logmein.com <mailto: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.
>

No one has objected in the past month (which included holidays, but I would
have asked this question with a week or two timeout, if the holidays had
not been coming up).

I think bringing the definition of PADDING into the current draft is the
right thing to do.

If TRAM people thought that the other experimental attributes in RFC 5780
don't have enough implementation experience to justify moving them past
Experimental status, changing the status of RFC 5780 to Historic might be
appropriate at some point, but that's not related to the conversation we're
having now, and I haven't asked a question about that, so I'll ignore that
for now.

Thanks for your help with this.

Spencer


> >
> > Thanks,
> >
> > Spencer
> >
> >     ____
> >
> >     __ __
> >
> >     Simon____
> >
>