Subject: [siprec] AD review: draft-ietf-siprec-req-08

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 23 Mar 2011 13:22:41 +0200

Hi,

the SIPREC WG requested the publication of the following draft a few
days ago. Please, find below my AD review.

https://datatracker.ietf.org/doc/draft-ietf-siprec-req/

Given that the draft contains both requirements and use cases, you may
want to edit the title so that it reads "Use Cases and Requirements for ..."

Typically, Section 1 contains the Introduction and Section 2 the
terminology. You may want to swap both sections.

Most of the requirements are phrased so that they describe capabilities
that need to be supported by the system (e.g., the mechanism MUST
provide the SRS with the means to ...) but that do not need to be
necessarily used (e.g., a particular use case may not make use of that
functionality). However, some requirements are phrased so that the
functionality needs to be used (e.g., the mechanism MUST provide the SRS
the wall clock time ...). Requirements 12, 22, 23, 27, 28, and 29 seem
to fall into the latter category. Could you please check whether that
was the intention with all those requirements?

A few requirements relate to the security and privacy related properties
of the SRC-SRS interface (e.g., requirements 24 and 29). However, the
draft does not discuss how the security and privacy of that interface
relate to the security and privacy level used for the CS being recorded.
For example, can the confidentiality level of the media going from the
SRC and the SRS be lower than that of the media flowing between the
actual participants of the CS? If you decide there should not be a
requirement on this area, you need to at least discuss this issue
(probably in Sections 6 or 7).

Once you address these comments, I will request the IETF-wide last call
for this draft.

Thanks,

Gonzalo

---

From: Leon Portman <[email-masked]>
Date: Sat, 26 Mar 2011 16:36:48 +0200

Hi,

I want to touch security requirement: about security level of RS vs security level of CS. We had a long mailing list discussion (below) and it was decided not to have it, because it is more implementation details

http://www.ietf.org/mail-archive/web/siprec/current/msg01164.html

Regards

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Gonzalo Camarillo
Sent: Wednesday, March 23, 2011 1:23 PM
To: [email-masked]
Subject: [siprec] AD review: draft-ietf-siprec-req-08

Hi,

the SIPREC WG requested the publication of the following draft a few days ago. Please, find below my AD review.

Given that the draft contains both requirements and use cases, you may want to edit the title so that it reads "Use Cases and Requirements for ..."

Typically, Section 1 contains the Introduction and Section 2 the terminology. You may want to swap both sections.

Most of the requirements are phrased so that they describe capabilities that need to be supported by the system (e.g., the mechanism MUST provide the SRS with the means to ...) but that do not need to be necessarily used (e.g., a particular use case may not make use of that functionality). However, some requirements are phrased so that the functionality needs to be used (e.g., the mechanism MUST provide the SRS the wall clock time ...). Requirements 12, 22, 23, 27, 28, and 29 seem to fall into the latter category. Could you please check whether that was the intention with all those requirements?

A few requirements relate to the security and privacy related properties of the SRC-SRS interface (e.g., requirements 24 and 29). However, the draft does not discuss how the security and privacy of that interface relate to the security and privacy level used for the CS being recorded.
For example, can the confidentiality level of the media going from the SRC and the SRS be lower than that of the media flowing between the actual participants of the CS? If you decide there should not be a requirement on this area, you need to at least discuss this issue (probably in Sections 6 or 7).

Once you address these comments, I will request the IETF-wide last call for this draft.

Thanks,

Gonzalo

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

---

From: "Elwell, John" <[email-masked]>
Date: Sun, 27 Mar 2011 10:33:01 +0200

Yes, indeed we had the discussion and came up with reasons you can't tie the two together. So as Gonzalo suggests, some of that discussion needs to be captured in the Security Considerations section.

John

> From: Leon Portman [mailto:[email-masked]] 
> Sent: 26 March 2011 14:37
> To: Gonzalo Camarillo; [email-masked]; Ken Rehor (krehor) 
> ([email-masked]); Elwell, John
> Subject: RE: [siprec] AD review: draft-ietf-siprec-req-08
> 
> Hi,
> 
> I want to touch security requirement: about security level of 
> RS vs security level of CS. We had a long mailing list 
> discussion (below) and it was decided not to have it, because 
> it is more implementation details
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Gonzalo Camarillo
> the SIPREC WG requested the publication of the following 
> draft a few days ago. Please, find below my AD review.
> 
> Given that the draft contains both requirements and use 
> cases, you may want to edit the title so that it reads "Use 
> Cases and Requirements for ..."
> 
> Typically, Section 1 contains the Introduction and Section 2 
> the terminology. You may want to swap both sections.
> 
> Most of the requirements are phrased so that they describe 
> capabilities that need to be supported by the system (e.g., 
> the mechanism MUST provide the SRS with the means to ...) but 
> that do not need to be necessarily used (e.g., a particular 
> use case may not make use of that functionality). However, 
> some requirements are phrased so that the functionality needs 
> to be used (e.g., the mechanism MUST provide the SRS the wall 
> clock time ...). Requirements 12, 22, 23, 27, 28, and 29 seem 
> to fall into the latter category. Could you please check 
> whether that was the intention with all those requirements?
> 
> A few requirements relate to the security and privacy related 
> properties of the SRC-SRS interface (e.g., requirements 24 
> and 29). However, the draft does not discuss how the security 
> and privacy of that interface relate to the security and 
> privacy level used for the CS being recorded.
> For example, can the confidentiality level of the media going 
> from the SRC and the SRS be lower than that of the media 
> flowing between the actual participants of the CS? If you 
> decide there should not be a requirement on this area, you 
> need to at least discuss this issue (probably in Sections 6 or 7).
>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sun, 27 Mar 2011 09:35:54 +0100

Hi,

exactly, the draft should reflect the conclusion of those discussions.

Thanks,

Gonzalo

---

From: Leon Portman <[email-masked]>
Date: Mon, 28 Mar 2011 09:39:17 +0200

I want to propose following additional text for the Security Considerations section (after the last paragraph)

"Communication Sessions and Recording Sessions will require different security levels both for signaling and media, depending on deployment configurations. For some environments, for example, SRS and SRC will be collocated in a secure network region and will not require same protection level as CS over public network. For other environments, SRS can be located in a public cloud and RS will require higher protection level then CS. Because of these reasons, there is not direct relation between security level of Communication Sessions and Recording Sessions"

Leon

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Sunday, March 27, 2011 10:33 AM
To: Leon Portman; Gonzalo Camarillo; [email-masked]; Ken Rehor (krehor) ([email-masked])
Subject: RE: [siprec] AD review: draft-ietf-siprec-req-08

John

> I want to touch security requirement: about security level of RS vs 
> security level of CS. We had a long mailing list discussion (below) 
> and it was decided not to have it, because it is more implementation 
> details
> 
> capabilities that need to be supported by the system (e.g., the 
> mechanism MUST provide the SRS with the means to ...) but that do not 
> need to be necessarily used (e.g., a particular use case may not make 
> use of that functionality). However, some requirements are phrased so 
> that the functionality needs to be used (e.g., the mechanism MUST 
> provide the SRS the wall clock time ...). Requirements 12, 22, 23, 27, 
> 28, and 29 seem to fall into the latter category. Could you please 
> check whether that was the intention with all those requirements?
> 
> properties of the SRC-SRS interface (e.g., requirements 24 and 29). 
> However, the draft does not discuss how the security and privacy of 
> that interface relate to the security and privacy level used for the 
> CS being recorded.

---

From: "Ken Rehor (krehor)" <[email-masked]>
Date: Mon, 28 Mar 2011 00:42:23 -0700

+1 

> Sent: Monday, March 28, 2011 12:39 AM
> To: Elwell, John; Gonzalo Camarillo; [email-masked]; Ken Rehor
(krehor)
> I want to propose following additional text for the Security
Considerations
> section (after the last paragraph)
> 
> "Communication Sessions and Recording Sessions will require different
> security levels both for signaling and media, depending on deployment
> configurations. For some environments, for example, SRS and SRC will
be
> collocated in a secure network region and will not require same
protection
> level as CS over public network. For other environments, SRS can be
located
> in a public cloud and RS will require higher protection level then CS.
> Because of these reasons, there is not direct relation between
security level
> of Communication Sessions and Recording Sessions"
> 
> Leon
> 
> 
> To: Leon Portman; Gonzalo Camarillo; [email-masked]; Ken Rehor
(krehor)
> ([email-masked])
> Yes, indeed we had the discussion and came up with reasons you can't
tie the
> two together. So as Gonzalo suggests, some of that discussion needs to
be
> captured in the Security Considerations section.
> 
> John
>

---

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

Works for me as well.

> From: [email-masked] [mailto:[email-masked]] On
Behalf Of Ken Rehor (krehor)
> Sent: Monday, March 28, 2011 9:42 AM
> To: Leon Portman; Elwell, John; Gonzalo Camarillo; [email-masked]
> Subject: Re: [siprec] AD review: draft-ietf-siprec-req-08
> 
> +1
> 
> > > want to edit the title so that it reads "Use Cases and
Requirements
> > > for ..."

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 28 Mar 2011 09:24:09 +0100

Hi,

this text is OK.

Thanks,

Gonzalo

---

From: Leon Portman <[email-masked]>
Date: Mon, 28 Mar 2011 10:38:49 +0200

---

From: Leon Portman <[email-masked]>
Date: Mon, 28 Mar 2011 10:42:47 +0200

Hi,

Following AD comments, I am proposing to indicate that following requirements are mandatory to implement, in contrast for other requirements that are mandatory for the protocol to support but optional for implementation depending use cases:

1. REQ-001 - implement SIP based protocol
2. REQ-012  - metadata reporting support 
3. REQ-013 - map between participant and  media 
4. REQ-022 - wall clock reporting for media synchronization
5. REQ-023 - wall clock, assuming pause/resume is used 
6. REQ 27-30 are mandatory security requirements

Leon

---

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

With some editorial changes:

"Communication Sessions and Recording Sessions will require different security levels both for signaling and media, depending on deployment configurations. For some environments, for example, SRS and SRC will be collocated in a secure network region and therefore the RS will not require the same protection level as a CS that extends over a public network, for example. For other environments, the SRS can be located in a public cloud, for example, and the RS will require a higher protection level than the CS. For these reasons, there is not a direct relationship between the security level of Communication Sessions and the security level of Recording Sessions." 

John

> Sent: 28 March 2011 08:39
> To: Elwell, John; Gonzalo Camarillo; [email-masked]; Ken 
> Rehor (krehor) ([email-masked])
> Considerations section (after the last paragraph)
> 
> "Communication Sessions and Recording Sessions will require 
> different security levels both for signaling and media, 
> depending on deployment configurations. For some 
> environments, for example, SRS and SRC will be collocated in 
> a secure network region and will not require same protection 
> level as CS over public network. For other environments, SRS 
> can be located in a public cloud and RS will require higher 
> protection level then CS. Because of these reasons, there is 
> not direct relation between security level of Communication 
> Sessions and Recording Sessions"
> 
> Leon
> 
> 
> Yes, indeed we had the discussion and came up with reasons 
> you can't tie the two together. So as Gonzalo suggests, some 
> of that discussion needs to be captured in the Security 
> Considerations section.
> 
> John
> 
> draft a few 
> cases, you may

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 28 Mar 2011 11:18:23 +0200

I disagree with this. The purpose of a requirements document is to document requirements on the solution. The solutions document(s) should give requirements on implementations. When reviewing the requirements document I had not interpreted any on the requirements as being requirements on implementations. 

> Sent: 28 March 2011 09:43
> Following AD comments, I am proposing to indicate that 
> following requirements are mandatory to implement, in 
> contrast for other requirements that are mandatory for the 
> protocol to support but optional for implementation depending 
> use cases:
> 
[JRE] This is clearly stated as a requirement the mechanism and should remain that way.

> 2. REQ-012  - metadata reporting support 
[JRE] Ditto. Perhaps the words could be improved by saying "The mechanism MUST include a means for providing the SRS...."

> 3. REQ-013 - map between participant and  media 
[JRE] "The mechanism MUST include a means for the SRS to be able to correlate..."

> 4. REQ-022 - wall clock reporting for media synchronization
[JRE] "The mechanism MUST include a means for the SRS to receive ..."

> 5. REQ-023 - wall clock, assuming pause/resume is used 
[JRE] Similar

> 6. REQ 27-30 are mandatory security requirements
[JRE] REQ-027-029: "The mechanism MUST include a means for ensuring..."
I think REQ-030 is fine as is.

John (as individual)

---

From: Leon Portman <[email-masked]>
Date: Tue, 29 Mar 2011 09:01:33 +0200

Ok, we will update the document with the below.

Thanks

Leon

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Monday, March 28, 2011 11:18 AM
To: Leon Portman; Gonzalo Camarillo; [email-masked]; Ken Rehor (krehor) ([email-masked])
Subject: RE: [siprec] AD review: draft-ietf-siprec-req-08

> (krehor) ([email-masked])
> Following AD comments, I am proposing to indicate that following 
> requirements are mandatory to implement, in contrast for other 
> requirements that are mandatory for the protocol to support but 
> optional for implementation depending use cases:
> 

[JRE] Similar

John (as individual)