Re: [rtcweb] WGLC review for data channel drafts

[Barry Dingle <[e-mail]>]

I agree with the change to the Abstract in
draft-ietf-rtcweb-data-channel-10 (see below) as Michael proposed.

> draft-ietf-rtcweb-data-channel-10
> ----------------------------------------------
> Abstract
>
> Ten years from now, the RFC will exist, but the RTCWEB WG will not. I
suggest replacing "The Real-Time Communication in Web browsers working
group is charged to" with "The WebRTC framework specifies".
OK so it reads:
<t>*The WebRTC framework specifies protocol support for direct interactive*
* rich communication using audio, video, and data between two peers'
web-browsers.*

But there is great variety in the first introductory words in the abstracts
in the RTCWEB RFC's. Why not use the one agreed introduction in ALL RTCWEB
RFC's?

Michael's words seem to be appropriate for all.

Cheers,
/Barry Dingle



On Sat, Jul 5, 2014 at 3:23 AM, Michael Tuexen <
[e-mail]> wrote:

> On 27 Jun 2014, at 15:00, Harald Alvestrand <[e-mail]> wrote:
>
> > On 06/10/2014 08:52 PM, Ted Hardie wrote:
> >> Dear WG,
> >>
> >> This starts a working group last call for our core Data Channel drafts:
> >>
> >> draft-ietf-rtcweb-data-protocol-06.txt
> >> draft-ietf-rtcweb-data-channel-10.txt
> >>
> >> Please review them in detail, especially for areas which may be of
> concern to the broader IETF community.  This WGLC will end on June 27, 2014.
> >
> > This is my Last Call review of these two drafts.
> First of all, thank you very much for the comments.
> >
> > First of all: The drafts are ready for IETF Last Call.
> > Second: There are a number of details that should be fixed. Whether that
> happens before IETF Last Call or not is not of great concern to me.
> I'll submit an update. That gives all the same basis for further
> discussions.
> >
> > draft-ietf-rtcweb-data-channel-10
> > ----------------------------------------------
> > Abstract
> >
> > Ten years from now, the RFC will exist, but the RTCWEB WG will not. I
> suggest replacing "The Real-Time Communication in Web browsers working
> group is charged to" with "The WebRTC framework specifies".
> OK so it reads:
> <t>The WebRTC framework specifies protocol support for direct interactive
> rich communication using audio, video, and data between two peers'
> web-browsers.
> >
> > 1. Introduction
> >
> > It's a little abrupt. Some more words of introduction may be needed
> here. Something like this:
> >
> > In the WebRTC framework, communication between the parties consists of
> media (for example audio and video) and non-media data. Media is sent using
> SRTP, and is not specified further here. Non-media data is handled by...."
> Done. Good suggestion.
> >
> > I suggest a global replace of "non-SRTP media data" with "non-media
> data" (3 occurences total). "non-SRTP media data" can be parsed as "media
> data that is not carried over SRTP", which is not the intended meaning.
> Done.
> >
> > 4. Requirements
> >
> > Suggest striking "and that the WebRTC PeerConnection as a whole is fair
> with competing traffic such as TCP". The RMCAT discussions have proved how
> difficult it is just to define that, far less achieve it.
> > If we want to say something in relation to TCP, I would suggest "and
> that the WebRTC PeerConnection does not cause excessive problems when run
> in parallel with TCP connections".
> Taken.
> >
> > 5. SCTP over DTLS over UDP Considerations
> >
> > In the paragraph on SCTP multihoming, I suggest using "the DTLS layer"
> instead of "the lower layer". There are multiple lower layers, identifying
> which one is mentioned here improves clarity.
> OK.
> >
> > The term "user-land" is used here, while Req. 10 uses "user application
> space". I suggest using "user application space" in both places.
> OK.
> >
> > The paragraph "When using DTLS as the lower layer..." repeats the info
> that SCTP multihoming is not used. It may be enough to say this once.
> Taken out.
> >
> > "The partial reliability extension MUST support policies..." - this
> paragraph would be more implementable if specific policies, specified in an
> I-D or RFC, were referenced.
> References added.
> >
> > The split between section 5 and section 6 seems odd. In particular, the
> section "This SCTP stack and its upper layer...." down to "exactly once and
> delivered in the order received." seems to belong to section 6 not section
> 5.
> Text reorganised and removed duplicate text.
> >
> > 6.1 SCTP Protocol Considerations
> >
> > I think the -ndata messsage interleaving MUST be implemented, according
> to previous consensus.
> > "SHOULD be used" seems both meaningless and unneccssary.
> I think the current text covers the case that it is not available in
> implementations yet.
> If you write MUST be implemented, a conformant implementation would reject
> interworking
> with currently existing implementations.
> >
> > 6.2 Association setup
> >
> > Nit: "that can negotiated" -> "that can be negotiated"
> Fixed.
> >
> > 6.4 Channel definition
> >
> > The title should probably be "WebRTC Data Channel Definition".
> OK.
> >
> > As part of getting the WGs out of the document, the first sentence
> should be "The  WebRTC DataChannels are bidirectional."
> OK.
> > "Among other things" is a bad term to have in a document at Last Call
> time. Can we remove it?
> Done.
> >
> > The SHOULD for -ndata- interleaving should be MUST implement and MUST
> offer. If it is not successfully negotiated at association setup time (is
> that how it works?), the "SHOULD limit" clause is appropriate.
> But if it is MUST implement and MUST offer, how could it be not
> negotiated? If it
> is offered by both sides, it is used. The SHOULD covers that it might not
> be supported.
> So I think the text is in tune with other parts of the data channel
> documents.
> >
> > 6.7 Closing a channel
> >
> > Nit: "available to reuse" -> "available for reuse"
> > Nit: "before resetting the stream" -> "before the stream is reset"
> Both fixed.
> >
> > 7 Security considerations
> >
> > Is there a security worry with an attacker sending over-long messages in
> an attempt to cause OOM situations?
> OK, I added:
> <t>I should be noted that a receiver must be prepared that the sender tries
> to send arbitrary large messages.</t>
> >
> > draft-ietf-rtcweb-data-protocol-06
> > ---------------------------------------------
> > Abstract: Same worry about WG reference.
> Same as above.
> >
> > 3. Terminology
> >
> > Stream is defined in terms of stream, which is unhealthy. A reference to
> a section of a relevant SCTP document would be better.
> >
> > The term "SCTP stream" occurs at least 18 times in the document (out of
> approx 41 occurences of "stream" overall). We should either use "SCTP
> stream" consistently" or stick to "Stream" consistently.
> Changed to Stream consistently.
> >
> > The term "SCTP stream identifier" (or "stream identifier") should be
> called out in the terminology.
> OK.
> >
> > The term "data channel" occurs 36 times. Consider standardizing on
> either Channel or Data Channel, and either capitalizing it or not.
> OK. Using Data Channel consistently.
> >
> > 6 Procedures
> > Nit: "the sender of it can start" -> "the sender of the
> DATA_CHANNEL_OPEN can start"
> Done.
> >
> > "If a DATA_CHANNEL_OPEN message is received .... the stream identifier
> corresponds to the role of the peer" - is there a reason to insist that the
> protocol machine enforce the odd/even rule?
> I would like to define what happens if the peer does not follow the
> rule... It has to
> be handled by any implementation, so why leave it up to the implementer?
> > `(actually the next paragraph does not cover the odd/even rule violation
> case, which is probably just an unintentional mistake - I prefer writing
> this kind of thing in "IF <condition> ... ELSE ....
> Jepp, that was unintentional...
> >  - because if one writes it as "IF <condition>; IF <opposite
> condition>", the risk of losing some edge cases is high.
> >
> > An alternative formulation for the second paragraph is "If the
> DATA_CHANNEL_OPEN message doesn't satisfy the conditions above, for
> instance if..."
> Good point. I will use:
> <t>If the DATA_CHANNEL_OPEN message doesn't satisfy the conditions above,
> for instance if a DATA_CHANNEL_OPEN message is received on an already used
> Stream or there are any problems with parameters within the
> DATA_CHANNEL_OPEN
> message, the odd/even rule is violated or the DATA_CHANNEL_OPEN message
> itself
> is not well-formed, the receiver MUST close the corresponding channel
> using the
> procedure described in <xref target='I-D.ietf-rtcweb-data-channel'/> and
> MUST NOT send a DATA_CHANNEL_ACK message in response to the received
> message.
> >
> > 7 Security Considerations
> >
> > The "When using..." paragraph sounds a bit off. What about saying
> >
> > This protocol does not provide privacy, integrity or authentication. It
> needs to be used as part of a protocol suite that contains all these
> things. Such a protocol suite is specified in [-dtls-encaps].
> Taken.
> >
> > Dependency worries
> > ---------------------------
> > -protocol- depends normatively on these non-WG documents:
> >
> > draft-ietf-tsvwg-sctp-ndata ("I-D exists")
> This is currently being worked on.
> > draft-ietf-tsvwg-sctp-dtls-encaps ("AD is watching")
> This is passed WG LC, just incorporating the comments. So there will be a
> new rev tomorrow.
> > draft-ietf-tsvwg-sctp-prpolicies ("I-D exists")
> The WG LC started yesterday. Reviews very welcome!
> > draft-ietf-mmusic-sctp-sdp ("I-D exists")
> I don't know about the status of this.
> >
> > None of these are in the IESG queue. Are we confident of their speed of
> progress?
> >
> >
> > This concludes my review. I think the protocol definition is ready, and
> needs no changes.
> >
> >
> >
> >
> > _______________________________________________
> > rtcweb mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/rtcweb
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>