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

Simon Perreault <Simon.Perreault@logmein.com> Fri, 23 November 2018 13:27 UTC

Return-Path: <prvs=8865a40234=simon.perreault@logmein.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 5244F12F1A2; Fri, 23 Nov 2018 05:27:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -19.16
X-Spam-Level:
X-Spam-Status: No, score=-19.16 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=logmein.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 BXMyoZF9cM-K; Fri, 23 Nov 2018 05:27:55 -0800 (PST)
Received: from mx0b-001a0901.pphosted.com (mx0a-001a0901.pphosted.com [67.231.144.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D173212E043; Fri, 23 Nov 2018 05:27:55 -0800 (PST)
Received: from pps.filterd (m0074903.ppops.net [127.0.0.1]) by mx0a-001a0901.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id wANDNOY6009202; Fri, 23 Nov 2018 08:27:51 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=logmein.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=email; bh=aBBuHA6RyzpCyaoyrYiNsREkM1d5s5V48GwAXiv+h1U=; b=O3LqxMKNg7WNQrUGq8vJDLj1mo4lX0PTjCCIaejO37gFteT7TvxCb+ta+ZRzB1Fkn6Ul 8gSsa6ZkZer4dysfe0GUd6Xio7xhHK6fImaDCCuEbM6wvLZjBmLzXU+d6jsa+jsOwteH IVXeA/9g2MtS0GX9TTlZjxLJxKTpglyQy60=
Received: from nam04-sn1-obe.outbound.protection.outlook.com (mail-sn1nam04lp0087.outbound.protection.outlook.com [216.32.180.87]) by mx0a-001a0901.pphosted.com with ESMTP id 2ntd6dfdq3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 23 Nov 2018 08:27:51 -0500
Received: from MWHPR15MB1200.namprd15.prod.outlook.com (10.175.2.142) by MWHPR15MB1695.namprd15.prod.outlook.com (10.175.142.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1339.21; Fri, 23 Nov 2018 13:27:47 +0000
Received: from MWHPR15MB1200.namprd15.prod.outlook.com ([fe80::190:b8da:412e:8be2]) by MWHPR15MB1200.namprd15.prod.outlook.com ([fe80::190:b8da:412e:8be2%4]) with mapi id 15.20.1339.031; Fri, 23 Nov 2018 13:27:47 +0000
From: Simon Perreault <Simon.Perreault@logmein.com>
To: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, Adam Roach <adam@nostrum.com>
CC: 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>
Thread-Topic: Adam Roach's Discuss on draft-ietf-tram-stun-pmtud-10: (with DISCUSS and COMMENT)
Thread-Index: AQHUWQNKbxGEYwDhVEaOcLCOF8V9tqVX4rYAgAV4EwA=
Date: Fri, 23 Nov 2018 13:27:46 +0000
Message-ID: <CA447D15-2E65-4340-9FF5-4700A53335ED@logmein.com>
References: <153834237082.13405.1228259718885034461.idtracker@ietfa.amsl.com> <CAKKJt-fouMOJa+eGUwEmQL+Uv5Fqe5KNM_fC0YxmhYojpFNzaA@mail.gmail.com>
In-Reply-To: <CAKKJt-fouMOJa+eGUwEmQL+Uv5Fqe5KNM_fC0YxmhYojpFNzaA@mail.gmail.com>
Accept-Language: fr-CA, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [69.156.197.18]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; MWHPR15MB1695; 6:sjwkj09alFRI4QvqprMrW1qADtt2/+41OxqXMxDKvYpphtbVgmfl6T5Nwg/03vOLeXrimJ3zGOgmqJgESrTsVgPS4RdZymCdZ+5FLN3nouXu+CPcs+di3MjXw8ljFpi+4U4aKGPmQnei3PokUKl52wI+dhXE4pxDHvfb+EiDsbOncaIsezPEmem98CjfZASzbVQ1blfZAU/zcmLLJMv5XHFMyU7dy4z7bkgRE/mXDTwihNiY2Go22RPQiKD0jnLY4HpA5PjVVrpStnrZfymouoRGDw75PA6WNbxJrlukbSAIS2XiRYvOAT0TviN/ZreBpvzlI0R6zMRwIr4uoAJYy1nNR1HKYp/VLlQurEnV/pQrtjPmVqI/oYff07bROZdDlXsyRoymwL2dyHfVlWAzPla3bHSJ7JfI+0Lxl2IVkNT05advpPQK45dCHzTid2xCIFm3Ufxyos7NkgeY6M/oeg==; 5:eAxbYS9T/2W4UsYG95gNt+gqt7pKM1uOwe8iZaRtyzytJd79Tzq5tZwe2z4lR5IIarAPSCArV6jh6e+2hB+WjQPhiTpJ5s04NFBg/sEvd1EbhkX4PzTH3QoE6eW5XML0fe1FjpH/XLNHbZKXk0Ac7qq/ThmbCt0E3uMh5zbbvLg=; 7:FZcPy9VK3gB9AsI+dhyD3NKIVLn6dIwqU1RBOv/gJmDXHPBSs/a/Y6RB7SaUIEq1TTjHbEEvkQA//PU0Hizz7Jenj2Gh5ZpmAgOR5cmLb+T3C9gU3N1dY90asrnUQ6toGrAXUvd0rFaDm/Fovsd60A==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 42250aae-5b76-4e8c-813e-08d65147752e
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:MWHPR15MB1695;
x-ms-traffictypediagnostic: MWHPR15MB1695:
x-microsoft-antispam-prvs: <MWHPR15MB169589B1889A02D847A6274BFAD40@MWHPR15MB1695.namprd15.prod.outlook.com>
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231442)(944501410)(52105112)(10201501046)(3002001)(148016)(149066)(150057)(6041310)(20161123558120)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(20161123562045)(201708071742011)(7699051)(76991095); SRVR:MWHPR15MB1695; BCL:0; PCL:0; RULEID:; SRVR:MWHPR15MB1695;
x-forefront-prvs: 086597191B
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39860400002)(346002)(376002)(396003)(136003)(189003)(199004)(78642003)(478694002)(71200400001)(71190400001)(7736002)(6246003)(36756003)(6436002)(256004)(14444005)(3846002)(83716004)(6116002)(8936002)(476003)(110136005)(39060400002)(486006)(68736007)(2616005)(316002)(54906003)(53936002)(4326008)(33656002)(2906002)(66066001)(76176011)(6486002)(446003)(99286004)(11346002)(81156014)(8676002)(6512007)(81166006)(54896002)(6306002)(86362001)(82746002)(508600001)(105586002)(106356001)(2900100001)(25786009)(97736004)(14454004)(72206003)(102836004)(26005)(229853002)(186003)(6506007)(5660300001)(69594002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1695; H:MWHPR15MB1200.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: logmein.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: KlUC6pTlmZ3/BSNKoV93ER7MyxQTOOt/VUrINtJAcKbqhea9zbVgQRHX2GujWeJMUHkHq71sXm2bTHU5iTT0Fzr01L3+//yu/eCmUIQkQIbQ0oEyybnFkPcYqZIF357+5FAiPr1Kn48Babqc2szrGC4DzR0PhOf4MsQGaeyHXQMgQJj+iwDPJQ+U76JhrUfrri8Y30+NzilZ5pbq+s+Wdy4uOwbFL+/wM+oJYyCHlbTIZtJshkZ4bX7izf1gbm2D9tGc6VOH+MLFx/KexFjq46huLMMp0jg422auMee32qVpMpPZruNx1V7jdMUbjSZdc/9LrRfNrJ8BoM0ii/PSXmrAMJHZEj8kRMJbvJsrm74=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CA447D152E6543409FF54700A53335EDlogmeincom_"
MIME-Version: 1.0
X-OriginatorOrg: logmein.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 42250aae-5b76-4e8c-813e-08d65147752e
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Nov 2018 13:27:46.8952 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 84c4e5b0-26a0-4dac-b686-301d76713569
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1695
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-23_09:, , signatures=0
X-Proofpoint-Spam-Reason: safe
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/7b84m3qXldrZfy07q-beYM5Vb6c>
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: Fri, 23 Nov 2018 13:27:59 -0000

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

I’m fine with whatever, for the record.

Simon