Re: [clue] Benjamin Kaduk's No Objection on draft-ietf-clue-datachannel-15: (with COMMENT)

Christer Holmberg <> Wed, 10 April 2019 14:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 189F612012E; Wed, 10 Apr 2019 07:39:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ehI-FJcQUYfK; Wed, 10 Apr 2019 07:39:56 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 492A7120021; Wed, 10 Apr 2019 07:39:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ahGlFhPYWklLfznF3h7Y44MTz6nw8cGgkeqqeOadT1o=; b=HEk/RKMIZlFI/wdCtHPJFkEA2nSvVnp406jeBOQIf9BEmr6Ce2AocKqRPxCcTdEtijUrrSB3DSnlTHtgDIG7dih6jUy5ef/FADW5dhvfN40nuVzwbkhk2Zb6VUe2f38TNPyFbW4cf+40LjxwibeqHRZ/0lFnoWrW7adJ9B+vm2A=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.8; Wed, 10 Apr 2019 14:39:53 +0000
Received: from ([fe80::a832:85f:a8bb:73b9]) by ([fe80::a832:85f:a8bb:73b9%5]) with mapi id 15.20.1792.007; Wed, 10 Apr 2019 14:39:53 +0000
From: Christer Holmberg <>
To: Benjamin Kaduk <>, The IESG <>
CC: "" <>, "" <>, "" <>
Thread-Topic: [clue] Benjamin Kaduk's No Objection on draft-ietf-clue-datachannel-15: (with COMMENT)
Thread-Index: AQHU76gXiqt5eDMzgUOQSMMSj80NOaY1qX0A
Date: Wed, 10 Apr 2019 14:39:53 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: dfb9944a-4a23-440e-22f1-08d6bdc264e1
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR07MB4169;
x-ms-traffictypediagnostic: HE1PR07MB4169:
x-microsoft-antispam-prvs: <>
x-forefront-prvs: 00032065B2
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(136003)(376002)(366004)(39860400002)(396003)(189003)(199004)(51444003)(305945005)(478600001)(7736002)(71190400001)(71200400001)(44832011)(76176011)(486006)(5660300002)(6246003)(6436002)(229853002)(36756003)(6486002)(2171002)(82746002)(25786009)(53936002)(86362001)(4326008)(6512007)(68736007)(14454004)(99286004)(97736004)(8936002)(316002)(110136005)(81166006)(58126008)(8676002)(54906003)(14444005)(256004)(81156014)(33656002)(6506007)(102836004)(105586002)(2906002)(186003)(3846002)(6116002)(66066001)(106356001)(26005)(476003)(83716004)(11346002)(446003)(2616005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4169;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: DsfDcckPuN+ejAKAkJdielIpfZjDxN6P/VDCW2Lex96IhLSuO8ahNQsf7s0S0LiEV0R3rorDIuAV9KL4MyjBsoGtJ4d5sykdPIhpuh7I46YmWDbpVQ2msUvTPaUoAEMdxbQQXaTt2MIsVRtlTiDuJBBatPjC8LtY0hLOLcrpJO2VoKMa4m3boqxitvriF+EQvY7CxtMyiIMQZqT0B0fUMFShhuD1aTOIslw0Y1Y/8xu5s26t3bwILDfnp1Pe/2T8xlvZJRW2Ycz2A/eorGDR+gK31y9DvrU/pSiMclH0IIjyMZQdHuuR5uGCghCAmhCGd4MJ7vsomaJtfW79AiLdaqbo6BKasQCI9wRAcbQl7THxATTOhwoVS41HhbNgoSbM945RIW5j0h4wJf/ERNk7GPicap9Nw9nlfKsLmu6ex6k=
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: dfb9944a-4a23-440e-22f1-08d6bdc264e1
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Apr 2019 14:39:53.1423 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4169
Archived-At: <>
Subject: Re: [clue] Benjamin Kaduk's No Objection on draft-ietf-clue-datachannel-15: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: CLUE - ControLling mUltiple streams for TElepresence <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 10 Apr 2019 14:39:59 -0000

Hi Benjamin,

Thank you for the review! Please see inline!

Section 1
>This includes SCTP
>considerations specific to a CLUE data channel, the SDP Media
>Description (m- line) values, and usage of SDP attributes specific to
>a CLUE data channel.
>nit: "m= line"
There is no rule on how to write it. Sometimes m- lines is used.

But, I can change to "m=" line, as that's what is used in 4566bis.

Section 2
>Please use the RFC 8174 boilerplate.

Will fix.


Section 3.1
>the WebRTC data channel mechanism.  This includes a set of SCTP
>characteristics specific to a CLUE data channel, the values of the m-
>line describing the SCTPoDTLS association associated with the WebRTC
>nit: "m= line"?
See comment on Section 1.

Section 3.2.7
>As described in [I-D.ietf-rtcweb-data-protocol], in order to close a
>data channel, an entity sends an SCTP reset message [RFC6525] on its
>This reference would normally make draft-ietf-rtcweb-data-protocol a
>normative reference, but I think that perhaps the intended reference is
>actually draft-ietf-rtcweb-data-channel (which is already a normative
>reference).  In particular, Section 6.7 of the latter document is about
>"Closing a Data Channel" and mentions resetting the streams.

Correct. I will change the reference to draft-ietf-rtcweb-data-channel.

Section 3.3.2
>The values of the SDP dcmap attribute
>[I-D.ietf-mmusic-data-channel-sdpneg], associated with the m- line
>nit: "m= line"?

See comment on Section 1.

Section 5.1
>I note that the WebSocket Subprotocol Name Registry has the "first come,
>first served" registration policy, which makes a declarative statement like
>this ("this document adds") a bit risky -- what if someone else swoops in
>to register this name?
Well, IF that would happen, we would have to deal with it, and there is nothing we can do in the draft to prevent that. I don't think this draft should update the registry policy.

Also, the risk applies to any draft registering new values, and if it becomes a problem I guess someone will have to look into it.