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

["Ben Campbell" <[e-mail]>]

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.