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

"Muthu Arul Mozhi Perumal (mperumal)" <> Fri, 16 August 2013 02:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AF9A211E823B for <>; Thu, 15 Aug 2013 19:07:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fzJ18Jel26Nu for <>; Thu, 15 Aug 2013 19:07:22 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id ED7C811E8235 for <>; Thu, 15 Aug 2013 19:07:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=31905; q=dns/txt; s=iport; t=1376618842; x=1377828442; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=qh8cdhWYlvB4UvpwrosWCGKaI7nXrMDTMjpjDmTW7fI=; b=UwzLp4VTnJadiiwtD6rW68NtbamFHOwVckEgQAz7WPDkNJ+69jTMBhzl Za0vEWlyzLvWbtmd9ZWelstddwMpMlHFik8CKqwChgX4LY7SyM7v/WMC6 QN+EUXjYypOoZvvOWssMQnHaEB2wTNdAxaAkv9na4LRKndyMFlA6VcU4c w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos; i="4.89,890,1367971200"; d="scan'208,217"; a="247762092"
Received: from ([]) by with ESMTP; 16 Aug 2013 02:07:21 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id r7G27LMp017760 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 16 Aug 2013 02:07:21 GMT
Received: from ([]) by ([]) with mapi id 14.02.0318.004; Thu, 15 Aug 2013 21:07:20 -0500
From: "Muthu Arul Mozhi Perumal (mperumal)" <>
To: Bernard Aboba <>, "" <>
Thread-Topic: [rtcweb] Unresolved normative references in IETF RTCWEB WG documents
Thread-Index: AQHOmfr73dJXuy10RE28IQN/c2d4XJmXFdHw
Date: Fri, 16 Aug 2013 02:07:20 +0000
Message-ID: <>
References: <BLU169-W11426A149ADD0123A6BEF4C93460@phx.gbl>
In-Reply-To: <BLU169-W11426A149ADD0123A6BEF4C93460@phx.gbl>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_E721D8C6A2E1544DB2DEBC313AF54DE224207685xmbrcdx02ciscoc_"
MIME-Version: 1.0
Subject: Re: [rtcweb] Unresolved normative references in IETF RTCWEB WG documents
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 16 Aug 2013 02:07:29 -0000

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


From: [] On Behalf Of Bernard Aboba
Sent: Friday, August 16, 2013 2:34 AM
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).


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.