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

From: Paul Kyzivat <[email-masked]>
Date: Sat, 02 Feb 2013 12:55:27 -0500

Some comments inline.

On 1/29/13 11:32 AM, Hutton, Andrew wrote:

>>> 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>
>>
>
> <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>.

IMO the point to get across is that multiple SRCs are *permitted* to 
refer to the same entities by using a common UUID. (The SRS must not 
consider this an error.) *How* the SRCs determine they are referring to 
the same entity and obtain the same UUID for it is out of scope for this 
document.

Perhaps it would be better to discuss this in 6.10.

>>> 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>
>
> <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.

Same comment as above.

>>> 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>
>
> <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>

I agree this is worthy of some discussion as to whether 3326 is 
sufficient, or if we need a wider range of causes than that provides.

I agree with Andy that just having a string, that might or might not be 
a standard string from 3326 is dubious. With that you can never be 
certain if the reason has the exact semantics of a 3326 reason.

So I'm inclined to think we should be able to carry everything from a 
Reason header.

>>> 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>
>
> <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>

Certainly we can't enumerate all the things we *don't* cover.
IIRC this was added because some people expected that we *would* include 
info about desired retention policy, and we wanted to make it clear that 
we were not. I see no harm in that.