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

[Roman Shpount <[e-mail]>]

Hi All,

Any reasonable time US Eastern works for me.

_____________
Roman Shpount

On Tue, Oct 25, 2016 at 1:07 AM, Eric Rescorla <[e-mail]> wrote:

> I am in Australia this week so next week would be easier. Otherwise,
> please make it late Pacific time so that it's not too early.
>
> -Ekr
>
>
> On Tue, Oct 25, 2016 at 3:33 PM, Christer Holmberg <
> [e-mail]> wrote:
>
>> Hi Flemming,
>>
>> Any day but Monday works for me.
>>
>> Regards,
>>
>> Christer
>>
>> Sent from my iPhone
>>
>> > On 25 Oct 2016, at 7.01, Flemming Andreasen <[e-mail]> wrote:
>> >
>> > Hi Ben
>> >
>> > We will get a poll setup as soon as we understand any major constraints
>> from the key participants.
>> >
>> > Thanks
>> >
>> > -- Flemming
>> >
>> >
>> >> On 10/21/16 4:49 PM, Ben Campbell wrote:
>> >> 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
>> >>
>> >> .
>> >>
>> >
>>
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>
>