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

From: Paul Kyzivat <[email-masked]>
Date: Wed, 06 Apr 2011 17:42:27 -0400

Just to be clear - do you consider mandatory to implement distinct from 
mandatory to *use*? (IOW, that an administrator deploying siprec 
compliant products might configure them to not use some of these features.)

IMO:
- most things are mandatory to implement in the SRS.
   Which are used is determined mostly by behavior of the SRC.
   We aren't defining the form or content of the actual recorded
   data/metadata, so the only definition of compliance we have
   will be based on how it interacts with an SRC.
- the basic mechanisms are probably mandatory to implement
   in the SRC, but there should be a lot of latitude. There are
   many ways to hook an SRC into CSs, so there can be a lot of
   special purpose SRCs that focus on a particular way of fitting
   in. Some of them will have more access to metadata than others.
   If they can't discover a certain sort of metadata then they
   will not be delivering it, and so don't need support for doing
   so.
- an SRC implementation may provide ways for an administrator
   to turn off a variety of things so that they aren't used.
   But we will have to draw a line somewhere - at some point if
   you have turned too much off it will cease to be identifiable
   as an SRC.

	Thanks,
	Paul

On 3/28/2011 4:42 AM, Leon Portman wrote:
> 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
>
> -----Original Message-----
> From: Leon Portman
> Sent: Monday, March 28, 2011 10:39 AM
> To: 'Elwell, John'; Gonzalo Camarillo; [email-masked]; Ken Rehor (krehor) ([email-masked])
> Subject: RE: [siprec] AD review: draft-ietf-siprec-req-08
>
>> -----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.
>>
>> 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
>>
>> _______________________________________________
>> siprec mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/siprec
>>
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec
>

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 8 Apr 2011 17:57:21 +0200

Paul,

I think we have moved in a different direction from what Leon suggested below - see -09 and Ken's slides from Prague. If you have concerns about what is in the requirements document, please respond to IETF last call. However, the points you make below will be relevant for the protocol document at some stage.

John (as chair)

> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: 06 April 2011 22:42
> To: [email-masked]
> Subject: Re: [siprec] AD review: draft-ietf-siprec-req-08
> 
> > 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:
> >