Re: [TLS] [MMUSIC] Confirmation call on draft-ietf-avtcore-rfc5764-mux-fixes-09

Magnus Westerlund <> Tue, 28 June 2016 14:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 240B912D1A6; Tue, 28 Jun 2016 07:35:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IC2OEfy-XCii; Tue, 28 Jun 2016 07:35:10 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 01E4D12D1B9; Tue, 28 Jun 2016 07:35:08 -0700 (PDT)
X-AuditID: c1b4fb3a-f79386d00000467b-73-57728b1a87e4
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id E9.6B.18043.A1B82775; Tue, 28 Jun 2016 16:35:06 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id; Tue, 28 Jun 2016 16:35:06 +0200
To: IETF AVTCore WG <>, "" <>,, "" <>, "mmusic (E-mail)" <>, "" <>
References: <>
From: Magnus Westerlund <>
Message-ID: <>
Date: Tue, 28 Jun 2016 16:35:04 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUyM2K7oq5Ud1G4waPthhYve1ayWxz4OJXZ 4tuFWoupyx+zWHw638Vo8WHtBTYHNo8lS34yBTBGcdmkpOZklqUW6dslcGVsWbuTveCdRMWK td2MDYwPhLsYOTkkBEwkPszYzgphi0lcuLeeDcQWEjjCKPFpXX0XIxeQvZxR4s3VtcxdjBwc wgIhEsf3J4HERQT+MUp83HiTBaLBXuLXzkZmEJtNwELi5o9GsEG8QPETb74zgvSyCKhK3Pge CxIWFYiRaLx9mB2iRFDi5MwnYGM4BRwkjv/cwAJSzgzU+mBrGUiYWUBeonnrbGaITdoSDU0d rBMYBWYh6Z6F0DELSccCRuZVjKLFqcXFuelGRnqpRZnJxcX5eXp5qSWbGIHBenDLb6sdjAef Ox5iFOBgVOLhfbCwMFyINbGsuDL3EKMEB7OSCK9nV1G4EG9KYmVValF+fFFpTmrxIUZpDhYl cV7/l4rhQgLpiSWp2ampBalFMFkmDk6pBsYIVu65q/fbrOl8Y5aWzliVlNs27diE1suTYqw5 n0zP+im5f/U6tSjjCPZzWrNSDLYF9R32nda0ojqsYNvfCbN5VxQd31Gqlm7WYG948ZHo2Udz X4gcVwpbn+A7u+Lk829sTheLGT7ZRgTn6qUxfVrtEsq9um6Ly13Vd49EpxtmOXi5HGqY7q/E UpyRaKjFXFScCADk8d++UgIAAA==
Archived-At: <>
Subject: Re: [TLS] [MMUSIC] Confirmation call on draft-ietf-avtcore-rfc5764-mux-fixes-09
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 28 Jun 2016 14:35:12 -0000

Authors and WGs,

In my review for the publication writeup I did spot some issues in the 
draft. Please consider the following issues:

1. Abstract: With the addition of the ZRTP the abstract should benefit 
from being updated. The ZRTP protocol being possible to multiplex is 
missing as well as that there are now 4 issues.

2. Abstract contains [ref] to RFC 5764. This is an ID nit.

3. Section 1. The introduction is not explicitly saying that it updates 
RFC 5764. I think that can be put as a sentence after:

    This is achieved by
    modifying the IANA registries with instructions for coordination
    between the protocols at risk.

4. Reference ID-nits:

   == Outdated reference: A later version (-31) exists of

5. Section 2:

ID-nits complains about the modified boilerplate for the RFC2119 text. 
First of all one usually don't cut down the list to only the used ones. 
The requirement on all caps ones I am very divided about. I do have a 
preference for unmodified boilerplate, this as I otherwise have to 
explain in the write-up the ID-nit.

6. Section 6:

    In order to prevent future documents from assigning values from the
    unused range to a new protocol, this document modifies the RFC 5764
    demultiplexing algorithm to properly account for TURN channels by
    allocating the values from 64 to 79 for this purpose.

I think this text fails to be explicit about that this restricts the 
TURN Channel space to a more limited set of possible channels when the 
TURN client does the channel binding request. Thus affecting the TURN 
channel allocation algorithm in the client implementations, at least 
when used in combination of muxing.

Based on this and the fact that this specification changes the IANA 
registrations performed by RFC5766, I think this document to have 
"Updates" for RFC5766 also. So please add that in header, abstract and 

7. Updates RFC5389:

Looking at the impact also on the STUN protocol I would also think that 
this requires and "Updates" also for RFC 5389.

8. Section 10.3:

The IANA registry name is not the correct one. The IANA page says that 
the registry name is:

Traversal Using Relays around NAT (TURN) Channel Numbers

Please update.

9. Section 12.2:

The reference to ZRTP [RFC6189] is likely in the wrong category, at the 
same time moving this to a normative one creates a downref. I guess it 
one that has to be accepted in this case. I suggest that you move it to 
the normative references.


Magnus Westerlund

Services, Media and Network features, Ericsson Research EAB/TXM
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: