[AVTCORE] Review of draft-ietf-avtcore-rfc5764-mux-fixes-02

[Magnus Westerlund <[e-mail]>]

Hi,

I did a review of draft-ietf-avtcore-rfc5764-mux-fixes-02 and have some 
comments:

A. Abstract:

It overrides the guidance from SRTP
    Extension for DTLS [RFC5764], which suffered from three issues
    described and fixed in this document.

There are four issues listed in Section 1.

B. Section 1, bullet 1 and 2:

"It implicitly allocated codepoints ..."

I am not particular happy about this formulation as it is only part of 
the truth. I think the authors should try to write a separate paragraph 
about the issue of overlapping value ranges, and the need to maintain 
the separated for any usage where multiplexing could occur. Thus this 
leading to an limitation of the usage of codepoints in the STUN/TURN as 
well as TLS protocol.

C. Section 1, bullet 4:

The current ranges are not efficiently allocated making it harder
        to introduce new protocols that might require multiplexing.

I am not quite certain what this bullet tries to really say. What is 
allocated in ranges, is the ranges available for registration that 
doesn't reserve space for future protocols, or something else?

D. Section 1:

    These flaws in the demultiplexing scheme were unavoidably inherited
    by other documents, such as [RFC7345] and
    [I-D.ietf-mmusic-sdp-bundle-negotiation].  These will need to be
    corrected with the updates this document provides.

It is unclear what the second "These" refers to, I guess "flaws" not the 
documents.

E. Section 1.1:

Also here I think the document could benefit from a more analytic and 
less confrontational language. It is better to write that "Multiplexing 
limits the available range for new STUN methods." than "... entirely 
obliterating those STUN method codepoints".

F. Section 1.2:

I want to remind the authors that this document will go to TLS WG during 
WG last call, and would recommend that one avoids to dictate to that WG 
how their situation are:

"Unlike STUN, TLS is a
    mature protocol that is already well established and widely
    implemented and thus we expect only relatively few new codepoints to
    be assigned in the future."

Considering the quite significant work ongoing on TLS, I think you might 
be wrong in this analysis.

Focus on the facts and the goal here. I think the goal is to avoid 
having future assignment of functions cause failure in the multiplexing 
scheme.

G. Section 1.

I am missing a clearer description of the long term goal with this 
update. To my understanding it is to avoid future allocation in any of 
the affected protocols to result in that multiplexing becomes impossible 
when using that feature.

A second goal appear to enable the possibility that additional protocols 
should be able to be given a range for them to multiplex. I think this 
second one can result in more discussion, as there are multiple people 
that express a preference for more explicit demultiplexing.

In addition I think the method for achieving these goals should be made 
more clear. That is to make it clear in the IANA registries which values 
that are subject to risks for collisions and where coordination between 
protocols may be required. That is at least what I thought was the 
conclusion of the Dallas meeting.

H. Section 1.2:
    0-19    Reserved (MUST be allocated with Standards Action)

As I EKR commented, as these values anyway require Standards action this 
is meaningless. I think something more like (Requires coordination, see 
RFCXXXX). Where RFCXXXX is this document would be more acceptable and 
also much more informative.

This relates to what I see as the need for this document to much better 
explanation of the goals and future considerations needed to avoid 
failure in allocations.

I. Section 1.3:

    An implementation that uses the source IP address and port to
    identify TURN channel messages MAY not need to restrict the channel
    numbers to the above range.

I think we need to have discussion about this. I personally think it 
makes much more sense to not limit the other protocols due to TURN, as 
an TURN client MUST know which address the TURN server uses. Thus 
limiting TURN channel demultiplexing based on source address appears 
trivial.

If I misunderstanding this, then I think this section must before giving 
any recommendation make it clear why src address is not sufficent and we 
actually want to consume part of the value space for this?

Note, I do think it is valuable to discuss TURN channels here, but I 
think it needs to reconsider what the message should be.

J. Section 1.4:

This is insufficient to explain any issues why the order of testing do 
matters?

K. Section 3:

  When
    new values or ranges are added, they MUST be tested in ascending
    order.

I am missing the text that makes it clear how one would go about to add 
allocate a new value or range when proposing to add a new protocol.

L. Section 5.

It doesn't simply update existing registries. It does currently 
specifies that TURN channels can be demultiplexed. Are there 
implications of that?

M. Section 6:

I think all the "Reserved" messages are the wrong ones. I think they 
should say "Reserved (DTLS-SRTP multiplexing collision avoidance, see 
RFC XXXX)

N. Section 6.1:

I think this needs to be more explicit about what it re-assigns. It 
needs to say that the values available for allocation i.e. 0-FFF are 
being changed to instead have the following ranges.

Then I think a resulting table for the ranges would be good.


Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------