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

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

Hi Ben,

Thanks for your through review. Please see inline

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

>Ben Campbell has entered the following ballot position for
>draft-ietf-siprec-metadata-20: No Objection
>
>When responding, please keep the subject line intact and reply to all
>email addresses included in the To and CC lines. (Feel free to cut this
>introductory paragraph, however.)
>
>
>Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>for more information about IESG DISCUSS and COMMENT positions.
>
>
>The document, along with other ballot positions, can be found here:
>https://datatracker.ietf.org/doc/draft-ietf-siprec-metadata/
>
>
>
>----------------------------------------------------------------------
>COMMENT:
>----------------------------------------------------------------------
>
>I'm going to ballot no-objection on this, but I do have some comments
>
>= 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).

>Along the same lines,
>what would it mean for a CS or CSG to be associated with more than one
>RS?

See above.

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

>
>- 5.1.2: See question on 5.1. (Also, the normative language seems
>redundant between the sections.)

Ok. I will fix the text to have normative at the beginning (say in the
first para of 5.1) and remove the normative in 5.1.2 as that is redundant.

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

>
>-6.2.2: The UML suggests that a given CS cannot be associated with more
>than 1 CSG. That¹s worth mentioning here.

Good Point. Will modify text as:

EXISTING:
There are one or more CSs per CS-Group (for example, in case where
      the call is transferred).


NEW:
There are one or more CSs per CS-Group (for example, in case where
      the call is transferred). A CS cannot be associated with more than
one CSG.


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

>
>-6.3.1, sipSessionID: I gather this is the session-id from the media
>session, not the recording session.

This is the INSIPID sessionID. This is the sessionID header that is
carried in the CS which in turn will be copied and sent in XML to SRS.
Note that the SRC to SRS SIP dialog itself can also have sessionID header
(which is different from what CS carries as its a different SIP dialog).

Current text indicates that :

"sipSessionID - This attribute carries sip Session-ID defined in
      [I-D.ietf-insipid-session-id].  Each CS object can have zero or
      more sipSessionID elements.²

Hope it is sufficient.
 
> If correct, it would be helpful to
>say it explicitly.
>
>- 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.

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.

>
>- 6.10: Why not MUST? Can you envision good reasons to not use this
>method?

I have already fixed in my copy (diffs sent to WG as well) this as part of
addressing comments from SecDir comments.

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

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


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

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

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

> 
>
>= Editorial =
>
>- Figure numbers and captions would be useful.
>
>- I found the organization to be a bit odd. Section 5 starts talking
>about some but not all XML details, then 6 goes over the UML model, but
>switches back to XML in the last few sections, then we've got more XML
>stuff (schema, etc) further down.
Not sure what we can fix here. Perhaps I can make section 6.9, 6.10, 6.11
outside 6 as separate sections.

>
>- There are a lot of missing articles and commas, especially in the in
>section 6 and subsections. The RFC editor will fix this, but it would
>save them work if the authors did a proofreading pass, if they otherwise
>have reason to update the draft.

Ok will fix whatever we can.

>
>- 6.1: It would have been helpful to mention that the <recording> element
>represented a recording session back when <recording> was first mentioned
>in section 5.

Ok. Will add text for this in 5.1 para 1.

Regards,
Ram

>
>