[rtcweb] Robert Wilton's No Objection on draft-uberti-rtcweb-rfc8829bis-03: (with COMMENT)

Robert Wilton via Datatracker <noreply@ietf.org> Mon, 03 October 2022 16:57 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: rtcweb@ietf.org
Delivered-To: rtcweb@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CAF9BC1524B2; Mon, 3 Oct 2022 09:57:55 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Robert Wilton via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-uberti-rtcweb-rfc8829bis@ietf.org, rtcweb-chairs@ietf.org, rtcweb@ietf.org, sean@sn3rd.com, sean@sn3rd.com
X-Test-IDTracker: no
X-IETF-IDTracker: 8.17.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Robert Wilton <rwilton@cisco.com>
Message-ID: <166481627582.57864.6504316378744010818@ietfa.amsl.com>
Date: Mon, 03 Oct 2022 09:57:55 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/2wEs6QUw-wGpT5Wn5nHwNYrIDiQ>
Subject: [rtcweb] Robert Wilton's No Objection on draft-uberti-rtcweb-rfc8829bis-03: (with COMMENT)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.39
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Oct 2022 16:57:55 -0000

Robert Wilton has entered the following ballot position for
draft-uberti-rtcweb-rfc8829bis-03: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-uberti-rtcweb-rfc8829bis/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Hi,

Thanks for this easy to review diff.

(1) p 23, sec 4.1.1.  Constructor

   [RFC8829] defined a policy known as "max-bundle", which, while
   defined identically to the "must-bundle" policy described above, was
   implemented by some implementations according to an earlier, pre-
   standard definition (in which, for example, no "m=" sections were
   marked as bundle-only).  As a result, "max-bundle" is considered
   deprecated, and new applications should use the "must-bundle" policy
   instead.

Disclaimer, I don't know this protocol.

I'm not sure why this isn't 'must use the "must-bundle" policy instead of
"max-bundle."'

It is somewhat unclear to me how implementations move from RFC8829 to this RFC.
 Specifically, it is unclear, for implementations that follow this RFC rather
than RFC8829 (which is being obsoleted by this RFC), what, if any, handling of
"max-bundle" is permitted.  My interpretation is that the "max-bundle" policy
can still be specified, but its behaviour is not well-defined.  Further, is it
appropriate for new implementations to also support "max-bundle" and treat it
identically to "must-bundle", or should they reject that policy?

In summary, I think that some extra explanation here might be helpful.

Regards,
Rob