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

["Ram Mohan R (rmohanr)" <[e-mail]>]

Please see inline

-----Original Message-----
From: Ben Campbell <[e-mail]>
Date: Thursday, 10 March 2016 at 4:10 AM
To: Cisco Employee <[e-mail]>
Cc: The IESG <[e-mail]>, "[e-mail]"
<[e-mail]>, "[e-mail]"
<[e-mail]>, "[e-mail]" <[e-mail]>,
Brian Rosen <[e-mail]>
Subject: Re: Ben Campbell's No Objection on draft-ietf-siprec-metadata-20:
(with COMMENT)

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

That’s right. SRS get multiple snapshots over a period of time. The model
actually represents how a SRS builds the metadata that is accumulated over
a period of time.
>
>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.

Correct.

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

I don’t see a need for separate section. I will modify 2nd to last para of
Section 4. So new text will be:

EXISTING:
The model allows the capture of a snapshot of a recording's metadata
   at a given instant in time.  Metadata changes to reflect changes in
   what is being recorded.  For example, if a participant joins a
   conference, then the SRC sends the SRS a snapshot of metadata having
   that participant information (with attributes like name/AoR pair and
   associate-time.)


NEW:
The model allows the capture of a snapshot of a recording's metadata
   at a given instant in time.  Metadata changes to reflect changes in
   what is being recorded.  For example, if a participant joins a
   conference, then the SRC sends the SRS a snapshot of metadata having
   that participant information (with attributes like name/AoR pair and
   associate-time.)


>
>[...]
>
>>>
>>> - 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."

Ok. New text is:

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

NEW:
The 'recording' element MUST contain an xmlns namespace attribute with
value as urn:ietf:params:xml:ns:recording:1. Only one recording element
MUST be present in every recording metadata XML document.


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

Will add following text to 6.1.2

NEW:

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 when the RS
is setup will not have have CS(and the related CSG) elements in the XML as
there is no session that is associated to the RS yet.  For e.g; a phone
acting
as SRC can setup a RS with SRS even before phone is part of a CS. Once the
phone
joins a CS, the same RS would be used to convey the CS metadata.

Does this look ok ?


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

Ok, Will add the following text at the beginning of 6.2

EXISTING:
One instance of a Communication Session Group(CS-Group) class namely
   the Communication Session Group object provides association or
   linking of Communication Sessions.


NEW:
One instance of a Communication Session Group(CS-Group) class namely
   the Communication Session Group object provides association or
   linking of Communication Sessions. A CS-Group is used to group all
related CS. For e.g, in a contact centre flow a call may get transferred
to multiple agents. Each of these may trigger setup of new CS.
In cases where the SRC knows the related CSs it can group them using
The CS-Group element.

Is this better ?


>
>[...]
>
>>
>>>
>>> - 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.)

You are right. Grouping CS is not mandatory. CSs can be directly linked to
RS. The current linkages of CS allows it already.
CS to CS-group linkage is optional (0..1) as you can see in 6.2 linkages
where a CS if present must be linked to atleast one RS (1..*)


>
>[...]
>
>>>
>>> - 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.)

All the other elements are contained inside the <recording> element by its
association via a CS.
I agree that media stream since it can be outside a CS can have a direct
linkage to RS. All the other elements link via CS
I will add a line from MS block to RS in the model.

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

Sorry my mistake. Did not do enough home-work on that and just took your
comment :)

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?

I don’t see a need.

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

The versioning was added after discussions with few XML experts who
suggested it is always a best practice.
Even if its a informational extension I would expect the ver to be
incremented, otherwise a SRS parsing the metadata
Would not understand the new elements. It can choose to ignore but I see
no harm in having a new ver for new extensions of this draft.

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

Right. I have fixed this after discussion with Stephen. New text for para
1 in Security Consideration is:
Para 2 is removed.

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.   The procedures mentioned in
security consideration
section of <xref target="I-D.ietf-siprec-protocol"/> MUST be implemented
by SRC and SRS for
 mutual authentication and to protect the content of the metadata in the
RS.

Some implementations may have the SRC choose parts of metadata that can be
sent to the SRS.  
In other cases, SRCs may send metadata that is not appropriate for the SRS
to record. Which
 metadata is actually recorded by the SRS must be carefully considered to
balance privacy 
concerns with usability. Implementations MUST control what metadata is
recorded, and MUST NOT
 save metadata sent by the SRC that does not conform to the recording
policy of the SRS. 
Metadata in storage needs to be provided with a level of security that is
comparable to that 
of the recording session.

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

Taken care above.
>
>>
>>> -- 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?

Yes. SRC policy will dictate on what metadata it can send.

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

WFM. I will modify the text to make it non-normative.

NEW:
The AoR is drawn from From header or P-Asserted-Identity header or
Remote-Party-ID header.

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

I am fine with adding RFC4424 Identity assertion header as one source for
nameID.

Ram

>
>[...]