Re: [rtcweb] revisiting MTI

[Adam Roach <[e-mail]>]

On 12/15/14 16:24, Peter Saint-Andre - &yet wrote:
> On 12/15/14, 3:22 PM, Adam Roach wrote:
>> On 12/15/14 16:18, Peter Saint-Andre - &yet wrote:
>>> Some folks have expressed a concern that whatever we choose as an MTI
>>> codec now must always be an MTI codec. I'm trying to allay that
>>> concern by saying that yes, indeed, we can change our MTI codec(s) in
>>> the future if we please (naturally, keeping interoperability in mind
>>> at that future time).
>>
>> I agree 100%, but I don't think we need to get consensus on what this
>> effort might look like 10 years in the future. Let's leave tomorrow's
>> battles for tomorrow, or we'll never make progress.
>
> Yes, that's why I'm now saying to leave out all future-oriented text.

I take the point, but there is one key future-looking component of the 
current accord. Leaving it undocumented basically violates the agreement 
that many people have signed up for. As I pointed out in a previous 
message, this particular little wart is necessary [1], even if untidy.

Which basically points to a need to document this intention (which, as 
Sean pointed out, has a non-trivial body of precedent), and to hold the 
line against documenting any further intended decision trees.

I suppose we could, without harm, document obvious points of IETF 
process like "RFCs can be obsoleted by other RFCs, and those new RFCs 
can say anything that the IETF comes to consensus around," but I doubt 
it's useful to do so, and it seems somewhat outside the purview of this 
WG to do so anyway.

/a

____
[1] To put a finer point on the necessity I mention here: in the straw 
poll last year, this option *without* the forward-looking provision 
received a mere 9% of participants supporting it, with 53% actively 
opposing it. The forward-looking provision is basically the "special 
sauce" that makes this approach palatable for some significant number of 
WG participants.