Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-4572-update-07.txt

From: Cullen Jennings <[email-masked]>
Date: Thu, 6 Oct 2016 15:39:20 -0600

It would be easy to rewrite it to not change it but simply clarify that multiple fingerprints are allowed and provide advice about additional ones to provide. 

> On Sep 30, 2016, at 11:39 AM, Cullen Jennings (fluffy) <[email-masked]> wrote:
> 
> 
> So I still disagree that this should update 4572 and the text for the interoperability issue if significantly different than what many people proposed on list. Can we arrange a phone call to discuss this. 
> 
> 
> 
>> On Sep 25, 2016, at 7:53 AM, [email-masked] wrote:
>> 
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the Multiparty Multimedia Session Control of the IETF.
>> 
>>       Title           : SDP Fingerprint Attribute Usage Clarifications
>>       Author          : Christer Holmberg
>> 	Filename        : draft-ietf-mmusic-4572-update-07.txt
>> 	Pages           : 8
>> 	Date            : 2016-09-25
>> 
>> Abstract:
>>  This document updates RFC 4572 by clarifying the usage of multiple
>>  SDP 'fingerprint' attributes with a single SDP media description ("m=
>>  line").  The document also updates the preferred cipher suite with a
>>  stronger cipher suite.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-mmusic-4572-update/
>> 
>> There's also a htmlized version available at:
>> https://tools.ietf.org/html/draft-ietf-mmusic-4572-update-07
>> 
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-4572-update-07
>> 
>> 
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>> _______________________________________________
>> I-D-Announce mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 7 Oct 2016 09:49:09 +0000

Hi,

First, being this late in the process, I think it would be fair to explain
(I would have expected the chairs to request the same) what the problem
is. We HAVE added the note saying that the draft does NOT make existing
4572 implementations non-compliant. What else is missing?

Second, IMO the draft says a little more than ³multiple fingerprints are
allowed². It also specifies HOW multiple fingerprints are used, HOW they
must be matched etc - using RFC 2119 terminology (there is a number of
MUSTs). Do we consider that ³advice²? Or, do you want to REMOVE that?

Last, if we don¹t indicate the draft as a ³4572 update², people will not
automatically be made aware of it when looking for 4572, as it will not be
listed as an 4572 update. Is that a good thing?

Regards,

Christer

On 07/10/16 00:39, "mmusic on behalf of Cullen Jennings"
<[email-masked] on behalf of [email-masked]> wrote:

>
>It would be easy to rewrite it to not change it but simply clarify that
>multiple fingerprints are allowed and provide advice about additional
>ones to provide. 
>
>
>> So I still disagree that this should update 4572 and the text for the
>>interoperability issue if significantly different than what many people
>>proposed on list. Can we arrange a phone call to discuss this.
>> 
>> 
>>

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 7 Oct 2016 16:42:41 -0700

There are lots of people using 4572 and there is nothing wrong with it. What is proposed in this draft is also fine and it if was RFCAAAA that is fine. But telling people doing 4572 that they have to do AAAA is not OK. You make not think that is what update means but it is what I and many others think update means. Given this disagreement on what update means, I don't want to use update. 

I'd be happy to write an alternative draft that does not need to be an update if that is the issue but I plan to get JSEP ready first. 

> On Oct 7, 2016, at 2:49 AM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
>

---

From: Roman Shpount <[email-masked]>
Date: Fri, 7 Oct 2016 20:03:01 -0400

Cullen,

Can you answer a fundamental question related to 4572: Does it allow
multiple fingerprint attributes per one m- line or not? Can you point to
the exact language in the RFC which says that?

There are people (including the authors of RFC 4572) which gave
contradictory answers to this question. Because of these contradictory
answers, you can create two implementations which claim to be compatible
with 4572 but incompatible with each other. For instance Firefox will fail
to establish a connection if multiple fingerprints per m- line are
provided. So, I would say, we definitely need a document update to resolve
this ambiguity.

Regards,
_____________
Roman Shpount

On Fri, Oct 7, 2016 at 7:42 PM, Cullen Jennings <[email-masked]> wrote:

>
> There are lots of people using 4572 and there is nothing wrong with it.
> What is proposed in this draft is also fine and it if was RFCAAAA that is
> fine. But telling people doing 4572 that they have to do AAAA is not OK.
> You make not think that is what update means but it is what I and many
> others think update means. Given this disagreement on what update means, I
> don't want to use update.
>
> I'd be happy to write an alternative draft that does not need to be an
> update if that is the issue but I plan to get JSEP ready first.
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 8 Oct 2016 12:01:47 -0400

Cullen,

> There are lots of people using 4572 and there is nothing wrong with it. What is proposed in this draft is also fine and it if was RFCAAAA that is fine. But telling people doing 4572 that they have…

I know you were following the wgchairs thread on '"Updates: RFC xxx" - 
what does it actually mean ?' because you replied in that thread. If you 
agree with the conclusion there then I don't see how you can conclude 
that people implementing a base draft MUST implement a "updates" draft.

	Thanks,
	Paul

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 8 Oct 2016 10:19:09 -0700

I am one of the people that believes they are allowed by 4572 because SDP explicitly allows multiple copies of a= extensions and this defines an a= extension. I believe SDP explicitly says that. However, I agree with your point that is not clear. As I have said in the past, I am fine with an update that clarifies this point.

I am not fine with an update that changes what ciphers are needed. I am fine with an extention, not update, that mandates the SHA 256 and people that want to implement that can but people that do not can still do 4572. 

> On Oct 7, 2016, at 5:03 PM, Roman Shpount <[email-masked]> wrote:
> 
> Cullen,
> 
> Can you answer a fundamental question related to 4572: Does it allow multiple fingerprint attributes per one m- line or not? Can you point to the exact language in the RFC which says that?
> 
> There are people (including the authors of RFC 4572) which gave contradictory answers to this question. Because of these contradictory answers, you can create two implementations which claim to be compatible with 4572 but incompatible with each other. For instance Firefox will fail to establish a connection if multiple fingerprints per m- line are provided. So, I would say, we definitely need a document update to resolve this ambiguity.
> 
> Regards,
> _____________
> Roman Shpount
> 
> On Fri, Oct 7, 2016 at 7:42 PM, Cullen Jennings <[email-masked] <mailto:[email-masked]>> wrote:
> 
> > On Oct 7, 2016, at 2:49 AM, Christer Holmberg <[email-masked] <mailto:[email-masked]>> wrote:
> >
> > Hi,
> >
> > <[email-masked] <mailto:[email-masked]> on behalf of [email-masked] <mailto:[email-masked]>> wrote:
> >
> >>
> >>> On Sep 30, 2016, at 11:39 AM, Cullen Jennings (fluffy)
> >>> <[email-masked] <mailto:[email-masked]>> wrote:
> >>>
> >>>
> >>>> On Sep 25, 2016, at 7:53 AM, [email-masked] <mailto:[email-masked]> wrote:
> >>>>
> >>>>
> >>>> https://datatracker.ietf.org/doc/draft-ietf-mmusic-4572-update/ <https://datatracker.ietf.org/doc/draft-ietf-mmusic-4572-update/>
> >>>>
> >>>> https://tools.ietf.org/html/draft-ietf-mmusic-4572-update-07 <https://tools.ietf.org/html/draft-ietf-mmusic-4572-update-07>
> >>>>
> >>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-4572-update-07 <https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-4572-update-07>
> >>>>
> >>>>
> >>>> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
> >>>>
> >>>> ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
> >>>>
> >>>> [email-masked] <mailto:[email-masked]>
> >>>> https://www.ietf.org/mailman/listinfo/i-d-announce <https://www.ietf.org/mailman/listinfo/i-d-announce>
> >>>> Internet-Draft directories: http://www.ietf.org/shadow.html <http://www.ietf.org/shadow.html>
> >>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt <ftp://ftp.ietf.org/ietf/1shadow-sites.txt>
> >>>
> >>> [email-masked] <mailto:[email-masked]>
> >>> https://www.ietf.org/mailman/listinfo/mmusic <https://www.ietf.org/mailman/listinfo/mmusic>
> >>
> >> [email-masked] <mailto:[email-masked]>
> >> https://www.ietf.org/mailman/listinfo/mmusic <https://www.ietf.org/mailman/listinfo/mmusic>
> >
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/mmusic <https://www.ietf.org/mailman/listinfo/mmusic>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/mmusic <https://www.ietf.org/mailman/listinfo/mmusic>
>

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 8 Oct 2016 18:33:28 +0000

Hi,

Would you be ok with the draft if we removed the cipher change?

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Cullen Jennings<mailto:[email-masked]>
Sent: ‎08/‎10/‎2016 20:19
To: Roman Shpount<mailto:[email-masked]>
Cc: mmusic<mailto:[email-masked]>; Christer Holmberg<mailto:[email-masked]>
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-4572-update-07.txt

On Oct 7, 2016, at 5:03 PM, Roman Shpount <[email-masked]<mailto:[email-masked]>> wrote:

Cullen,

Regards,
_____________
Roman Shpount

On Fri, Oct 7, 2016 at 7:42 PM, Cullen Jennings <[email-masked]<mailto:[email-masked]>> wrote:

> On Oct 7, 2016, at 2:49 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
>
> Hi,
>
> <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:
>
>>
>>> <[email-masked]<mailto:[email-masked]>> wrote:
>>>
>>>
>>>> On Sep 25, 2016, at 7:53 AM, [email-masked]<mailto:[email-masked]> wrote:
>>>>
>>>>
>>>> until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org/>.
>>>>
>>>> [email-masked]<mailto:[email-masked]>
>>> [email-masked]<mailto:[email-masked]>
>> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 8 Oct 2016 11:42:34 -0700

> On Oct 8, 2016, at 9:01 AM, Paul Kyzivat <[email-masked]> wrote:
> 
> 
> I know you were following the wgchairs thread on '"Updates: RFC xxx" - what does it actually mean ?' because you replied in that thread. If you agree with the conclusion there th

The conclusion of that thread - after it expanded beyond the chairs list - was AFAIC, that this was unclear and someone should write a RFC to clarify it. If you think there was consensus on what update means, then I strongly agree and invite you to go look at number of people that put out position on each side. Until a new RFC gets issues, I will use the meaning in the only published RFC that defined this even though it was deprecated by a later RFC that did not provide any definition one way or the other.  

And to be clear, what I am proposing here is a simple way for this WG to move forward without having to resolve that debate or wait for consensus on what update means.

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 8 Oct 2016 11:45:15 -0700

or split the change to clarify multiple fingerprints in a a draft that was and update and then published something along the lines of this draft that added the requirement for SHA 256. I'm not at all against requiring SHA 256 for WebRTC or other things, I'm against requiring that for things that do 4572. 

> On Oct 8, 2016, at 11:33 AM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 
> From: Cullen Jennings <mailto:[email-masked]>
> To: Roman Shpount <mailto:[email-masked]>
> Cc: mmusic <mailto:[email-masked]>; Christer Holmberg <mailto:[email-masked]>
>> On Oct 7, 2016, at 5:03 PM, Roman Shpount <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Cullen,
>>

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 8 Oct 2016 19:30:47 +0000

Hi,

I think the clarification of multiple fingerprints is the most time critical (it's also the reason we wrote the draft to begin with), so I'd prefer to remove the cipher update and move the draft forward.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Cullen Jennings<mailto:[email-masked]>
Sent: ‎08/‎10/‎2016 21:45
To: Christer Holmberg<mailto:[email-masked]>
Cc: Roman Shpount<mailto:[email-masked]>; mmusic<mailto:[email-masked]>
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-4572-update-07.txt

On Oct 8, 2016, at 11:33 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Regards,

Christer

Cullen,

Regards,
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 8 Oct 2016 16:20:27 -0400

On 10/8/16 2:42 PM, Cullen Jennings wrote:
>
>> On Oct 8, 2016, at 9:01 AM, Paul Kyzivat <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>
>> what does it actually mean ?' because you replied in that thread. If
>> you agree with the conclusion there th
>
> The conclusion of that thread - after it expanded beyond the chairs list
> - was AFAIC, that this was unclear and someone should write a RFC to
> clarify it. If you think there was consensus on what update means, then
> I strongly agree and invite you to go look at number of people that put
> out position on each side. Until a new RFC gets issues, I will use the
> meaning in the only published RFC that defined this even though it was
> deprecated by a later RFC that did not provide any definition one way or
> the other.

My understanding was that it is unclear and people were happy to leave 
it unclear. Instead of clarifying it, individual drafts are expected to 
add prominent text that explains what it means in the context of that draft.

I don't *like* that conclusion, but I don't consider it worthwhile to 
pursue it further.

> And to be clear, what I am proposing here is a simple way for this WG to
> move forward without having to resolve that debate or wait for consensus
> on what update means.

If splitting this into two drafts will satisfy you, then I'm ok with that.

But it also seems like it ought to be adequate to leave it one document, 
with Updates, and a clear statement of what Updates does and doesn't 
mean in this case.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 9 Oct 2016 08:47:13 +0000

Hi,

>>> I know you were following the wgchairs thread on '"Updates: RFC xxx" 
>>> - what does it actually mean ?' because you replied in that thread. 
>>> If you agree with the conclusion there th
>>
>> clarify it. If you think there was consensus on what update means, 
>> then I strongly agree and invite you to go look at number of people 
>> that put out position on each side. Until a new RFC gets issues, I 
>> will use the meaning in the only published RFC that defined this even 
>> though it was deprecated by a later RFC that did not provide any 
>> definition one way or the other.
>
> My understanding was that it is unclear and people were happy to leave it unclear. Instead
> of clarifying it, individual drafts are expected to add prominent text that explains what it 
> means in the context of that draft.

...which is exactly what we have done in the latest version of draft-4572-update.

But, again, if that's enough, I'm personally ok to remove the cipher update.

> I don't *like* that conclusion, but I don't consider it worthwhile to pursue it further.
>
>> And to be clear, what I am proposing here is a simple way for this WG 
>> to move forward without having to resolve that debate or wait for 
>> consensus on what update means.
>
> But it also seems like it ought to be adequate to leave it one document, with Updates, and a clear statement of what Updates does and doesn't mean in this case.

In my opinion, the most time critical is to get the multiple fingerprint clarification done, so I'll start working on a pull request that removes all the SHA-256 stuff.

I do think it's sad that issues like this are raised in the last minute - especially by people that for sure have been aware of the work - e.g., when others have spent lots of time in order to come up with agreeable text. But, at the end of the day what matters is to finalize the work...

Regards,

Christer