Subject: [siprec] review comments on draft-ietf-siprec-architecture-01

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Sat, 26 Mar 2011 11:23:16 -0700

I started my review of the SIPREC drafts with the architecture document.
I have some nits and some concerns.
Let me state the concerns first.

Section 4.2 reads, "the Session Recording Client must decrypt any media
received on the Communication Session and, if required, re-encrypt the
media using a separate SRTP key for the Recording Session." Why must? I
imagine it could be done in some cases, but I do not see why it is a
must.

Section 4.2.1 reads, "Indicate support for the recording metadata event
package." I am not sure this is needed and do not think it should be
stated here.

Section 4.3.1, no sure why Dialog state of the Communication Session is
required.

Section 4.3.2, regarding the OPEN ISSUE, I think we decided on XML as
message body in re-INVITE or UPDATE.

Section 4.4 reads, "If the Session Recording Client is aware that the
remote UA is a recording aware UA then it MUST notify the UA using a SIP
based mechanism." Why MUST? It seems "should" is more appropriate as
other mechanisms may be used depending on the use case. Also, it seems
there should not be any normative language in this draft.

Section 6 reads, "SRTP is used for securing the Replicated Media." I
think other mechanisms should be allowed as well.

Nits

Section 4.2
Replace "Recording Session is a completely independent" with "Recording
Session is completely independent".

Cheers,
Charles

---

From: "Hutton, Andrew" <[email-masked]>
Date: Mon, 28 Mar 2011 10:12:24 +0200

Hi Charles,

Thanks for the comments, see below.

Regards
Andy 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Charles Eckel (eckelcu)
> Sent: 26 March 2011 18:23
> To: [email-masked]
> Subject: [siprec] review comments on draft-ietf-siprec-architecture-01
> 

[AndyH] - This will be removed in the next update it was there due to some old requirements which have now been removed.

> package." I am not sure this is needed and do not think it should be

[AndyH] This is also tentatively removed in the next draft due to comments from Partha. It is not an architectural issue anyway but my personal opinion is that some indication from the SRC as to whether it supports sending metadata would be useful.

> Section 4.3.1, no sure why Dialog state of the Communication 

[AndyH] - This is currently under debate I am also tending towards thinking it is not needed.
 
> message body in re-INVITE or UPDATE.

[AndyH] - Agreed removed from next version.

> there should not be any normative language in this draft.

[AndyH] - The next version will only state that it is the SRC's responsible for the notifications and not mandate the mechanism. All normative language will also be removed. Hope this will be ok.

> think other mechanisms should be allowed as well.

[AndyH] - What do you suggest we should say here? I guess anything that can be negotiated via SIP/SDP is within scope so we could say something more generic.

> Session is completely independent".

[AndyH] - Done.

> 
> Cheers,
> Charles
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec
>

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 28 Mar 2011 01:19:51 -0700

Hi Andy,

Thank you for your response. It seems we are in agreement on all points.

> think other mechanisms should be allowed as well.

[AndyH] - What do you suggest we should say here? I guess anything that
can be negotiated via SIP/SDP is within scope so we could say something
more generic.

I think we do not need to mention anything specific here as I do not
think SIPREC has any special requirements. The requirement to support
separate security mechanism for CS than RS in some cases is already
covered in another thread, and I agree with what was proposed there.

Cheers,
Charles

> From: Hutton, Andrew [mailto:[email-masked]]
> Sent: Monday, March 28, 2011 10:12 AM
> To: Charles Eckel (eckelcu); [email-masked]
> Subject: RE: review comments on draft-ietf-siprec-architecture-01
> 
> Hi Charles,
> 
> [AndyH] - This will be removed in the next update it was there due to
some old requirements which have
> now been removed.
> [AndyH] This is also tentatively removed in the next draft due to
comments from Partha. It is not an
> architectural issue anyway but my personal opinion is that some
indication from the SRC as to whether
> it supports sending metadata would be useful.
> 
> 
> [AndyH] - The next version will only state that it is the SRC's
responsible for the notifications and
> not mandate the mechanism. All normative language will also be
removed. Hope this will be ok.
> [AndyH] - What do you suggest we should say here? I guess anything
that can be negotiated via SIP/SDP
> is within scope so we could say something more generic.
> 
> >
> > Nits
> >
> > Section 4.2

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 28 Mar 2011 17:04:32 +0200

I agree it is probably not necessary to say anything in the architecture document. Whether we need to say something in the protocol document remains to be seen. SRTP is the only IETF-standardized means of securing RTP, so I expect it at least to be mentioned somewhere in the protocol document.

John

> Sent: 28 March 2011 09:20
> To: Hutton, Andrew; [email-masked]
> Subject: Re: [siprec] review comments on 
> draft-ietf-siprec-architecture-01
> 
> Hi Andy,
>