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

On 3/9/16 5:40 PM, Ben Campbell wrote:

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

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.

> 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 *thought this was evident. Maybe not.

	Thanks,
	Paul

> [...]
>
>>>
>>> - 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?
>
> [...]
>
> _______________________________________________
> siprec mailing list
> siprec@ietf.org
> https://www.ietf.org/mailman/listinfo/siprec