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

[Eric Rescorla <[e-mail]>]

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
>