Skip to main content

WebRTC Data Channels
draft-ietf-rtcweb-data-channel-13

Revision differences

Document history

Date Rev. By Action
2020-12-03
13 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2020-11-05
13 (System) RFC Editor state changed to AUTH48 from AUTH48-DONE
2020-09-30
13 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2020-05-18
13 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2020-03-16
13 (System) RFC Editor state changed to RFC-EDITOR from REF
2019-08-19
13 (System) RFC Editor state changed to REF from EDIT
2019-08-16
13 (System) RFC Editor state changed to EDIT from MISSREF
2019-08-15
13 (System) RFC Editor state changed to MISSREF from EDIT
2019-08-15
13 (System) RFC Editor state changed to EDIT from MISSREF
2015-10-14
13 (System) Notify list changed from rtcweb-chairs@ietf.org, draft-ietf-rtcweb-data-channel@ietf.org to (None)
2015-10-12
13 Alissa Cooper Shepherding AD changed to Alissa Cooper
2015-01-12
13 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2015-01-12
13 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2015-01-12
13 (System) IANA Action state changed to Waiting on Authors from In Progress
2015-01-08
13 Amy Vezza IESG state changed to RFC Ed Queue from Approved-announcement sent
2015-01-08
13 (System) RFC Editor state changed to MISSREF
2015-01-08
13 (System) Announcement was received by RFC Editor
2015-01-08
13 (System) IANA Action state changed to In Progress
2015-01-08
13 Amy Vezza IESG state changed to Approved-announcement sent from IESG Evaluation::AD Followup
2015-01-08
13 Amy Vezza IESG has approved the document
2015-01-08
13 Amy Vezza Closed "Approve" ballot
2015-01-08
13 Amy Vezza Ballot approval text was generated
2015-01-08
13 Amy Vezza Ballot writeup was changed
2015-01-05
13 Benoît Claise [Ballot comment]
Thanks for addressing my DISCUSS.
2015-01-05
13 Benoît Claise [Ballot Position Update] Position for Benoit Claise has been changed to No Objection from Discuss
2015-01-04
13 Michael Tüxen IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2015-01-04
13 Michael Tüxen New version available: draft-ietf-rtcweb-data-channel-13.txt
2014-11-11
12 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'No Response'
2014-10-30
12 Vijay Gurbani Request for Last Call review by GENART Completed: Ready. Reviewer: Vijay Gurbani.
2014-10-30
12 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: David Harrington.
2014-10-30
12 Cindy Morgan IESG state changed to IESG Evaluation::AD Followup from IESG Evaluation
2014-10-30
12 Cindy Morgan Changed consensus to Yes from Unknown
2014-10-30
12 Alia Atlas [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas
2014-10-30
12 Spencer Dawkins
[Ballot comment]
I'm a Yes on this one, but there are a few things I'd like the authors to look at. In particular, the 6.6 …
[Ballot comment]
I'm a Yes on this one, but there are a few things I'd like the authors to look at. In particular, the 6.6 comment may require a bit of additional text.

In this text: 6.4.  Data Channel Definition

  One strong wish is for the application-level API to be close to the
  ^^^^^^^^^^^^^^^

  API for WebSockets, which implies bidirectional streams of data and a
  textual field called 'label' used to identify the meaning of the data
  channel.

  The realization of a data channel is a pair of one incoming stream
  and one outgoing SCTP stream having the same SCTP stream identifier.
  How these SCTP stream identifiers are selected is protocol and
  implementation dependent.  This allows a bidirectional communication.

I wonder how this will sound after this RFC and the WebRTC API have been published. Could this be a bit more concrete? Perhaps something like

  The realization of a data channel is a pair of one incoming stream
  and one outgoing SCTP stream having the same SCTP stream identifier.
  How these SCTP stream identifiers are selected is protocol and
  implementation dependent.  This allows a bidirectional communication,
  and allows the application-level API to be close to the API for
  WebSockets, which provides bidirectional streams of data and a
  textual field called 'label' used to identify the meaning of the data
  channel.

In this text: 6.5.  Opening a Data Channel

  When one side wants to open a channel using out-of-band negotiation,
  it picks a stream.  Unless otherwise defined or negotiated, the
  streams are picked based on the DTLS role (the client picks even
  stream identifiers, the server odd stream identifiers).  However, the
  application is responsible for avoiding collisions with existing
  streams.  If it attempts to re-use a stream which is part of an
  existing data channel, the addition SHOULD fail.
                                      ^^^^^^

My understanding of SHOULD says that if the addition doesn't fail, that's discouraged but legal under this specification. Is that OK? Or ought this be a MUST?

In this text: 6.6.  Transferring User Data on a Data Channel

  No more than one message should be put into an SCTP user message.

This statement doesn't use uppercase 2119 language, and the Conventions section doesn't say anything about whether lowercase 2119 wording is to be interpreted,

so at least some implementers will say that The spec doesn't prohibit it.

If a sender puts more than one message into an SCTP user message, is that OK? If the sender does that, what does the receiver do?

It would be helpful to include a sentence about why this restriction is included. The specification has a nice explanation of why non-interleaved connections should be limited to 16-Kb maximum message sizes. That's the level of detail I'm asking about here.

In this text: 7.  Security Considerations

  I should be noted that a receiver must be prepared that the sender
  ^
  tries to send arbitrary large messages.

is likely "It".
2014-10-30
12 Spencer Dawkins [Ballot Position Update] New position, Yes, has been recorded for Spencer Dawkins
2014-10-30
12 Brian Haberman [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman
2014-10-30
12 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko
2014-10-29
12 Ted Lemon [Ballot Position Update] New position, No Objection, has been recorded for Ted Lemon
2014-10-29
12 Alissa Cooper
[Ballot comment]
= General comment =
I'm assuming Sections 3 and 4 are included here because data channels can be used outside the context of …
[Ballot comment]
= General comment =
I'm assuming Sections 3 and 4 are included here because data channels can be used outside the context of WebRTC or when no media is being exchanged. It would help to make that clear and only enumerate the use cases and requirements that are not already covered in draft-ietf-rtcweb-use-cases-and-requirements.

= Section 5 =
s/WebRTP/WebRTC/

= Section 6.1 =
OLD:
      The dynamic address reconfiguration extension defined in [RFC5061]
      MUST be used to signal the support of the stream reset extension
      defined in [RFC6525], other features of [RFC5061] are not REQUIRED
      to be implemented.

NEW:
      The dynamic address reconfiguration extension defined in [RFC5061]
      MUST be used to signal the support of the stream reset extension
      defined in [RFC6525]. Other features of [RFC5061] are OPTIONAL.

("not REQUIRED" does not make sense)

= Section 6.4 =
OLD:
  One strong wish is for the application-level API to be close to the
  API for WebSockets, which implies bidirectional streams of data and a
  textual field called 'label' used to identify the meaning of the data
  channel.

NEW:
  Data channels are defined such that their accompanying application-level API can closely mirror the API for WebSockets, which implies bidirectional streams of data and a
  textual field called 'label' used to identify the meaning of the data
  channel.

(I didn't understand "One strong wish".)
2014-10-29
12 Alissa Cooper [Ballot Position Update] New position, Yes, has been recorded for Alissa Cooper
2014-10-29
12 Martin Stiemerling
[Ballot comment]
A few comments/nits:
- Section 1, page 3, 1st paragraph reads:
  "source authentication, and integrity protected transfers.  This data
  transport service …
[Ballot comment]
A few comments/nits:
- Section 1, page 3, 1st paragraph reads:
  "source authentication, and integrity protected transfers.  This data
  transport service operates in parallel to the SRTP media transports,
  and all of them can eventually share a single transport-layer port
  number."

It is not not clear for me, what transport-layer the port refers to? SCTP or UDP or both?

- Section 5, page 6, reads in one sentence:
"SCTP association.  In the WebRTP context, the PPID is used to"
This should for sure read WebRTC instead of WebRTP, isn’t it?

-  Section 5, page 8, reads:
  " In general, the lower layer interface of an SCTP implementation
  SHOULD be adapted to address the differences between IPv4 and IPv6
  (being connection-less) or DTLS (being connection-oriented)."

The SHOULD here isn’t looking right, as this is not about protocol interworking, but advice for the implementers. Better to say "should be adapted to".
2014-10-29
12 Martin Stiemerling [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling
2014-10-29
12 Stephen Farrell
[Ballot comment]

These are not DISCUSSes because I'm betting they get answered
in some other document, but be good to have answers here too
maybe. …
[Ballot comment]

These are not DISCUSSes because I'm betting they get answered
in some other document, but be good to have answers here too
maybe.

- In 6.2, what does "typically" mean for DTLS state shared
between SCTP streams or SCTP associations or data channels or
PeerConnections? Don't you need to use some 2119 terms and be
more specific about that? Maybe that's just me not being so
familiar with BUNDLE though, and what equivalent is meant here?

- Where do I find text that will show me that it's not possible
to cut'n'paste anything from one SCTP stream to any other
anywhere?
2014-10-29
12 Stephen Farrell [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell
2014-10-29
12 Kathleen Moriarty
[Ballot comment]
The draft looks good, thanks for your work on it. 

There is a tiny nit in the security considerations section that would likely …
[Ballot comment]
The draft looks good, thanks for your work on it. 

There is a tiny nit in the security considerations section that would likely be caught anyway:  Last sentence should start with "It" instead of "I".

  I should be noted that a receiver must be prepared that the sender
  tries to send arbitrary large messages.
2014-10-29
12 Kathleen Moriarty [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty
2014-10-29
12 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel
2014-10-29
12 Benoît Claise
[Ballot discuss]

  Req. 1:  Multiple simultaneous data channels MUST be supported.
            Note that there may be 0 or …
[Ballot discuss]

  Req. 1:  Multiple simultaneous data channels MUST be supported.
            Note that there may be 0 or more SRTP media streams in
            parallel with the data channels in the same PeerConnection,
            and the number and state (active/inactive) of these SRTP
            media streams may change at any time.

Multiple simultaneous data channels from different "modes" (unreliable, partially or fully reliable), or even from the same mode? "modes" in double quotes, because, if I recall correctly SCTP delivery mode is per message, not per stream. However, I don't have a better word.

Then I started to wonder...  I've see those requirements before.

http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14
  ----------------------------------------------------------------
  F22    The browser must be able to receive streams and
          data from multiple peers concurrently.
  ----------------------------------------------------------------

So I should not be commenting on the requirements again!
Why do you repeat, with different wording, the use cases and requirements in this document?
Note that this document contains RFC 2119 keywords for the requirements, while
draft-ietf-rtcweb-use-cases-and-requirements doesn't.
Does it imply the requirements in this document are more important?
This is confusing.

Disclaimer: I have not done a 1:1 comparison of the requirements in both documents.
A discrepancy would be another DISCUSS reason.

Referring to draft-ietf-rtcweb-use-cases-and-requirements is the way to go.
Even if [I-D.ietf-rtcweb-use-cases-and-requirements] is an informative reference, progressing this draft while [I-D.ietf-rtcweb-use-cases-and-requirements] still has issues is not appropriate. I'll trust the responsible AD on that.

Ah, I just realized that Pete has got a similar feedback.
2014-10-29
12 Benoît Claise [Ballot Position Update] New position, Discuss, has been recorded for Benoit Claise
2014-10-28
12 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2014-10-28
12 Pete Resnick
[Ballot comment]
[Sorry for the resend; forgot to cut/paste one bit into my ballot.]

3/4: I don't understand what the point of putting these two …
[Ballot comment]
[Sorry for the resend; forgot to cut/paste one bit into my ballot.]

3/4: I don't understand what the point of putting these two sections into the document. They don't add anything to the discussion of the protocol, AFAICT, and are referring to a document that is still in IESG Evaluation and IMO has some serious problems. Please delete these sections.

6.5 -

  If it attempts to re-use a stream which is part of an
  existing data channel, the addition SHOULD fail.
 
What does an implementation do if it *doesn't* fail? That is, why is this a SHOULD, and under what circumstances would you ignore the SHOULD?
 
  In addition to
  choosing a stream, the application SHOULD also determine the options
  to use for sending messages.  The application MUST ensure in an
  application-specific manner that the application at the peer will
  also know the selected stream to be used, and the options for sending
  data from that side.

I don't understand what the SHOULD and MUST here mean. Don't you just mean "will" in both cases?

6.6 -

OLD
  The following PPIDs MUST be used (see Section 8):
NEW
  Only the following PPIDs MUST be used (see Section 8):

or better yet:

  This specification uses the following four PPIDs (see Section 8).
  Other PPIDs MUST NOT be used for WebRTC data channels.

6.7 - s/MUST/is

8 - Why are you re-using (and renaming) previously registered values instead of creating new ones, given that this is a FCFS registry?
2014-10-28
12 Pete Resnick Ballot comment text updated for Pete Resnick
2014-10-28
12 Pete Resnick
[Ballot comment]
6.5 -

  If it attempts to re-use a stream which is part of an
  existing data channel, the addition SHOULD fail. …
[Ballot comment]
6.5 -

  If it attempts to re-use a stream which is part of an
  existing data channel, the addition SHOULD fail.
 
What does an implementation do if it *doesn't* fail? That is, why is this a SHOULD, and under what circumstances would you ignore the SHOULD?
 
  In addition to
  choosing a stream, the application SHOULD also determine the options
  to use for sending messages.  The application MUST ensure in an
  application-specific manner that the application at the peer will
  also know the selected stream to be used, and the options for sending
  data from that side.

I don't understand what the SHOULD and MUST here mean. Don't you just mean "will" in both cases?

6.6 -

OLD
  The following PPIDs MUST be used (see Section 8):
NEW
  Only the following PPIDs MUST be used (see Section 8):

or better yet:

  This specification uses the following four PPIDs (see Section 8).
  Other PPIDs MUST NOT be used for WebRTC data channels.

6.7 - s/MUST/is

8 - Why are you re-using (and renaming) previously registered values instead of creating new ones, given that this is a FCFS registry?
2014-10-28
12 Pete Resnick [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick
2014-10-28
12 Richard Barnes IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2014-10-28
12 Richard Barnes Ballot has been issued
2014-10-28
12 Richard Barnes [Ballot Position Update] New position, Yes, has been recorded for Richard Barnes
2014-10-28
12 Richard Barnes Created "Approve" ballot
2014-10-23
12 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2014-10-17
12 Richard Barnes Placed on agenda for telechat - 2014-10-30
2014-10-16
12 Jean Mahoney Request for Last Call review by GENART is assigned to Vijay Gurbani
2014-10-16
12 Jean Mahoney Request for Last Call review by GENART is assigned to Vijay Gurbani
2014-10-16
12 Tero Kivinen Request for Last Call review by SECDIR is assigned to David Harrington
2014-10-16
12 Tero Kivinen Request for Last Call review by SECDIR is assigned to David Harrington
2014-10-16
12 Pearl Liang
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-rtcweb-data-channel-12.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon …
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-rtcweb-data-channel-12.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We received the following comments/questions from the IANA's reviewer:

IANA understands that, upon approval of this document, there is a single action which
IANA must complete.

In the SCTP Payload Protocol Identifiers subregistry of the Stream Control Transmission
Protocol (SCTP) Parameters registry located at:

http://www.iana.org/assignments/sctp-parameters/

six existing registrations, using First Come First Served as defined in RFC 5226, were
made as follows:

OLD:
51 DOMString Last  [Michael_Tuexen] 2013-09-20
52 Binary Data Partial [Michael_Tuexen] 2013-09-20
53 Binary Data Last [Michael_Tuexen] 2013-09-20
54 DOMString Partial [Michael_Tuexen] 2013-09-20
56 WebRTC String Empty [draft-ietf-rtcweb-data-channel] 2014-08-22
57 WebRTC Binary Empty [draft-ietf-rtcweb-data-channel] 2014-08-22

In each of first four registrations, the reference will be changed to [ RFC-to-be ]. In the
cases of values 52 and 54, the registration will be marked "deprecated." 

NEW:

  +-------------------------------+----------+-----------+------------+
  | Value                        | SCTP    | Reference | Date      |
  |                              | PPID    |          |            |
  +-------------------------------+----------+-----------+------------+
  | WebRTC String                | 51      | [RFCXXXX] | 2013-09-20 |
  | WebRTC Binary Partial        | 52      | [RFCXXXX] | 2013-09-20 |
  | (Deprecated)                  |          |          |            |
  | WebRTC Binary                | 53      | [RFCXXXX] | 2013-09-20 |
  | WebRTC String Partial        | 54      | [RFCXXXX] | 2013-09-20 |
  | (Deprecated)                  |          |          |            |
  | WebRTC String Empty          | 56      | [RFCXXXX] | 2014-08-22 |
  | WebRTC Binary Empty          | 57      | [RFCXXXX] | 2014-08-22 |
  +-------------------------------+----------+-----------+------------+

IANA understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.
2014-10-16
12 (System) IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2014-10-12
12 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Niclas Comstedt
2014-10-12
12 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Niclas Comstedt
2014-10-10
12 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2014-10-10
12 Amy Vezza Last call announcement was generated
2014-10-09
12 Richard Barnes Last call was requested
2014-10-09
12 Richard Barnes IESG state changed to Last Call Requested from In Last Call
2014-10-09
12 Richard Barnes Last call announcement was changed
2014-10-09
12 Cindy Morgan
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (WebRTC Data Channels) to Proposed …
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (WebRTC Data Channels) to Proposed Standard


The IESG has received a request from the Real-Time Communication in
WEB-browsers WG (rtcweb) to consider the following document:
- 'WebRTC Data Channels'
  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
ietf@ietf.org mailing lists by 2014-10-23. 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


  The WebRTC framework specifies protocol support for direct
  interactive rich communication using audio, video, and data between
  two peers' web-browsers.  This document specifies the non-media data
  transport aspects of the WebRTC framework.  It provides an
  architectural overview of how the Stream Control Transmission
  Protocol (SCTP) is used in the WebRTC context as a generic transport
  service allowing WEB-browsers to exchange generic data from peer to
  peer.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-channel/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-channel/ballot/


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


2014-10-09
12 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2014-10-09
12 Cindy Morgan Last call announcement was generated
2014-10-09
12 Richard Barnes Last call was requested
2014-10-09
12 Richard Barnes IESG state changed to Last Call Requested from AD Evaluation
2014-10-09
12 Ted Hardie
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard,

Informational, Experimental, or Historic)? Why is this the proper type of RFC? …
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard,

Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC

indicated in the title page header?

draft-­ietf­-rtcweb­-data­-channel is targeted at the Standards track, and this write­up is for Proposed

Standard. This is reflected on the title page and in the data tracker. Note that there is a related

draft: draft­-ietf­-rtcweb­-data­-protocol. I recommend that the two drafts be sent to IETF last call

together and be considered by the IESG together.

(2) The IESG approval announcement includes a Document Announcement Write­Up. Please

provide such a Document Announcement Write­Up. Recent examples can be found in the

"Action" announcements for approved documents. The approval announcement contains the

following sections:

Technical Summary:

This document specifies the non­media data transport aspects of the WebRTC

framework. It provides an architectural overview of how the Stream Control Transmission

Protocol (SCTP) is used in the WebRTC context as a generic transport service.  It also contains a set of use cases and requirements.

Working Group Summary:

There was early discussion of the stacking order, but there has been no significant

controversy since that was fixed. There have been a number of discussion on how to manage

particular aspects of the larger context (e.g. WebRTC­level congestion control, since SCTP

manages congestion control at the association level) and this has played a part in those, but

not in any way that made it the focus of controversy.  There was a late request for additional compatibility with the WebSockets API, which resulted in significant additional text in section 6.4.  This has been reviewed in the working group, but additional attention to this text in AD and IESG review may be warranted.

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors

indicated their plan to implement the specification? Are there any reviewers that merit

special mention as having done a thorough review, e.g., one that resulted in important

changes or a conclusion that the document had no substantive issues? If there was a MIB

Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a

Media Type review, on what date was the request posted?\

There are implmentations of previous versions of this document, and we expect updates to

them to the final version. Vendor support seems solid. This document did not require

expert review of the types noted.

Personnel:

The document shepherd is Ted Hardie; the responsible Area Director is Richard Barnes.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If

this version of the document is not ready for publication, please explain why the document is

being forwarded to the IESG.

This document and its companion document were re­read, the IPR tracker consulted, and the

minutes of the most recent meetings (plenary and interim) reviewed.  The final changes caused by the additional of the labels were reviewed.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews

that have been performed?

I do not have any concerns about the working group reviews to date, nor about the reviews

conducted by SCTP folks or DTLS folks. Because of the complexity of this stack, however, I

remain eager to solicit community review of the whole. The number of working group participants

who actively contributed to more than one aspect of the document was low compared to the

overall size of the group,

There have been implementations of previous versions of this specification, so it is clear that the

whole works, but additional thought on the whole stack from new perspectives would valuable.

(5) Do portions of the document need review from a particular or from broader perspective, e.g.,

security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe

the review that took place.

Security review is always welcome. Because portions of the specification rely on work in the

SCTP working group, review of the spec from within that community has already taken place.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document

that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps

he or she is uncomfortable with certain parts of the document, or has concerns whether there

really is a need for it. In any event, if the WG has discussed those issues and has indicated that it

still wishes to advance the document, detail those concerns here.

As noted above, the stack appears to be a workable, but additional thinking about the problem

space may eventually yield more elegant approaches. Real­ world deployment will, I expect,

eventually guide the development of a bis. In the mean time, this should be finished so that the

current state converges.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full

conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain

why?

Yes

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG

discussion and conclusion regarding the IPR disclosures.

No IPR has been filed on this document, its companion document or the antecedent drafts.

(9) How solid is the WG consensus behind this document? Does it represent the strong

concurrence of a few individuals, with others being silent, or does the WG as a whole understand

and agree with it?

The working group as a whole concurs with this approach.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please

summarise the areas of conflict in separate email messages to the Responsible Area Director. (It

should be in a separate email because this questionnaire is publicly available.)

No appeal has been threatened nor has extreme discomfort surfaced elsehwere..

(11) Identify any ID nits the Document Shepherd has found in this document. (See

http://www.ietf.org/tools/idnits/ and the Internet­Drafts Checklist). Boilerplate checks are not

enough; this check needs to be thorough.

The document was updated near the draft deadline, as were several documents on which it

depends; as a result, it has a number of stale references to previous versions. There is one

reference to RFC 4347, which has been obsoleted by RFC 6347, but this is an intentional

reference to DTLS 1.0 in preference to a reference to DTLS 1.2. The working group discussed

which version to require and preferred the early version, since it was the most widely

implemented. See the mailing list thread begun here:

http://www.ietf.org/mail­archive/web/rtcweb/current/msg12562.html.  As noted in the companion write-up, there is a chance that later discussion may result in a preference for DTLS 1.2 emerging (as time marches on, it will obviously be more prevalent).  If that takes place, this adjustment will be needed.  There is also a type in the Security considerations "I should" should be "It should", but this did not seem to be worth a re-spin.

(12) Describe how the document meets any required formal review criteria, such as the MIB

Doctor, media type, and URI type reviews.

This document does not present the need for these reviews.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are

otherwise in an unclear state? If such normative references exist, what is the plan for their

completion?

There are normative references to two RTCWEB working group drafts (the security and security-
architecture documents) and to two documents the working group (one in TSVWG: draft­ietf-
tsvwg­sctp­ndata and on in SCTP: draft­ietf­tsvwg­sctp­dtls­encaps). The working group

documents are moving forward well and should reach the IESG shortly; those outside the working

group have been adopted and are active work items. Until they are approved, this document will

await their references. We are not requesting downrefs for either.

(15) Are there downward normative references references (see RFC 3967)? If so, list these

downward references to support the Area Director in the Last Call procedure.

There are no requests for downward references.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs

listed on the title page header, listed in the abstract, and discussed in the introduction? If the

RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the

document where the relationship of this document to the other RFCs is discussed. If this

information is not in the document, explain why the WG considers it unnecessary.

This document does not change the status of any existing RFC.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially

with regard to its consistency with the body of the document. Confirm that all protocol extensions

that the document makes are associated with the appropriate reservations in IANA registries.

Confirm that any referenced IANA registries have been clearly identified. Confirm that newly

created IANA registries include a detailed specification of the initial contents for the registry, that

allocations procedures for future registrations are defined, and a reasonable name for the new

registry has been suggested (see RFC 5226).

This document requests an update to an existing registry (SCTP Payload Protocol Identifiers);

the update is not controversial within the working group.  Note, however, that there is a change in both the registry pointers and, in some case, the name of the entry, which may cause some further discussion.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any

public guidance that the IESG would find useful in selecting the IANA Experts for these new

registries.

This document does not request new registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate

sections of the document written in a formal language, such as XML code, BNF rules, MIB

definitions, etc.

This document does not use a formal grammar of this type.
2014-09-28
12 Michael Tüxen IANA Review state changed to Version Changed - Review Needed from IANA - Not OK
2014-09-28
12 Michael Tüxen New version available: draft-ietf-rtcweb-data-channel-12.txt
2014-08-12
11 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2014-08-12
11 Pearl Liang
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-rtcweb-data-channel-11.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon …
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-rtcweb-data-channel-11.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We received the following comments/questions from the IANA's reviewer:

We have a question about the requested action in this document.

IANA understands that, upon approval of this document, there is a single action which IANA must complete.

In the SCTP Payload Protocol Identifiers subregistry of the Stream Control Transmission Protocol (SCTP) Parameters registry located at:

http://www.iana.org/assignments/sctp-parameters/

four existing registrations, using First Come, First Served as defined in RFC 5226, were made as follows:

OLD:
51 DOMString Last  [Michael_Tuexen] 2013-09-20
52 Binary Data Partial [Michael_Tuexen] 2013-09-20
53 Binary Data Last [Michael_Tuexen] 2013-09-20
54 DOMString Partial [Michael_Tuexen] 2013-09-20

In each of these four registrations, the reference will be changed to [ RFC-to-be ]. In the cases of values 52 and 54, the registration will be marked "deprecated." 

NEW:
+------------------------------------+-----------+----------------+
| Value | SCTP PPID | Reference |
+------------------------------------+-----------+----------------+
| WebRTC String | 51 | RFC-to-be |
| WebRTC Binary Partial (Deprecated) | 52 |  RFC-to-be |
| WebRTC Binary | 53 |  RFC-to-be |
| WebRTC String Partial (Deprecated) | 54 |  RFC-to-be |
+------------------------------------+-----------+----------------+

QUESTION: Do the authors intend to keep the listed date in the registry? 

IANA understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.
2014-08-08
11 Richard Barnes IESG state changed to AD Evaluation from In Last Call
2014-08-08
11 Amy Vezza IANA Review state changed to IANA - Review Needed
2014-08-08
11 Amy Vezza
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (WebRTC Data Channels) to Proposed …
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (WebRTC Data Channels) to Proposed Standard


The IESG has received a request from the Real-Time Communication in
WEB-browsers WG (rtcweb) to consider the following document:
- 'WebRTC Data Channels'
  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
ietf@ietf.org mailing lists by 2014-08-22. 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


  The WebRTC framework specifies protocol support for direct
  interactive rich communication using audio, video, and data between
  two peers' web-browsers.  This document specifies the non-media data
  transport aspects of the WebRTC framework.  It provides an
  architectural overview of how the Stream Control Transmission
  Protocol (SCTP) is used in the WebRTC context as a generic transport
  service allowing WEB-browsers to exchange generic data from peer to
  peer.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-channel/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-channel/ballot/


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


2014-08-08
11 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2014-08-08
11 Richard Barnes Last call was requested
2014-08-08
11 Richard Barnes Ballot approval text was generated
2014-08-08
11 Richard Barnes IESG state changed to Last Call Requested from Publication Requested
2014-08-08
11 Richard Barnes Last call announcement was generated
2014-08-08
11 Richard Barnes Ballot writeup was changed
2014-08-08
11 Richard Barnes Ballot writeup was generated
2014-07-08
11 Ted Hardie
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard,

Informational, Experimental, or Historic)? Why is this the proper type of RFC? …
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard,

Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC

indicated in the title page header?

draft­ietf­rtcweb­data­channel is targeted at the Standards track, and this write­up is for Proposed

Standard. This is reflected on the title page and in the data tracker. Note that there is a related

draft: draft­ietf­rtcweb­data­protocol. I recommend that the two drafts be sent to IETF last call

together and be considered by the IESG together.

(2) The IESG approval announcement includes a Document Announcement Write­Up. Please

provide such a Document Announcement Write­Up. Recent examples can be found in the

"Action" announcements for approved documents. The approval announcement contains the

following sections:

Technical Summary:

This document specifies the non­media data transport aspects of the WebRTC

framework. It provides an architectural overview of how the Stream Control Transmission

Protocol (SCTP) is used in the WebRTC context as a generic transport service.

Working Group Summary:

There was early discussion of the stacking order, but there has been no significant

controversy since that was fixed. There have been a number of discussion on how to manage

particular aspects of the larger context (e.g. WebRTC­level congestion control, since SCTP

manages congestion control at the association level) and this has played a part in those, but

not in any way that mde it the focus of controversy.

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors

indicated their plan to implement the specification? Are there any reviewers that merit

special mention as having done a thorough review, e.g., one that resulted in important

changes or a conclusion that the document had no substantive issues? If there was a MIB

Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a

Media Type review, on what date was the request posted?\

There are implmentations of previous versions of this document, and we expect updates to

them to the final version. Vendor support seems solid. This document did not require

expert review of the types noted.

Personnel:

The document shepherd is Ted Hardie; the responsible Area Director is Richard Barnes.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If

this version of the document is not ready for publication, please explain why the document is

being forwarded to the IESG.

This document and its companion document were re­read, the IPR tracker consulted, and the

minutes of the most recent meetings (plenary and interim) reviewed.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews

that have been performed?

I do not have any concerns about the working group reviews to date, nor about the reviews

conducted by SCTP folks or DTLS folks. Because of the complexity of this stack, however, I

remain eager to solicit community review of the whole. The number of working group participants

who actively contributed to more than one aspect of the document was low compared to the

overall size of the group,

There have been implementations of previous versions of this specification, so it is clear that the

whole works, but additional thought on the whole stack from new perspectives would valuable.

(5) Do portions of the document need review from a particular or from broader perspective, e.g.,

security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe

the review that took place.

Security review is always welcome. Because portions of the specification rely on work in the

SCTP working group, review of the spec from within that community has already taken place.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document

that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps

he or she is uncomfortable with certain parts of the document, or has concerns whether there

really is a need for it. In any event, if the WG has discussed those issues and has indicated that it

still wishes to advance the document, detail those concerns here.

As noted above, the stack appears to be a workable, but additional thinking about the problem

space may eventually yield more elegant approaches. Real­world deployment will, I expect,

eventually guide the development of a bis. In the mean time, this should be finished so that the

current state converges.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full

conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain

why?

Yes

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG

discussion and conclusion regarding the IPR disclosures.

No IPR has been filed on this document, its companion document or the antecedent drafts.

(9) How solid is the WG consensus behind this document? Does it represent the strong

concurrence of a few individuals, with others being silent, or does the WG as a whole understand

and agree with it?

The working group as a whole concurs with this approach.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please

summarise the areas of conflict in separate email messages to the Responsible Area Director. (It

should be in a separate email because this questionnaire is publicly available.)

No appeal has been threatened nor has extreme discomfort surfaced elsehwere..

(11) Identify any ID nits the Document Shepherd has found in this document. (See

http://www.ietf.org/tools/idnits/ and the Internet­Drafts Checklist). Boilerplate checks are not

enough; this check needs to be thorough.

The document was updated near the draft deadline, as were several documents on which it

depends; as a result, it has a number of stale references to previous versions. There is one

reference to RFC 4347, which has been obsoleted by RFC 6347, but this is an intentional

reference to DTLS 1.0 in preference to a reference to DTLS 1.2. The working group discussed

which version to require and preferred the early version, since it was the most widely

implemented. See the mailing list thread begun here:

http://www.ietf.org/mail­archive/web/rtcweb/current/msg12562.html

(12) Describe how the document meets any required formal review criteria, such as the MIB

Doctor, media type, and URI type reviews.

This document does not present the need for these reviews.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are

otherwise in an unclear state? If such normative references exist, what is the plan for their

completion?

There are normative references to two RTCWEB working group drafts (the security and security-
architecture documents) and to two documents the working group (one in TSVWG: draft­ietf-
tsvwg­sctp­ndata and on in SCTP: draft­ietf­tsvwg­sctp­dtls­encaps). The working group

documents are moving forward well and should reach the IESG shortly; those outside the working

group have been adopted and are active work items. Until they are approved, this document will

await their references. We are not requesting downrefs for either.

(15) Are there downward normative references references (see RFC 3967)? If so, list these

downward references to support the Area Director in the Last Call procedure.

There are no requests for downward references.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs

listed on the title page header, listed in the abstract, and discussed in the introduction? If the

RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the

document where the relationship of this document to the other RFCs is discussed. If this

information is not in the document, explain why the WG considers it unnecessary.

This document does not change the status of any existing RFC.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially

with regard to its consistency with the body of the document. Confirm that all protocol extensions

that the document makes are associated with the appropriate reservations in IANA registries.

Confirm that any referenced IANA registries have been clearly identified. Confirm that newly

created IANA registries include a detailed specification of the initial contents for the registry, that

allocations procedures for future registrations are defined, and a reasonable name for the new

registry has been suggested (see RFC 5226).

This document requests an update to an existing registry (SCTP Payload Protocol Identifiers);

the update is not controversial within the working group.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any

public guidance that the IESG would find useful in selecting the IANA Experts for these new

registries.

This document does not request new registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate

sections of the document written in a formal language, such as XML code, BNF rules, MIB

definitions, etc.

This document does not use a formal grammar of this type.
2014-07-08
11 Ted Hardie State Change Notice email list changed to rtcweb-chairs@tools.ietf.org, draft-ietf-rtcweb-data-channel@tools.ietf.org
2014-07-08
11 Ted Hardie Responsible AD changed to Richard Barnes
2014-07-08
11 Ted Hardie IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2014-07-08
11 Ted Hardie IESG state changed to Publication Requested
2014-07-08
11 Ted Hardie IESG process started in state Publication Requested
2014-07-08
11 Ted Hardie Changed document writeup
2014-07-04
11 Michael Tüxen New version available: draft-ietf-rtcweb-data-channel-11.txt
2014-06-30
10 Ted Hardie Intended Status changed to Proposed Standard from None
2014-06-30
10 Ted Hardie IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2014-06-19
10 Ted Hardie Document shepherd changed to Ted Hardie
2014-06-19
10 Ted Hardie IETF WG state changed to In WG Last Call from WG Document
2014-06-09
10 Randell Jesup New version available: draft-ietf-rtcweb-data-channel-10.txt
2014-05-15
09 Michael Tüxen New version available: draft-ietf-rtcweb-data-channel-09.txt
2014-04-09
08 Michael Tüxen New version available: draft-ietf-rtcweb-data-channel-08.txt
2014-02-11
07 Michael Tüxen New version available: draft-ietf-rtcweb-data-channel-07.txt
2014-01-10
06 Magnus Westerlund Document shepherd changed to Magnus Westerlund
2013-10-21
06 Michael Tüxen New version available: draft-ietf-rtcweb-data-channel-06.txt
2013-07-15
05 Michael Tüxen New version available: draft-ietf-rtcweb-data-channel-05.txt
2013-02-25
04 Randell Jesup New version available: draft-ietf-rtcweb-data-channel-04.txt
2013-02-24
03 Michael Tüxen New version available: draft-ietf-rtcweb-data-channel-03.txt
2012-10-22
02 Randell Jesup New version available: draft-ietf-rtcweb-data-channel-02.txt
2012-09-07
01 Randell Jesup New version available: draft-ietf-rtcweb-data-channel-01.txt
2012-03-05
00 Randell Jesup New version available: draft-ietf-rtcweb-data-channel-00.txt