Re: [rtcweb] Unresolved normative references in IETF RTCWEB WG documents

["Muthu Arul Mozhi Perumal (mperumal)" <[e-mail]>]

On I-D.muthu-behave-consent-freshness, we are currently discussing with the related chairs to find a home for it..

Muthu

From: [e-mail] [mailto:[e-mail]] On Behalf Of Bernard Aboba
Sent: Friday, August 16, 2013 2:34 AM
To: [e-mail]
Subject: [rtcweb] Unresolved normative references in IETF RTCWEB WG documents

I've taken a look at the unresolved normative references in all of the current RTCWEB WG work items.  Here are some comments.

Overall comment

Several of the documents (draft-ietf-rtcweb-rtp-usage, draft-ietf-rtcweb-security) have a normative reference to draft-ietf-rtcweb-overview, while others do not (draft-ietf-rtcweb-audio, draft-ietf-rtcweb-data-channel, draft-ietf-rtcweb-data-protocol, draft-ietf-rtcweb-security-arch).  While it probably makes sense for some documents to reference an overview of WebRTC, the overview document also functions as an overview of work relating to WebRTC, so that it has 9 unresolved normative dependencies.  The effect of a normative reference to the overview document is therefore to delay publication until all of the overview normative dependencies are resolved.  I am therefore wondering whether the normative references to the overview document are really necessary, or whether the dependencies shouldn't just go one way (e.g. from the overview to the other docs).

draft-ietf-rtcweb-data-channel

Two unresolved normative references in this document are to individual submissions:  [I-D.stewart-tsvwg-sctp-ndata], [I-D.jesup-rtcweb-data-protocol] (now an RTCWEB WG work item).   The reference to  [I-D.tuexen-tsvwg-sctp-prpolicies<http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-05#ref-I-D.tuexen-tsvwg-sctp-prpolicies>] is informative, even though the document refers to it as a MUST implement in Section 6.1.  Was there any progress at IETF 87 on getting the individual submissions adopted as WG work items?

draft-ietf-rtcweb-audio

The normative reference to  [I-D.ekr-security-considerations-for-rtc-web] appears to refer to a 2011 individual submission, rather than the RTCWEB WG Security Considerations document.  The reference is in Section 8, Security Considerations, which states:



   The codec requirements have no additional security considerations

   other than those captured in

   [I-D.ekr-security-considerations-for-rtc-web<http://tools.ietf.org/html/draft-ietf-rtcweb-audio-02#ref-I-D.ekr-security-considerations-for-rtc-web>].


Looking at draft-ietf-rtcweb-security I don't see much in the way of security considerations relating to codecs.  This leads me to wonder whether this reference shouldn't be non-normative, or even whether it could be removed.


draft-ietf-rtcweb-rtp-usage


This document has a normative reference to  [I-D.westerlund-avtcore-transport-multiplexing].  Since that document hasn't been accepted as a WG work item (and Section 4.4 indicates that there is no consensus to use a shim-based approach), I am wondering if that reference should instead be non-normative (or be removed entirely).  Here is what the text in Section 4.4 says:


   It is also possible to use a shim-based approach to run multiple RTP

   sessions on a single transport-layer flow.  This gives advantages in

   some gateway scenarios, and makes it easy to distinguish groups of

   RTP media streams that might need distinct processing.  One way of

   doing this is described in

   [I-D.westerlund-avtcore-transport-multiplexing<http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-07#ref-I-D.westerlund-avtcore-transport-multiplexing>].  At the time of this

   writing, there is no consensus to use a shim-based approach in WebRTC

   implementations.


There is also a normative reference to [I-D.ietf-mmusic-sdp-bundle-negotiation].  Since signaling is out-of-scope of WebRTC, I wonder whether this normative reference, which comes from Section 4.4, is appropriate.  Here is what the text says:





   If such RTP session set-up is to be used, this MUST be negotiated during

   the signalling phase [I-D.ietf-mmusic-sdp-bundle-negotiation<http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-07#ref-I-D.ietf-mmusic-sdp-bundle-negotiation>].




draft-ietf-rtcweb-security-arch


This document has a normative reference to [I-D.muthu-behave-consent-freshness], which as I understand it is not going to be a BEHAVE WG work item.  Does it make sense to pull text from the consent-freshness document into another RTCWEB WG work item?


draft-ietf-rtcweb-overview


This document has 9 unresolved normative dependencies.  Of these, [I-D.nandakumar-rtcweb-stun-uri] and [I-D.tuexen-tsvwg-sctp-dtls-encaps] are to individual submissions.   The latter is now a WG work item (draft-ietf-tsvwg-sctp-dtls-encaps).  As I recall, at IETF 87 we discussed getting AD sponsorship for the stun-uri document, right?


draft-ietf-rtcweb-qos


This document has one unresolved normative reference, to draft-ietf-mmusic-traffic-class-for-sdp.  That document has no unresolved normative dependencies.













draft-ietf-rtcweb-use-cases-and-requirements



This document has no unresolved normative references.   Yeah!







draft-ietf-rtcweb-jsep









This document has 4 unresolved normative dependencies: [I-D.alvestrand-mmusic-msid] (now draft-ietf-mmusic-msid), [I-D.holmberg-mmusic-sdp-bundle-negotiation] (now draft-ietf-mmusic-sdp-bundle), [I-D.jennings-rtcweb-signaling] and [I-D.nandakumar-rtcweb-sdp].   It is also referenced by several documents.  Are all these references necessary?











draft-ietf-rtcweb-data-protocol





This document has two unresolved normative references, but both appear appropriate.