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

[Paul Kyzivat <[e-mail]>]

[Omitting the IESG]

This seems fine to me except for a couple of small English tweaks:

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

s/Only one/Exactly one/

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

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

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

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

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

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