[rtcweb] Unresolved normative references in IETF RTCWEB WG documents

Bernard Aboba <bernard_aboba@hotmail.com> Thu, 15 August 2013 21:03 UTC

Return-Path: <bernard_aboba@hotmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 211FA11E818F for <rtcweb@ietfa.amsl.com>; Thu, 15 Aug 2013 14:03:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.598
X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id H1i1H2jjsSz3 for <rtcweb@ietfa.amsl.com>; Thu, 15 Aug 2013 14:03:54 -0700 (PDT)
Received: from blu0-omc3-s31.blu0.hotmail.com (blu0-omc3-s31.blu0.hotmail.com []) by ietfa.amsl.com (Postfix) with ESMTP id 201B211E819E for <rtcweb@ietf.org>; Thu, 15 Aug 2013 14:03:54 -0700 (PDT)
Received: from BLU169-W114 ([]) by blu0-omc3-s31.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Aug 2013 14:03:53 -0700
X-TMN: [3R+Gv2yUxC/U/I/1U08ex+WaS81/4j5h]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: <BLU169-W11426A149ADD0123A6BEF4C93460@phx.gbl>
Content-Type: multipart/alternative; boundary="_28d453fb-2069-42e1-b40f-3bd82c79b651_"
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Date: Thu, 15 Aug 2013 14:03:53 -0700
Importance: Normal
MIME-Version: 1.0
X-OriginalArrivalTime: 15 Aug 2013 21:03:53.0836 (UTC) FILETIME=[F30492C0:01CE99FA]
Subject: [rtcweb] Unresolved normative references in IETF RTCWEB WG documents
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Aug 2013 21:03:59 -0000

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).  
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] 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? 
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
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. 
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].  At the time of this
   writing, there is no consensus to use a shim-based approach in WebRTC
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].

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? 
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? 
This document has one unresolved normative reference, to draft-ietf-mmusic-traffic-class-for-sdp.  That document has no unresolved normative dependencies. 

This document has no unresolved normative references.   Yeah! 


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? 


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