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

Hi, Ben,

Thank you very much for your careful review!

Spencer

----- Original Message ----- 
From: "Ben Campbell" <ben@estacado.net>
To: "Chris Boulton" <chris@ns-technologies.com>; <lorenzo.miniero@unina.it>
Cc: <rai@ietf.org>; <mediactrl@ietf.org>
Sent: Tuesday, February 23, 2010 10:19 PM
Subject: 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
>
> _______________________________________________
> MEDIACTRL mailing list
> MEDIACTRL@ietf.org
> https://www.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/mediactrl 