Re: [rtcweb] Last Call: <draft-ietf-rtcweb-data-channel-12.txt> (WebRTC Data Channels) to Proposed Standard

["Wyss, Felix" <[e-mail]>]

> I had a suspicion that this was the intended use-case - and it's a real use-case
> for certain applications/industries.
> 
> So, for those applications (remembering that webrtc applications are not
> random external devices, but basically code linked to the usage) just either
> use pre-defined or external negotiation for channel assignments, or
> implement *in the application* allocation-choosing strategy.  Such as:
> 
> middlebox: offer to A and B (actpass)
> A: accept (active)
> B: accept (active)
> ok, now both are on the same "evenness"
> both statically open (pre-defined) channel 0 always Both send a random
> token value The side with the lower random value is even, and the other is
> odd All channel allocations are preceeded by message on channel 0 that
> amounts to an "I'm opening channel N with these params" that takes the
> place of DCEP Encapsulate this behavior in some simple functions that take
> the place of the default createDataChannel()/etc
> 
> There are other solutions of course for glare resolution.  If you want, if the
> two sides chose the opposite evenness, you just leave createDataChannel
> alone.  There are a LOT of ways to deal with this at the application level, since
> the application "should" know it's talking to (or may be talking to) a
> middlebox that will decrypt/forward things.

My discomfort and objection is with using the DTLS roles--even if it's just as default.  Why can't we either leave it up to the application to allocate the IDs, suggest some "best practice" approaches, or codify one as the preferred?  I don't feel strongly either way.  All I care about here is that we don't use the DTLS role for anything related to DCEP.  DTLS should just be an opaque transport for the endpoints' SCTP packets.  If we leave the DTLS role as default in the RFC, middleboxes have to worry about it because it's part of the standard.  It doesn't matter that the application _can_ use other means.   If it's in the RFC, it is part of an implied interface contract and 3rd party developers and system integrators will expect it to be supported and work as specified.  

Thanks,
--Felix