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

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

> When rethinking this, I've come to the conclusion that my original conclusion
> (that there couldn't possibly be a point in preserving channel numbers across
> a relay) was probably wrong. Please consider that withdrawn.

Thank you!


> I now see a tradeoff between allowing such non-mapping boxes (operating
> below the SCTP layer but above the DTLS layer in our model) and avoiding
> additional complexity (either extending DCEP with glare resolution -
> something it was designed to avoid needing - or requiring such boxes to not
> use actpass).
> 
> I agree that the DTLS hack is ugly. But glare resolution is ugly too.

Requiring middleboxes to assert a specific DTLS role instead of using actpass as offerer conflicts with RFC#5763.  That risks incompatibility with endpoints that assume they get the choice as answerer and blindly use active--or weren't tested by their vendor to be DTLS server as answerer and misbehave in other ways.  In our experience, interoperability is already challenging enough with how vendors interpret RFCs liberally and appear to use a "sunny weather" approach to test coverage.  End customers won't take "big vendor X doesn't implement an RFC correctly" as excuse why their system doesn't work properly or won't interoperate.  They paid a lot of money to have a working solution--which then requires hacks and workarounds to make it work somehow.  Abstraction leaks and unexpected dependencies greatly increases the risk of incorrect implementations and bugs.  

Speaking from an implementer's perspective, I thus strongly recommend against codification of conflicting requirements between RFCs and/or dubious dependencies across layers.  


--Felix