Re: [tram] Ben Campbell's No Objection on draft-ietf-tram-stun-pmtud-10: (with COMMENT)
Ben Campbell <ben@nostrum.com> Thu, 14 November 2019 13:59 UTC
Return-Path: <ben@nostrum.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 02E9512011B; Thu, 14 Nov 2019 05:59:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.4, MAY_BE_FORGED=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 YQ9Zl8xYNtKZ; Thu, 14 Nov 2019 05:59:50 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 DEDF51200EF; Thu, 14 Nov 2019 05:59:49 -0800 (PST)
Received: from [192.168.127.239] (mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged)) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id xAEDxhPo005068 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 14 Nov 2019 07:59:44 -0600 (CST) (envelope-from ben@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1573739985; bh=Q6box0gWY6vC/5VVpBhbeg2x+XX1jRu8sG2TWM1xrS8=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=VOoMWpGh61F6NywlSksIHfh+V4Y2uD3025a63OuqKXfbL45ehgmM3KwGqFeLe67Go WbXjpv/oTS9ZWyTYMePmtfBa8R9FIeOh58ikruQB7rn3lUFZMe0G2MehdToTaaGlA3 6A7USEorf3Al3VyCK5RxWI0BrvfrUKud8uEvweV8=
X-Authentication-Warning: raven.nostrum.com: Host mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged) claimed to be [192.168.127.239]
From: Ben Campbell <ben@nostrum.com>
Message-Id: <08A846D1-34A2-47E1-8DE6-D393DF5DA1E2@nostrum.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_00CF6520-E9CD-4D60-AA56-7112DF5B9819"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
Date: Thu, 14 Nov 2019 07:59:37 -0600
In-Reply-To: <F4F1CDF2-A1E0-4D82-913E-0E5178855783@cisco.com>
Cc: "draft-ietf-tram-stun-pmtud@ietf.org" <draft-ietf-tram-stun-pmtud@ietf.org>, "tram-chairs@ietf.org" <tram-chairs@ietf.org>, "tram@ietf.org" <tram@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>
To: "Felipe Garrido (fegarrid)" <fegarrid@cisco.com>
References: <153799041044.21545.15688918373860539781.idtracker@ietfa.amsl.com> <77E6F21E-094B-42B4-8601-A7CEF28EAA79@cisco.com> <F4F1CDF2-A1E0-4D82-913E-0E5178855783@cisco.com>
X-Mailer: Apple Mail (2.3601.0.10)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/E-kTBciQeIXlOAJ8nMeUzl-87is>
Subject: Re: [tram] Ben Campbell's No Objection on draft-ietf-tram-stun-pmtud-10: (with 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, 14 Nov 2019 13:59:52 -0000
Hi, I am no longer an AD, so my comments are only advisory at this point. But in any case, your responses resolve my comments. Thanks! Ben. > On Nov 14, 2019, at 2:29 AM, Felipe Garrido (fegarrid) <fegarrid@cisco.com> wrote: > > Hi Ben, > > Responses are in-line and updated in the latest draft. Let me know if they address your COMMENTS. > > Thanks, > -Felipe > > > > From: Ben Campbell <ben@nostrum.com <mailto:ben@nostrum.com>> > Subject: Ben Campbell's No Objection on draft-ietf-tram-stun-pmtud-10: (with COMMENT) > Date: September 26, 2018 at 3:33:30 PM EDT > To: The IESG <iesg@ietf.org <mailto:iesg@ietf.org>> > Cc: <draft-ietf-tram-stun-pmtud@ietf.org <mailto:draft-ietf-tram-stun-pmtud@ietf.org>>, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com <mailto:gonzalo.camarillo@ericsson.com>>, Tolga Asveren <tasveren@rbbn.com <mailto:tasveren@rbbn.com>>, <tram-chairs@ietf.org <mailto:tram-chairs@ietf.org>>, <tasveren@rbbn.com <mailto:tasveren@rbbn.com>>, <tram@ietf.org <mailto:tram@ietf.org>> > Resent-From: <alias-bounces@ietf.org <mailto:alias-bounces@ietf.org>> > Resent-To: <marc@petit-huguenin.org <mailto:marc@petit-huguenin.org>>, <gsalguei@cisco.com <mailto:gsalguei@cisco.com>> > > Ben Campbell has entered the following ballot position for > draft-ietf-tram-stun-pmtud-10: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html <https://www.ietf.org/iesg/statement/discuss-criteria.html> > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-tram-stun-pmtud/ <https://datatracker.ietf.org/doc/draft-ietf-tram-stun-pmtud/> > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I support Adam's DISCUSS. I will go a bit further to say that, even if a new > IETF LC occurs, I would be skeptical that the dependency on PADDING in a > standards track protocol is appropriate unless people are willing to argue that > RFC 5780 has become mature enough that it could reasonably be promoted to > standards track. > > Another alternative might be to re-describe PADDING in this draft, as it is > used in the context of the draft. I don't normally love that sort of > duplication, but it might be appropriate here. > > > [FG] This was addressed in an earlier draft. > > > > > Other comments: > > §2: "It is not intended as a replacement for [RFC4821]": I find this comment > confusing. Are other sections in the document intended to replace some or all > of 4821? > [FG] Updated wording. > > “This section is meant to be informative only and is not intended as a substitute for…” > > > §4: "The probing mechanism is used to discover the Path MTU in one direction > only...": Can this mechanism not be used bidirectionally, with reciprocal > client-server roles? > > [FG] Yes, and this is noted in later sections. Added additional wording in this section. > > “Both endpoints MAY behave as a client and a server to achieve bi-directional path discovery.” > > > §4.1.2: "The server MUST add the FINGERPRINT attribute...": Is this a new > requirement for PMTUD, or a generic STUN requirement? If the latter, it should > not be stated normatively. (Same comment for §4.2.1) > > [FG] Yes, this is new for PMTUD. > > > §4.2.1: "If the authentication mechanism permits it, then the Indication MUST > be authenticated": Is that intended to imply it's okay to use authentication > mechanisms that don't allow this? > > [FG] Yes, do you see an issue with the statement? > > >
- [tram] Ben Campbell's No Objection on draft-ietf-… Ben Campbell
- Re: [tram] Ben Campbell's No Objection on draft-i… Adam Roach
- Re: [tram] Ben Campbell's No Objection on draft-i… Felipe Garrido (fegarrid)
- Re: [tram] Ben Campbell's No Objection on draft-i… Ben Campbell