Subject: [siprec] Comments on draft-ietf-siprec-metadata-10.

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 8 Jan 2013 20:42:44 +0000

Hi,

I just read through the draft-ietf-draft-siprec-metadata-10 and have the following comments.

1. Section 6.1.1 - The Start/End time is I assume the start/end time of the RS not of the "Recording Session Object".

2. Section 6.1.2 - Whilst discussing the linkage between a RS and a CSG states: 

"Also the allowance of zero instances is to accommodate persistent recording, where there may be none".  I think this could be made a bit clearer and suggest 

"Also the allowance of zero instances is to accommodate persistent recording, where there may be no CS or CSG in existence when the RS is created".

3. Section 6.2.1 Which discusses CS session attributes includes the following statement: "SRC (or SRS) is responsible for ensuring the uniqueness of Unique-ID in case multiple SRC interacts with the same SRS.".  I don't see how the SRS can be responsible for this and think the statement is unnecessary and could simple be replaced with a reference to 6.10 which stated describes how unique-id's are created.

4. Section 6.2.2 States "Each Communication Session Group object has to be associated with one or more RS [Here each RS can be setup by the potentially different SRCs".  Is it really the case that there can be more than one RS per CS Group? If it is because each RS can be established by different SRC's then I assume this should impact the object model which only describes the metadata generated by a single SRC.

5. Section 6.2.2 States "There is one or more Communication Sessions per CS Group [e.g. Consult Transfer]". I think we need more explanation of scenarios in which a CS Group is applicable than just "E.g. Consult Transfer". Can somebody provide a description of a basic scenario in which a CSG would be used?

6. Section 6.3.1 Communication Session Attributes. I think we need more detail as to the format of the Termination Reason. It would probably be useful to say that it is formatted according to the rules of RFC3326 if that is the intention and give an example in section 7.1.

7. Section 6.3.1. The last paragraph which starts "This document does not specify attributes relating to what should happen to a recording of a CS after it has been delivered..." does not appear to be useful to me and could be removed.

8. Section 6.3.2 "CS to have atleast zero or more participants" should read "CS has zero or more participants". I started a separate thread on a CS having zero particants.

9. Section 6.5 states "A Participant class and its objects has information about a device..."  I don't think it is necessarily information about a "device" which implies some kind of endpoint device and a participant does not relate to a device in my mind. I think we should stick to the term "participant".

10. Section 6.5.1 replace "Participant has attributes like" with "Replace with "A participant class has the following attributes:".

11. Section 6.7.1. "A Media Stream class has the the following attributes:" - Remove duplicate "the".

12. Section 7.1 claims to contain example usage of all the metadata attributes but I noted it does not contain a CS reason attribute.

13. Can we change the name of the CS "reason" attribute to "terminationReason" or do we think it is too late to do that.

14. Section 9 Security Considerations - Maybe we should make a reference to the protocol draft which specifies the security considerations for transporting the information certainly we should not duplicate information already in the protocol draft.

Regards
Andy

---

From: "Parthasarathi R" <[email-masked]>
Date: Sat, 12 Jan 2013 22:22:10 +0530

Andy,

Thanks a lot for the detailed review. Please read inline.

Thanks
Partha

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Hutton, Andrew
> Sent: Wednesday, January 09, 2013 2:13 AM
> To: [email-masked]
> Subject: [siprec] Comments on draft-ietf-siprec-metadata-10.
> 
> Hi,
> 
> 1. Section 6.1.1 - The Start/End time is I assume the start/end time of
> the RS not of the "Recording Session Object".
> 
<Partha> Your assumption is right. Recording session object start/end time
is same as start/end time of RS. It is clarified in the draft as "In cases
where Date header is not present, Start/End time are derivable from the 
time at which SRS receives the notification of SIP message to setup RS / 
disconnect RS." </Partha>
> "Also the allowance of zero instances is to accommodate persistent
> recording, where there may be none".  I think this could be made a bit
> clearer and suggest
> 
> "Also the allowance of zero instances is to accommodate persistent
> recording, where there may be no CS or CSG in existence when the RS is
> created".
> 
<Partha> Agreed </Partha>

> 3. Section 6.2.1 Which discusses CS session attributes includes the
> following statement: "SRC (or SRS) is responsible for ensuring the
> uniqueness of Unique-ID in case multiple SRC interacts with the same
> SRS.".  I don't see how the SRS can be responsible for this and think
> the statement is unnecessary and could simple be replaced with a
> reference to 6.10 which stated describes how unique-id's are created.
> 
<Partha> Agreed. SRS has to be remove. The updated text will look like
"SRC is responsible for ensuring the uniqueness of Unique-ID in case
multiple SRC interacts with the same SRS." </Partha>

> 4. Section 6.2.2 States "Each Communication Session Group object has to
> be associated with one or more RS [Here each RS can be setup by the
> potentially different SRCs".  Is it really the case that there can be
> more than one RS per CS Group? If it is because each RS can be
> established by different SRC's then I assume this should impact the
> object model which only describes the metadata generated by a single
> SRC.
>
<Partha> Multiple SRC to SRS is supported in metadata model wherein how
SRC Communicate with each other for CSG/CS unique id is outside the scope 
of SIPREC. It is stated in both Sec 6.2.1 and Sec 6.2.2. Multiple RS 
shall  be associated with single CSG. </Partha>
 
> 5. Section 6.2.2 States "There is one or more Communication Sessions
> per CS Group [e.g. Consult Transfer]". I think we need more explanation
> of scenarios in which a CS Group is applicable than just "E.g. Consult
> Transfer". Can somebody provide a description of a basic scenario in
> which a CSG would be used?
> 
<Partha> Please let me whether it is sufficient to provide the CS group 
usage in the example draft. In case you wish to see any specific text, 
Please propose </Partha>

> 6. Section 6.3.1 Communication Session Attributes. I think we need more
> detail as to the format of the Termination Reason. It would probably be
> useful to say that it is formatted according to the rules of RFC3326 if
> that is the intention and give an example in section 7.1.
> 
<Partha> Reason XML element is a string which may be as per RFC 3326 and 
there is no Mandate to strictly follow RFC 3326Please let me whether it 
is sufficient to provide the reason XML element usage in the example draft. 
</Partha>

> 7. Section 6.3.1. The last paragraph which starts "This document does
> not specify attributes relating to what should happen to a recording of
> a CS after it has been delivered..." does not appear to be useful to me
> and could be removed.
> 
<Partha> This statement was added after long discussion in mailing alias 
and earlier IETF meeting about "when CS actually terminates".
The discussion happened very long back and in case it is required, I will
Search for the archive to find the exact timeframe at which this
Statement was added </Partha>

> 8. Section 6.3.2 "CS to have atleast zero or more participants" should
> read "CS has zero or more participants". I started a separate thread on
> a CS having zero particants.
<Partha> I have proposed the statement/usecase for this usage in the 
another mail thread. Let us close this open item in the another mail 
thread </Partha>

> 
> 9. Section 6.5 states "A Participant class and its objects has
> information about a device..."  I don't think it is necessarily
> information about a "device" which implies some kind of endpoint device
> and a participant does not relate to a device in my mind. I think we
> should stick to the term "participant".
<Partha> Agreed </Partha>

> 
> 10. Section 6.5.1 replace "Participant has attributes like" with
> "Replace with "A participant class has the following attributes:".
<Partha> Agreed </Partha>
> attributes:" - Remove duplicate "the".
<Partha> Agreed </Partha>

> 
> 12. Section 7.1 claims to contain example usage of all the metadata
> attributes but I noted it does not contain a CS reason attribute.
> 
<Partha> reason is used during the termination of the session. The 
Example usage is based on the CS initiation. Stop time usage is not
Shown for the same reason. I think that Sec 7.1 text has to be updated
to indicate that "CS initiation with complete metadata XML usage".
Also, please let me know whether you are interested in adding
one more example usage for the termination metadata XML usage </Partha>

> 13. Can we change the name of the CS "reason" attribute to
> "terminationReason" or do we think it is too late to do that.
>
<Partha> Reason XML element name is based on Reason SIP header and 
I'm fine with your proposal of detailed name to avoid confusion. We
will ask more opinion before Changing as some SIPREC implementation may 
have used this XML tag. </Partha>
 
> 14. Section 9 Security Considerations - Maybe we should make a
> reference to the protocol draft which specifies the security
> considerations for transporting the information certainly we should not
> duplicate information already in the protocol draft.
> 
<Partha> I agree with you that security consideration has to be updated.
I'm not very sure whether it is fine to have circular reference as
SIPREC metadata draft is referenced in the protocol draft. Also,
Protocol draft covers the complete RS with SDP, XML, RTP security whereas 
here, the interest is specific to XML schema. </Partha>

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

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 29 Jan 2013 16:32:55 +0000

Hi Partha,

See inline below.

Sorry for the slow response had my head down in other stuff.

Could you put the open issues in to the tracker?

Regards
Andy

> From: Parthasarathi R [mailto:[email-masked]]
> Sent: 12 January 2013 16:52
> To: Hutton, Andrew; [email-masked]
> Subject: RE: [siprec] Comments on draft-ietf-siprec-metadata-10.
> 
> Andy,
> 
> > 2. Section 6.1.2 - Whilst discussing the linkage between a RS and a
> CSG
> > states:
> >

<AndyH> Ok but still it really does not have anything to do with the case of multiple SRC's as the SRC is of course unaware that there is another SRC so I still think we could just refer to section 6.10. </AndyH>.

> shall  be associated with single CSG. </Partha>

<AndyH>I am not convinced that we can say anything about the multiple SRC case other than making sure we keep the id's unique I don't think we said anything about this in the architecture draft. Can you describe the use case and requirement that this covers.

> usage in the example draft. In case you wish to see any specific text,

<AndyH> I need to understand further the use case(s) we are trying to cover here can you start a separate thread on that and describe the use case. I really don't think we can put "[e.g. Consult Transfer]" in the draft as this is a service which is quite complex and can have many interpretations. We need to be clearer about why we need the CSG and the potential use cases I don't understand them myself. </AndyH>

> is sufficient to provide the reason XML element usage in the example

<AndyH> Lets have a thread on that as well what is the purpose of the reason attribute if it is just free form text it is I think more useful if we follow a defined structure such as RFC3326 for this. </AndyH>

> Statement was added </Partha>

<AndyH> But this statement seems to be about how long the SRS might retain the recording which has nothing to do with metadata and I don't think it is useful to put possible usages of extension data in the draft when any such usage will be proprietary and not interoperable. I think this paragraph should be removed. </AndyH>

> one more example usage for the termination metadata XML usage </Partha>

<AndyH> Yes I would like to see example of the termination case and as my previous comment I think we should be more prescriptive about the format of the termination reason </AndyH>

> have used this XML tag. </Partha>

<AndyH>I propose changing it we can start a thread on it if you like. <AndyH>.

> here, the interest is specific to XML schema. </Partha>

<AndyH>For me the security considerations don't relate to the schema but how it is transported which is the responsibility of the protocol draft. </AndyH>.