Subject: [MMUSIC] 4572 moving forward

From: Cullen Jennings <[email-masked]>
Date: Tue, 1 Nov 2016 17:52:07 -0600

So Martin and I talked today about how to move forward on this. We think that we have a proposal that meets everyones requirements (you will groan when you hear but just ask yourself if you can live with it vs is it your favorite because we think everyone could live with this) 

We discussed two paths 1) split to two drafts, one with update for multiple fingerprints and separate extension that adds sha256. 2) just obsolete 4572 with new RFC. Martin prefers the obsolete path and I can live with that so that’s our proposal. To make this happen quickly, I converted 4572 to markdown and you can find it in the master branch at https://github.com/fluffy/4572bis and took the changes from Christer's draft and turned them in to a PR for bis draft. If you like to review on GitHub, you can check out PR at https://github.com/fluffy/4572bis/pull/1/files If you just want to see what the final draft would look like, it is attached to this email.

---

From: Roman Shpount <[email-masked]>
Date: Tue, 1 Nov 2016 20:10:48 -0400

Doing a 4572-bis is a path that I preferred from the beginning, since this
produces a cleaner document in the end. Doing an update was preferred since
there was a general feeling that an update can be completed faster.

If we take the 4572-bis path we are probably going to spend at least
another month or two on editorial reviews and WGLC before we can release
this document. Is this something everyone can live with?

Regards,

_____________
Roman Shpount

On Tue, Nov 1, 2016 at 7:52 PM, Cullen Jennings <[email-masked]> wrote:

>
> So Martin and I talked today about how to move forward on this. We think
> that we have a proposal that meets everyones requirements (you will groan
> when you hear but just ask yourself if you can live with it vs is it your
> favorite because we think everyone could live with this)
>
> We discussed two paths 1) split to two drafts, one with update for
> multiple fingerprints and separate extension that adds sha256. 2) just
> obsolete 4572 with new RFC. Martin prefers the obsolete path and I can live
> with that so that’s our proposal. To make this happen quickly, I converted
> 4572 to markdown and you can find it in the master branch at
> https://github.com/fluffy/4572bis and took the changes from Christer's
> draft and turned them in to a PR for bis draft. If you like to review on
> GitHub, you can check out PR at https://github.com/fluffy/
> 4572bis/pull/1/files If you just want to see what the final draft would
> look like, it is attached to this email.
>
>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>
>

---

From: Suhas Nandakumar <[email-masked]>
Date: Tue, 1 Nov 2016 19:26:39 -0700

+1 for the new approach .. since the contents in the bis is refactored from
the existing draft which has been reviewed quite a bit already , we should
work towards moving it through the process quickly for publication

On Tuesday, November 1, 2016, Roman Shpount <[email-masked]> wrote:

> On Tue, Nov 1, 2016 at 7:52 PM, Cullen Jennings <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
>>
>> GitHub, you can check out PR at https://github.com/fluffy/4572
>> bis/pull/1/files If you just want to see what the final draft would look
>> like, it is attached to this email.
>>
>>
>>
>> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>

---

From: Martin Thomson <[email-masked]>
Date: Wed, 2 Nov 2016 14:36:43 +1100

> We discussed two paths 1) split to two drafts, one with update for multiple fingerprints and separate extension that adds sha256. 2) just obsolete 4572 with new RFC. Martin prefers the obsolete pat…

Looks good.

The other thing here is that we don't want to touch anything else in
this document.  What Cullen has updated is exactly what we have agreed
to change, with the text that we have agreed on.  We should not expand
the scope just because the form of the document has changed.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 2 Nov 2016 08:13:40 +0000

Hi,

The suggested obsolete approach looks ok to me.

Note, however, that such approach would have impact on drafts currently
referencing both RFC4572 and draft-4572-update. Straight from my head, at
least the following drafts would be impacted:

RTCWEB: draft-ietf-rtcweb-jsep
STIR:   draft-ietf-stir-passport (NOTE: The draft is already in IESG
evaluation state)

In MMUSIC, draft-ietf-mmusic-sdp-mux-attributes references RFC 4572.
Should we replace it with the to-be-publishd-RFC?

Regards,

Christer

On 02/11/16 05:36, "Martin Thomson" <[email-masked]> wrote:

>>obsolete 4572 with new RFC. Martin prefers the obsolete path and I can
>>live with that so that¹s our proposal. To make this happen quickly, I
>>converted 4572 to markdown and you can find it in the master branch at
>>GitHub, you can check out PR at
>>https://github.com/fluffy/4572bis/pull/1/files If you just want to see
>>what the final draft would look like, it is attached to this email.
>
>Looks good.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 2 Nov 2016 09:40:42 -0400

On 11/2/16 4:13 AM, Christer Holmberg wrote:
> referencing both RFC4572 and draft-4572-update.

While it certainly would be best to clean up the references, AFAICT 
there would be no real harm in referencing both. With the change to 
"obsoletes" in the newer document it would clearly preempt the reference 
to the older one.

	Thanks,
	Paul

> Straight from my head, at

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 2 Nov 2016 14:21:52 +0000

Hi,

I think it would be weird to reference something which is obsoleted. We don't intend to do that for SDP, ICE etc either afaik.

Regards.

Christer

Sent from my iPhone

> On 2 Nov 2016, at 15.40, Paul Kyzivat <[email-masked]> wrote:
> 
> While it certainly would be best to clean up the references, AFAICT there would be no real harm in referencing both. With the change to "obsoletes" in the newer document it would clearly preempt the reference to the older one.
> 
>    Thanks,
>    Paul
>

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 2 Nov 2016 09:11:19 -0600

Just as a general rule of thumb, if TLS 1.2 obsoletes TLS 1.1, you don't have to update the IMAP specs which might point at TLS 1.1. IMAP can just use TLS 1.2 or TLS 1.1. Separation of orthogonal parts is a good thing. 

> RTCWEB: draft-ietf-rtcweb-jsep

JSEP already points at the update draft and if the WG switched to this approach, JSEP would point at the 4572 bis. No Problems there. 

> STIR:   draft-ietf-stir-passport (NOTE: The draft is already in IESG

An AD note to RFC Ed to change the ref would fix that if that was was the WG wanted.

---

From: Jonathan Lennox <[email-masked]>
Date: Wed, 2 Nov 2016 15:30:09 +0000

I’m happy to become a co-author on this (retroactively), but my affiliation should probably be updated from Columbia University. :-)

(I think I may have argued for a 4572bis previously, too.)

On Nov 1, 2016, at 7:52 PM, Cullen Jennings <[email-masked]<mailto:[email-masked]>> wrote:

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic
<draft-jennings-4572bis-00.txt>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 2 Nov 2016 13:58:44 -0400

> I think it would be weird to reference something which is obsoleted. We don't intend to do that for SDP, ICE etc either afaik.

I agree it is weird. My point is that it isn't a tragedy, and will do no 
harm. If it turns out to be too hard to pull back some document and fix 
it, that isn't necessary.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 2 Nov 2016 19:21:33 +0000

Hi,

>Just as a general rule of thumb, if TLS 1.2 obsoletes TLS 1.1, you don't have to update the IMAP specs which might point at TLS 1.1. IMAP can just use TLS 1.2 or TLS 1.1. 

Sure, but would you use TLS 1.2 and TLS 1.1 in the same spec?

> JSEP already points at the update draft and if the WG switched to this approach, JSEP would point at the 4572 bis. No Problems there. 

There are 5 references to RFC 4572 in JSEP, so they also need to be replaced with 4572bis.

>> STIR:   draft-ietf-stir-passport (NOTE: The draft is already in IESG evaluation state)
>

Sure. But, passport references both RFC 4572 and draft-4572-update, so both references need to be replaced with draft-4572-bis.

Regards,

Christer

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 2 Nov 2016 13:43:56 -0700

This seems satisfactory to me in principle. I haven't read the drafts, but
I will if we decide that that's the way forward.

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 2 Nov 2016 17:03:46 -0400

Thanks for all the replies and everybody's willingness to find a 
solution that everybody can live with.

I believe we have agreement from all the major stakeholders to move 
forward with the proposal below - if anybody agrees with that direction, 
now would be the time to speak up. Absent any further input on this, we 
will declare this as the new consensus on how to proceed.

It also does not sound like we need the call we had tentatively 
scheduled for Friday - please let us know if you disagree.

Thanks

-- Flemming (with chair hat on)

On 11/2/16 4:43 PM, Eric Rescorla wrote:
> This seems satisfactory to me in principle. I haven't read the drafts, 
> but I will if we decide that that's the way forward.
>
> On Tue, Nov 1, 2016 at 4:52 PM, Cullen Jennings <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>     So Martin and I talked today about how to move forward on this. We
>     think that we have a proposal that meets everyones requirements
>     (you will groan when you hear but just ask yourself if you can
>     live with it vs is it your favorite because we think everyone
>     could live with this)
>
>     multiple fingerprints and separate extension that adds sha256. 2)
>     just obsolete 4572 with new RFC. Martin prefers the obsolete path
>     and I can live with that so that’s our proposal. To make this
>     happen quickly, I converted 4572 to markdown and you can find it
>     in the master branch at https://github.com/fluffy/4572bis
>     <https://github.com/fluffy/4572bis> and took the changes from
>     Christer's draft and turned them in to a PR for bis draft. If you
>     like to review on GitHub, you can check out PR at
>     https://github.com/fluffy/4572bis/pull/1/files
>     <https://github.com/fluffy/4572bis/pull/1/files> If you just want
>     to see what the final draft would look like, it is attached to
>     this email.
>
>
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/mmusic>
>
>
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 2 Nov 2016 19:07:10 -0400

On 11/2/16 5:03 PM, Flemming Andreasen wrote:
> now would be the time to speak up.

Yes, I agree. (I think you probably meant to say "disagree" above.)

	Thanks,
	Paul

> Absent any further input on this, we

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 2 Nov 2016 21:38:33 -0400

> Yes, I agree. (I think you probably meant to say "disagree" above.)
Indeed :-)

Thanks Paul

-- Flemming

> .