Subject: [MEDIACTRL] Fw: AD review of draft-ietf-mediactrl-requirements

From: Spencer Dawkins <[email-masked]>
Date: Mon, 12 Nov 2007 16:03:24 -0600

Hi, Mediactrl,

Jon has sent some comments on the mediactrl requirements draft (AD 
Evaluation is the first step after we request that a draft be published).

We (as chairs) think these comments are suggestions for word-smithing, not 
substantive changes, but there are enough comments that a new draft will be 
required, so please don't be surprised when you see an announcement for 
requirements-02.

Prospective authors/editors can also learn something about Jon's review 
style :-)

Thanks,

Spencer and Eric, as co-chairs

----- Original Message ----- 
From: "Peterson, Jon" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, November 09, 2007 5:35 PM
Subject: AD review of draft-ietf-mediactrl-requirements

I'd like to see a revision of this before the document goes forward. In 
particular, I'd like to see the Abstract and  Introduction read a bit more 
smoothly (as outlined below), and also I recommend dispensing with 2119 
language. More  detailed comments on the text follow; let me know what you 
think.

Nit, second sentence of Abstract "current work in IETF working groups show" 
should be "shows"; "do not address" should  be "does not address". Nit, 
second paragraph of Abstract "from a media server control protocol (MCP)" 
should be "for a  media server control protocol (MCP)". While we can rely on 
the RFC-Editor to get most things along these lines, I  really would like 
the Abstract to be clean before we send docs to the IESG for review.

>From the Intro:

   There is an interest to work on a protocol that will enable one
   physical entity that includes the conference/media policy server,
   notification server and the focus also known as Application Server
   (AS)

Does this mean that the focus is also known as the Application Server, or 
that the focus, notification server and  conference/media policy server are 
all collectively known as the Application Server? The text here should be 
clearer  which you mean.

Nit, Intro, "An example of decomposition to a media server and application 
server" should be "An example of the  decomposition of a media server and an 
application server".

Nit, Intro, just like in the Abstract, "requirements from a media server 
control protocol" should be "requirements for  a media server control 
protocol".

Nit, Intro, "The requirements are from the protocol" should be "The 
requirements are for the protocol". "from" - Latin  "ab", "for = Latin "ad"

In section 2, Terminology, I'm not sure that RFC2119 terms only "indicate 
requirement levels for compliant RTP  implementations" in this document. I'm 
not a fan of RFC2119 language in requirements documents, but, that's up to 
the  conscience of the individual churchgoer.

In 2,

   The media server source media streams for announcements, it
   process media streams for functions like DTMF detection and
   transcoding.

Perhaps the media server "sources" and "processes" media streams?

Does REQ-MCP-02 mean that the MS control protocol will be able to run over a 
variety of (reliable) transport  protocols? If so, might be best to state 
that explicitly.

REQ-MCP-04, "application" should be plural?

REQ-MCP-05 You might want to distinguish tones from audio, here. My 
(uninformed) guess is that by "tones" you mean  RTP-signaled 2833-style 
DTMF?

REQ-MCP-07 Are channels independent transport connections, or what? How do 
they help? The blurb about sessions doesn't  immediately make this any more 
clear.

REQ-MCP-09 Just to be clear, is this saying that SIP/SDP is used to the 
exclusion of any other protocol, including,  say, RTSP, Jingle, Skype, etc.? 
What impact is this expected to have on future protocol design?

REQ-MCP-12 and REQ-MCP-13, while undoubtedly well intentioned, really don't 
say anything useful. Especially 13. If you  want to put out some concrete 
requirements for what sort of extensibility is needed, or what sort of 
threats the  protocol might want to address, that's fine, but these sorts of 
motherhood-and-apple-pie statements should be removed.

Throughout these requirements, RFC2119 language is used spottily. Look at 
REQ-MCP-17 & 18, for example, compared to 02  and 03. My inclination would 
be to make everything lowercase and not refer to 2119 here. Similarly, when 
I read  REQ-MCP-21 versus, say, 22 I just wonder what is the intended 
difference between "shall be able" and "may be able". Do  you mean that all 
ASs need to have a capability to define a conference mix, but that some ASs 
might not need to be  able to define a separate mix for each participant? If 
so, what impact does this have on the future protocol design;  how does that 
fact constrain future decisions you'll be making?

In REQ-MCP-24 "The number of sub-windows will start from one." Does this 
mean that sub-windows will be indexed based  on an integer starting with one 
and incrementing from there?

The statement in Section 5 seems highly dubious to me, or at best, a 
prediction that I have hard time seeing how you  can really make. That much 
said, the core sentiment here is good. You do want to say that you intended 
to make use of  existing IETF protocols whose security properties are 
well-understood, and to build any security properties that you  need from 
those tools. I just wouldn't go claiming in a requirements document that the 
eventual solution is guaranteed  not to introduce any new security 
vulnerabilities.

- J

_______________________________________________
MEDIACTRL mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl