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

From: Bernard Aboba <[email-masked]>
Date: Thu, 15 Aug 2013 14:03:53 -0700

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] 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].
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].  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].

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.

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Fri, 16 Aug 2013 02:07:20 +0000

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

Muthu

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

Overall comment

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

   [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>].

   [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

   implementations.

   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-qos

draft-ietf-rtcweb-jsep

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 18 Aug 2013 11:37:47 +0200

On 08/15/2013 11:03 PM, Bernard Aboba wrote:
> 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).  
>
In my opinion, the normal case should be that references to -overview
are informative, not normative. Documents should be published when
they're ready.

Most likely, the proper form is something like "This document specifies
a protocol intended for use within the WebRTC effort, but is not
restricted to that context. An overview of the WebRTC effort is given in
[OVERVIEW]".

Or something like that.

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 18 Aug 2013 14:58:53 -0700

Harald said: 

"In my opinion, the normal case should be that references to -overview are
informative, not normative. Documents should be published when they're
ready."

[BA]  Looking over the both RTP usage and security documents, it seems
reasonable to convert the normative references to informative in both cases

Looking at the RTP usage document, there is no normative language that
points to -overview and in fact -overview is only mentioned twice: 

Section 1

   The WebRTC overview [I-D.ietf-rtcweb-overview
<http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-07#ref-I-D.ietf-rtcw
eb-overview> ] outlines the complete
   WebRTC framework, of which this memo is a part.
 
[BA] While -overview does reference RTP usage, and the RTP usage document is
certainly an important part of WebRTC, I don't think this implies a
normative reference to -overview.  After all, almost everything in the RTP
usage document can (and probably has been) implemented outside of WebRTC. 

Section 3

   Other terms are used according to their definitions from the RTP
   Specification [RFC3550 <http://tools.ietf.org/html/rfc3550> ] and WebRTC
overview
   [I-D.ietf-rtcweb-overview
<http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-07#ref-I-D.ietf-rtcw
eb-overview> ] documents.

[BA] This sentence doesn't point to specific terms defined in Section 2.4 of
-overview that are needed for understanding the RTP usage document, but if
there are some, those could be added to the RTP usage document, rather than
requiring a normative reference.  

The security document only has a single reference to -overview: 

Section 1

   The Real-Time Communications on the Web (RTCWEB) working group is
   tasked with standardizing protocols for real-time communications
   between Web browsers, generally called "WebRTC"

   [I-D.ietf-rtcweb-overview
<http://tools.ietf.org/html/draft-ietf-rtcweb-security-05#ref-I-D.ietf-rtcwe
b-overview> ].

[BA] Since the security documents has its own introductory material, and
doesn't reference terminology or other aspects of -overview other than the
above, an informative reference seems like it should be fine.

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Thu, 22 Aug 2013 18:22:03 +0000

On Aug 18, 2013, at 3:37 AM, Harald Alvestrand <[email-masked]> wrote:

> In my opinion, the normal case should be that references to -overview are informative, not normative. Documents should be published when they're ready.
> 
> Most likely, the proper form is something like "This document specifies a protocol intended for use within the WebRTC effort, but is not restricted to that context. An overview of the WebRTC effort is given in [OVERVIEW]".
> 
> Or something like that.
> 

+1

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Thu, 22 Aug 2013 18:31:45 +0000

> 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…

Thanks for reviewing this. I'll work with Justin to sort this out in next version. I suspect they all need to point at the correct document and that the jennings-rtcweb-signaling can be removed.