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 00:20 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 3CA9B13133C; Wed, 12 Dec 2018 16:20:23 -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 mI-Qf9SCc5-i; Wed, 12 Dec 2018 16:20:20 -0800 (PST)
Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (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 EB99013133D; Wed, 12 Dec 2018 16:20:19 -0800 (PST)
Received: by mail-lj1-x22e.google.com with SMTP id s5-v6so180797ljd.12; Wed, 12 Dec 2018 16:20:19 -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=WNHWGBPQjAg3961PDFmD7Em1Qra7KuabRzkpED9icIE=; b=ZJ1B4nBevFlTkkQ3pBQ1uYkqFNUkSprAymMWq2/ElH8MnQ4FlR9yFfB8Vf29UEY4n7 QLImo2LCWbzvAnGgFEdbLAdRebs0t0cjhxO8lVqKtd9B2vqU4btW5Kk/tgawZNbgjU6I 51qQEa6m3zYSzQ4Ub9KIWq750Hea1sQUY8wjefgPHEPJmfYz3xKrYSvPyTZLkSW/BfSF cQ0S2+F9dzlzZxoQaNKHj9L+8xG6SfAx/EPmkXhXmOGzGhfL7jHK4vHGXlOBUElNASBW iL4jbXXhHzAEiWjeQyVT4P88fTqqD+AD7S0r/0yKW0j0WuBW8aU2b47ZZpwrEMDLmJdp Ja5w==
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=WNHWGBPQjAg3961PDFmD7Em1Qra7KuabRzkpED9icIE=; b=OIbWUgI3IQXRCCZr/W1M9WGIVrZvSnZa/IBYLsHmf0gt/jX9foNdnm3ngipM/quHFA Xx1rZ4CzNz794YAEEjVSXcq9VK0gdp19nzDwi6TY4/C4Tfamh7FBxk8QzlAwVWaYWxu3 IyBwQ53rJRGIi63A+igNEv7eoNoL32lHGpONXAljH/b6N4iqNHo0jZiJ2ZSpjzZY58by xX/g2pNiWKN4GKTUOGIZYJd6OGmSVhUPyYc95+6CSk3fjRiofZGwhU8fVCfRLn5ztsgP Hs9j2ULXgcC/4DUgIFh0t1+d3z1W6Tc6dqiMzvx7woAy10DelnvBS5GB7IcbEeDx1hih Z6Lg==
X-Gm-Message-State: AA+aEWY+mouG4OzquuLz32dZ0NOXZRfNQgTs13a8JFATI20DdYzpHWRo l9yxPzI6iG43MXidjRA5LGDeqbXaFzH/ah2voXk=
X-Google-Smtp-Source: AFSGD/Xg52Q+wh3i3shL0R5tWBR+DhhQ9gwJCOJJCYOYhph/WL07Wj7a4QKEuuaXKmLFt3M7I94ZqsIQjQ1gOP7BPSs=
X-Received: by 2002:a2e:197:: with SMTP id f23-v6mr13572738lji.144.1544660418041; Wed, 12 Dec 2018 16:20:18 -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>
In-Reply-To: <CA447D15-2E65-4340-9FF5-4700A53335ED@logmein.com>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Wed, 12 Dec 2018 18:20:07 -0600
Message-ID: <CAKKJt-cG=R5ide_qHx5hNKbYwxhDKmwk0tOQutNPYBJp8L7HUA@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="000000000000841d16057cdc47ee"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/1ndp3oy784bjmjR06aEujB5KKuo>
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 00:20:23 -0000

Hi, Simon,

On Fri, Nov 23, 2018 at 7:27 AM Simon Perreault <Simon.Perreault@logmein.com>
wrote:

> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> This seems like an interesting technique that warrants collection of
> operational
> experience.
>
> >From a process perspective, I think we have a bit of an issue, unless I've
> overlooked something relevant. This is proposed as a Standards-Track
> document,
> but it relies on the use of the PADDING attribute defined in RFC 5780. RFC
> 5780 is Experimental, so this is a formal downref. And RFC 5780 does not
> appear in the downref registry [1], nor did the IETF last call [2] include
> a
> request that the IETF community consider allowing such a refernce.
>
> >From a practical perspective, the mechanism described in this document
> seems
> like the kind of thing that it would be useful to gather operational
> experience
> with prior to putting it on the standards track. I have some operational
> concerns (described below) that I think could be either proven out or
> dispelled
> by experimental deployment of the technology.
>
> My recommendation is to recategorize this mechanism as experimental,
> adding some
> text about the desire to gather operational experience.
>
> For avoidance of doubt: My DISCUSS is only on the process issue, and I'll
> happily clear regardless of how this issue is rationalized (e.g., either by
> running IETF last call again, by reclassifying this mechanism as
> experimental,
> or perhaps some novel solution that I may not have thought of). Everything
> else is merely a recommendation.
>
>
>
> I don't think I've seen a specific response to Adam's point here, which I
> believe is that one of (at least) three things should happen -
>
>
>
> - a second Last Call, explicitly calling out this downref, OR
>
>
>
> - approval as an Experimental RFC, which makes the downref issue go away,
> OR
>
>
>
> - (and this didn't happen in this thread, but in some conversation, I
> remember that) Adam wondered if reusing the PADDING attribute was the right
> thing to do (and that was a question, not a concern, but relevant here,
> since if this document defined its own attribute, the downref would also go
> away).
>
>
>
> Any thoughts on this?
>
>
>
> Spencer, Adam,
>
>
>
> I see an easy fourth option:
>
>
>
> - 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 have an opinion about this, but I should ask.

Thanks,

Spencer


> I’m fine with whatever, for the record.
>
>
>
> Simon
>