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

"Felipe Garrido (fegarrid)" <fegarrid@cisco.com> Mon, 19 August 2019 14:13 UTC

Return-Path: <fegarrid@cisco.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 C2086120116; Mon, 19 Aug 2019 07:13:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=izKyp1a5; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=T0c3k2pu
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 bOEN5fedxOp6; Mon, 19 Aug 2019 07:13:20 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 384E51200F3; Mon, 19 Aug 2019 07:13:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13962; q=dns/txt; s=iport; t=1566224000; x=1567433600; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=0376hdDFLPahmtfuvg95iy9YC1z+eqbFvsP73Fw6If4=; b=izKyp1a5z23ptsNognEb7l0lMul9QB4e3L6XszQzfn1ofZH+dpIogncH Pfsbpsq2VtMSPpPKJKUHEDbT+DKaTPX7tWOxtYLcOXv1EfCj1P7wz5Hp7 OuX441s/kuI8C8TxjSupuWFoH4guIaCNBIMSjR1RzeM1aIN6uPsvq0L6r c=;
IronPort-PHdr: =?us-ascii?q?9a23=3AEgFUWh026eWeiHEYsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxKGt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQB0D0JeTwbiASF8VZX1gj9Ha+YgBY?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DnAQBrrVpd/40NJK1kDg8BAQUBBwU?= =?us-ascii?q?BgVYFAQsBgURQA21VIAQLKoQfg0cDinmCXJdlgUKBEANUCQEBAQwBARgLCgI?= =?us-ascii?q?BAYQ/AheDDyM3Bg4CBQEBBAEBAQIBBgRthScMhUoBAQEBAgEBARAREQwBASw?= =?us-ascii?q?LAREBCBEDAQIBAgImAgQlCxUICgQOBSKDAAGBagMODwECDJ5fAoE4iGFzgTK?= =?us-ascii?q?CegEBBYFGQYMDGIIUAwaBDCgBi2gXgUA/gREnH4JMPoJhAQEBAgGBKgERAgE?= =?us-ascii?q?IgyEygiaMP4IlMZxACQKCHYZojVEbgjGHMHWDI4pLlTyQKQIEAgQFAg4BAQW?= =?us-ascii?q?BZiJnWBEIcBU7KgGCQYJCCRoVgzqFFIUEO3IBgSiKdCuCJQEB?=
X-IronPort-AV: E=Sophos;i="5.64,405,1559520000"; d="scan'208";a="314245704"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Aug 2019 14:13:18 +0000
Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id x7JEDHSF015558 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 19 Aug 2019 14:13:18 GMT
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 19 Aug 2019 09:13:17 -0500
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 19 Aug 2019 09:13:17 -0500
Received: from NAM05-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 19 Aug 2019 09:13:16 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=g23uKC0IV33h/Cc39J+XMi46Vu1PeWvPwZ6ijktja4Mq7WpNCv/KdC6XM7fldZcd2Y6028eBYPYumihhYwNpfbHNCBMnhIKYuZks/PsF0CaqkrAcQPnAqEJ8lAw08xWYq40oK+mD6WaeKKwpMyRUi+ZxkhtcSouUmVl8A7QIUba7uUvbcnWqOPzxqzkB49bLuqIO+vjO6kReJO+U2l0XYlPc+8TFMyxfLPdbWyLQ3JmMfG5T3IOUHYvxn7hixDMwDMJ5v3B9hwGiysitiC5kvfww4ibxOobNmzC4Qt6PscJoQwJXNTyq7wtl+EW8LtM28kdOiJazmmNG+UcwBQfY0A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0376hdDFLPahmtfuvg95iy9YC1z+eqbFvsP73Fw6If4=; b=CtQDvPBaYjLjksLkz01wA8bmnmidtKI9t8GuD5AxyZUXRsfGGVBReVJPxtgxKsp1V72OdOqv8Zw01ZKPU4DumJC7+2tdTcogofz2n4V7pPrNA7miUhOVB7ep6eyrmhqeeyJJrTm+b+uJa6lxu6gA/3tYO/ryVk95dxLU/ZuIG7SFd4Ng6zo5vWUytmt4500csheaq1v+Y6kLsAreY1Y9uRf9dSGKBJcu5zBxPhmMDEX1DommAWRBOQHU+zt58iO8R5enNgskQEkem0O+A1GPLHYQT971Mu8XJgaNpQeRkQY4Q5Q82310OTm/JG2YU2BNBWLYWR13vvpCLyYxwryv9Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0376hdDFLPahmtfuvg95iy9YC1z+eqbFvsP73Fw6If4=; b=T0c3k2puQi4h6DkSVubPqQgaSekZ7EdXzWX8kt+5nlh+1vrgqgelvlZd7ELEHeDH33zWupPRT/yNiEomqcxLqE4QTvG3RURWBoKzauWCfkasnsRzI/Tc7yuk4Wuy6pw9T/HUYB3viboVYxPz8suqs18ls71zxRSHa8K8E/m7XSA=
Received: from SN6PR11MB2800.namprd11.prod.outlook.com (52.135.93.15) by SN6PR11MB3039.namprd11.prod.outlook.com (52.135.125.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2178.16; Mon, 19 Aug 2019 14:13:14 +0000
Received: from SN6PR11MB2800.namprd11.prod.outlook.com ([fe80::d486:f01e:4774:c7f5]) by SN6PR11MB2800.namprd11.prod.outlook.com ([fe80::d486:f01e:4774:c7f5%7]) with mapi id 15.20.2178.018; Mon, 19 Aug 2019 14:13:14 +0000
From: "Felipe Garrido (fegarrid)" <fegarrid@cisco.com>
To: Benjamin Kaduk <kaduk@mit.edu>
CC: "tram-chairs@ietf.org" <tram-chairs@ietf.org>, "draft-ietf-tram-stun-pmtud@ietf.org" <draft-ietf-tram-stun-pmtud@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "tasveren@rbbn.com" <tasveren@rbbn.com>, "tram@ietf.org" <tram@ietf.org>
Thread-Topic: [tram] Benjamin Kaduk's Discuss on draft-ietf-tram-stun-pmtud-10: (with DISCUSS and COMMENT)
Thread-Index: AQHVVpg8IbJ8/qOxhU2JEz3mbWOuMw==
Date: Mon, 19 Aug 2019 14:13:13 +0000
Message-ID: <D4026211-D94F-4BE9-BF3E-0B655AF4E83C@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1c.0.190812
authentication-results: spf=none (sender IP is ) smtp.mailfrom=fegarrid@cisco.com;
x-originating-ip: [2001:420:2280:1272:6501:8be9:d2b8:e11b]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: afb3ff36-49ee-49a0-795c-08d724af5fb9
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:SN6PR11MB3039;
x-ms-traffictypediagnostic: SN6PR11MB3039:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <SN6PR11MB30397487700590968B276CF5C8A80@SN6PR11MB3039.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0134AD334F
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(376002)(39860400002)(346002)(366004)(396003)(51444003)(189003)(199004)(2616005)(476003)(6916009)(36756003)(99286004)(33656002)(86362001)(486006)(53936002)(186003)(7736002)(91956017)(6246003)(2171002)(6506007)(46003)(14454004)(256004)(478600001)(14444005)(71190400001)(71200400001)(102836004)(6116002)(966005)(5660300002)(4326008)(53546011)(305945005)(66946007)(66556008)(66446008)(64756008)(6436002)(81156014)(58126008)(66476007)(76116006)(54906003)(81166006)(6306002)(6512007)(8936002)(316002)(229853002)(8676002)(25786009)(6486002)(66574012)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN6PR11MB3039; H:SN6PR11MB2800.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: 5QFIZQ13Hd0HV4HM+1UJINVtxbwCU2zU8mpw6ABjFfHnLbGlpHuushLwOHLr2WevjYKFIwRdhk187ZaBLaPfgHJYGcLxDpRbqhycRT0+uhQY8DXlO5sdYY/QUThxoC7YNGunmp0nyIGQn+ALbW+oyaE+rxg9GMJ/XBqpuVSP/zbXAPSXLMbq6L7C/guyaRujbMi6uLrLs0WDTlKWR55zHxTTzP4Cijg09h0qP7uF+Iqf/OAsqRGoMboPiFwrWYA4thRx4vLEGj1SaYZ5ekyv7zHU4h/HkxwytVRpN4z0+yT0eSeaE71KZHDKSVGr+iTQARgEeemTEkhmzUq0c8cE8CKPV4NxnLh3TfR6eA+F1tPnpO09qHrxenFAoPJfhhEPtBGk8Fh87oR/N1ImTdh7Mg23JfyuAltII+j5ZqXtRWY=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <F0F99FA662842F4CAB6F5AC2422EC8D6@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: afb3ff36-49ee-49a0-795c-08d724af5fb9
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Aug 2019 14:13:13.5184 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: HcDftWohXMQbTS9GnJNhyjl14A7UHvPqlgDnGUpoK/xXgmzwrWcgDfFb1P7kUOQR3CmK1vYJjh+BLCm1MbdIJA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR11MB3039
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.23, xch-aln-013.cisco.com
X-Outbound-Node: alln-core-8.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/mXxJuaOtXzPniBN03AY3vJYEc7U>
Subject: Re: [tram] Benjamin Kaduk'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, 19 Aug 2019 14:13:23 -0000

Hi Ben, 

Do you agree with the latest wording changes? A new draft version has been published with them.

Thanks,
-Felipe

On 7/8/19, 10:43 AM, "tram on behalf of Felipe Garrido (fegarrid)" <tram-bounces@ietf.org on behalf of fegarrid@cisco.com> wrote:

    Hi Ben, 
    
    Totally agree now that I've re-read it. 
    
    Here's the new proposed wording. 
    
    "The packets that are to be associated to an identifier are selected according to Section 5.2 of [RFC4821]."
    
    Here's the full text. 
    
    A server supporting this specification will keep the identifiers of
    all packets received in a chronologically ordered list.  The
    packets that are to be associated to an identifier are selected 
    according to Section 5.2 of [RFC4821]."
    
    Thanks,
    -Felipe
    
    On 6/27/19, 12:00 AM, "Benjamin Kaduk" <kaduk@mit.edu> wrote:
    
        Hi Felipe,
        
        Thanks for following up -- it looks like I filed away the original mail
        without responding to it, somehow(!)
        The Discuss point's resolution is fine; I just have one more question
        (inline).
        
        -Ben
        
        On Wed, Jun 26, 2019 at 04:01:58AM +0000, Felipe Garrido (fegarrid) wrote:
        > Hi Benjamin,
        > 
        > Just following up on my previous email. Let me know if the below response satisfies your comments.
        > 
        > Thanks,
        > -Felipe
        > 
        > From: "Felipe Garrido (fegarrid)" <fegarrid@cisco.com>
        > Date: Tuesday, May 21, 2019 at 11:59 AM
        > To: "kaduk@mit.edu" <kaduk@mit.edu>du>, "iesg@ietf.org" <iesg@ietf.org>
        > Cc: "draft-ietf-tram-stun-pmtud@ietf.org" <draft-ietf-tram-stun-pmtud@ietf.org>rg>, "tram-chairs@ietf.org" <tram-chairs@ietf.org>rg>, "tasveren@rbbn.com" <tasveren@rbbn.com>om>, "tram@ietf.org" <tram@ietf.org>
        > Subject: Benjamin Kaduk's Discuss on draft-ietf-tram-stun-pmtud-10: (with DISCUSS and COMMENT)
        > 
        > 
        > Hi Benjamin,
        > 
        > Apologies for the delay in responding, the current authors are having scheduling conflicts and have added me to address the current concerns. Please see my responses inline.
        > 
        > thanks
        > -Felipe
        > 
        > 
        > Benjamin Kaduk has entered the following ballot position for
        > draft-ietf-tram-stun-pmtud-10: Discuss
        > 
        > 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
        > 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/
        > 
        > 
        > 
        > ----------------------------------------------------------------------
        > DISCUSS:
        > ----------------------------------------------------------------------
        > 
        > I was going to report the same thing as Adam, but will just say that I support his Discuss.
        > [FG]: I’ll be addressing this Discuss in Adam’s feedback.
        > 
        > I also have one other (also minor and easy to resolve) Discuss point:  Section 4.2.6 needs
        > to state what the Length field is measuring the length of.
        > [FG]: Agree that this is required. Adding the following text to Section 4.2.6.
        > “The Length field specifies the length in bytes of the sequence number and application data fields.”
        >
        > ----------------------------------------------------------------------
        > COMMENT:
        > ----------------------------------------------------------------------
        > 
        > I understand that this document inherently has to be incomplete and "vague",
        > since the procedure specified within is only meaningful in the context of a
        > STUN usage or other protocol.  But in general it seems like there could be
        > greater clarity even within the constraints that we must work under.  My
        > points are probably less interesting than the ones Adam raised already, though.
        > The only general observation in this space that I can offer is that some parts of
        > the text read as if only the Probe packets are going to be monitored for the
        > report (but this is clearly not the case given the document as a whole).
        > 
        > Section 4.2
        > 
        >   The Complete Probing mechanism is implemented by sending one or more
        >   Probe Indications with a PADDING attribute over UDP with the DF bit
        >   set in the IP header followed by a Report Request to the same server.
        >   A router on the path to the server can reject this Indication with an
        >   ICMP message or drop it.
        > 
        > nit: I don't think "this" is the right word; perhaps "each" would be
        > better.
        > 
        > 
        > 
        > [FG]: Agree, updates will be made.
        > 
        > Section 4.2.3
        > 
        >   A server supporting this specification will keep the identifiers of
        >   all packets received in a chronologically ordered list.  The packets
        >   that are to be associated to a list are selected according to
        >   Section 5.2 of [RFC4821].  [...]
        > 
        > 4821 doesn't talk about "list"s at all, and in fact the indicated section
        > seems to be talking more about where to store a PMTU value after it has
        > been determined, rather than what packets to be considering for a report.
        > So I'm pretty confused about what this sentence is trying to say.
        > 
        > 
        > 
        > [FG]: Agree. Updated wording to make the statement easier to read.
        > “The selection process specified in Section 5.2 of [RFC4821] is to be used to determine whether a packet is added with a list.”
        
        I still don't understand what "the selection process specified in Section
        5.2 of [RFC4821]" is -- can you point me to the text from RFC 4821
        describing the process in question?
        
        > Section 4.2.4
        > 
        > nit: I think that all instances of "the Probe Indication" should be
        > replaced with "a Probe Indication", in this section.
        > 
        > 
        > 
        > [FG]: Agree, updates will be made.
        > 
        > Section 4.2.5
        > 
        >   When using a checksum as a packet identifier, the client calculates
        >   the checksum for each packet sent over UDP that is not a STUN Probe
        >   Indication or Request and keeps this checksum in a chronologically
        >   ordered list.  The client also keeps the checksum of the STUN Probe
        >   Indication or Request sent in that same chronologically ordered list.
        >   The algorithm used to calculate the checksum is similar to the
        >   algorithm used for the FINGERPRINT attribute (i.e., the CRC-32 of the
        >   payload XOR'ed with the 32-bit value 0x5354554e [ITU.V42.2002]).
        > 
        > (editorial) It's pretty confusing to start out with the split between STUN
        > and non-STUN messages, only later to clarify that this is because the
        > FINGERPRINT is used for STUN messages.  So maybe:
        > 
        >  When using a checksum as a packet identifier, the client keeps a
        >  chronologically ordered list of the packets it transmits, along with an
        >  associated checksum value.  For STUN Probe Indication or Request packets,
        >  the associated checksum value is the FINGERPRINT value from the packet; for
        >  other packets a checksum value is computed using a similar algorithm to the
        >  FINGERPRINT calculation.
        > 
        > 
        > 
        > [FG]: Agree with changing of the language. It doesn’t change the content and easier to read.
        > 
        > Section 4.2.6
        > 
        >   When using sequence numbers, a small header similar to the TURN
        >   ChannelData header [...]
        > 
        > Probably want an informative reference for this header.
        > 
        > 
        > 
        > [FG]: Agree, updates will be made to reference.
        > Section 6.2
        > 
        > 6.2.  PMTUD-SUPPORTED
        > 
        >   The PMTUD-SUPPORTED attribute indicates that its sender supports this
        >   specification.  This attribute has no value part and thus the
        >   attribute length field is 0.
        > 
        > "this specification" is not sufficiently detailed to interoperate, so I
        > think this needs to be qualified as more like "supports this mechanism, as
        > incorporated into the STUN usage or protocol being used".
        > 
        > 
        > 
        > [FG]: Agree, updates will be made.
        > 
        > Section 7
        > 
        > The contents of the PADDING do not seem to be specified anywhere, so it
        > could in theory be used as a side channel to convey other information,
        > which has some potential privacy considerations.  Nowadays we tend to ask
        > for the value of the padding bytes to be deterministic (but validation
        > remains optional); I forget if there are STUN-specific considerations that
        > would discourage just setting them all to zero.
        > 
        > 
        > 
        > [FG]: Agree.  Adding language to state contents of PADDING.
        > “The padding bits MUST be set to zero on sending and MUST be ignored by the receiver.”
        > 
        > 
        > 
        > 
        > 
        
    
    _______________________________________________
    tram mailing list
    tram@ietf.org
    https://www.ietf.org/mailman/listinfo/tram