Subject: [siprec] Barry Leiba's Discuss on draft-ietf-siprec-protocol-16: (with DISCUSS and COMMENT)

From: "Barry Leiba" <[email-masked]>
Date: Wed, 27 May 2015 13:10:48 -0700

Barry Leiba has entered the following ballot position for
draft-ietf-siprec-protocol-16: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-siprec-protocol/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I have to raise one of Ben's comments to DISCUSS, after giving it a lot
of thought.  We talked about it before Ben posted his ballot, and I said
that I thought the way the rs-metadata-request subtype is used is abusing
media types: media types are meant to label containers for protocol
elements, but are not meant to be protocol elements themselves.  I said I
didn't want to get too wound up with that, though, and I don't...

...except that it allows no room for extensibility.  And the moment you
need another, different request, we see why this mechanism is abusive. 
Now, you may say that you don't see any need for extensibility, but we've
been proven wrong in those sorts of assumptions many times.

So, the discussion is about how you will deal with that.  Specifically,
an alternative would be to have an rs-request subtype, with a
content-type parameter such as "req=metadata" (or even use rs-metadata
with "req=snapshot") and a rule that req= values that are not recognised
be ignored.  If this should ever need to be extended, other "req=" values
could be defined.  A registry could be created in future, if there turns
out to be a need.

There are other options, as well, but the main question is why are you
sure that no such extensibility is needed?

Also, what you're doing with content-disposition isn't in accord with
what that field is for: it is for describing how the information in the
message part should be presented -- not what it's meant to contain or be
used for.  This, too, could be better handled with a content-type
parameter.

The discussion on this point is whether thus was considered, and, if so,
why it was rejected.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

-- Section 7.1.1 --

   Since the SRC does not expect to receive media from the SRS, the SRC
   typically sets each media stream of the SDP offer to only send media,
   by qualifying them with the a=sendonly attribute

Why "typically"?  Why would it not?  Why not just remove the word? The
same question applies to 7.2.

-- Section 8.1.4 --

   It is RECOMMENDED that an SRC or
   Recording aware UA, when acting as a mixer, sets the CSRC list
   accordingly, and that the SRC and SRS interpret the CSRC list
   appropriately when received.

A few questions about this:
"Accordingly" and "appropriately" are quite vague... any better guidance
on what is accorded and appropriate?  For the former, I presume you're
saying that the UA should set the CSRC list to encompass what's being
mixed.  But I have no idea what's appropriate for the SRC and SRS to do
when interpreting that.  Further, on "RECOMMENDED", what happens if
someone doesn't do this as you're hoping they do?  What are the
consequences to interop or security?

-- Section 8.1.5 --

   The ability to identify individual contributing sources is important
   in the content of SIPREC.

I think you mean "context", yes?

-- Section 8.2.1.1 --

   UAs may receive multiple sets of RTCP Receiver Reports, one or more
   from other UAs participating in the CS, and one from the SRS
   participating in the RS.  A UA SHOULD process the RTCP Receiver
   Reports from the SRS if it is recording-aware.

Is it woth mentioning what the UA is likely to do with the reports from
other UAs (just for information, without 2119 words)?  Would the UA
generally process them too?  Ignore them?  Doesn't matter?  Is there any
advantage one way or another, or any advice that would be useful for
implementors to have?

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 28 May 2015 11:52:45 -0400

I agree with Barry and Ben here: I think we should have some syntax in 
the body that indicates a request for a snapshot, and that has potential 
for future extension.

> used for.  This, too, could be better handled with a content-type

I disagree with Barry here. He is an app guy, so I guess it makes sense 
that he would say this. But almost none of the Content-Dispositions used 
with SIP are actually rendered to a human. For instance "session" for SDP.

I see the distinction between C-T and C-D being a distinction between 
how it is represented and how it is used. There could be two different 
C-Ts for SDP and SDPng, but they would both be C-D "session". The SIPREC 
metadata is used very differently, and C-D is the way to distinguish it 
from "session".

	Thanks,
	Paul