Subject: [MMUSIC] Reference update from 4566 to 4566bis?

From: Christer Holmberg <[email-masked]>
Date: Tue, 5 May 2020 08:34:55 +0000

Hi,

Some of the drafts in Cluster 238 that reference RFC 4566, while other reference draft-4566bis-

Since draft-4566bis is also part of Cluster 238, and is in the RFC editor’s queue, should we update the references to draft-4566bis?

The change would be done *at least* to the following drafts (I will only check the ones I author/co-author):

MMUSIC WG:

draft-ietf-mmusic-dtls-sdp
draft-ietf-mmusic-sdp-bundle-negotiation
draft-ietf-mmusic-sctp-sdp

BFCPbis:

draft-ietf-bfcpbis-rfc4583bis-27

One of the reason many drafts do not reference 4566bis is because the drafts were going to be finalized long before 4566bis. But, as that is now not the case….

draft-ietf-mmusic-mux-attributes references both 4566 (normative) and 4566bis (informative). In my opinion we could make 4566bis normative there, but I’d like to hear what Suhas thinks.

Regards,

Christer

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 5 May 2020 09:19:50 -0400

Makes sense (as long as none of those references were explicitly to 4566 
rather than 4566bis).

Cheers

-- Flemming (as individual)

On 5/5/20 4:34 AM, Christer Holmberg wrote:
> Since draft-4566bis is also part of Cluster 238, and is in the RFC 
> editor’s queue, should we update the references to draft-4566bis?
>
> The change would be done **at least** to the following drafts (I will 
> only check the ones I author/co-author):
>
> MMUSIC WG:
>
> One of the reason many drafts do not reference 4566bis is because the 
> drafts were going to be finalized long before 4566bis. But, as that is 
> now not the case….
>
> draft-ietf-mmusic-mux-attributes references both 4566 (normative) and 
> 4566bis (informative). In my opinion we could make 4566bis normative 
> there, but I’d like to hear what Suhas thinks.
>
> Regards,
>
> Christer
>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 5 May 2020 15:51:27 +0000

Hi,

>Makes sense (as long as none of those references were explicitly to 4566 rather than 4566bis).
Sure.
But, at least in the drafts listed below, I did not find anything that would have been 4566-specific, so I have asked the RFC editor to update the references.
I don’t think we should publish RFCs with references to specifications that are obsoleted from day one…
Regards,
Christer

MMUSIC WG:

BFCPbis:

Regards,

Christer

mmusic mailing list

[email-masked]<mailto:[email-masked]>

---

From: Ted Hardie <[email-masked]>
Date: Tue, 5 May 2020 08:51:40 -0700

At least for JSEP, this was considered by the authors and they declined to
make the change:

https://github.com/rtcweb-wg/jsep/issues/562

I personally assume that we'd need to confirm for each one that references
RFC 4566 that it was not a deliberate choice and that the internal detailed
references do not need an update.  That latter, I think, is why we should
avoid it; it is not necessarily the case that the structure of bis will
allow us to make one-for-one swaps.

Were this a github issue, I would personally suggest "close with no action"
and leave the mix as it is; I don't see a big enough advantage to take on
the work.

regards,

Ted

On Tue, May 5, 2020 at 6:21 AM Flemming Andreasen <fandreas=
[email-masked]> wrote:

> drafts were going to be finalized long before 4566bis. But, as that is now
> not the case….
>
>
>
> 4566bis (informative). In my opinion we could make 4566bis normative there,
> but I’d like to hear what Suhas thinks.
>
>
>
> Regards,
>
>
>
> Christer
>
> mmusic mailing [email-masked]://www.ietf.org/mailman/listinfo/mmusic
>
>

---

From: Ted Hardie <[email-masked]>
Date: Tue, 5 May 2020 08:55:15 -0700

This appears to have crossed my message in the air.  I respectfully request
that you revert this request to the RFC editors, on the basis I gave in my
mail.  If you don't do that, I'm afraid I will, and we will have a mess.

Please also recall that time zones are a thing, and that some of the people
you wanted to review this just started their day a small amount of time
ago; generally speaking, less than a day's review for a suggested change to
this cluster is not reasonable.

regards,

Ted

On Tue, May 5, 2020 at 8:51 AM Christer Holmberg <christer.holmberg=
[email-masked]> wrote:

> But, at least in the drafts listed below, I did not find anything that
> would have been 4566-specific, so I have asked the RFC editor to update the
> references.
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 5 May 2020 16:07:08 +0000

Hi Ted,

All the drafts I listed are in cluster 238, so it is going to take some time before they got published.

And, we will anyway have a mix of references in cluster 238, because some of the drafts that were recently finalized do reference 4566bis.

Having said that, I will ask the RFC editor to revert the change before people have a chance to give an opinion.

Regards,

Christer

From: Ted Hardie <[email-masked]>
Date: Tuesday, 5 May 2020 at 18.55
To: Christer Holmberg <[email-masked]>
Cc: Flemming Andreasen <[email-masked]>, "[email-masked]" <[email-masked]>, bfcpbis <[email-masked]>, "[email-masked]" <[email-masked]>, Suhas Nandakumar <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [MMUSIC] Reference update from 4566 to 4566bis?

This appears to have crossed my message in the air.  I respectfully request that you revert this request to the RFC editors, on the basis I gave in my mail.  If you don't do that, I'm afraid I will, and we will have a mess.

Please also recall that time zones are a thing, and that some of the people you wanted to review this just started their day a small amount of time ago; generally speaking, less than a day's review for a suggested change to this cluster is not reasonable.

regards,

Ted

On Tue, May 5, 2020 at 8:51 AM Christer Holmberg <christer.holmberg=[email-masked]<mailto:[email-masked]..org>> wrote:
Hi,

Sure.

MMUSIC WG:

BFCPbis:

Regards,

Christer

mmusic mailing list

---

From: Ted Hardie <[email-masked]>
Date: Tue, 5 May 2020 09:09:17 -0700

On Tue, May 5, 2020 at 9:07 AM Christer Holmberg <
[email-masked]> wrote:

> And, we will anyway have a mix of references in cluster 238, because some
> of the drafts that were recently finalized do reference 4566bis.
>
>
>
Thank you very much,

Ted

> Regards,
>
>
>
> Christer
>
>
>
> *From: *Ted Hardie <[email-masked]>
> *Date: *Tuesday, 5 May 2020 at 18.55
> *To: *Christer Holmberg <[email-masked]>
> *Cc: *Flemming Andreasen <[email-masked]>, "[email-masked]" <
> [email-masked]>, bfcpbis <[email-masked]>, "
> [email-masked]" <[email-masked]>, Suhas Nandakumar <
> [email-masked]>, "[email-masked]" <[email-masked]>, "
> [email-masked]" <[email-masked]>
> *Subject: *Re: [MMUSIC] Reference update from 4566 to 4566bis?
>
>
>
> This appears to have crossed my message in the air.  I respectfully
> request that you revert this request to the RFC editors, on the basis I
> gave in my mail.  If you don't do that, I'm afraid I will, and we will have
> a mess.
>
>
>
> Please also recall that time zones are a thing, and that some of the
> people you wanted to review this just started their day a small amount of
> time ago; generally speaking, less than a day's review for a suggested
> change to this cluster is not reasonable.
>
>
>
> regards,
>
>
>
> Ted
>
>
>
> [email-masked] <[email-masked]..org>> wrote:
>
> Hi,
>
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 5 May 2020 16:21:39 +0000

Hi,

>At least for JSEP, this was considered by the authors and they declined to make the change:
>
>I personally assume that we'd need to confirm for each one that references RFC 4566 that it was not a deliberate choice and that the internal
>detailed references do not need an update.

I claim that the reason we chose to not reference 4566bis was because of the assumption that the rest of the RTCWEB-related stuff was going to be published before 4566bis. I am happy to be proven wrong on that assumption, though :)

>That latter, I think, is why we should avoid it; it is not necessarily the case that the structure of bis will allow us to make one-for-one swaps.

I fully agree – it should not be a search/replace exercise.

In the case of the drafts below, the references were mostly in the syntax section, for definitions of “token” etc. And, those have not changed from 4566 to 4566bis.

Also, I am NOT suggesting that everyone has to do the reference update. As I said in my other reply, we already have a mix of 4566/4566bis references, and many specifications probably anyway reference both if we count explicit and implicit references.

Regards,

Christer

On Tue, May 5, 2020 at 6:21 AM Flemming Andreasen <fandreas=[email-masked]<mailto:[email-masked]>> wrote:
Makes sense (as long as none of those references were explicitly to 4566 rather than 4566bis).

Cheers

MMUSIC WG:

BFCPbis:

Regards,

Christer

mmusic mailing list

---

From: Ted Hardie <[email-masked]>
Date: Tue, 5 May 2020 11:33:13 -0700

On Tue, May 5, 2020 at 9:21 AM Christer Holmberg <
[email-masked]> wrote:

> >I personally assume that we'd need to confirm for each one that
> references RFC 4566 that it was not a deliberate choice and that the
> internal
>
> I claim that the reason we chose to not reference 4566bis was because of
> the assumption that the rest of the RTCWEB-related stuff was going to be
> published before 4566bis. I am happy to be proven wrong on that assumption,
> though :)
>
>
Another way to put this same claim, though, is that none of the documents
needed anything from RFC 4566bis enough to wait for it.

>
>
> >That latter, I think, is why we should avoid it; it is not necessarily
> the case that the structure of bis will allow us to make one-for-one swaps.
>
>
>

That's going to slow down the progress of Cluster 238, which is clearly
contrary to our interests.  If there was not enough of an advantage to take
on the shift to -bis during the active life of these drafts, taking it on
during the end game does not seem the right choice to me.  Each document
would have to be adjusted and cross checked all over again, at a point when
active review of these is at its lowest.  There is a real chance of
introduced error at moments like these, and strongly urge you to reconsider.

> In the case of the drafts below, the references were mostly in the syntax
> section, for definitions of “token” etc. And, those have not changed from
> 4566 to 4566bis.
>
>
>
> Also, I am NOT suggesting that everyone has to do the reference update. As
> I said in my other reply, we already have a mix of 4566/4566bis references,
> and many specifications probably anyway reference both if we count explicit
> and implicit references.
>
>
Then let's not mess with the mix; we can't avoid having a mix and there is
no per document advantage to 4566bis that was identified at the time.

That's my two cents, anyway.

Ted

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 5 May 2020 19:45:02 +0000

Date: Tuesday, 5 May 2020 at 21.33

On Tue, May 5, 2020 at 9:21 AM Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

>https://github.com/rtcweb-wg/jsep/issues/562<https://protect2.fireeye.com/v1/url?k=8076acb5-ded64c2b-8076ec2e-86ee86bd5107-ba490800c052dc7e&q=1&e=3714c464-f102-4faa-86a0-99d5dce1b431&u=https%3A%2F%2Fgithub.com%2Frtcweb-wg%2Fjsep%2Fissues%2F562>
>

Another way to put this same claim, though, is that none of the documents needed anything from RFC 4566bis enough to wait for it.

That's going to slow down the progress of Cluster 238, which is clearly contrary to our interests.  If there was not enough of an advantage to take on the shift to -bis during the active life of these drafts, taking it on during the end game does not seem the right choice to me.  Each document would have to be adjusted and cross checked all over again, at a point when active review of these is at its lowest.  There is a real chance of introduced error at moments like these, and strongly urge you to reconsider.

Then let's not mess with the mix; we can't avoid having a mix and there is no per document advantage to 4566bis that was identified at the time.

Ted

Regards,

Christer

Cheers

MMUSIC WG:

BFCPbis:

Regards,

Christer

mmusic mailing list

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 5 May 2020 20:18:00 +0000

Hi,

Sorry, sent the SEND button by mistake…

>>https://protect2.fireeye.com/v1/url?k=8076acb5-ded64c2b-8076ec2e-86ee86bd5107-ba490800c052dc7e&q=
>>1&e=3714c464-f102-4faa-86a0-99d5dce1b431&u=https://github.com/rtcweb-wg/jsep/issues/562
>> 
>> I claim that the reason we chose to not reference 4566bis was because of the assumption that the rest of the RTCWEB-related
>> stuff was going to be published before 4566bis. I am happy to be proven wrong on that assumption, though :)
> 
 
Correct. Unlike ICE (where we also had a discussion in RTCWEB regarding what to reference), 4566bis does not (Paul, please correct me if I'm wrong) provide new or modified functionality where implementations would act differently based on which spec is implemented.

To be fair, this is mostly a cosmetic thing. We have been working for too-many-years to get the RTCWEB stuff/dependencies done, and the same day as we finally publish the RFCs we immediately end up referencing an obsolete specification :)

 So, as this should not have any technical impacts, I am not going to push for it. I thought it would be an easy thing to do, and wanted to know what people think, but unless someone can come up with some technical issues with referencing RFC 4566 I am also fine leaving things as they are.

Regards,
 
Christer

 
On Tue, May 5, 2020 at 6:21 AM Flemming Andreasen <fandreas=mailto:[email-masked]> wrote:
Makes sense (as long as none of those references were explicitly to 4566 rather than 4566bis). 

Cheers

 

MMUSIC WG:

BFCPbis:

 
 
Regards,
 
Christer
 
mailto:[email-masked]
 
mailto:[email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 5 May 2020 16:44:09 -0400

> At least for JSEP, this was considered by the authors and they declined 

Clearly in cases where 4566 is referenced rather than 4566bis we know 
that the changes in 4566bis are not pertinent to the referencing 
document. So the motivation could be one or both of the following:

1) didn't want to introduce a publishing delay waiting for 4566bis
2) didn't want to introduce a requirement to implement 4566bis.

Of those, (1) is now moot since 4566bis is now in the bundle.

That means that there is already an implementation requirement for 
*some* part of the bundle. There could still be an advantage to stick 
with 4566 for those pieces that don't need it if there is some subset of 
the package that is meaningful to implement on its own, without pulling 
in 4566bis. It should be possible to figure that out.

	Thanks,
	Paul

> internal detailed references do not need an update.  That latter, I 
> think, is why we should avoid it; it is not necessarily the case that 
> the structure of bis will allow us to make one-for-one swaps.
> 
> Were this a github issue, I would personally suggest "close with no 
> action" and leave the mix as it is; I don't see a big enough advantage 
> to take on the work.
> 
> regards,
> 
> Ted
> 
> On Tue, May 5, 2020 at 6:21 AM Flemming Andreasen 
> <fandreas=[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>>     Hi,____
>>     __ __
>>     Some of the drafts in Cluster 238 that reference RFC 4566, while
>>     other reference draft-4566bis-____
>>
>>     __ __
>>
>>     editor’s queue, should we update the references to draft-4566bis? ____
>>
>>     __ __
>>
>>     The change would be done **at least** to the following drafts (I
>>     will only check the ones I author/co-author):____
>>
>>     __ __
>>
>>     MMUSIC WG:____
>>
>>     __ __
>>
>>     draft-ietf-mmusic-dtls-sdp____
>>
>>     draft-ietf-mmusic-sdp-bundle-negotiation____
>>
>>     draft-ietf-mmusic-sctp-sdp____
>>
>>     __ __
>>
>>     BFCPbis:____
>>
>>     __ __
>>
>>     draft-ietf-bfcpbis-rfc4583bis-27____
>>
>>     __ __
>>
>>     One of the reason many drafts do not reference 4566bis is because
>>     the drafts were going to be finalized long before 4566bis. But, as
>>     that is now not the case….____
>>
>>     __ __
>>
>>     draft-ietf-mmusic-mux-attributes references both 4566 (normative)
>>     and 4566bis (informative). In my opinion we could make 4566bis
>>     normative there, but I’d like to hear what Suhas thinks.____
>>
>>     __ __
>>
>>     Regards,____
>>
>>     __ __
>>
>>     Christer____
>>
>>
>>     [email-masked]  <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 5 May 2020 16:55:55 -0400

(I saw this after my prior post.)

> Correct. Unlike ICE (where we also had a discussion in RTCWEB regarding what to reference), 4566bis does not (Paul, please correct me if I'm wrong) provide new or modified functionality where imple…

I haven't studied the rtcweb docs in a long time, but AFAIK there are no 
dependencies on 4566bis.

>   So, as this should not have any technical impacts, I am not going to push for it. I thought it would be an easy thing to do, and wanted to know what people think, but unless someone can come up w…

I the interest in progress I agree.

	Thanks,
	Paul