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

From: "Ben Campbell" <[email-masked]>
Date: Tue, 01 Mar 2016 16:25:15 -0800

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?  Along the same lines,
what would it mean for a CS or CSG to be associated with more than one
RS? 

- 5.1: Does the xml doc contain _exactly_ one <recording> element?

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

- 6.1.2: Can you elaborate on "persistent recording" and why it removes
the need for a CS/CSG?

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

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

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

-6.3.1, sipSessionID: I gather this is the session-id from the media
session, not the recording session. 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. 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 ;-)

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

-6.11: Do I understand correctly that means  no extensions are allowed
without changing the version number? Is that really the intent?

-10, first paragraph:
Why is the SHOULD not a MUST? Also,  what does the SRC need to
authenticate/authorize?
-- 2nd paragraph: Do you really expect people to implement s/mime?
-- 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?)

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

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

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

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

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Wed, 2 Mar 2016 17:01:58 +0000

Hi Ben,

Thanks for your through review. Please see inline

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

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

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.

>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

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

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

>(I guess that will always be true in the XML, but it's not apparent from

In the UML diagram there is association from CS To RS as well from CS to
CSG.
I hope that is sufficient.

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

Sure. Will add RFC reference.

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

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

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

> Also,  what does the SRC need to

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.

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

>only be true for deployments where P-AID makes sense.)

Fine. We can make reference to 3325 and 3326 normative.

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

>have reason to update the draft.

Ok will fix whatever we can.

>represented a recording session back when <recording> was first mentioned

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

Regards,
Ram

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 09 Mar 2016 16:40:07 -0600

Hi Ram,

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

Ben.

> Date: Wednesday, 2 March 2016 at 5:55 AM

[...]

[...]

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

[...]

> Perhaps I can tighten that and say only one if it is going to make it

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

[...]

> on that phone the Session will be recorded from that RS.

It would be helpful to say that in the draft.

> This is expected to provide useful information to SRS.

Some text to that effect would be helpful.

[...]

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

[...]

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

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

> has to be done by means of a new version number to the namespace 

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.

> has to be done. We plan to add text referring to that in the first 

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?

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

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

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

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

[...]

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 9 Mar 2016 17:51:21 -0500

> confusion I had over things like CSRS Association.

The SRC delivers a series of xml snapshots over the RS. We don't mandate 
what the SRS does with those. But we try to provide sufficient 
information so that it *could* build up a database such as you describe.

> operation (unless that's already in another document, in which case a

I *thought this was evident. Maybe not.

	Thanks,
	Paul

> RFC4424/4424bis identity assertion should be listed as an example source?
>
> [...]
>
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Thu, 10 Mar 2016 04:33:39 +0000

Please see inline

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

>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.
>confusion I had over things like CSRS Association.

Correct.

>operation (unless that's already in another document, in which case a

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

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

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

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

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

>explained in terms of the UML model, I find it at least a little bit

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.

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

>Is its mention here absolutely necessary?

I don’t see a need.

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

>required in siprec-protocol? (I am pretty sure the MUST is already

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.

>the limitations it brings.

Taken care above.
>just trying to say that it MUST follow it's own policy?

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

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

>RFC4424/4424bis identity assertion should be listed as an example

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

Ram

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Thu, 10 Mar 2016 04:37:28 +0000

Sorry for typo in the new text on the below response. Below is correct one

-----Original Message-----
From: Cisco Employee <[email-masked]>
Date: Thursday, 10 March 2016 at 10:03 AM
To: Ben Campbell <[email-masked]>
Cc: The IESG <[email-masked]>, "[email-masked]"

>The model allows the capture of snapshots of recording's metadata
>   over a period of time.  Metadata changes to reflect changes in

Regards,
Ram

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Mar 2016 00:20:34 -0500

[Omitting the IESG]

> MUST be present in every recording metadata XML document.

s/Only one/Exactly one/

> joins a CS, the same RS would be used to convey the CS metadata.

(The above seems to suggest that a persistent RS must be setup before
any CS.)

s/even before/possibly even before/

s/will not have have CS/may not have CS/

> In cases where the SRC knows the related CSs it can group them using

s/centre/center/ (AFAIK we are doing American English)

> of the recording session.

How about:

An SRC MAY, by policy, choose to limit the parts of the metadata sent to
the SRS for recording. And the SRS MAY not need all the metadata it
receives or choose, by policy, to limit the metadata it records.
Metadata in storage needs to be provided with a level of security that
is comparable to that of the recording session.

	Thanks,
	Paul

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Thu, 10 Mar 2016 05:25:14 +0000

Paul,

Thanks. I will fix the nits you pointed out.

Regards,
Ram

-----Original Message-----
From: Paul Kyzivat <[email-masked]>
Date: Thursday, 10 March 2016 at 10:50 AM
To: Cisco Employee <[email-masked]>, Ben Campbell <[email-masked]>
Cc: "[email-masked]"

>>is

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Mar 2016 00:29:25 -0500

> Thanks. I will fix the nits you pointed out.

The last one is more than a nit. So it might require more discussion. Ben?

	Thanks,
	Paul

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 14 Mar 2016 13:27:25 -0500

On 9 Mar 2016, at 16:51, Paul Kyzivat wrote:

> The SRC delivers a series of xml snapshots over the RS. We don't 
> mandate what the SRS does with those. But we try to provide sufficient 

Keeping a history may not be required, but there seems to be 
relationships in the model that cannot ever occur in real life unless 
the SRS builds a cross-snapshot picture. (E.g.,  a given CS associated 
with more than one RS, and much anything useful with CSRS associations).

> I *thought this was evident. Maybe not.

Maybe I missed something, but the only thing I find on the subject is 
the penultimate paragraph in section 4, which says:

" The model allows the capture of a snapshot of a recording's metadata
    associate-time.) "

To me that suggests that the model only describes an instant in time. 
One might infer otherwise from the document as a whole, but I think a 
more explicit explanation of assumptions would be helpful for someone 
coming newly to this work.

Ben.

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 14 Mar 2016 14:06:18 -0500

Hi, further comments inline. I removed sections that didn't seem to need 
further discussion.
On 9 Mar 2016, at 22:33, Ram Mohan R (rmohanr) wrote:

[...[

>    that participant information (with attributes like name/AoR pair 

I see you corrected this is a separate email, so I will respond there.

> MUST be present in every recording metadata XML document.

I see Paul beat me to suggesting s/"Only one"/"Exactly one". It's fine 
with that change applied.

> joins a CS, the same RS would be used to convey the CS metadata.

Yes, thanks.

>>> the

Yes, thanks.

[...]

> I will add a line from MS block to RS in the model.

That helps, thanks.

[...]

> no harm in having a new ver for new extensions of this draft.

Okay. I don't consider myself an XML expert, and certainly won't argue 
real ones. :-)

[...]

> recorded

Perhaps s/"control what metadata is recorded"/"limit what metadata is 
recorded" ?

> The AoR is drawn from From header or P-Asserted-Identity header or

I suggest going a little further, such as "... For example, the AoR may 
be drawn from the From header field or P-Asserted-Identity header 
field." (eliding RPID as mentioned earlier)

> I am fine with adding RFC4424 Identity assertion header as one source 

On reflection, the actual AoR would still come from From, etc, even with 
4474/4474bis. So the mention is probably not needed.

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 14 Mar 2016 14:06:55 -0500

>>   that participant information (with attributes like name/AoR pair and

Tha WFM, thanks.

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 14 Mar 2016 14:16:06 -0500

> is comparable to that of the recording session.

I think that helps, but might need a couple of tweaks:

- The 2nd MAY seems more a statement of fact.

- I think the concept that the SRS MUST NOT record unneeded metatdata 
came from the discussion with Stephen, so I am hesitant to suggest 
removing the 2119 language. How about something like:

"An SRC MAY, by policy, choose to limit the parts of the metadata sent 
to the SRS for recording. And the policy of the SRS might not require 
all the metadata it receives. For the sake of data minimization, the SRS 
MUST not record additional metadata that is not explicitly required by 
local policy. Metadata in storage needs to be provided with a level of 
security that is comparable to that of the recording session."

(But on the other hand, if Stephen has already agreed to the previous 
language, then I would hesitate to change it more than necessary.)

Ben.

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 14 Mar 2016 14:16:39 -0500

> The last one is more than a nit. So it might require more discussion. Ben?

Agreed--see separate email.

Ben.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 14 Mar 2016 18:19:13 -0400

The below seems good to me.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 14 Mar 2016 18:45:04 -0400

> coming newly to this work.

OK, you are right. Those of us who have been working on it knew what we 
meant, but the text doesn't reflect that. Would the following be a 
suitable replacement for the above paragraph?

"The model allows metadata describing communications sessions to be 
communicated to the SRS as a series of snapshots, each representing the 
state as seen by a single SRC at a particular instant in time. Metadata 
changes from one snapshot to another 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.)"

	Thanks,
	Paul

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 14 Mar 2016 18:16:12 -0500

Oops, s/MUST not record/MUST NOT record

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 14 Mar 2016 18:17:48 -0500

On 14 Mar 2016, at 17:45, Paul Kyzivat wrote:

> OK, you are right. Those of us who have been working on it knew what 
> we meant, but the text doesn't reflect that. Would the following be a 
> communicated to the SRS as a series of snapshots, each representing 
> the state as seen by a single SRC at a particular instant in time. 
> Metadata changes from one snapshot to another 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.)"

Yes, that would help. Ram proposed different text, which is also fine. 
Either would improve things.

Thanks,

Ben.

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Tue, 15 Mar 2016 13:00:12 +0000

Hi Ben,

Thanks for review. See inline. Removed those that does not need any
response (which you have accepted). Will send diffs to WG and reviewers
soon with all the comments incorporated.

-----Original Message-----
From: Ben Campbell <[email-masked]>
Date: Tuesday, 15 March 2016 at 12:36 AM
To: Cisco Employee <[email-masked]>
Cc: "[email-masked]"
<[email-masked]>, "[email-masked]"
<[email-masked]>, Brian Rosen <[email-masked]>, The IESG
<[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Ben Campbell's No Objection on draft-ietf-siprec-metadata-20:
(with COMMENT)

>Perhaps s/"control what metadata is recorded"/"limit what metadata is

I see that Paul and you have discussed in the other thread and came up
with text for this part. I will use that text here.

NEW: (Taken from your mail with Paul)

MUST NOT record additional metadata that is not explicitly required by

>field." (eliding RPID as mentioned earlier)

WFM. Will add the suggested text.

>4474/4474bis. So the mention is probably not needed.

Ok. Will not add this.

I will send out diffs with all the comments incorporated soon.

Regards,
Ram

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 15 Mar 2016 09:22:06 -0500

Hi Ram,

It all looks good to me.

Thanks!

Ben.

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Wed, 16 Mar 2016 03:15:05 +0000

Hi All,

Please find the diffs attached. This addresses Stephen¹s and Ben¹s IESG
comments. Please check and let me know if this is fine. I will publish the
revision by end of this week.

Regards,
Ram

-----Original Message-----
From: Ben Campbell <[email-masked]>
Date: Tuesday, 15 March 2016 at 7:52 PM
To: Cisco Employee <[email-masked]>
Cc: "[email-masked]"
<[email-masked]>, "[email-masked]"
<[email-masked]>, Brian Rosen <[email-masked]>,
"[email-masked]" <[email-masked]>
Subject: Re: Ben Campbell's No Objection on draft-ietf-siprec-metadata-20:
(with COMMENT)

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 15 Mar 2016 23:06:28 -0500

I'm going to be on the road for the rest of the week. I will try to fit 
in a look at the diff, but please do not hold submission on my behalf 
(revisions are cheap). Failing that, I should be able to look at it by 
Monday or Tuesday.

Ben.

On 15 Mar 2016, at 22:15, Ram Mohan R (rmohanr) wrote:

>>>>> Right. I have fixed this after discussion with Stephen. New text 
>>>>> for
>>>>> para
>>>>> metadata could be considered private data.   The procedures 
>>>>> mentioned
>>>>> in
>>>>> security consideration
>>>>>  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
>>>>>>>> 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
>>>>> I am fine with adding RFC4424 Identity assertion header as one 
>>>>> source
>>>>> for
>>>>> nameID.
>>>>

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Sat, 19 Mar 2016 05:56:24 +0000

Hi Ben,

I just published the new revision. Please review this whenever you get
time.

Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-siprec-metadata-21

Thanks,
Ram

-----Original Message-----
From: Ben Campbell <[email-masked]>
Date: Wednesday, 16 March 2016 at 9:36 AM
To: Cisco Employee <[email-masked]>
Cc: Stephen Farrell <[email-masked]>, "[email-masked]"
<[email-masked]>, "[email-masked]"
<[email-masked]>, The IESG <[email-masked]>,
"[email-masked]" <[email-masked]>, Brian Rosen
<[email-masked]>
Subject: Re: Ben Campbell's No Objection on draft-ietf-siprec-metadata-20:
(with COMMENT)

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 21 Mar 2016 13:09:40 -0500

(Adding back ADs and IESG)

This version looks mostly good. I have one substantive comment, and a 
few editorial:

# Substantive #

- 10: (Apologies, I missed this when we discussed the text via mail)

I like the change to refer back to the protocol spec for the normative 
bits in the first paragraph. However, saying those procedures MUST be 
implemented doesn't seem right, since 12.3 of that draft says metadata 
SHOULD be protected. That is, the protocol spec says MUST implement, and 
SHOULD use (for metadata).

I propose a simple fix: s/"MUST be implemented by"/"apply for the"   (Or 
"MUST be followed by", if you really want to keep a 2119 statement 
keyword.

# Editorial #

- 6.2, last paragraph: "One instance of a Communication Session 
Group(CS-Group) class namely the CS-Group object provides association or 
grouping all related CS."

Something's not right with that sentence. Is there a missing "for" or 
"of" before "all related CS"? (And shouldn't that be "all related CSs"?

- 6.5.1, name-id:

Consider moving the reference for P-AID to the first mention of it. 
(Yes, I realize that's not really new text ;-) )

- 6.10 "If two SRCs use the same UUID, it MUST retain the UUID/element 
mapping."

Ambiguous antecedent for "it".

On 19 Mar 2016, at 0:56, Ram Mohan R (rmohanr) wrote:

>>> comments. Please check and let me know if this is fine. I will 
>>> publish
>>> the
>>>>>>> Metadata in storage needs to be provided with a level of 
>>>>>>> security
>>>>>>> that
>>>>>>> is
>>>>>>> comparable to that
>>>>>> Perhaps s/"control what metadata is recorded"/"limit what 
>>>>>> metadata
>>>>>> is
>>>>>> recorded" ?
>>>>>
>>>>> I see that Paul and you have discussed in the other thread and 
>>>>> came
>>>>> up
>>>>> all the metadata it receives. For the sake of data minimization, 
>>>>> the
>>>>> SRS
>>>>> MUST NOT record additional metadata that is not explicitly 
>>>>> required
>>>>> by
>>>>> local policy. Metadata in storage needs to be provided with a 
>>>>> level
>>>>> of
>>>>>> I suggest going a little further, such as "... For example, the 
>>>>>> AoR
>>>>>> may
>>>>>> On reflection, the actual AoR would still come from From, etc, 
>>>>>> even
>>>>>> with

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Tue, 22 Mar 2016 03:51:29 +0000

Hi Ben,

Thanks for your review. See inline

-----Original Message-----
From: Ben Campbell <[email-masked]>
Date: Monday, 21 March 2016 at 11:39 PM
To: Cisco Employee <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, IESG <[email-masked]>, ART ADs
<[email-masked]>

>"MUST be followed by", if you really want to keep a 2119 statement

I will keep the text to “MUST be followed by”

>"of" before "all related CS"? (And shouldn't that be "all related CSs"?

Right will add - “of all related CSs”

>Consider moving the reference for P-AID to the first mention of it.

Ok.

>- 6.10 "If two SRCs use the same UUID, it MUST retain the UUID/element

NEW:
If two SRCs use the same UUID, they MUST retain the UUID/element mapping.

Regards,
Ram

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 22 Mar 2016 00:08:34 -0500

All of your responses look good to me.

Thanks!

Ben.