JavaScript Session Establishment Protocol (JSEP)
draft-uberti-rtcweb-rfc8829bis-04

[Ballot comment]
Some minor comments that are likely my misunderstanding of the protocol:

Section 3.5.2.1:

        Implementations MUST be prepared to receive objects with some fields
        missing, as mentioned above.

What does it mean to be "prepared"? Is there any guidance to give here ?

Section 5.2.1:

        The  MUST be representable by a 64-bit signed integer,
        and the value MUST be less than 2^63-1.

Why is this a _signed_ integer and not an unsigned integer? What is the meaning of
2^63-1 in a 64 bit signed integer ?


        [...] SHOULD NOT be included.

        [...] MUST NOT be included.

Should these be extended to say "MUST be ignored when received" ? Or is there specific action that should take place that can be specified here?

NITS:

        opaque blobs; that is, the application will not need to read or
        change them.

maybe:

        opaque blobs; that is, the application will not need to parse or
        modify these.

("read" is a little ambiguous, it might need to memcpy (read and write) it,
but not grok it)


we could easily enable -> it could easily enable

[Ballot comment]
As with many of the other ballots:
1: I don't really understand this protocol but
2: I do like the 'diff's :-)

I'd also like to thank Qin Wu for the [OpsDir review](https://datatracker.ietf.org/doc/review-uberti-rtcweb-rfc8829bis-02-opsdir-lc-wu-2022-03-27/), and also the authors for addressing them (https://github.com/rtcweb-wg/jsep/pull/1025) - from what I can tell (see #1 :-)), this improved the document.

[Ballot comment]
Thanks for the updated specification and finding a way solve the issue with minimal changes.

One comment -

  - if not MUST, I was at least expecting a normative SHOULD to use the must-bundle policy instead of max-bundle in the following text-
   
    "As a result, "max-bundle" is considered deprecated, and new applications should use the "must-bundle" policy instead."

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-uberti-rtcweb-rfc8829bis-03
CC @evyncke

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Like John Scudder, with such an easy diff vs. RFC 8829, I have only reviewed the diffs.

Special thanks to Sean Turner for the shepherd's detailed write-up including the WG consensus and the justification of the intended status, the unusual format is sensible for such a minimum -bis.

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS

### I-D name

Like Erik Kline @ekline, I really wonder (and regret) why the I-D name was not updated to become draft-ietf-*, the shepherd explanation does not really satisfy me as at least two ADs are commenting on this I-D name and if is generating more work for the IESG review (checking mailing list & status). Not a big deal but a real annoyance.

### Section 4.1.1

The change from "max-bundle" to "must-bundle" is unclear to me (but I am not an expert in this protocol) and, with an apparently significant change, should there be normative language to ensure transition from 8829 to the -bis ?

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

[Ballot 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

[Ballot comment]
# Internet AD comments for {draft-uberti-rtcweb-rfc8829bis-03}
CC @ekline

## Comments

### general

* Is there a reason this didn't get renamed with -ietf-?
  I see a working group adoption event in the history.
  Not important, just curious.

### S5.2.1, S5.3.1

* RFC 8840 Section 4.1.1 says that either 0.0.0.0 or :: may be used.  This
  section says that "c=" MUST use 0.0.0.0.  Can :: be used instead?

* Ditto for the Initial Answers discussion (and 8440 S4.1.3), pp. 53, 55.

[Ballot comment]
# GEN AD review of draft-uberti-rtcweb-rfc8829bis-03

CC @larseggert

Thanks to Joel Halpern for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/i_745aF4T6deyFdN6ocUBuddfg8).

## Comments

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Term `traditional`; alternatives might be `classic`, `classical`, `common`,
  `conventional`, `customary`, `fixed`, `habitual`, `historic`,
  `long-established`, `popular`, `prescribed`, `regular`, `rooted`,
  `time-honored`, `universal`, `widely used`, `widespread`

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Outdated references

Reference `[RFC4566]` to `RFC4566`, which was obsoleted by `RFC8866` (this may
be on purpose).

Reference `[RFC5285]` to `RFC5285`, which was obsoleted by `RFC8285` (this may
be on purpose).

Reference `[RFC6347]` to `RFC6347`, which was obsoleted by `RFC9147` (this may
be on purpose).

Reference `[RFC5245]` to `RFC5245`, which was obsoleted by `RFC8445` and
`RFC8839` (this may be on purpose).

Reference `[RFC8843]` to `RFC8843`, which was obsoleted by `RFC9143` (this may
be on purpose).

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-uberti-rtcweb-rfc8829bis-02, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Michelle Thangtamsatid
IANA Services Specialist

The following Last Call announcement was sent out (ends 2022-04-05):

From: The IESG
To: IETF-Announce
CC: draft-uberti-rtcweb-rfc8829bis@ietf.org, rtcweb-chairs@ietf.org, rtcweb@ietf.org, sean@sn3rd.com, superuser@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (JavaScript Session Establishment Protocol (JSEP)) to Proposed Standard


The IESG has received a request from the Real-Time Communication in
WEB-browsers WG (rtcweb) to consider the following document: - 'JavaScript
Session Establishment Protocol (JSEP)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2022-04-05. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document describes the mechanisms for allowing a JavaScript
  application to control the signaling plane of a multimedia session
  via the interface specified in the W3C RTCPeerConnection API and
  discusses how this relates to existing signaling protocols.

  This specification obsoletes RFC 8829.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-uberti-rtcweb-rfc8829bis/



No IPR declarations have been submitted directly on this I-D.

# Summary

Sean Turner is the document shepherd.
Murray Kucherawy is the responsible Area Director?

This document is a bis for JSEP (aka 8829). The changes are noted in s1.3.

This I-D is Standards Track because JSEP is Standards Track.

Please note that this is a WG I-D despite the I-D's name; we adopted it as is and did not want to waste time submitting a draft-ietf-rtcweb version.

# Review and Consensus

This I-D was the sole topic of conversation at IETF 110 & 111. It was developed in close coordination with MMUSIC who produced a coordinated bis for RFC 8843, which is now published as RFC 9143.

The Shepherd does not believe there are any controversies. There is consensus as demonstrated during the WGLC that there is consensus to publish this document. I do not believe additional review is required.

# Intellectual Property

The Shepherd has confirmed that each author has stated that to their direct, personal knowledge any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79.

# Other Points

None.

# Summary

Sean Turner is the document shepherd.
Murray Kucherawy is the responsible Area Director?

This document is a bis for JSEP (aka 8829). The changes are noted in s1.3.

This I-D is Standards Track because JSEP is Standards Track.

Please note that this is a WG I-D despite the I-D's name; we adopted it as is and did not want to waste time submitting a draft-ietf-rtcweb version.

# Review and Consensus

This I-D was the sole topic of conversation at IETF 110 & 111. It was developed in close coordination with MMUSIC who produced a coordinated bis for RFC 8843, which is now published as RFC 9143.

The Shepherd does not believe there are any controversies. There is consensus as demonstrated during the WGLC that there is consensus to publish this document. I do not believe additional review is required.

# Intellectual Property

The Shepherd has confirmed that each author has stated that to their direct, personal knowledge any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79.

# Other Points

None.

# DRAFT - DRAFT

# Summary

Sean Turner is the document shepherd.
Murray Kucherawy is the responsible Area Director?

This document is a bis for JSEP (aka 8829). The changes are noted in s1.3.

This I-D is Standards Track because JSEP is Standards Track.

Please note that this is a WG I-D despite the I-D's name; we adopted it as is and did not want to waste time submitting a draft-ietf-rtcweb version.

# Review and Consensus

This I-D was the sole topic of conversation at IETF 110 & 111. It was developed in close coordination with MMUSIC who produced a coordinated bis for RFC 8843, which is now published as RFC 9143.

The Shepherd does not believe there are any controversies. There is consensus as demonstrated during the WGLC that there is consensus to publish this document. I do not believe additional review is required.

# Intellectual Property

The Shepherd has confirmed that each author has stated that to their direct, personal knowledge any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79.

# Other Points

None.

# DRAFT - DRAFT