Subject: [rtcweb] RTP usage: requirement levels

From: Martin Thomson <[email-masked]>
Date: Mon, 16 Jul 2012 11:38:59 -0700

The RTP usage draft current uses MUST, SHOULD, MAY to indicate two
levels of compliance.  This is not a particularly good division for
this sort of draft.

Firstly, it's unclear what meaningful distinction there is between
SHOULD and MAY.  Then there is the distinction between MUST implement
and MUST use.

The following classifications are more relevant to this sort of draft.

mandatory to USE
 - all implementations MUST always use this feature
 - there is no reason to signal support for the feature
 - there is no reason to provide a means to disable it
 - no API requirements need to be derived for features that are mandatory to use

mandatory to IMPLEMENT
 - all implementations MUST include support for the feature
 - implementations MUST provide a means to enable and disable the
feature (API requirement)
 - there is no API requirement for indicating support of the feature

mandatory to DISABLE
 - implementations MAY include support for the feature
 - implementations MUST provide a means to signal support for the
feature (API requirement)
 - implementations that support the feature MUST provide a means to
enable and disable the feature (optional API requirement)

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 16 Jul 2012 15:15:21 -0700

Good questions.  Some comments below. 

> Date: Mon, 16 Jul 2012 11:38:59 -0700
> From: [email-masked]
> To: [email-masked]
> Subject: [rtcweb] RTP usage: requirement levels
> 

[BA] Overall, I think we need a cleaner understanding of the meaning of the term "signal" in this document. 

The RTP usage document does not update any SDP standards, so if an SDP RFC describes how to do something, that still applies to SDP transmitted on the wire. 

On the other hand, if we are talking about whether an JSEP API implementation has to handle SDP that omits a mandatory to use feature (e.g., offering RTP/AVP with no key management functionality), I'd say "not a requirement, but an appropriate error message is still needed". 

>  - there is no reason to provide a means to disable it

[BA] If this is referring to the API, I would agree.  If we are referring to SDP, I'd say that the usual rules apply.  An endpoint (which after all could be legacy communicating via a gateway) can send a valid SDP answer that might not result in a session being established.  Being able to clearly indicate why the session could not be established is better than an undiagnosable failure. 

>  - there is no API requirement for indicating support of the feature

[BA]  Even if something is "mandatory to implement" there could still be a need to for the feature to be included in an SDP blob output by createOffer(), no?  Or to have a constraint relating to the feature?

---

From: Martin Thomson <[email-masked]>
Date: Mon, 16 Jul 2012 15:23:40 -0700

> term "signal" in this document.

Ah yes, that was an unfortunate choice of words.  To be absolutely
clear, I am talking about the nature of the information that is
required to pass between browser and javascript, not some sort of
signaling protocol.  SDP is a signaling protocol.

That said, if you need to use SDP, then you need to follow the rules
established by SDP.  That means that you might have to include some
things that are optional in SDP but not rtcweb, and you might feel
inclined to reject SDP that would be otherwise valid.

---

From: Colin Perkins <[email-masked]>
Date: Tue, 17 Jul 2012 10:32:38 +0100

Martin,

If you have suggestions for specific changes where the recommendations in the draft are unclear, we'd be happy to receive them. The classifications you suggest below are not appropriate for all the normative statements in the draft, so it's not clear exactly what you think needs to change.

Colin

On 16 Jul 2012, at 19:38, Martin Thomson wrote:
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

-- 
Colin Perkins
http://csperkins.org/

---

From: Martin Thomson <[email-masked]>
Date: Tue, 17 Jul 2012 10:17:23 -0700

> If you have suggestions for specific changes where the recommendations in the draft are unclear, we'd be happy to receive them. The classifications you suggest below are not appropriate for all the…

I thought that I was being specific.  I would like to see an end to
the shoehorning of 2119 language into classifications that are
inappropriate for 2119 language.

As a profile, a normative statement that doesn't directly pertain to
whether a feature is implemented or not would be out of place.  Much
of the 2119 language that is left over is simply reiteration of
requirements made in the referenced specifications.  For instance,
   [...] The use of header
   extensions is OPTIONAL in the WebRTC context, but if they are used,
   they MUST be formatted and signalled following the general mechanism
   for RTP header extensions defined in [RFC5285],

In this case, the first "OPTIONAL" implies that an implementation can
implement this, but if they do, they must provide a) a way to disable
the feature, and b) a way to indicate support for the feature.  A
clear classification that included this information would be useful.
Of course, the second "MUST" is a reiteration of language in 5285.
(To be clear, reiteration of this sort is harmless, except where the
language overlaps with the core purpose of the document.)

Specific problems:

"RECOMMENDED" is used a lot in the document.  It could be clearer if
the admonitions made in Section 3 regarding "MAY" also apply to these.
 The distinction between these two requirement levels is toothless.
"MUST...unless" is a far less ambiguous construct, unless a feature
really is optional.

CNAME generation is currently "RECOMMENDED", but the text then goes on
to say that it doesn't meet the bar for privacy.  I would argue for
MUST on draft-rescorla-random-cname, but we probably need more
discussion on that.

Section 5.1 says "These RECOMMENDED topologies are expected to be
supported by all WebRTC end-points "  which is a non-requirement.

Here's a good example:

   Senders are REQUIRED to understand the Generic NACK message defined
   in Section 6.2.1 of [RFC4585], but MAY choose to ignore this feedback [...]
   Receivers MAY send NACKs for missing RTP packets

This seems clear, but who decides to ignore the feedback?  Can you
negotiate the use of the generic NACK?  That is, is this MUST
implement or MUST use ?

A clearer way to describe this would be to describe a feature (in this
case, two features: NACK and retx) and then indicate whether each is
MUST implement, MUST use or whatever.

---

From: Colin Perkins <[email-masked]>
Date: Wed, 18 Jul 2012 15:43:02 +0100

On 17 Jul 2012, at 18:17, Martin Thomson wrote:
> the shoehorning of 2119 language into classifications that are inappropriate for 2119 language.

I disagree that these are inappropriate uses of the RFC 2119 language.

> language overlaps with the core purpose of the document.)

The 2nd MUST is a statement that the RFC5285 mechanism is to be used, not a reiteration of the requirements in RFC5285. Your first points are implied by OPTIONAL, as you note.

> "MUST...unless" is a far less ambiguous construct, unless a feature

I disagree. The RFC 2119 terms are well defined, and have clear meaning. 

> MUST on draft-rescorla-random-cname, but we probably need more

As I've previously stated, if AVTCORE adopts EKR's random CNAME draft, the reference can be changed. 

> supported by all WebRTC end-points "  which is a non-requirement.

Agree. That should be clarified.

> This seems clear, but who decides to ignore the feedback?  

The sender may choose to ignore the feedback. The text seems clear to me.

> Can you negotiate the use of the generic NACK?  That is, is this MUST
> implement or MUST use ?

Neither; this is why the current phrasing is used.

> MUST implement, MUST use or whatever.

I disagree.

-- 
Colin Perkins
http://csperkins.org/