Re: [clue] Tsvart telechat review of draft-ietf-clue-datachannel-15

Christer Holmberg <> Wed, 10 April 2019 18:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DAE3F120311; Wed, 10 Apr 2019 11:07:20 -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 UHpOl6ENhoAZ; Wed, 10 Apr 2019 11:07:18 -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 30D4412030E; Wed, 10 Apr 2019 11:07:18 -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=RrzztJo4bfEuy+8LDv6t2uOuhH1vH+t4J/2e3n23GeM=; b=ZKQ9U70T3XCOIciukPKOLOSjejb8n2As5hGl4YTQWlrEcR/5EttCpNRV9RiuPWw6SgKiZ539BZAnt8XunfkmS1ilFHFRQGExsXYyJ9EnSsommkN0k0en40zna0E8kYSc9Jo6MWEwpHmsUmIDBGcj5081Z8Q/Vo9hyhllf/cdsjU=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.11; Wed, 10 Apr 2019 18:07:15 +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 18:07:15 +0000
From: Christer Holmberg <>
To: Joerg Ott <>, "" <>
CC: "" <>, "" <>, "" <>
Thread-Topic: [clue] Tsvart telechat review of draft-ietf-clue-datachannel-15
Thread-Index: AQHU7GD2GnGei/nc50Wm2hUTJaNg66Y16fsA
Date: Wed, 10 Apr 2019 18:07:14 +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: 7881a135-1dd9-45e5-1471-08d6bddf5cb8
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR07MB3083;
x-ms-traffictypediagnostic: HE1PR07MB3083:
x-microsoft-antispam-prvs: <>
x-forefront-prvs: 00032065B2
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39860400002)(396003)(136003)(376002)(366004)(51444003)(199004)(189003)(446003)(476003)(2906002)(81166006)(6246003)(53936002)(6486002)(7736002)(8676002)(25786009)(33656002)(81156014)(11346002)(36756003)(486006)(106356001)(8936002)(2616005)(229853002)(105586002)(5660300002)(4326008)(44832011)(305945005)(2501003)(86362001)(97736004)(14454004)(54906003)(58126008)(83716004)(3846002)(478600001)(6116002)(316002)(110136005)(68736007)(71200400001)(6512007)(26005)(71190400001)(82746002)(76176011)(186003)(102836004)(6506007)(99286004)(256004)(66066001)(6436002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3083;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: eQPylytfnJh0Z4pzwET2XZnPuw8uxjd26OKptn9g6Kh+RzboO3GJdQZMKAqOlbDH7MPBTf4od56ymjIWRqISfufoYNyuNgbhvnUDaV+pWr1lG1fwUkNPExRYPDEMluCLKmzOHUfOd85p4bSan3oa2MR8igBm4PFHviyysIKkTEEnZze3Jh9h6v9I67aRvWOwBYPbNyzjLCjBL4D+SitgaDMCjw/dsXozLdoAbIKp6YV457cB/hZxMi4UbYt06/fhHb0+3xnmXCEypBTFO88g6dh8BZjOmGiHKooUY2sORIO8sLm51hKbX67h+TFznSbbDW915Jqt2HG11d/gGXhzhLdvVA1B6RQQs61V1AAnQ1+AQVKK8Kjry+oWCU3SXGldDDEbz7U3Y50ykmg+XHHJpYGNWAfavLV9koEi0ZQCAKk=
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 7881a135-1dd9-45e5-1471-08d6bddf5cb8
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Apr 2019 18:07:14.8997 (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: HE1PR07MB3083
Archived-At: <>
Subject: Re: [clue] Tsvart telechat review of draft-ietf-clue-datachannel-15
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 18:07:21 -0000

Hi Joerg,

Thank You for the comments! Please see inline.
>    Reviewing this document for tsv-art, I don't see any any transport-specific
>    issues in the document, but a bunch of other (smaller) issues and nits came up.
>    I am not sure that that the reference to a "SIP User Agent" as an entity is
>    strictly correct here. SIP User Agents are defined in RFC 3261 to carry out
>    SIP transactions. Just speaking about "User Agents" may be more accurate.
>    But this is just a side note.

I think it is good to have "SIP" there for clarity.

>    Section 3.2.3 defines behaviour in a negative way, i.e., via MUST NOT
>    statements, excluding all but one possibility. This could be problematic in
>    the future if another option gets added to SCTP usage, which would then
>    implicitly be allowed. It would be better if the behaviour was defined i
>     a positive way, i.e., using MUST.
In general I agree with you. But, in the case the base data channel spec mandates a set of SCTP extensions, and the text says that a couple of them must not be used for CLUE. I think that is the clearest way.

(And, if additional SCTP extensions are added to rtcweb-data-channel in the future, that could cause problems no matter if we use MUST or MUST NOT, depending on whether such extensions can be used with CLUE or not.)


>    Sect. 3.2.5, 2nd para: use "MUST" instead of "must" since this appears to
>    be normative, so RFC 2119 wording should be used.

The reason I use "must" is because the text is referencing requirements in another specification, i.e., the requirement is not defined or introduced by this draft. That is based on guidance I have received on earlier drafts.


>    Sect. 3.2.7, 1st para: this appears t be normative language and thus
>    should use the RFC 2119 keywords.

As for your comment on 3.2.5, the text is simply referencing requirements defined elsewhere.

>    Sect., table 1 + 2nd para after table 1: the text in the 2nd para
>    defines the value for the "application usage"; this should also be reflected
>    in table 1 since it seems that only one application usage is defined.
I don't know how I would get it into the table, as it is a generic description of an m- line for SCTP over DTLS.

I could of course copy/paste the table, indicate that it shows the m- line for CLUE, and replace "application usage" with "webrtc-datachannel". But, I am not sure that would make things more clear.

>    Sect. this again appears to be normative, so RFC 2119 language
>    should be used.
>    What does the sentence "A CLUE entity can choose any valid SCTP port
>    value." mean in this context?  Is a "valid SCTP port" value that of a
>    previously established SCTP connection within the context of the
>    SIP session? If such a match is desired it should be specified or a
>    reference to a peer document (draft-ietf-mmusic-sctp-sdp-26?) 
>    should be provided.
draft-ietf-mmusic-sctp-sdp specifies how the port is used, and the port range, so suggest adding a reference to draft-ietf-mmusic-sctp-sdp.


>    Sect. 3.3.2: NOTE statement: It is ok to have a note but this still is
>    somewhat normative. It should also be specified what happens if
>    the values _are_ set by the peer. What is the error handling?
>    Ignore? Reject the connection setup?
I guess we could allow two options: either discard the parameters, or reject the SDP and take proper actions to release the connection.

I am also ok "de-noting" the text.

>    Figure 1 is a nice example. But it would be even better if a complete
>    example with the SDP for the data channel setup (in the previous
>    or the same offer/answer exchange) be given. Makes life easier
>    for readers and implementers.
draft-ietf-clue-signaling contains more complete SDP examples, so I would suggest to add a reference there.



>    Don't just copy the first paragraph(s) from the introduction to create an abstract.

I will see if I can make the Abstract shorter.


>    3.2.2, 2nd para, 3rd line: "what" -> "which"
Will fix.


>    Sect. 3.3.1: the ref to the clue-signalling draft is missing a link (all other refs have one).
Not sure I understand. What do you mean by "missing a link"?

>    Fix the formatting of table 2 to avoid letter breaking from words.
Will do.