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

"Felipe Garrido (fegarrid)" <fegarrid@cisco.com> Mon, 26 August 2019 14:11 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 D16F21200FB; Mon, 26 Aug 2019 07:11:30 -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=XChzUmo+; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=004gnw1i
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 5YCu0MgA0cB4; Mon, 26 Aug 2019 07:11:28 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C53C41200A3; Mon, 26 Aug 2019 07:11:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17050; q=dns/txt; s=iport; t=1566828687; x=1568038287; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=XhIkPiurwk8jMyCjTqxo3Afl46bnMK96zfW7h706Qwk=; b=XChzUmo+AWHSaG8m7OYkkfEyGIOWvMwaSfiKOTDS5GC2MXGhgMYmFJiI OyqdpGfggKFSo20rwludfzgHAHeEaut7s/Bmqbf+oefiE5RNR9+yoOIrA PokF8iMKspEoeS1pcZc6YCk3xJV632kNr+jLFJ8qnIi/pa9ZbgGQpFWtB 0=;
IronPort-PHdr: =?us-ascii?q?9a23=3AUDcfcBaV5sf9aJ+EN5/QKMH/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20gabRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn?= =?us-ascii?q?1NksAKh0olCc+BB1f8KavkYiMzBt5DWHdu/mqwNg5eH8OtL1A=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CrAAAE6GNd/4oNJK1kDgwBAQEBAQI?= =?us-ascii?q?BAQEBBwIBAQEBgWeBRVADbVYgBAsqhCGDRwOKbYJcl2iBQoEQA1QJAQEBDAE?= =?us-ascii?q?BGAsKAgEBhD8CF4JQIzgTAgMCAgMBAQQBAQECAQYEbYUtDIVKAQEBBAEBEBE?= =?us-ascii?q?RDAEBLAsBDwIBCBEDAQIBAgImAgICJQsVCAgCBA4FIoMAAYFqAx0BAgydIQK?= =?us-ascii?q?BOIhhc4EygnsBAQWBRkGCeBiCFgMGgQwoi3IYgUA/gREnH4JMPoJhAQEBAgG?= =?us-ascii?q?BKgERAgEIFoMLMoImjESCJzKcUQkCgh6Gao1ZG4IyhzB1gyaKUpVTkDsCBAI?= =?us-ascii?q?EBQIOAQEFgWchZ1gRCHAVOyoBgkFQEBSBTgkaFYM6hRSFBDtyAYEoizYrgiU?= =?us-ascii?q?BAQ?=
X-IronPort-AV: E=Sophos;i="5.64,433,1559520000"; d="scan'208";a="324858210"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Aug 2019 14:11:26 +0000
Received: from XCH-ALN-018.cisco.com (xch-aln-018.cisco.com [173.36.7.28]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id x7QEBQ4Z021735 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 26 Aug 2019 14:11:26 GMT
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-ALN-018.cisco.com (173.36.7.28) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 26 Aug 2019 09:11:25 -0500
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 26 Aug 2019 10:11:24 -0400
Received: from NAM05-DM3-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 26 Aug 2019 09:11:24 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GxuE7oRnuew9pndS0ZVxukxg9TBjEYPpWMOHlHsBJXZogpPtCwMV0VkgtmdqSSqMwWO5VQ8+EQqDyOAOhAMNUAf5dCKQ760Z2KaWEYZHildDkP1yKYgdoOto0WPIoMPY6QyCteaLkncj1I23OVQE80XEcEw6sZbJnkM2ZTd02hzNsxonr3w8UsEMnlF1mSu1aJOtXbE+VJF0PbllK/nuC4W0N1PcTkILRfJMzzSZDaF3FXI74/5p2eM3R6J5FPV9sQK3vMy/fbrE0Nua8AuhQEcoyuBZpHnAf6/deaSw3s238ZsuehJv1rulIoSRvtGCZrDZwaSg4Ri1x1K7HjJrww==
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=XhIkPiurwk8jMyCjTqxo3Afl46bnMK96zfW7h706Qwk=; b=TWtxfbMdWJyFFQh221kz8mabxkv+jPEu/xL+0L8oG4glr78FyyHi7Fr13pd2J1cjRZPQmfnKixPAeRM9gRwBk07/zYvnSloHJkYtg8fYojLA5TwlXLB3gP+71sVDke4NzFuhEfsLSikAgUy8MtUsG9bbmOI+oChfFl2prBmp0tSHtSosvZzyzkaLiWqZts8gyb1DMB8XJ4XXfyGdaDMBeG1QGMAW9HZ46S3BB7gqvlYAMHsJHosofhfj0VZtjbI7sz8ieqPyutZ2O4akFE/9CPGrgFtdmbA6K3KPLA3RDbVb6ZSFBfHRAWVza1MC4M5hot72O6SOU2o/OluClKLbSg==
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=XhIkPiurwk8jMyCjTqxo3Afl46bnMK96zfW7h706Qwk=; b=004gnw1iTX6V+s+gqIR+owA0sNCeZissUd5k9xaYvvn9BbB/LE1aHBl/A0zwQwLF7KtkQ5mlzyZ8dx3K0YY7OvUbWRJb0jYBZg2vIS9CxR2gIw4TLwyGZ2FchOjtLJ3DjpBx9GxDigY4xJW32diJlIUBZz9AXY8SBN0vSGMcXow=
Received: from SN6PR11MB2800.namprd11.prod.outlook.com (52.135.93.15) by SN6PR11MB2813.namprd11.prod.outlook.com (52.135.93.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2199.19; Mon, 26 Aug 2019 14:11:23 +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.020; Mon, 26 Aug 2019 14:11:23 +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/qOxhU2JEz3mbWOuM6cDJHYAgAobkIA=
Date: Mon, 26 Aug 2019 14:11:22 +0000
Message-ID: <6BEF16A5-8FC0-4BED-9C09-A47EF0B76CF1@cisco.com>
References: <D4026211-D94F-4BE9-BF3E-0B655AF4E83C@cisco.com> <20190819234944.GC60855@kduck.mit.edu>
In-Reply-To: <20190819234944.GC60855@kduck.mit.edu>
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: 5029e296-73a7-4ec0-40fd-08d72a2f469b
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:SN6PR11MB2813;
x-ms-traffictypediagnostic: SN6PR11MB2813:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <SN6PR11MB281384E86419487968C8570AC8A10@SN6PR11MB2813.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 01415BB535
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(136003)(376002)(39860400002)(346002)(366004)(189003)(199004)(51444003)(6436002)(476003)(6486002)(99286004)(7736002)(81156014)(5660300002)(478600001)(64756008)(86362001)(486006)(81166006)(66574012)(54906003)(66556008)(66476007)(58126008)(66446008)(76116006)(6116002)(316002)(71200400001)(71190400001)(66946007)(33656002)(14444005)(256004)(36756003)(8676002)(966005)(2171002)(229853002)(446003)(8936002)(53936002)(4326008)(2616005)(53546011)(46003)(91956017)(186003)(2906002)(14454004)(6246003)(6306002)(11346002)(102836004)(6512007)(6916009)(76176011)(305945005)(6506007)(25786009); DIR:OUT; SFP:1101; SCL:1; SRVR:SN6PR11MB2813; 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: uzomzPWicie/LuzdzI/ajVYM7aTuB6ibn/hYz4sn9quYb6ZOWOC5CYCKaKJ6l1OASVhmQpXW8iekg/f/UboChIQQrNhAd+pstVnPlXPSD2tTk3LMaCEItcXoO5U/faEbFQ1Z+gE2/5kkZGcsx0zZ9xRwTzm7PD8MZdX9zWeD77+CEZPMKqgYUVZ7EF0XTODwl2mB1LxGGXB5Pd2vtZbYTbDQ/Dw0/Q9VnC3NRWJycCMbXxrHazBspCkg1BwMeiiN4vipjCH5YUqDq2IDf+cNjnZZraBIyErRnkQUq1LhRqci/qO9/uKKB7YSapSzaeknv/R25rX45qHqF6urBMe9xESQXEc0KZP/uWJMdA5BzfihgHc4FhDUTg+OEGxSfk893qhJ6n5xNj1bpvPdcnpXepnVvcu73BQiNsF8a61q5e0=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <4EBF3D9F298CE248BCCCF37A6D807C3E@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 5029e296-73a7-4ec0-40fd-08d72a2f469b
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Aug 2019 14:11:22.9645 (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: Vj6Maa07HU5+zVK5qqWGZeMlXY+ABXQ/QFqzJbudNwg7zIcZ0MLwninMLs03GrESFkET9HW9Q5Zjf4iBpUVR+A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR11MB2813
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.28, xch-aln-018.cisco.com
X-Outbound-Node: alln-core-5.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/W9UpBuoGetCmOt_YD1lH7c5YYg4>
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, 26 Aug 2019 14:11:31 -0000

Ben, 

I agree with the improvement but would rather use the same terminology as in rfc4821. 
It' would be, 

The packets that are to be associated to a given flow's identifier are selected according to Section 5.2 of [RFC4821]."

Thanks,
-Felipe

On 8/19/19, 7:50 PM, "Benjamin Kaduk" <kaduk@mit.edu> wrote:

    Hi Felipe,
    
    The new wording is at least enough for me to come up with what seems like a
    plausible guess for what the identifier (and algorithm thereto) is supposed
    to be, but I do still feel like I'm guessing.  If it's the path identifier
    used to associate stored (PL)PMTU state across different flows (which is my
    guess), then maybe "associated to a given path's identifier" would be a
    further improvement?
    
    Thanks,
    
    Ben
    
    On Mon, Aug 19, 2019 at 02:13:13PM +0000, Felipe Garrido (fegarrid) wrote:
    > 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
    >     
    >