Re: [MEDIACTRL] [RAI] RAI-ART Review of draft-ietf-mediactrl-mrb-03

Oops, sorry, my mailer pulled up an old address for Chris. Trying again...

On Feb 23, 2010, at 9:18 PM, Ben Campbell wrote:

> I am the assigned RAI-ART reviewer for draft-ietf-mediactrl-mrb-03.
> 
> For background on RAI-ART, please see the FAQ at
> <http://www.softarmor.com/rai/art/FAQ.html>.
> 
> Please resolve these comments along with any other comments you may receive.
> 
> This draft is on the right track for publication as a proposed standard, but there are issues that should be considered first.
> 
> Disclaimer: This draft has 40+ pages of XML schema definitions. I did not attempt to verify them beyond a cursory look. Hopefully they can be verified mechanically (by someone with deeper XML knowledge than me) prior to publication.
> 
> Architectural Comments:
> 
> -- The publish interface defines yet another way to do subscriptions. Since it's based on mediactrl, this means using a SIP dialog to establish a mediactrl session for these subcriptions. The data in this case feels like metadata related to signaling more than content.  Did the working group consider the possibility of using SIP-events? (RFC 3265)? If so, what was the motivation for creating something new? (Perhaps other mediactrl packages already have subscription semantics, and this follows their precedents? It's been a long time since I read the IVR package)
> 
> -- You note that the consumer inline interface can be equivalent to the query interface when the MRB sends a 3XX response. Why, then, do you propose two ways to accomplish the same thing? It seems like this just makes life harder for everyone. Implementations will have to implement both methods in order to be interoperable with any other arbitrary implementation.
> 
> -- The inline approach to the consumer interface basically involves the MRB acting as a b2bua to select downstream destinations according to the app server preferences. This is very similar to the problem caller-prefs [RFC 3841] set out to solve. Did the work group consider using caller-prefs  as the basis?
> 
> -- section 4.2: 
> 
> The IUMM requires the MRB to understand how to interpret the SIP signaling and SDP offer normally intended for the MS. This means it has to have the same application level knowledge as the MS. This creates brittleness in the network. For example, if a new mediactrl feature is invented that requires SDP extensions, the MRB must be updated, in addition to the AS and MSs. This is generally counter to the end-to-end principle of the internet architecture.
> 
> 
> Major Comments:
> 
> -- 5.2.2: 
> 
> I think you really need a required/supported option tag to indicate the expected interpretation of the new body parts. You can't just infer the application by the presence of the body parts, as future applications could someday use the same MIME types.
> 
> -- 5.2.2, first two items in first bullet list
> 
> This use of multipart doesn't really work. You can't just specify SDP in the first part, and msb-consumer in the 2nd. This breaks if combined with other extensions that use other body parts or other multipart types. You really need something like a multi-part related with an index part, or a header field that contains reference to the mrb-consumer part. 
> 
> -- 5.2.3:
> 
> You need some more "big picture" discussion about the lease mechanism. Does "lease" imply the MRB is managing resources--i.e. keeping state of allocated resources against available resources, etc, rather than simply depending on the MS to provide the information? If so, can the MS and the MRB get out of sync? Is it legal to have some access to a given MS be direct, and other via the MRB? If there are multiple MRBs do they need to share resource state?
> 
> 
> -- 5.2.3, <action> definition:
> 
> Are 409 and 410 the only allowed errors? Why a separate error codes that only seem to differ as to the request type?
> 
> Also, from experience in defining MSRP, I think it is a mistake to choose error codes for other protocols to match those of SIP or HTTP. This causes a lot of confusion in place the meanings are subtly different. It also causes layer confusion (When someone says they got a 409, is that a SIP 409, or an mrb-consumer 409?)
> 
> 
> Minor Comments:
> 
> -- publish interface in general: How does an MRB know what MSs it should query? Is this expected to be provisioned?
> 
> -- section 5.1, 2nd paragraph:
> 
> Can you provide a reference for the spec for "good engineering"?  Seriously, though, you're saying that the MRB can live with imprecise or even stale information, and that operating on this imperfect information will provide better results ( or more scaleability or less complexity) than simply guessing. I'm not saying you're wrong, but I think that proposal needs a little more analysis for me to accept it as axiomatic.
> 
> -- section 5.1.1.4:
> 
> What are the uniqueness requirements (scope, chance of collision, etc) for "id"? (Question applies to all the ID attributes in this draft.)
> 
> I think seqnumber needs some more explanation. How is it constructed? Can the recipient infer anything about gaps in sequence numbers? Do  you have to worry about roll over? Do you have separate sequence spaces in each direction (like CSeq for SIP?)
> 
> What is the scope for "expires"? For example, does a the expiring state survive the end of a mediactrl session? How is it handled if not present? (Similar questions applies to all occurrences of "Expires" attributes in the draft.)
> 
> -- 5.1.4.*
> 
> This entire section seems to enumerate the features for an MS. How do new features get added?
> 
> -- 5.1.4.5:
> 
> I'm not sure I understand what a non-active session is. Do you mean available ports, resources, etc that could be used for sessions? Is that the right way to express available resources? (For example, how would you express available CPU cycles in terms of available sessions?) I think you mentioned this issue somewhere, but I'm not sure I agree that you've found the right abstraction here.
> 
> -- 5.1.4.7:
> 
> What's the practical difference between deactivated and unavailable?
> 
> -- 5.1.4.9:
> 
> It's not clear to me what <application data> is for--can you elaborate?
> 
> 5.1.4.10, "supported-format"
> 
> What kind of name goes in the supported format. Is this a MIME type, or some other managed namespace? (Similar questions apply for the values for other "name" attributes in the draft, where the name spaces or registries need to be defined.)
> 
> -- 5.1.4.12:
> 
> What goes in "name"? Are you picking from a registry?
> 
> --5.1.4.13, "audio-mixing-modes"
> 
> What sort of value does the "package" attribute carry? Is there a registry for mediactrl package names?
> 
> (This sort of issue occurs several more times. I'm going to quite commenting on it.)
> 
> 
> -- security considerations:
> 
> It's worth discussing the fact that the IAMM model involves a b2bua modifying SIP bodies. This impacts the ability to use any SIP security feature that protects the body (e.g. 4474, s/mime, etc.) unless the MRB intermediates the security association. Given that one of points of using SIP for mediactrl in the first place was to reuse SIP features when possible, I think this is an issue.
> 
> The security considerations talk about channel security, but not so much about authorization. I think it's important to make sure only authorized application servers can get information about media servers, etc.
> 
> -- 5.2.4, definition of <mrbconsumer>
> 
> Is the exclusion enforced by the schema? If not, should it be normative?
> 
> Editorial Comments:
> 
> -- idnits generates some warnings.
> 
> -- General Comment: There's a lot of redundancy in this draft. A procedures are often described several times. Many data elements are described several times. Data elements that are either identical or very close to identical between the publish and consumer interface are described in detail for both interfaces, including in the schemas. It makes sense to have a section that describes how the protocols work at a high level, and another that describes them normatively, but that distinction is not clear. The result is a very long document, that could probably be considerably shorter with some editing.
> 
> -- section 2, 2119 language: Why the BCP 15 reference? That's "Deployment of the Internet White Pages Service"--is that really what you meant? (BTW, that additional text confuses idnits when it's checking for 2119 boilerplate.)
> 
> -- Section 3, paragraph 1: "It is clear from Section 1 that the MediaCtrl group will be producing
>   a solution that must service a wide variety of deployment
>   architectures."
> 
> It is clear to whom? (making forward looking statements about what a WG will solve is dangerous, at best--not to mention this one will date the draft if it becomes an RFC.)
> 
> -- section 5.1, first paragraph, 2nd sentence:
> 
> Generally accepted by whom? I'm not sure what information this sentence intends to convey.
> 
> -- ... 2nd to last sentence:
> 
> Perfect? Really? :-)  (I'd suggest turning down the hype a bit.)
> 
> -- section 5.1.1:
> 
> That MUST is a statement of fact, not a normative requirement imposed by _this_ spec. I suggest it be uncapitalized.
> 
> -- section 5.1.1.4:
> 
> Is (or can) the MUST requirement of mutual exclusivity expressed in the schema?
> 
> -- section 5.1.3.1, definition of "id"
> 
> What is the "session"? Are we talking about the resulting subscription, or the mediactrl session?
> 
> -- section 5.1.4.2: Did you mean to say no child elements? Isn't <package> a child element?
> 
> -- 5.1.4.14, supported-country-codes:
> 
> Need a reference for ISO-3166-1
> 
> -- 5.2.3, definition of "action"
> 
> It would help to separate the possible values into separate paragraphs, sub-bullets, a table, or something. It's hard to can with the values defined mid-paragraph.
> 
> 
> -- 5.3.2, 5th paragraph:
> 
> s/IAMM/MRB ?
> 
> s/fulfil/fulfill
> _______________________________________________
> RAI mailing list
> RAI@ietf.org
> https://www.ietf.org/mailman/listinfo/rai