Re: [rtcweb] WGLC review for data channel drafts

[Harald Alvestrand <[e-mail]>]

On 07/08/2014 05:58 AM, Barry Dingle wrote:
> 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.

I wouldn't mind having standard words in the abstract. It saves arguing.

The call for consensus to do so has to come from our chairs, but I'm 
willing to be part of the consensus (if the proposed text isn't too 
egregrious).


>
> Cheers,
> /Barry Dingle
>
>
>
> On Sat, Jul 5, 2014 at 3:23 AM, Michael Tuexen 
> <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     On 27 Jun 2014, at 15:00, Harald Alvestrand <[e-mail]
>     <mailto:[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] <mailto:[e-mail]>
>     > https://www.ietf.org/mailman/listinfo/rtcweb
>
>     _______________________________________________
>     rtcweb mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/rtcweb
>
>