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

Ted Hardie <ted.ietf@gmail.com> Tue, 05 May 2020 18:33 UTC

Return-Path: <ted.ietf@gmail.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 371E83A0BFB; Tue, 5 May 2020 11:33:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vAOdu_IbHrmV; Tue, 5 May 2020 11:33:40 -0700 (PDT)
Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com [IPv6:2607:f8b0:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 594393A0BFA; Tue, 5 May 2020 11:33:39 -0700 (PDT)
Received: by mail-oi1-x229.google.com with SMTP id x10so2895605oie.1; Tue, 05 May 2020 11:33:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Dh4QjySimx17CmvZ/auj6GxTDNABkEhbIF6ezP/HQ2E=; b=h69QatWhCBYKuRUFZ9zcO5r7Bgg/67I0k2iKqdAGku5NkdfQj40F0hwbJp3J7SBwsF 2CnrP9TLK1H/PcPTlClLTuFmWiiuIUR/OBXffKJ26rMDO8dKXXJqUrHhOi7WfpAMqEse V+qR4AByn1gfja+kRTBiKsaG4k2WUlMzjagaH8QPNeDrPbGwzVfUXHGx0kJlBbOy3Qid AXDmf5GlU1MXoi7ft6Ro/R0XkEVwgA0cV9Gikd4ffdwaelSs5bjwyCtreVOjA4LfIgso U79xawhvb3kkYNXrNIMIKlZdX+yaCn6qOJXF5Jo6rjaCYafAQx3XSzLkQyfiNIfHdwO/ Ab5g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Dh4QjySimx17CmvZ/auj6GxTDNABkEhbIF6ezP/HQ2E=; b=pNe9fTpxNEHpRg6dPMO1zRAcqeAOcVZYOEZfXVnH1qjRSdCZl/DF8Pbvx0LSWJdRfr nueeVSlbXdQ+iZCWCTh16F9X5novie8jSwtJ94j3POYVImBhLo5nHRHRe9HZqBCZ3sCQ Hphoy9wjvnmhkzb4wPNvz/OfkU3IqtNrDDyoHuCAwkpUrOljRDRmW9iRKFqzltlu1zrr NFlkXe8ooreP8y6aLSXWL4486I5uAKuEmAFAbF5ldsrrq1Oj+4KkIx1j6gQOQOfL+HFC SjbqitUgLqjmMYtnoNjTimR4kIYHH9D32iH9dOmSOSx63pqsjTc3meB6ulQXTYRedCmS pxzw==
X-Gm-Message-State: AGi0PuYzn+bfNDZZWOyhN3QSZwVTXv01BZIKaI1KFM59sWKWJO2S9ner X4+u9FF4qTuFNUHXzvPMrXEX9OzqviXM1KBIGL0=
X-Google-Smtp-Source: APiQypIywU16cGrpp2NA2eWFJadV0nbCihS/SHnSKXeAXPIecsp+xgFhsqVW73goKBFjKbtCgO6yYa1Dos9Z/eHomiU=
X-Received: by 2002:aca:cc82:: with SMTP id c124mr38711oig.35.1588703618417; Tue, 05 May 2020 11:33:38 -0700 (PDT)
MIME-Version: 1.0
References: <12B81692-4EA9-4AC2-8F46-DE3E1A39BE8C@ericsson.com> <f93ff4b8-3485-893c-e2ed-316babf8fe05@cisco.com> <CA+9kkMA_pVqaUk7XM80F+G-8MtGgj2Nh+pmFCb2GPJYLH6rXcQ@mail.gmail.com> <0BAA16C9-B53A-4EBD-B133-ED111DBE92CA@ericsson.com>
In-Reply-To: <0BAA16C9-B53A-4EBD-B133-ED111DBE92CA@ericsson.com>
From: Ted Hardie <ted.ietf@gmail.com>
Date: Tue, 5 May 2020 11:33:13 -0700
Message-ID: <CA+9kkMBLEAJ-by5QQ3=QC9BYwa14gwzBGXG8QF-eOuyGA410Xw@mail.gmail.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: Flemming Andreasen <fandreas@cisco.com>, "mmusic@ietf.org" <mmusic@ietf.org>, bfcpbis <bfcpbis-bounces@ietf.org>, "mmusic-chairs@ietf.org" <mmusic-chairs@ietf.org>, Suhas Nandakumar <snandaku@cisco.com>, "pkyzivat@alum.mit.edu" <pkyzivat@alum.mit.edu>, "bfcpbis-chairs@ietf.org" <bfcpbis-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d4473205a4eae2bf"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/nhkuMwMxLOoGES2YUGC6Uth_byU>
Subject: Re: [MMUSIC] Reference update from 4566 to 4566bis?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 May 2020 18:33:47 -0000

On Tue, May 5, 2020 at 9:21 AM Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> Hi,
>
>
>
> >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.
>
>
>
> 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.
>
>
>
> I fully agree – it should not be a search/replace exercise.
>
>
>

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



>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
>
>
> On Tue, May 5, 2020 at 6:21 AM Flemming Andreasen <fandreas=
> 40cisco.com@dmarc.ietf.org> wrote:
>
> 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:
>
> 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
>
>
>
> _______________________________________________
>
> mmusic mailing list
>
> mmusic@ietf.org
>
> https://www.ietf.org/mailman/listinfo/mmusic
>
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>
>