Subject: Re: [siprec] #12: REQ-001/002/003/004

From: "siprec issue tracker" <[email-masked]>
Date: Tue, 07 Sep 2010 13:14:05 -0000

#12: REQ-001/002/003/004
------------------------------------------------+---------------------------
 Reporter:  john.elwell@…                       |       Owner:  krehor@…        
     Type:  defect                              |      Status:  new             
 Priority:  major                               |   Milestone:  milestone1      
Component:  Requirements                        |     Version:                  
 Severity:  Candidate WG Document               |    Keywords:                  
------------------------------------------------+---------------------------

Comment(by john.elwell@…):

 This issue has been here a long time without progress. In addition to the
 original concern that led to this issue, basing these normative statements
 on terms that are not formally defined (Full-time, Selective, Dynamic,
 Persistent) is not very satisfactory.

 I would propose the following to replace these requirements:
 "REQ-001: The mechanism MUST support the ability to record all CSs in
 their entirety.
 REQ-002: The mechanism MUST support the ability to record selected CSs in
 their entirety, according to policy.
 REQ-003: The mechanism MUST support the ability to record selected parts
 of selected CSs."
 The "persistent" one is more difficult. At first glance, it would appear
 to be coved by REQ-001. However, I have heard there are performance
 concerns that lead to a solution whereby an RS is retained permanently. I
 think that is a solution matter, and we should limit ourselves to
 requirements. Perhaps something along the following lines would work:
 "REQ-004": The mechanism MUST support the ability to start recording a CS
 without losing media that occurs at the start of the CS and without
 delaying the start of the CS while preparation for recording takes place."

 John

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/siprec/trac/ticket/12#comment:1>
siprec <http://tools.ietf.org/siprec/>

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 7 Sep 2010 15:58:29 +0200

A further thought on one of the points below: 

> -----Original Message-----
> From: siprec issue tracker [mailto:[email-masked]] 
> Sent: 07 September 2010 14:14
> To: [email-masked]; Elwell, John
> Cc: [email-masked]
> Subject: Re: [siprec] #12: REQ-001/002/003/004
> 
> #12: REQ-001/002/003/004
>  Reporter:  john.elwell@...                       |       
> Owner:  krehor@...        
>      Type:  defect                              |      
> Status:  new             
>  Priority:  major                               |   
> Milestone:  milestone1      
> Comment(by john.elwell@...):
> 
[JRE] Or perhaps REQ-004 is already covered to some extent by REQ-027?
"REQ-027 The mechanism SHOULD support means to avoid clipping media
   (leading or trailing samples) when the media is transported from the
   SRC to the SRS."

John

> 
>  John
> 
> -- 
> Ticket URL: 
> <http://trac.tools.ietf.org/wg/siprec/trac/ticket/12#comment:1>

---

From: "siprec issue tracker" <[email-masked]>
Date: Thu, 09 Sep 2010 07:45:39 -0000

#12: REQ-001/002/003/004

Comment(by krehor@…):

 I agree with the original concern and prefer the new definitions of -001,
 -002, and -003. I would like to see a clearer definition of -004.

-- 
Ticket URL: <https://trac.tools.ietf.org/wg/siprec/trac/ticket/12#comment:2>
siprec <http://tools.ietf.org/siprec/>

---

From: "siprec issue tracker" <[email-masked]>
Date: Tue, 14 Sep 2010 00:17:33 -0000

#12: REQ-001/002/003/004

Comment(by dave.smith@…):

 I agree as well to the recommended re-write of REQ-001/002/003; however
 also include:

 REQ-001:  Reference to Use Case 1 and Use Case 4 (for example, "See Use
 Case 1 and 4 in Section 5.")
 REQ-002:  Reference to Use Case 2
 REQ-003:  Reference to Use Case 3

 For REQ-004 I recommend the following:
    Change current wording:
 "REQ-004: The mechanism MUST support the ability to start recording a CS
 without losing media that occurs at the start of the CS and without
 delaying the start of the CS while preparation for recording takes place."
    To:
 "REQ-004: The mechanism MUST support the ability to record a CS without an
 intentional loss of media (for example, clipping media at the beginning of
 the CS) and without impacting the quality or timing of the CS (for
 example, delaying the start of the CS while preparation for recording
 takes place).  See Use Case 4 in Section 5."

-- 
Ticket URL: <https://wiki.tools.ietf.org/wg/siprec/trac/ticket/12#comment:3>
siprec <http://tools.ietf.org/siprec/>

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 20 Sep 2010 12:49:57 +0200

I agree with Dave's proposed changes in general, but I don't like "intentional loss of media". Loss of media isn't exactly intended, but could be an unavoidable consequence of design decisions.

How about: "designed-in loss of media"?

John (as individual) 

> Sent: 14 September 2010 01:18
> To: [email-masked]; [email-masked]; Elwell, John
> Cc: [email-masked]
> Comment(by dave.smith@...):
> 
> <https://wiki.tools.ietf.org/wg/siprec/trac/ticket/12#comment:3>

---

From: "siprec issue tracker" <[email-masked]>
Date: Tue, 28 Sep 2010 07:28:22 -0000

#12: REQ-001/002/003/004
------------------------------------------------+---------------------------
 Reporter:  john.elwell@…                       |        Owner:  krehor@…        
     Type:  defect                              |       Status:  closed          
 Priority:  major                               |    Milestone:  milestone1      
Component:  Requirements                        |      Version:                  
 Severity:  Candidate WG Document               |   Resolution:  fixed           
 Keywords:                                      |  
------------------------------------------------+---------------------------
Changes (by krehor@…):

  * status:  new => closed
  * resolution:  => fixed

-- 
Ticket URL: <https://wiki.tools.ietf.org/wg/siprec/trac/ticket/12#comment:4>
siprec <http://tools.ietf.org/siprec/>