[MMUSIC] Moving Forward on 4572-update (was Re: Rough concensus: Re: 4572-update: Consensus call on how to move forward)

["Ben Campbell" <[e-mail]>]

Hi Everyone, please accept my apologies for waiting this long to weigh 
in.

I think it's clear that multiple people are not happy with how we got to 
this point. But assigning blame doesn't help us make progress on the 
draft. I propose that we get over that, and instead focus instead on how 
to move forward. Email discussion doesn't seem to be helping. Maybe a 
call will.

Flemming and/or Bo: Can you set up a Doodle poll to get Christer, 
Cullen, and other demonstratively  interested parties on a conference 
call? I will join if at all possible, but don't let scheduling around me 
stop a call from happening.

Thanks!

Ben.

On 21 Oct 2016, at 11:05, Flemming Andreasen wrote:

> [fixing cc-list]
>
> On 10/21/16 11:59 AM, Flemming Andreasen wrote:
>>
>>
>> On 10/21/16 11:21 AM, Cullen Jennings wrote:
>>> I think that is a bad way to run a WG. All I asked for was a phone 
>>> call to discuss this so we could get the issues on the table and 
>>> discuss what is best. The chairs never even replied to my request 
>>> for a WG call to discuss this.
>> That is simply not true. You (and Christer) were explicitly asked to 
>> setup a phone call on 10/6/16 to discuss this issue; a request that 
>> (like many other others) went unanswered or required extensive 
>> prodding to get any attention.
>>
>>> The list discussions that ensued from this resulted in people other 
>>> than me sugesting possibilities that were much better than any of 
>>> the three below -  none of which were considered in your consensus 
>>> call.
>> I'm not sure what those proposals are, nor were they brought up in 
>> response to the consensus call.
>>
>>> I don’t plan to appeal this but I am considering if it’s worth 
>>> my time to participate in this WG if we are not going to be willing 
>>> to actually spend a short time to discuss possible solutions before 
>>> taking a consensus call.  As input to that decisions, it would be 
>>> really useful to know why you refused to have a phone call on this 
>>> topic and what your policy in general is going to be toward 
>>> discussions of proposed solutions to problems in the future.
>> My position is that we will try our very best to get to not only 
>> consensus but to satisfy as many concerns as we possibly can. It does 
>> however require people to engage in a timely manner, and even when 
>> they don't, we still do what we can, but at some point we need to 
>> move forward. As for the issue at hand, it has been discussed 
>> extensively, and several changes were made to the draft to try and 
>> accommodate your requests.
>>
>> The one major remaining issue I believe you have is around whether 
>> this document updates RFC 4572. This has been discussed extensively 
>> on the wgchairs list; a discussion I initiated to try and help 
>> address your concern. You may disagree with how that discussion 
>> concluded, but again, to try and alleviate your concerns, a note was 
>> added to 4572-update to make it clear that the document does not make 
>> existing 4572 implementations non-compliant with RFC 4572.
>>
>> I believe the chairs, authors, and the WG at large has done 
>> everything that can reasonably be done to try and address your 
>> concerns, and at this point we need to move forward.
>>
>> Thanks
>>
>> -- Flemming (as MMUSIC co-chair)
>>
>>
>>
>>>
>>>> On Oct 19, 2016, at 6:43 AM, Flemming Andreasen 
>>>> <[e-mail]> wrote:
>>>>
>>>> Hi
>>>>
>>>> Following up on the consensus call, we have received 5 responses in 
>>>> favor of option a) below, one neutral, and one objection. Looking 
>>>> at the document we have noted that backwards compatibility is 
>>>> handled by the current text in the document and it also clearly 
>>>> states that it does not make current RFC 4572 implementation 
>>>> non-compliant with RFC 4572. Since we have not heard of any 
>>>> technical problems with proposal a), nor seen any tangible progress 
>>>> on how to address the objection, we are hereby declaring rough 
>>>> consensus on option a). We will proceed with the publication 
>>>> request for the current draft while duly noting the "roughness" of 
>>>> the consensus based on the pending objection as part of this.
>>>>
>>>> Thanks
>>>>
>>>>     Flemming & Bo (MMUSIC chairs)
>>>>
>>>>
>>>> On 10/12/16 6:23 PM, Flemming Andreasen wrote:
>>>>> Greetings
>>>>>
>>>>> There has been quite a bit of discussion on 
>>>>> draft-ietf-mmusic-4572-update (currently -07), which had 
>>>>> previously completed WGLC when a few concerns were raised. The 
>>>>> document currently:
>>>>> 1. Clarifies the usage of multiple SDP 'fingerprint' attributes
>>>>> 2. Updates the preferred cipher-suite with a stronger cipher suite
>>>>> 3. Updates RFC 4572.
>>>>>
>>>>> Item 1 seems to be generally agreeable, whereas items 2 and 3 are 
>>>>> not. The chairs are hereby soliciting WG feedback on how to 
>>>>> proceed based on the following choices:
>>>>>
>>>>> a) Proceed with publication of 4572-update-07 in its current form 
>>>>> (i.e. covering all 3 items above)
>>>>>
>>>>> b) Remove item 2 from 4572-update, i.e. do not update the 
>>>>> preferred cipher-suite
>>>>>
>>>>> c) Remove item 3 from 4572-update, i.e. do not indicate that this 
>>>>> document constitutes an update to RFC 4572.
>>>>>
>>>>>
>>>>> Note that choice a) is mutually exclusive with b) and c), but b) 
>>>>> and c) are not mutually exclusive.
>>>>>
>>>>> Please let us know your preference wrt to the above no later than 
>>>>> Friday October 14th.
>>>>>
>>>>>
>>>>> Thanks
>>>>>
>>>>>        Flemming & Bo (MMUSIC chairs)
>>>>>
>>>>> _______________________________________________
>>>>> mmusic mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>> .
>>>>>
>>>> _______________________________________________
>>>> mmusic mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>> .
>>>
>>
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic