Re: [rtcweb] confirming sense of the room: mti codec

[Sean Turner <[e-mail]>]

On Dec 12, 2014, at 19:00, Iñaki Baz Castillo <[e-mail]> wrote:

> 2014-12-13 0:49 GMT+01:00 Peter Saint-Andre - &yet <[e-mail]>:
>> To promote the use of non-royalty bearing video codecs,
>>      participants in the RTCWEB working group, and any successor
>>      working groups in the IETF, intend to monitor the evolving
>>      licensing landscape as it pertains to the two mandatory-to-
>>      implement codecs.  If compelling evidence arises that one of the
>>      codecs is available for use on a royalty-free basis, the working
>>      group plans to revisit the question of which codecs are required
>>      for Non-Browsers, with the intention being that the royalty-free
>>      codec will remain mandatory to implement, and the other will
>>      become optional.
>> 
>>      These provisions apply to WebRTC Non-Browsers only.  There is no
>>      plan to revisit the codecs required for WebRTC Browsers.
> 
> Clear. H264 mandatory for browsers forever. Congrats patent holders.
> 
> BTW this is the first specification/standard/draft/RFC that states how
> future revisions of itself should behave. A clear lock-in IMHO.
> 

Just to be clear:  "No plan" does not mean that the requirement is immutable forever, just that we don't have a plan right now.  MTI requirements in IETF documents can always be updated, and they very frequently are.

In fact, coming from the security area the idea of an MTI for life is really odd to me.  MTI cipher suites get changed often enough that many security protocols don’t include the MTI algorithms in the base spec.  For ones that die hard they get the draft names like draft-ietf-krb-wg-des-die-die-die, which became RFC 6649, that deprecates the use of DES the original MTI in Kerberos 5.

On the flip side, there are plenty of RFCs that either hint at or specify future requirements (a non exhaustive list):
1) RFCs 4305/4835/7321, RFC 5750 and 5751 use MUST+/-, SHOULD+/-, etc. to telegraph what algorithms future versions are likely to support.
2) BGP-3/4(RFC 1163/4271) specify that future verions MUST retain the format of the OPEN and NOTIFICATION messages.
3) LDAP specifications (RFC 1487/1777) indicated new authentication mechanisms would be included.
4) Diameter (RFC 3588) says future versions may mandate that clients support SCTP.
5) DOCSIS (RFC 4131) says future versions are expected to support IPv6.
6) NETCONF over TLS (RFC 5539) applies to a particular version but says it applies to future versions as well and the later MTI cipher suite MUST be supported.
7) MRCPv2 (RFC6787) includes the following "If in the future voice biometric providers standardize on such a mechanism, then a future version of MRCP can mandate it.” 

Cheers,

spt