Re: [siprec] Review of draft-yan-siprec-msrp-recording-02

[Paul Kyzivat <[e-mail]>]

Brian, and others,

Below is the last message on this draft. It came in the midst of IETF91, 
so the discussion never came to completion.

I don't think my co-author is interested in further work on it, and I no 
longer have any sponsorship to work on it, but I'd still like to finish 
it if there is interest. But I won't do so unless there is active 
interest. A start at that would be to finish off the discussion started 
in this thread.

	Thanks,
	Paul

On 11/11/14 5:23 AM, Paul Kyzivat wrote:
> On 11/10/14 9:06 PM, Brian Rosen wrote:
>> I have reviewed -02 and have the following comments
>
> Thanks. Obviously this draft *needed* a review!
>
>> 1. I don’t see value in multiplexing separate CSs in one RS.  We don’t
>> do that for other media, we need completely separate metadata, and
>> generally I don’t think session state is very meaningful.  The
>> applications I have in mind would not see any significant advantage and
>> the complexity I think outweighs it.  I could imagine a large investment
>> company needing a huge number of sessions and maybe they would think it
>> was worth it.
>
> I brought it up because I was uncertain. I'll take your comment as one
> data point.
>
> The advantage is that you need less MSRP sessions on the RS.
>
> There is an analogy to audio/video: we do allow a single RS media
> session to be multiplexed *serially* for multiple CS media sessions.
> This mechanism for MSRP could be used that way.
>
>> 2. In section 3.1 it says “If the MSRP client/SRC is aware the MSRP
>> session needs to be
>>
>>     recorded, it can initiate the establishment of a SIP RS by sending an
>>     INVITE to SRS, or vice-versa.”“or vice-versa” is confusing as is.
>> The SRS would have to either have knowledge of the CS or set up the RS
>> in advance of a CS.
>>
>> Please expand this sentence (or maybe refer to another doc that
>> explains how an SRS can initiate the RS.
>
> This is unchanged from -01, but I agree it is messed up and needs to be
> reworked.
>
>> 3. Just beyond that, the text says“is responsible” (2 places).  Should
>> that be a normative MUST?
>
> Same comment as above.
>
>> 4. In Section 4, it says “If the SRC mixes
>>
>>     MSRP media from multiple senders, then each message that isn't
>>     already in CPIM format SHOULD be embedded in a CPIM message, and the
>>     From and To headers of that CPIM wrapper SHOULD identify the sending
>>     and receiving participants for that message.
>>
>>
>>   Is SHOULD correct?  What circumstance would it not CPIM wrap?
>
> I screwed up here. The text is unchanged from -01, but it should have
> been changed. This comment is wrong - the new wrapper type replaces this.
>
>> 5. The last paragraph in Section 6 is replicated from Section 5.  Do
>> we need that?
>
> Yet another thing that was wrong in -01. :-(
>
>> 6. In Section 8, I think it’s MUST.  Can’t come up with a reason why
>> it shouldn’t do that.
>
> I was thinking there might be an SRC that has a policy of not disclosing
> this. But I'm not sure why. But in general I think an SRC should be
> allowed to censor as much as it wants.
>
>> 7. Re the note about prefixes in the extension.  Even if it doesn’t
>> require them, it seems to me that it’s helpful here, so I think you
>> can just do it and not question it.
>
> I was mostly not sure if I fully understood how the extension mechanism
> was intended to be used. It just needs a bit more research to be sure it
> is being done right.
>
>> 8. In Section 10.1 it says “The 'drop' token indicates that the
>> content of a SEND message in the
>>
>>     CS is not being sent to the RS for recording.
>>
>>
>> This confused me.  There wouldn’t be a body in this case, right?  This
>> is the case where the SRS doesn’t support, say file transfer, and
>> we’re recording that fact  Seems like we need more text here, perhaps
>> just a reference to Section 11.2.
>
> This message gets used in multiple circumstances. If a CS message is
> being dropped because the SRS doesn't want that type, then yes, there
> will be no body from the CS message. The MSRP message on the RS will
> still have the "wrapper" body, but it won't be wrapping anything. All
> the info will be in the wrapper headers.
>
>> 9. Since the SRC can reassemble a fragmented message, it can also
>> fragment it.  Therefore, it may be able to not drop a large message on
>> the CS by fragmenting on the RS.  The text in 11.2 doesn’t cover that,
>> and probably should be explicitly noted elsewhere.
>
> The negotiated size is not the limit on *fragments* - it is a limit on
> the unfragmented message.
>
> One challenge is that when the SRC receives the first fragment it may
> not be able to tell how big the complete message will be. (That info is
> optional.) So it may send one or a few fragments before it discovers
> that the message in total will be too big. At *that* time it sends a
> drop message.
>
>> 10. I don’t think this text:
>>
>> When a 'drop' message is sent:
>>
>>     o  it MUST be terminated with a continuation-flag of "#";
>>
>>
>> is correct.  I think that is only true if the SRC sent a prior
>> fragment.  You are telling me that if you were fragmenting, and you
>> dropped, that that is the end of the message,
>>
>> so we ended continuatiuon.  Fine, but that’s only if you were
>> fragmenting.
>
> Yeah, this needs a bit more work. If some fragments have been sent, and
> then the SRC discovers the message is too big, it can't send the drop as
> part of the fragmented message. It needs to send a last (empty?)
> fragment with a "#", and *then* it can send a drop message with the same
> rs.Message-ID. And then the drop message can end with "$".
>
>> 11. I don’t know why SHOULD is not MUST in 11.3
>
> In some sense they are redundant, since the nickname is sent to the SRS
> in the wrapper with each message. It might be interesting for the SRS to
> see the requests for nicknames, and especially denials of those. But it
> the general spirit of giving the SRC discretion, I thought it can be
> allowed to drop based on policy.
>
>> 12. Generally, I think the recording should record failures at the
>> SRC, so I think we need a way to record them, and I don’t think they
>> are optional (assuming its a CS error).
>
> I would expect that would be the normal case. I just can't think of a
> strong reason to *insist* that the SRC do so.
>
>      Thanks,
>      Paul
>
> _______________________________________________
> siprec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/siprec
>