Re: [siprec] Ben Campbell's No Objection on draft-ietf-siprec-metadata-20: (with COMMENT)

["Ben Campbell" <[e-mail]>]

Hi Ram,

Thanks for the response. Additional comments below. (I removed sections 
that did not appear to need further discussion.)

Ben.

On 2 Mar 2016, at 11:01, Ram Mohan R (rmohanr) wrote:

>
> -----Original Message-----
> From: Ben Campbell <[e-mail]>
> Date: Wednesday, 2 March 2016 at 5:55 AM

[...]

>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------

[...]

>> = Substantive =
>>
>> - I'm confused about the associations between an RS (as modeled by
>> <recording>) and a CS or CSG. As far as I can tell, a <recording> 
>> element
>> is associated with a given CS/CSG by the fact of enclosing it. But 
>> the
>> UML and related text indicates that a CS or a CSG can be associated 
>> with
>> more than one RS. How does that work in the XML?
>
> There are use-cases where you can have multiple RS (SIP dialogs from 
> SRC
> to SRS) to record the same CS (that may be part of CSG).
> For e.g a call between A and B can be initially recorded by  RS - RS1.
> Mid-call the recording may be stopped (due to transfer to a MoH server
> which the SRC does not have a policy to record).
> Later during resumption, a new RS (RS2) will be setup to record the 
> same
> CS(and hence the related CSG).
> Look at use-case 3 of requirement RFC6341 in section 4.
>
> There would be different SIP dialog setup from SRC to SRS and that 
> would
> carry the metadata with <recording> element having same CS, CSG 
> elements
> (retaining the same UUID of those).

I read that to mean that the SRS builds a database over time, and 
recognizes that the same CS arrived in two different xml documents, and 
therefore associates it with the <recording> element of each?

If so, that seems to conflict with the statement in the 2nd to last 
paragraph in section 4, that says the model represents a snapshot. I 
think maybe an XML document represents a snapshot, but the model 
represents metadata accumulated over time. This would explain some 
confusion I had over things like CSRS Association.

In any case, I don't get a sense of how this works from the draft. I 
think it would benefit from a section that describes the high-level 
operation (unless that's already in another document, in which case a 
reference would help.)

[...]

>>
>> - 5.1: Does the xml doc contain _exactly_ one <recording> element?
>
> Yes. Each instance of metadata sent from SRC to SRS must have only one
> <recording> element.
> Section 5.1.2 has some that indicates the same.
>
> Here is the existing text:
> "The <recording> element MUST contain an xmlns namespace attribute
>    with value as urn:ietf:params:xml:ns:recording:1.  One recording
>    element MUST be present in every recording metadata XML document.²
>
> Perhaps I can tighten that and say only one if it is going to make it
> clear.

I think that would help. I don't think people will universally interpret 
"One...MUST be present" to mean "Exactly one...MUST be present."
>

[...]

>>
>> - 6.1.2: Can you elaborate on "persistent recording" and why it 
>> removes
>> the need for a CS/CSG?
>
> A persistent RS is a SIP dialog that is setup between SRC to SRS even
> before any CS is setup. So the metadata sent from SRC to SRS at that 
> time
> would not have CS(and the related CSG)
>  element as there is no session that is being recorded yet. IIRC the 
> WG
> discussions this is primarily for endpoints based recording where the
> endpoint (like a SIP phone) will have a
> Persistent RS to SRS. As soon as any call is made from that 
> phone/answered
> on that phone the Session will be recorded from that RS.

It would be helpful to say that in the draft.

>>
>> - 6.2: What does a CSG model? What does it mean for a CS to be part 
>> of a
>> group or not part of a group?
>
> A CSG is used to group all related CS. For e.g, in a contact centre 
> flow a
> call may get transferred to multiple agents/SIP elements. Each of 
> these
> may trigger setup of new CS.
> In cases where the SRC knows the related CSs it can group them using 
> the
> CSG element. Even though each CS has its only identifier (UUID) all 
> will
> be associated to same CSG element.
> This is expected to provide useful information to SRS.
>

Some text to that effect would be helpful.

[...]

>
>>
>> - 6.3: Can a given CS be directly associated with an RS and also a 
>> CSG?
>> (I guess that will always be true in the XML, but it's not apparent 
>> from
>> the UML).
>
> In the UML diagram there is association from CS To RS as well from CS 
> to
> CSG.
> I hope that is sufficient.

Do I assume correctly that each CS is always linked directly to the RS, 
and may also be linked to a CSG? (I originally thought in terms of 
having ungrouped CSs linked directly to the RS, but grouped CSs to only 
be linked indirectly via a CSG.)

[...]

>>
>> - 6.3.3: "A stream in a persistent RS is not required to be 
>> associated
>> with any CS..."
>> It's not apparent how you would do that in the UML.
>
> In the UML diagram you can see the Media Stream element is associated 
> with
> CS which allows a stream to be associated with zero or more CS.
> In the XML as you noted the <stream> elements session_id attribute 
> which
> will be absent for this case.

In the UML is that media streams are only indirectly associated to an RS 
via the CS, i.e. if the CS doesn't exist, then it looks like the media 
stream is not associated with an RS, either. But in the XML, the 
<stream> element is always enclosed in a <recording> element.

(I'm probably being overly pedantic in expecting the UML and XML 
associations to formally match. But since the semantics are mainly 
explained in terms of the UML model, I find it at least a little bit 
confusing.)

>
> E.g;
> <stream stream_id="EiXGlc+4TruqqoDaNE76ag==">
>    <label>99</label>
>         </stream>
>
>
>> I can see how you
>> would do it by virture of being contained in a <recording> element.
>>
>> - 6.5.1: Remote-Party-ID? Citation needed ;-)
>
> Sure. Will add RFC reference.

Apologies, I was being a bit tongue-in-cheek. You won't find one. 
Remote-Party-ID was never standardized in the IETF. The closest you 
might find is draft-ietf-sip-privacy-05.

Is its mention here absolutely necessary?

>>
>> -6.11: Do I understand correctly that means  no extensions are 
>> allowed
>> without changing the version number? Is that really the intent?
>
> Yes. If any new extensions to the schema defined in this draft is 
> done, it
> has to be done by means of a new version number to the namespace 
> defined
> here.
>

I'm not going to push on this, but I'm surprised this doesn't allow at 
least "informational" extensions (where nothing breaks if the receiver 
doesn't understand it) using normal XML extension mechanisms.

>>
>> -10, first paragraph:
>> Why is the SHOULD not a MUST?
>> Also,  what does the SRC need to
>> authenticate/authorize?
>
> SIPREC protocol draft security section has details of how 
> authorization
> has to be done. We plan to add text referring to that in the first 
> para.

I still think it would be helpful, if you are going to mention 
authentication here, to say what is being authenticated. I'm not asking 
for technical details--I think you mean to say the SRC authenticates the 
identity of the SRS?

> Does this look better ?
>
> NEW:
>
> This document describes an extensive set of metadata that may be
>    recorded by the SRS.  Most of the metadata could be considered
>    private data.  For this reason, it is RECOMMENDED that a SRC use a
>    strong means for authentication and metadata information protection
>    and that it apply comprehensive authorization rules when using the
>    metadata format defined in this document.  The procedures mentioned
>    in security consideration section of [I-D.ietf-siprec-protocol] 
> MUST
>    be implemented by SRC and SRS for mutual authentication.

Now that you've added the reference, you may not need the normative 
language here. Is the RECOMMENDED something new beyond what is already 
required in siprec-protocol? (I am pretty sure the MUST is already 
covered there.)

>
>
>> -- 2nd paragraph: Do you really expect people to implement s/mime?
>
> Good question. Many of the implementations of SIPREC I know of does 
> not do
> it.
> Most of them just setup the RS SIP dialog over TLS (with mutual
> authentication) and send metadata.
> We can make this a non-normative.

I think you may already be dealing with this for Stephen's review, but 
the real problem is that the draft says you SHOULD use e2e SIP 
protection, and no such thing really exists in practice. Making that 
non-normative doesn't solve the issue. The best we can probably expect 
is hop-by-hop. It would be better to simply point that out, and describe 
the limitations it brings.

>
>> -- last paragraph: I'm not sure what "Implementations MUST control 
>> what
>> metadata
>>   is recorded" means. Is the point that the implementation must let
>> someone control that policy? That it must not record unnecessary
>> metadata? (If the later, how is "necessary" determined?)
>
> An SRC may have policy that suggests what kind of metadata can/cannot 
> be
> recorded. The same holds for SRS. If a SRS has a policy on what can be
> recorded it can use that to
> control what it can record.

So what is the practical thing that implementations MUST do? Is this 
just trying to say that it MUST follow it's own policy?

>
>>
>> - 13.2: I think RFCs 3325 and 3326 need to be normative references.
>> That's an issue for 3325, but section 6.5.1 normatively states that 
>> P-AID
>> is a potential source for nameID. (which should probably be scoped to
>> only be true for deployments where P-AID makes sense.)
>
> Fine. We can make reference to 3325 and 3326 normative.

On reflection, I think I've changed my mind on suggesting 3325 be 
normative. In the description of the nameID attribute, it would be 
better to say that nameID is the AoR of the participant, and then 
non-normatively mention examples of where that might come from 
(including P-AID as one of those examples.)

And now that I look at that paragraph again, I wonder if an 
RFC4424/4424bis identity assertion should be listed as an example 
source?

[...]