[MMUSIC] Review of draft-ietf-mmusic-msid-07

[Ted Hardie <[e-mail]>]

Some time ago I promised a review of this draft, wrote one, and then never
sent it; Ari kindly reminded me that I owed to the group, without properly
berating me for the idiocy.  I've done a quick review of the updates since
the original and updated it.  I followed the template for the Apps Area
Directorate reviews, but this is not a review from that team (and not part
of their archives, etc.)

My apologies for the delay.

Ted

Document: draft-ietf-mmusic-msid
Title: WebRTC MediaStream Identification in the Session Description Protocol


Reviewer: Ted Hardie

Summary: No basic concerns with the mechanism described.
Comments:
Because the document currently describes the WebRTC semantics and makes
specific
references to JSEP, it's not clear that it can safely go forward with JSEP
not yet approved.
JSEP, on the other hand, needs this and BUNDLE to be stable.  Rather than
deadlock on
this at the WG level, I suggest that this document (and Bundle) go forward
even if JSEP is not yet
approved, but with an explicit note that they are not requesting downrefs.
That will
hold them for a final check by authors at the RFC Editor

Major Issues:

Minor Issues:

Section 4 consistently describes the requirements in terms of what the
entity implements, e.g.:

   An entity implmementing an MSID semantic MUST add one or more "msid-
   semantic" attributes to its session level attributes, indicating the
   MSID semantic it supports.

It's not clear this formulation is correct, as there may be cases
where an implementation
supports a specific semantic,but does not wish to use it.  This
hinges, I guess, on what
"entity" means here (the implementation or the instance in which it is
used).  I'd suggest
changing these formulations to something like "An implementation
supporting an MSID semantic
for a specific offer/answer MUST add..." unless there is a strong
reason to believe that
it must be offered if implemented.

Later, in section 5.1, the document says:

  "If an entity implementing the WMS semantic sends a description,
   it MUST include the msid-semantic:WMS attribute, even if no media
   streams are sent. This allows us to distinguish between the case
   of no media streams at the moment and the case of legacy SDP generation."


It's not clear what legacy SDP generation means here. It seems that the
presence of any msid-semantic session level attribute would indicate
that it was not "legacy SDP generation", for at least some values of legacy.

I think the point here is that you want to know at beginning of the session
whether or not WMS semantics will be used, even if there no media to bear
the MSIDs yet.  I'd suggest recasting this to say that, with something like

"In an entity intends to use WMS semantics in a session, it should the
msid-semantic
on sending a description, even if no media are sent"

In the IANA considerations, the document says:

   This document requests IANA to create a new registry called
   "Semantics for the msid-semantic SDP attribute", which should have
   exactly the same rules as for the "Semantics for the ssrc-group SDP
   attribute" registry (Expert Review), and to register the "WMS"
   semantic within this new registry.

Generally, IANA seems to be asking for guidance to the expert when
you create a registry with expert review; if the intent is to repeat
the guidance given for ssrc-group SDP attribute registry, then a pointer
to the guidance may be necessary.  Alternatively, it may be enough to
suggest that the working group expects this to be a sparsely used registry


Nits: