Re: [AVTCORE] Comments on draft-ietf-avtcore-rfc5764-mux-fixes-03.txt

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Sorry for the delay in processing this.  See answers inline.

On 10/20/2015 03:49 AM, Magnus Westerlund wrote:
> Hi,
> 
> I have looked at the updated draft. I think you have resolved my previous comments, thank you. However, I still have some comments.
> 
> 1. Split the introduction chapter. The introduction is much more than an introduction. I think the sub-sections likely belong in a new section after the introduction that discusses the issues and intended changes in depth. However, they are not introduction.
> 

Done.

> 2. Section 1.3:
> 
> I still are uncertain if TURN channels needs the whole range 64 to 79. I think the text should be explicit about how many turn channels this support. So according to my math the proposed change is from 64-127 to 64-79, i.e. the available number of channels has been reduced from 16384 to 4096. That still a large number of channels.
> 
> What number of channels are currently used by implementations? I expect that to be single digit, or am I missing some use cases?

We think these questions would be better answered by people implementing RFC 5764, so we left the range as is.  One can imagine an allocation scheme where higher channel numbers are used, without necessarily using many channels.  What you propose would negatively impact these implementations.  Until we hear from implementors, we would prefer to keep it as written.

> 
> 3.  Section 1.4:
> 
> I still don't see how what is written in this section results in any improvement. You authors have assumptions of how this needs to be implemented that isn't written down. Looking on this problem of demultiplexing I would build a table driven solution based on the ranges, where the packet is sent to the relevant protocol based on the table-lookup. If that protocol don't use that value, that will be the end of the road for that packet as invalid, rather than giving it to any other protocol. I get the impression that you want one to send the packet for testing by the protocols one after each other according to the order the protocols are listed. I still don't see that implementations will do that.

Based on the discussion with Paul Kyzivat and you, we decided to remove that section altogether.

With that, we believe that all pending issues are now resolved, which in our opinion makes the draft ready for WGLC.

> 
> Cheers
> 
> 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: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt
> 

- -- 
Marc Petit-Huguenin
Email: marc@petit-huguenin.org
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWp9bdAAoJECnERZXWan7EPVcP/0iXm8r4OVe9deIaELtuB/vs
12F2seMTOgVk0DBBoNipLS5MNrzRsDSbp+ORc/mBOFbyXjACDGBIx5q4Bz86+oJz
bbPg0bFXZxHlxMXZzK76iZ28fw7w2BfnKKs65lrV3ICzgZ1UvfFy5OuD1Kb78gqf
aWHdKTmKa8pLwGoTter2xfZ7XMyCG/PkEVnWVfvOSjHmUbIqovGjvClaohO4U8u+
jWfYbcZKaT5jeONkh7J9czWyIi4yGKangFrnbHUUEYMtzWoNXZQrEmOPiTTAg4Sj
Va281BqX8Dv4p+eXFtKtTVTztpjOupZJM6N+IyAB5Rp2gCwTWOf5k3ryEgYdWug+
9SPZBpwc77RtmapyNryFXayMjjOSBzG7/LsLArQWXBEX3+RHzs5OGKJjZyR81gdQ
ZHIqpGuOWrAEqQN9Ff3cfERZBZEpleO/iyXwkXMxSXDrX1dRnequ0Tb5nKS3CJZh
Xbhh1mogFIQUrSdL32tYn42abuZhgZZd8jAk/oTozyMQxW9AzGTGvyDlTnVj/c5D
w6+qXH0UW89eTyUaBO1ioUda9wdtie4mnp8NCOVMD6nQQaFEn5P9LJgeI+OYRajr
bDtOCaZssLFy8BA9+nsZ07uhsHW3lXJyPBW0NKgX1ZRFD+q4Hhk6dJMGcdAdSLhC
0CwjIw9eUzjnUX/VCc/w
=lyQb
-----END PGP SIGNATURE-----