Re: [MEDIACTRL] Review of draft-ietf-mediactrl-call-flows-10

Lorenzo Miniero <lorenzo@meetecho.com> Sat, 13 April 2013 07:51 UTC

Return-Path: <lorenzo@meetecho.com>
X-Original-To: mediactrl@ietfa.amsl.com
Delivered-To: mediactrl@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C29D421F8FDC for <mediactrl@ietfa.amsl.com>; Sat, 13 Apr 2013 00:51:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.881
X-Spam-Level:
X-Spam-Status: No, score=0.881 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_BACKHAIR_23=1, J_CHICKENPOX_22=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A375uN5tiQXc for <mediactrl@ietfa.amsl.com>; Sat, 13 Apr 2013 00:51:49 -0700 (PDT)
Received: from smtpdg12.aruba.it (smtpdg7.aruba.it [62.149.158.237]) by ietfa.amsl.com (Postfix) with ESMTP id 4000121F8FE9 for <mediactrl@ietf.org>; Sat, 13 Apr 2013 00:51:47 -0700 (PDT)
Received: from rainpc ([79.46.24.65]) by smtpcmd04.ad.aruba.it with bizsmtp id PKrk1l00H1QG29K01KrkTS; Sat, 13 Apr 2013 09:51:46 +0200
Date: Sat, 13 Apr 2013 09:51:42 +0200
From: Lorenzo Miniero <lorenzo@meetecho.com>
To: Eric Burger <eburger@standardstrack.com>
Message-ID: <20130413095142.709b0a10@rainpc>
In-Reply-To: <97700AB5-E682-4DA2-BCD6-874A50F66575@standardstrack.com>
References: <201212192009.qBJK9j8a3356324@shell01.TheWorld.com> <20121226131152.4660538e@rainpc> <97700AB5-E682-4DA2-BCD6-874A50F66575@standardstrack.com>
Organization: Meetecho
X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.16; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Cc: "mediactrl@ietf.org list mailing" <mediactrl@ietf.org>
Subject: Re: [MEDIACTRL] Review of draft-ietf-mediactrl-call-flows-10
X-BeenThere: mediactrl@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Media Control WG Discussion List <mediactrl.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mediactrl>, <mailto:mediactrl-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mediactrl>
List-Post: <mailto:mediactrl@ietf.org>
List-Help: <mailto:mediactrl-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mediactrl>, <mailto:mediactrl-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 13 Apr 2013 07:51:52 -0000

Hello Eric,

there were some points in that thread where I asked for some more feedback, as I wasn't sure about the most apt way to go on. Anyway, I've already integrated the other comments, so I'll just publish that new version ASAP and take it from there.

L.


On Sat, 13 Apr 2013 02:57:23 -0400
Eric Burger <eburger@standardstrack.com> wrote:

> Are we done yet?
> 
> On Dec 26, 2012, at 7:11 AM, Lorenzo Miniero <lorenzo@meetecho.com> wrote:
> 
> > Hello Dale,
> > 
> > first of all, thanks for your detailed review! I'm answering to this
> > mail first, leaving the extracted issue of the previous issue to later,
> > since, as you pointed out, that's a more general issue.
> > 
> > I've added my replies inline prefixed by a [LM].
> > 
> > 
> > On Wed, 19 Dec 2012 15:09:45 -0500 (EST)
> > worley@ariadne.com (Dale R. Worley) wrote:
> > 
> >> Review of draft-ietf-mediactrl-call-flows-10
> >> 
> >> The first thing that comes to mind is that this is a massive body of
> >> work, and tremendously useful for the implementer!
> >> 
> > 
> > 
> > [LM] Thanks! That's exactly what we wanted to achieve.
> > 
> > 
> >> I've listed the items in the order they appear in the draft.  Almost
> >> all of them are editorial rather than technical.  The technical
> >> questions are:
> >> 
> >> item 15 (is the listing of control packages in the SDP important or not)
> >> item 17 (the negotiation of the timeout value is vague)
> >> item 35 (mixing of playback of two recordings)
> >> item 38 (semantics of setgain)
> >> item 53 (how does AS send media INVITE to the correct MS)
> >> item 55 (how does the MS know which AS sent each request)
> >> 
> >> item 1) various
> >> 
> >> The indentation of the header lines identifying various messages is
> >> inconsistent.  I can find the following lines in various places:
> >> 
> >> 1. AS -> MS (SIP INVITE)
> >> A1. AS -> MS (CFW CONTROL, createconference)
> >>  A1. AS1 -> MS (CFW CONTROL, audit IVR)
> >>   1. AS -> MS (CFW SYNC)
> >> 
> >> However, it may be easiest to have the RFC Editor fix that by giving
> >> them an appropriate instruction, as they are likely to manually adjust
> >> the indentation of the examples anyway.
> >> 
> > 
> > 
> > [LM] You're right, the indentation often varies, and the logic behind
> > this currently is according to whether or not the example fits the page.
> > Instructions about this would be welcome!
> > 
> > 
> >> item 2) various
> >> 
> >> There are a lot of places where an arrow seems to go from a network
> >> entity to itself, such as "create conf and its ID" below:
> >> 
> >>                    AS                                 MS
> >>                    |                                  |
> >>                    | 1. CONTROL (create conference)   |
> >>                    |++++++++++++++++++++++++++++++++>>|
> >>                    |                                  |--+ create
> >>                    |                                  |  | conf and
> >>                    |       2. 200 OK (conferenceid=Y) |<-+ its ID
> >>                    |<<++++++++++++++++++++++++++++++++|
> >> 
> >> However, the event described on the label, "create conf and its ID",
> >> is not the transmission of a message, and so it doesn't seem like it
> >> should be represented by an arrow.  A more accurate alternative would
> >> be:
> >> 
> >>                    AS                                 MS
> >>                    |                                  |
> >>                    | 1. CONTROL (create conference)   |
> >>                    |++++++++++++++++++++++++++++++++>>|
> >>                    |                                  | create
> >>                    |                                  | conf and
> >>                    |       2. 200 OK (conferenceid=Y) | its ID
> >>                    |<<++++++++++++++++++++++++++++++++|
> >> 
> > 
> > 
> > [LM] Yes, in that case the arrow was not meant as a network connection,
> > but as a further step in the sequence diagram, that is what that
> > CONTROL message triggers in the MS application logic. The same applies
> > to all the examples where this happens. If you think the arrowless
> > diagram is clearer to the reader we might remove them: the problem with
> > this is that, without arrows, some diagrams might be harder to read,
> > i.e., in terms of who does what in diagrams with several components
> > interacting with each other. As an alternative, we might clarify what
> > those arrows are and what they are not. What do you think about this?
> > 
> > 
> > 
> >> item 3) section 1
> >> 
> >> "self-sustained" should be "self-contained".
> >> 
> > 
> > 
> > [LM] Ok.
> > 
> > 
> >> item 4) section 2
> >> 
> >>   Note that due to RFC formatting conventions, this document often
> >>   splits SIP/SDP and CFW across lines whose content would exceed 72
> >>   characters.
> >> 
> >> "whose content ..." is applied to the wrong referent, a "lines", but
> >> those lines are the post-split lines, not the pre-split lines.
> >> Perhaps:
> >> 
> >>   Note that due to RFC formatting conventions, SIP/SDP and CFW lines
> >>   whose content exceeds 72 characters are split across lines.  This
> >>   line folding is marked by a backslash at the end of the first line.
> >>   This backslash, the preceding whitespace, the following CRLF, and
> >>   the whitespace beginning the next line would not appear in the
> >>   actual protocol contents.
> >> 
> > 
> > 
> > [LM] Thanks, we'll change the sentence.
> > 
> > 
> >> item 5) section 2
> >> 
> >>   Due to the same 72 characters limitation, this document also
> >>   sometimes splits the content of XML elements across lines: please
> >>   beware that, when this happens, no whitespace is actually meant to
> >>   be neither at the beginning nor at the end of the element content.
> >> 
> >> This seems to be incorrect, as in many places, an XML *element*, that
> >> is, everything from the start tag to the end tag (see XML spec, rule
> >> "element"), is quite long and is necessarily split across lines, but
> >> is also valid.  (However, that interpretation depends on entities
> >> respecting the common convention that whitespace character content is
> >> to be ignored if it appears immediately within an element that does
> >> not admit immediate character content.)
> >> 
> >> I believe you meant "start tag" instead of "element".  But in that
> >> case, line breaks between the attributes of a start tag are valid in
> >> XML (see XML spec, rule "STag").  If this is correct, the above
> >> sentence can be omitted.
> >> 
> >> However, the message B1 in section 7.1 may be an exception.  See the
> >> appropriate item.
> >> 
> > 
> > 
> > [LM] We actually added this line after a comment of yours on the MRB
> > document examples, which exhibited a similar behaviour. Since we wanted
> > to clarify that the examples didn't include pre and post whitespaces,
> > we added the text to make this clearer. If that's unneeded we can
> > remove the sentence again.
> > 
> > 
> >> item 6) section 3
> >> 
> >>   This document makes use of the same terminology as the one that can
> >>   be found in the referenced documents.
> >> 
> >> This is awkward.  Perhaps:
> >> 
> >>   This document makes use of the same terminology as the referenced
> >>   documents [RFC6230] [RFC6231] [RFC6505] [I-D.ietf-mediactrl-mrb].
> >> 
> > 
> > 
> > [LM] Ok.
> > 
> > 
> >> item 7) section 4
> >> 
> >> This section starts with a paragraph over one page long.  Could it be
> >> broken into multiple paragraphs?
> >> 
> > 
> > 
> > [LM] Did you mean section 4.1? Section 4 starts with just a few lines.
> > 
> > 
> >> item 8) section 4
> >> 
> >> It seems overly complicated to explicitly describe "categories" to
> >> contain only four things.  Also, the text needs to mention that Figure
> >> 3 contains *two* diagrams, otherwise the accounting seems to be
> >> incorrect.  Perhaps:
> >> 
> >>   Four diagrams are provided.  Two of them (Figure 1 and Figure 2)
> >>   describe normal operation of the framework.  Figure 3 contains two
> >>   diagrams describing asynchronous event notifications.  Figure 1
> >>   embraces the MS perspective, whereas Figure 2 is on on the AS side.
> >>   The upper part of Figure 3 shows how events are generated, on the
> >>   MS side, by issuing a CONTROL message addressed to the AS; events
> >>   are acknowledged by the AS through standard 200 responses.  Hence,
> >>   the behavior of the AS, which mirrors that of the MS, is depicted
> >>   in the lower part of the figure.
> >> 
> > 
> > 
> > [LM] Good point, we'll fix this.
> > 
> > 
> >> item 9) section 4 figure 1
> >> 
> >> I think the state machine could be clarified:
> >> 
> >> - Replace the event "API 200" in "API 200/200" with "API terminate",
> >>  which is how the API termination is described on other arcs.
> >> 
> >> - Replace the event "API 202" in "API 202/202" with "API update",
> >>  which is how the API non-termination is described on other arcs.
> >> 
> >> - Further, change "API update" to "timer" or something like that, to
> >>  indicate that the MS CFW state machine must generate a 202 *based on
> >>  the passage of time*, not based on the API providing some sort of
> >>  "update".  If these time intervals are globally fixed for the CFW
> >>  protocol, their fixed values could be written in.
> >> 
> > 
> > 
> > [LM] Ok, we'll make this clearer.
> > 
> > 
> >> - The states "'202' sent" and "'update' sent" have the same outgoing
> >>  transitions, so they should probably be merged.
> >> 
> > 
> > 
> > [LM] I'm not sure about this: 202 is only sent after the first CONTROL
> > message to tell the AS it may take a while to process the request, after
> > which you can either have further 202 messages should the processing
> > take even more time, or one or more UPDATE messages related to that
> > CONTROL request after that. They're two different messages in the
> > protocol semantics. Nevertheless, it's also true that, according to
> > RFC6230, a 202 is basically a pre-REPORT message... any feedback on
> > this?
> > 
> > 
> >> - Is there truly an "Error" message that is comparable to the "200"
> >>  and "202" messages?  Or is sending "Error" a shorthand for a cluster
> >>  of numeric response codes?  If the latter, it would help to make
> >>  that clearer here in the introductory material.
> >> 
> > 
> > 
> > [LM] Yes, errors are numeric codes (Section 7. in RFC6230). We'll fix
> > the text.
> > 
> > 
> >> - What happens if the API detects an error after 202 has been sent?
> >>  There is no "API Error" arc from "'202' sent"/"'update' confirmed".
> >> 
> > 
> > 
> > [LM] Good point. The idea is that, once the MS sends a 202, the request
> > has been correctly processed, and so is supposed to be fine as far as
> > the protocol is concerned. I guess there could be circumstances when an
> > errors occurs after that, e.g., in retrieving an audio file to be played
> > to a UAC: in that case, the AS would be informed of the termination of
> > the dialog/request in a REPORT terminate, including details on the issue
> > which are Control Package specific. Do you think explaining this in the
> > text may help readers?
> > 
> > 
> >> item 10) section 4 figure 2
> >> 
> >> Clarifications of the state machine:
> >> 
> >> - There is no "Error" arc from the "202 received" and "'update'"
> >>  states.  Are errors impossible here?
> >> 
> >> - The states "202 received" and "'update'" have the same outward arcs
> >>  and so could be merged.
> >> 
> >> - The two figures are inconsistent regarding whether response numbers
> >>  (200, 202) are within quotes '...'.
> >> 
> >> - The two figures are inconsistent regarding whether report categories
> >>  (update, terminate) are within quotes '...'.
> >> 
> >> - The two figures are inconsistent regarding whether the sending of a
> >>  request or response in an arc's label is indicated using "send" or
> >>  not.
> >> 
> >> item 11) section 4 figure 3
> >> 
> >> There are similar inconsistencies between figure 3 and figures 1 and 2.
> >> 
> >> item 12) section 5
> >> 
> >> The term "COMEDIA" is used, and a reference is given to RFC 4145.  But
> >> that RFC does not use the term "COMEDIA" at all.  The framework I-D
> >> also uses "COMEDIA" without explicitly defining it.  It would be
> >> helpful to insert here a definition of "COMEDIA", which seems to be
> >> synonymous with "media of type application/cfw".
> >> 
> > 
> > 
> > [LM] I thought COMEDIA actually came from RFC4145, standing for
> > "connection-oriented media". Even the MSRP RFC refers to it that way. If
> > that's incorrect or incomplete we'll fix this in the next version.
> > 
> > 
> >> item 13) section 5.1
> >> 
> >>   If the request is fine, the MS answers with its own offer,
> >> 
> >> shouldn't this be:
> >> 
> >>   If the request is fine, the MS answers with its answer,
> >> 
> > 
> > 
> > [LM] Ok.
> > 
> > 
> >> item 14) section 5.1
> >> 
> >>   The MS replies with the list of packages it supports, by
> >>   adding a dummy example package to the list provided by the AS.
> >> 
> >> The "by" should be removed, as the replying is not done "by adding";
> >> instead, the MS replies and also adds.
> >> 
> > 
> > 
> > [LM] OK.
> > 
> > 
> >> item 15) section 5.1
> >> 
> >>   It is worth noting that this exchange of information is not meant
> >>   as a strict or formal negotiation of packages: in case the AS
> >>   realizes that one or more packages it needs are not supported
> >>   according to the indications sent by the MS, it may, or may not,
> >>   choose not to open a control channel with the MS at all, if its
> >>   application logic leads to such a decision.  The actual negotiation
> >>   of control packages is done subsequently through the use of the
> >>   framework SYNC transaction.
> >> 
> >> This confuses me:  Either the list of packages in the SDP offer/answer
> >> is significant or it is not.  If it is not, why is it provided?
> >> 
> >> In particular, if the MS may support packages that it does not admit
> >> to in the answer, then when the AS sees an answer that does not
> >> contain the needed packages, it will have to continue with the control
> >> channel connection in order to determine if the MS *actually* supports
> >> the needed packages or not.  Thus, the MS could omit all ctrl-package
> >> attributes in its answers all the time.
> >> 
> >> Also, it's not clear whether the AS is required to provide the list of
> >> packages it will need.  If it is required, then the SDP can be used to
> >> choose the correct MS based on MS capabilities.  If it is not
> >> required, a different architectural mechanism is needed.
> >> 
> > 
> > 
> > [LM] That section refers to a draft Chris submitted to the MMUSIC WG
> > some time ago:
> > 
> > http://tools.ietf.org/html/draft-boulton-mmusic-sdp-control-package-attribute-07
> > 
> > so any clarification about the purpose and constraints of such a
> > mechanism should be addressed in the specification. Chris, do you think
> > this behaviour could be clarified in the draft, in order to have it
> > reflected in the Call Flows as a consequence?
> > 
> > 
> >> item 16) section 5.3
> >> 
> >> Whether "keep alive" is hyphenated is not consistent.
> >> 
> > 
> > 
> > [LM] The right word is "keep-alive", we'll make this consistent.
> > 
> > 
> >> item 17) section 5.3
> >> 
> >>   In the previous section it has been described how a timeout value for
> >>   the keep alive mechanism is negotiated.  Specifically, in the example
> >>   the AS and the MS agreed on a value of 100 seconds.  
> >> 
> >> In fact, that section does not describe how the value is negotiated
> >> (since it is not clear what happens if the MS dislikes the value
> >> proposed by the AS).  However, this is correct:
> >> 
> >>   In example in the previous section, the AS and the MS agreed on a
> >>   value of 100 seconds.
> >> 
> > 
> > 
> > [LM] According to RFC6230, the 200 to the SYNC MUST have the same
> > keep-alive value proposed in the original SYNC. Who sends the SYNC can
> > change according to the COMEDIA negotiation. Specifically, "The previous
> > steps ensure that the entity initiating the Control Channel connection
> > is always the one specifying the keep-alive timeout period.". So, to
> > answer your question, I guess that if a MS dislikes the value, it can
> > just pick the active role and send a new SYNC with a new keep-alive
> > value.
> > 
> > 
> >> 
> >> item 18) section 6
> >> 
> >>   Besides, unless stated otherwise, the same UAC session is referenced
> >>   in all the above mentioned examples.
> >> 
> >> Is "above mentioned" the correct modifier?  The previous paragraph
> >> refers to "the following scenarios".
> >> 
> > 
> > 
> > [LM] You're right, it's a bit unclear, we'll fix this.
> > 
> > 
> >> item 19) section 6 figure 10
> >> 
> >> It would be useful at this point to make it clear that the two INVITEs
> >> are different SIP dialogs (as these scenarios are constructed).  (Or,
> >> if the AS may be inline and acting as a proxy, describe that there may
> >> be two dialogs or only one.)  Including, replace the second "INVITE
> >> (X)" with "INVITE (Y)" to show that the URIs need not be the same.
> >> 
> > 
> > 
> > [LM] OK.
> > 
> > 
> >> Also, why not include the establishment of the Control Channel in the
> >> figure, as that will not need to be duplicated in any further figure.
> >> 
> > 
> > 
> > [LM] It's not there as the Control Channel may already have been
> > negotiated and synced in advance. That is, the AS may be redirecting
> > calls to a MS it has already been already "talking with" for a while.
> > We explained this at the beginning of the section, "All the examples
> > assume that a Control Channel has already been correctly established
> > and SYNCed between the reference AS and MS", as that was already
> > addressed in the previous section.
> > 
> > 
> >> item 20) section 6 figure 11
> >> 
> >> Figure 11 appears to be only a caption.  Or is it the SIP signaling?
> >> Expositions of protocol messages are rarely considered to be figures.
> >> 
> > 
> > 
> > [LM] You're right, we made use of figures to simplify the formatting
> > of the messages, we'll remove te caption.
> > 
> > 
> >> item 21) section 6
> >> 
> >> The phrase "These three identifiers" is confusing because the text has
> >> just introduced four identifiers.
> >> 
> > 
> > 
> > [LM] Oops, right.
> > 
> > 
> >> I assume that if the SDP from AS to MS also contains label attributes,
> >> the Mediactrl framework specifies how they will be used (or ignored),
> >> so that the "addressing" of media streams is not made ambiguous.
> >> 
> >> item 22) section 6.1.2
> >> 
> >>   The 202+REPORT(s) mechanism is used whenever the MS wants to tell
> >>   the AS that the requested operation might take some more time than
> >>   expected.
> >> 
> >> This is probably incorrect.  What you mean is, "the requested
> >> operation might take more than *** seconds".  The fixed or variable
> >> time limit should be specified here.
> >> 
> > 
> > 
> > [LM] Actually, the time is Control Package dependent. Different packages
> > may have different timeouts. Quoting the framework, "A Control Package
> > MUST explicitly define the circumstances under which the server sends
> > 200 and 202 messages."
> > 
> > 
> >>   In this example, the preparation ends before the
> >>   timeout, and so the transaction is concluded with a 'REPORT
> >>   terminate', which acts as the 200 message in the previous example.
> >> 
> >> The last clause is rather confusing, as 'REPORT terminate' is a
> >> request, not a response, and thus doesn't "act like" a 200 message.
> >> Perhaps: "which reports the end of the transaction (as did the 200
> >> message in the previous example)".
> >> 
> > 
> > 
> > [LM] OK.
> > 
> > 
> >> item 23) section 6.2 figure 18
> >> 
> >> It might be useful to distinguish the four(?) SIP dialogs involved.
> >> 
> > 
> > 
> > [LM] Do you mean as in different figures? or clearer text?
> > 
> > 
> >> item 24) section 6.2.2
> >> 
> >> Three hours is 10,800 seconds, not 1,800 seconds.  I think the easiest
> >> fix is to replace "3 hours" with "30 minutes".
> >> 
> > 
> > 
> > [LM] Oops, ugly typo, will fix this (and good thing my math teacher is
> > not reading this :-) )
> > 
> > 
> >> RFC 6230 section 6.2
> >> 
> >>   An entity acting as a Control Server, on receiving a request, MUST
> >>   generate a response [...].  The response MUST conform to the ABNF
> >>   Responses MUST NOT include the 'Status' or 'Timeout' message
> >>   headers, [...]
> >> 
> >> RFC 6230 section 6.3.2.1
> >> 
> >>   A Control Server issuing a 202 response MUST ensure the message
> >>   contains a 'Timeout' message header.
> >> 
> >> item 25) section 6.2.3
> >> 
> >> This section is rather difficult to follow.  I'm not sure why, but
> >> partly it's because the text doesn't rigorously make clear what events
> >> are "before", that is, when the two audio channels of the original
> >> conference are being recorded, and "after", when the two recordings
> >> are being played back.  For instance, in the second paragraph, the last
> >> sentence is "after", but the first two sentences are "before".
> >> Instead, there should be a paragraph break there, and starting "Later,
> >> when we desire to play the whole conversation to UAC, the AS may
> >> take...".
> >> 
> > 
> > 
> > [LM] You're right, we'll try to make this clearer.
> > 
> > 
> >> It would help if the UAC which is listening to the playback was called
> >> "UAC3" or something like that, as "UAC" is also a generic term, and
> >> it's not immediately clear that it is unrelated to UAC1 and UAC2.
> >> 
> >> It would also help if the two *recordings* had names different from
> >> the UACs during the recording.  In particular "play UAC1 on confY" is
> >> hard for the naive reader to understand until he realizes that "UAC1"
> >> means the recording file of the audio generated by UAC1.
> >> 
> > 
> > 
> > [LM] Good points.
> > 
> > 
> >> item 26) section 6.3
> >> 
> >>   o  The AS invokes the creation of a new conference instance by means
> >>      of a CONTROL request (1); this request is addressed to the
> >>      conferencing package (msc-mixer/1.0) and contains in the body the
> >>      directive (createconference) with all the desired settings for it;
> >> 
> >> The antecedent of "it" is not particularly clear.  The antecedent is
> >> "a new conference", which is the 6th preceding noun phrase, which is
> >> only determined because it is the first preceding noun phrase which
> >> has settings.  Better to say "... the desired settings for the new
> >> conference instance".
> >> 
> > 
> > 
> > [LM] Ok.
> > 
> > 
> >> item 27) section 6.3.1 figure 30
> >> 
> >> This figure uses "UAC1" and "UAC2", but the other figures in 6.3 use
> >> "UAC A", "UAC B", and "UAC C".  Ditto for figure 31 and some of the
> >> text.
> >> 
> > 
> > 
> > [LM] Nice catch, we'll fix this.
> > 
> > 
> >> item 28) section 6.3.4 figure 38
> >> 
> >> The notation "D+[a+c]" is clever, but "D+(A+C)/2" would be more
> >> accurate.  (And see the following item regarding the volume level.)
> >> 
> > 
> > 
> > [LM] Ok.
> > 
> > 
> >> item 29) section 6.3.4
> >> 
> >> The volume level at which the main conference is heard in the sidebar
> >> is not stated consistently:
> >> 
> >>   the main conference.  The mix of the conference, instead, must be
> >>   attached to the sidebar, but with a lower volume (50%), being just a
> >>   background to the actual conversation.  This would allow both B and D
> >> 
> >>   2.  then, the main conference mix is attached to it as 'sendonly' and
> >>       with a -5dB gain to limit the volume of its own contribution to
> >>       30% (so that B and D can hear each other louder, while still
> >>       listening to what's happening in the main conference in
> >>       background);
> >> 
> >>  |         |         | B1. CONTROL (join confX-->confY) |
> >>  |         |         |++++++++++++++++++++++++++++++++>>|
> >>  |         |         |                                  |--+ join confX
> >>  |         |         |                                  |  | & confY
> >>  |         |         |                       B2. 200 OK |<-+ sendonly
> >>  |         |         |<<++++++++++++++++++++++++++++++++|    (50% vol)
> >> 
> >>      <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
> >>         <join id1="2f5ad43" id2="519c1b9">
> >>            <stream media="audio" direction="sendonly">
> >>               <volume controltype="setgain" value="-5"/>
> >>            </stream>
> >>         </join>
> >>      </mscmixer>
> >> 
> >> Of these, two references say 50% (-3dB) and two references say 30% or
> >> -5dB.
> >> 
> > 
> > 
> > [LM] You're right, we'll make this consistent.
> > 
> > 
> >> item 30) section 6.3.5 figure 43
> >> 
> >> Is it intended that UAC (FCC) does not have any RTP going to the MS?
> >> (Indeed, is it necessarily a UAC?  But perhaps SIP is needed to set up
> >> BFCP.)
> >> 
> > 
> > 
> > [LM] Yes, to clarify the distinction between a simple participant and a
> > chair we chose to only display RTP for the participant, with the chair
> > moderating what happens on it. Whether or not the FCC has any RTP
> > flowing is not relevant to the example and that's why we omitted it.
> > That said, the chair does not need to be a UAC, you're right, and SIP is
> > not mandated to set up BFCP (RFC4583 is only a way to do so, BFCP just
> > talks of out of band mechanisms generally). We will remove the UAC for
> > the FCC in the figure to make this clearer.
> > 
> > 
> >> item 31) section 6.3.5
> >> 
> >> The participant UAC is labeled inconsistently as "UAC", "UAC (FCP)",
> >> and "UAC1".  ("UAC" may be correct, as the context for that term my be
> >> describing a generic or abstract UAC.)  Similarly, "UAC (FCC)" and
> >> "UAC2" are used for the chair UAC.
> >> 
> > 
> > 
> > [LM] We'll fix the diagrams accordingly.
> > 
> > 
> >> item 32) section 6.3.5
> >> 
> >> It might be desirable to mention that the previous speaker should be
> >> muted before UAC1 can be un-muted.  Usually, this muting will happen
> >> between the Accepted and Granted BFCP messages, so it probably should
> >> be illustrated in the sequence of events.
> >> 
> > 
> > 
> > [LM] That's actually not needed, as BFCP does not force an exclusive
> > access to the resources it moderates. According to the policy in use,
> > several participants may be granted the same resource (e.g., ability to
> > talk) at the same time (e.g., in a conference bridge).
> > 
> > 
> >> item 33) section 6.4
> >> 
> >> It might be helpful to expand "VCR" the first time it is used.
> >> (Apparently it does not mean "video cassette recorder", and I see no
> >> suitable meaning on the Wikipedia "disambiguation" page for "VCR".)
> >> 
> > 
> > 
> > [LM] We borrowed this terminology from RFC6231, the IVR Control Package.
> > The idea is to have "video cassette recorder"-lie controls, right, like
> > the ability to play, pause, stop, rewind, etc. We'll expand this.
> > 
> > 
> >> item 34) section 6.4.2
> >> 
> >>   In fact,
> >>   rather than having the AS build different framework messages
> >>   according to the current time to build an announcement, 
> >> 
> >> This is difficult to read.  Perhaps
> >> 
> >>   In fact, rather than having the AS build an announcement according
> >>   to the current time using different framework messages,
> >> 
> > 
> > 
> > [LM] Ok.
> > 
> > 
> >> item 35) section 6.4
> >> 
> >> The discussion of mixing in the background music should be contrasted
> >> with the mixing of the two recordings during playback in section
> >> 6.2.3.  Naively, it would seem that the same mixing techniques could
> >> be used in both cases, but the two sections implement mixing in
> >> entirely different ways.
> >> 
> > 
> > 
> > [LM] Are you talking of 6.4.2 (current time example)? If so, this was
> > done on purpose, to exploit two different scenarios to showcase the use
> > of two different techniques. You're right in saying that the same could
> > be applied to both cases, nothing naive in this :-)
> > 
> > 
> >> item 36) section 6.4.3
> >> 
> >> An example contains XML elements that seem to be unnecessarily
> >> complex:
> >> 
> >>       <rule id="action" scope="public">
> >>         <item>
> >>           *
> >>           <item><ruleref uri="#digit"/></item>
> >>         </item>
> >>       </rule>
> >> 
> >> As far as I can tell from the SRGS specification, <item> functions
> >> more-or-less as a type of parenthesis, and is needed only when (1) a
> >> "weight" or "repeat" attribute needs to be applied to the group, (2)
> >> delimiting one alternative of a <one-of> element, or (3) constructing
> >> the "null" regular expression (that consumes no input and always
> >> matches).  Thus, these examples can be simplified to:
> >> 
> >>       <rule id="action" scope="public">
> >>         *
> >>         <ruleref uri="#digit"/>
> >>       </rule>
> >> 
> >> Then again, if the example is taken from a real interaction, perhaps
> >> it is best to leave it as it really happened.
> >> 
> > 
> > 
> > [LM] I'm not an expert of SRGS, so I'm not sure about this. This is how
> > we implemented it in our Media Server, and it works this way, but it
> > would be nice to hear from other implementers to see if they usually
> > realize similar scenarios in a different way!
> > 
> > 
> >> item 37) section 6.4.3
> >> 
> >>      to implement is a <collect>, and we are only interested in two-
> >>      digits DTMF strings (maxdigits); the AS is not interested in a
> >> 
> >> "two-digits" should be "two-digit".  (Because this phrase is used as a
> >> modifier of "DTMF strings", the "digit" is not plural.)
> >> 
> > 
> > 
> > [LM] Ok.
> > 
> > 
> >>      instructs the MS into modifying the volume of the UAC-->conference
> >> 
> >> "into modifying" would better be "to modify".
> >> 
> > 
> > 
> > [LM] Ok.
> > 
> > 
> >>      audio flow (setgain=-5dB sendonly); notice how the request also
> >> 
> >> This is probably intended to be "-3dB", as all other uses of setgain
> >> in this section (including the displayed messages) use a 3 dB
> >> increment.
> >> 
> > 
> > 
> > [LM] Right, we0ll make this consistent.
> > 
> > 
> >> item 38) section 6.4.3
> >> 
> >> This section leads to a question about the semantics of the <volume
> >> controltype="setgain" ...> operation:  Clearly, initially the stream
> >> is output at the same volume as the input media.  But when "<volume
> >> controltype='setgain' value='+1'>" is applied, does that cause the
> >> stream's output volume to be set to +1 dB *relative to the input
> >> media* or to +1 dB *relative to the previous volume setting*?
> >> 
> >> E.g., if I apply that operation twice, does the second application
> >> leave the amplification at +1 dB or raise it to +2 dB?
> >> 
> >> The examples in section 6.4.3 suggest the second interpretation.
> >> 
> >> The text in draft-ietf-mediactrl-mixer-control-package-14 is not clear
> >> on this point: "setgain" is only discussed in section 4.2.2.5.1, and
> >> it says "use the value of the "value" attribute as a specific gain
> >> measured in dB to apply".  That would be most likely to mean "as a
> >> specific gain measured in dB to apply to the input", which suggests
> >> the first interpretation.
> >> 
> >> In any case, the semantics of this need to be clarified and the
> >> example adjusted accordingly.
> >> 
> > 
> > 
> > [LM] If I recall correctly, when we first implemented this we discussed
> > it with the IVR authors during a meeting. If I'm not wrong the
> > conclusion was that setgain *sets* the gain, and does not modify the
> > previous value. I don't have the MS code in front of me right now,
> > though, I'll have to double check how we implemented this and let you
> > know.
> > 
> > IVR authors, any insight on this from a specification point of view?
> > 
> > 
> >> item 39) section 7.1
> >> 
> >>   Each MS makes use of the publishing interface to provide an MRB with
> >>   relevant information.
> >> 
> >> In the relationship between the MRB and MS, the MRB initiates the
> >> relationship.  Thus, it would be clearer to express this:
> >> 
> >>   An MRB makes use of the MS's publishing interface to acquire
> >>   relevant information.
> >> 
> >>   It is
> >>   enough to point out that, in this case, the MRB adds a new voice to
> >>   the 'Packages' it needs support for (mrb-publish/1.0).
> >> 
> >> "voice" should be "item".
> >> 
> >>   All
> >>   this messages flow through the control channel as all the messages in
> >> ---^^^^
> >> should be "these"
> >> ----------------------------------------------------^
> >> insert "do"
> >>   this document.
> >> 
> > 
> > 
> > [LM] Ok.
> > 
> > 
> >> item 40) section 7.1 message B1
> >> 
> >> This seems to be the only place in the draft where whitespace has been
> >> introduced where character content is valid, and so there is a
> >> question whether the draft needs to indicate that the whitespace would
> >> not be present on the wire.  The relevant elements are:
> >> 
> >>        <mixing-modes>
> >>            <audio-mixing-modes>
> >>                <audio-mixing-mode package="msc-ivr/1.0">
> >>                     nbest
> >>                </audio-mixing-mode>
> >>            </audio-mixing-modes>
> >>            <video-mixing-modes activespeakermix="true" vas="true">
> >>                <video-mixing-mode package="msc-mixer/1.0">
> >>                     single-view
> >>                </video-mixing-mode>
> >>                <video-mixing-mode package="msc-mixer/1.0">
> >>                     dual-view
> >>                </video-mixing-mode>
> >>                <video-mixing-mode package="msc-mixer/1.0">
> >>                     dual-view-crop
> >>                </video-mixing-mode>
> >>                <video-mixing-mode package="msc-mixer/1.0">
> >>                     dual-view-2x1
> >>                </video-mixing-mode>
> >>                <video-mixing-mode package="msc-mixer/1.0">
> >>                     dual-view-2x1-crop
> >>                </video-mixing-mode>
> >>                <video-mixing-mode package="msc-mixer/1.0">
> >>                     quad-view
> >>                </video-mixing-mode>
> >>                <video-mixing-mode package="msc-mixer/1.0">
> >>                     multiple-5x1
> >>                </video-mixing-mode>
> >>                <video-mixing-mode package="msc-mixer/1.0">
> >>                     multiple-3x3
> >>                </video-mixing-mode>
> >>                <video-mixing-mode package="msc-mixer/1.0">
> >>                     multiple-4x4
> >>                </video-mixing-mode>
> >>            </video-mixing-modes>
> >>        </mixing-modes>
> >> 
> >> I'm not sure if the schema defining urn:ietf:params:xml:ns:mrb-publish
> >> indicates that the whitespace before and after the mixing mode names
> >> is to be ignored.  But this might be a place to use the
> >> backslash-line-folding convention specified in section 2:
> >> 
> >>        <mixing-modes>
> >>            <audio-mixing-modes>
> >>                <audio-mixing-mode package="msc-ivr/1.0"> \
> >>                     nbest \
> >>                </audio-mixing-mode>
> >>            </audio-mixing-modes>
> >>            <video-mixing-modes activespeakermix="true" vas="true">
> >>                <video-mixing-mode package="msc-mixer/1.0"> \
> >>                     single-view \
> >>                </video-mixing-mode>
> >>                <video-mixing-mode package="msc-mixer/1.0"> \
> >>                     dual-view \
> >>                </video-mixing-mode>
> >>                <video-mixing-mode package="msc-mixer/1.0"> \
> >>                     dual-view-crop \
> >>                </video-mixing-mode>
> >>                <video-mixing-mode package="msc-mixer/1.0"> \
> >>                     dual-view-2x1 \
> >>                </video-mixing-mode>
> >>                <video-mixing-mode package="msc-mixer/1.0"> \
> >>                     dual-view-2x1-crop \
> >>                </video-mixing-mode>
> >>                <video-mixing-mode package="msc-mixer/1.0"> \
> >>                     quad-view \
> >>                </video-mixing-mode>
> >>                <video-mixing-mode package="msc-mixer/1.0"> \
> >>                     multiple-5x1 \
> >>                </video-mixing-mode>
> >>                <video-mixing-mode package="msc-mixer/1.0"> \
> >>                     multiple-3x3 \
> >>                </video-mixing-mode>
> >>                <video-mixing-mode package="msc-mixer/1.0"> \
> >>                     multiple-4x4 \
> >>                </video-mixing-mode>
> >>            </video-mixing-modes>
> >>        </mixing-modes>
> >> 
> > 
> > 
> > [LM] Yes, as I anticipated, we added that text to reflect a similar
> > comment you made when reviewing the MRB draft. This fix you suggest
> > makes sense, so we'll add it to the draft.
> > 
> > 
> >> item 41) section 7.1, section 7.2, section 7.2.1
> >> 
> >>   In the Inline mode, instead, the MRB is in the
> >>   path between the AS and the pool of MSs it is handling.
> >> 
> >>   Anyway, the MRB is also
> >>   conceived to work with ASs that are unaware of its functionality,
> >> 
> >>   and the SIP addresses of the chosen MSs.
> >> 
> >> Generally, "AS" and "MS" are used as the plurals of "AS" and "MS", but
> >> in these instances, "ASs" and "MSs" are used.
> >> 
> > 
> > 
> > [LM] You're right, I fixed this in the MRB and not here, sorry. Besides,
> > ASs sounds really bad... :-)
> > 
> > 
> >> item 42) section 7.1
> >> 
> >>   request itself and an SDP related to related to either the creation
> >> -----------------------------^^^^^^^^^^^^^^^^^^^^^
> >> "related to" is duplicated.
> >> 
> >> item 43) section 7.2.1
> >> 
> >>   MS the MRB has deemed better capable to fulfill the AS requirements),
> >> -------------------------^^^^^^
> >> This should be "best".
> >> -------------------------------------------------------^^
> >> This should be "AS's" or "AS'" (depending on which spelling convention
> >> we are using).
> >> 
> >>      targeting the request, and as a consequence picks up two MS which
> >> --------------------------------------------------^^^^^^^^
> >> I think you want "picks" here.
> >> 
> >>   after the Query the AS<->interaction becomes 1:1, UAC media dialogs
> >> ----------------------------^
> >> Something appears to be missing here.
> >> 
> > 
> > 
> > [LM] We'll fix them all.
> > 
> > 
> >> item 44) section 7.2.2.1, section 7.2.2.2, section 7.2.3
> >> 
> >> I think it would make the diagrams a little easier for the naive
> >> reader to follow if the media types specified in the SDP of the
> >> message bodies were given.  E.g., if an INVITE or 200 carries an
> >> application/sdp body for audio media, that is shown on the diagram.
> >> This would be particularly helpful in 7.2.3, where it takes the reader
> >> more consideration to deduce what the media types must be.  Updated in
> >> this way, the diagrams are as follows.  (But this has removed the
> >> comments noting where the SDP has been copied from one message to
> >> another.  That may need to be improved.)
> > 
> > 
> > [LM] Ok, we'll try and improve this to make it clearer.
> > 
> > 
> >> 
> >> 7.2.2.1.  Inline-aware Mode: CFW-based approach
> >> 
> >>   AS                      MRB                          MS
> >>    |                       |                           |
> >>    | 1. INVITE             |                           |
> >>    | (multipart/mixed:     |                           |
> >>    |  audio,               |                           |
> >>    |  application/mrb-consumer+xml)                    |
> >>    |---------------------->|                           |
> >>    |       2. 100 (Trying) |                           |
> >>    |<----------------------|                           |
> >>    |                       |--+ Extract SDP and        |
> >>    |                       |  | MRB payloads; handle   |
> >>    |                       |<-+ Consumer request to    |
> >>    |                       |    pick MS                |
> >>    |                       |                           |
> >>    |                       | 3. INVITE                 |
> >>    |                       | (audio)                   |
> >>    |                       |-------------------------->|
> >>    |                       |           4. 100 (Trying) |
> >>    |                       |<--------------------------|
> >>    |                       |                           |--+ Negotiate
> >>    |                       |                           |  | CFW Control
> >>    |                       |                           |<-+ Channel
> >>    |                       |                 5. 200 OK |
> >>    |                       |                   (audio) |
> >>    |                       |<--------------------------|
> >>    |                       | 6. ACK                    |
> >>    |                       |-------------------------->|
> >>    |        Prepare new +--|                           |
> >>    |       payload with |  |                           |
> >>    |    SDP from MS and +->|                           |
> >>    |     Consumer reply    |                           |
> >>    |                       |                           |
> >>    |             7. 200 OK |                           |
> >>    |     (multipart/mixed: |                           |
> >>    |      audio,           |                           |
> >>    |      application/mrb-consumer+xml)                |
> >>    |<----------------------|                           |
> >>    | 8. ACK                |                           |
> >>    |---------------------->|                           |
> >>    |                       |                           |
> >>    |--+ Read Cons. reply   |                           |
> >>    |  | and use SDP to     |                           |
> >>    |<-+ create CFW Chn.    |                           |
> >>    |                       |                           |
> >>    |                                                   |
> >>    |<<############## TCP CONNECTION #################>>|
> >>    |                                                   |
> >>    | CFW SYNC                                          |
> >>    |++++++++++++++++++++++++++++++++++++++++++++++++++>|
> >>    |                                                   |
> >> 
> >> 7.2.2.2.  Inline-aware Mode: Media dialog-based approach
> >> 
> >>   UAC              AS                     MRB                        MS
> >>    |               |                       |                          |
> >>    | 1. INVITE     |                       |                          |
> >>    | (audio)       |                       |                          |
> >>    |-------------->|                       |                          |
> >>    | 2. 100 Trying |                       |                          |
> >>    |<--------------|                       |                          |
> >>    |               | 3. INVITE             |                          |
> >>    |               | (multipart/mixed:     |                          |
> >>    |               |  audio,               |                          |
> >>    |               |  application/mrb-consumer_xml)                   |
> >>    |               |---------------------->|                          |
> >>    |               |       4. 100 (Trying) |                          |
> >>    |               |<----------------------|                          |
> >>    |               |                       |--+ Extract SDP and       |
> >>    |               |                       |  | MRB payloads; handle  |
> >>    |               |                       |<-+ Consumer request to   |
> >>    |               |                       |    pick Media Servers    |
> >>    |               |                       |                          |
> >>    |               |                       | 5. INVITE                |
> >>    |               |                       | (audio)                  |
> >>    |               |                       |------------------------->|
> >>    |               |                       |          6. 100 (Trying) |
> >>    |               |                       |<-------------------------|
> >>    |               |                       |                       +--|
> >>    |               |                       |   Handle media dialog |  |
> >>    |               |                       |       (connection-id) +->|
> >>    |               |                       |                          |
> >>    |               |                       |                7. 200 OK |       
> >>    |               |                       |                  (audio) |
> >>    |               |                       |<-------------------------|
> >>    |               |                       | 8. ACK                   |
> >>    |               |                       |------------------------->|
> >>    |               |        Prepare new +--|                          |
> >>    |               |       payload with |  |                          |
> >>    |               |    SDP from MS and +->|                          |
> >>    |               |     Consumer reply    |                          |
> >>    |               |                       |                          |
> >>    |               |             9. 200 OK |                          |
> >>    |               |     (multipart/mixed: |                          |
> >>    |               |      audio,           |                          |
> >>    |               |      application/mrb-consumer+xml)               |
> >>    |               |<----------------------|                          |
> >>    |               | 10. ACK               |                          |
> >>    |               |---------------------->|                          |
> >>    |               |                       |                          |
> >>    |               |--+ Read Cons. reply   |                          |
> >>    |               |  | and send SDP       |                          |
> >>    |               |<-+ back to UAC        |                          |
> >>    |    11. 200 OK |                       |                          |
> >>    |       (audio) |                       |                          |
> >>    |<--------------|                       |                          |
> >>    | 12. ACK       |                       |                          |
> >>    |-------------->|                       |                          |
> >>    |               |                       |                          |
> >>    |<<*************************** RTP ******************************>>|
> >>    |               |                       |                          |
> >>    |               |--+ Negotiate          |                          |
> >>    |               |  | CFW channel        |                          |
> >>    |               |<-+ towards MS         |                          |
> >>    |               |    (if needed)        |                          |
> >>    |               |                       |                          |
> >>    |               |<<############## TCP CONNECTION ################>>|
> >>    |               |                                                  |
> >>    |               | CFW SYNC                                         |
> >>    |               |+++++++++++++++++++++++++++++++++++++++++++++++++>|
> >>    |               |                                                  |
> >> 
> >> 7.2.3.  Inline-unaware Mode
> >> 
> >>   AS                      MRB                          MS
> >>    |                       |                           |
> >>    | 1. INVITE             |                           |
> >>    | (application/cfw)     |                           |
> >>    |---------------------->|                           |
> >>    |       2. 100 (Trying) |                           |
> >>    |<----------------------|                           |
> >>    |                       |--+ Pick a MS              |
> >>    |                       |  | and redirect           |
> >>    |                       |<-+ INVITE there           |
> >>    |                       |                           |
> >>    |                       | 3. INVITE                 |
> >>    |                       | (application/cfw)         |
> >>    |                       |-------------------------->|
> >>    |                       |           4. 100 (Trying) |
> >>    |                       |<--------------------------|
> >>    |                       |                           |--+ Negotiate
> >>    |                       |                           |  | CFW Control
> >>    |                       |                           |<-+ Channel
> >>    |                       |                 5. 200 OK |
> >>    |                       |         (application/cfw) |
> >>    |                       |<--------------------------|
> >>    |                       | 6. ACK                    |
> >>    |                       |-------------------------->|
> >>    |                       |                           |
> >>    |             7. 200 OK |                           |
> >>    |     (application/cfw) |                           |
> >>    |<----------------------|                           |
> >>    | 8. ACK                |                           |
> >>    |---------------------->|                           |
> >>    |                       |                           |
> >>    |                                                   |
> >>    |<<############## TCP CONNECTION #################>>|
> >>    |                                                   |
> >>    | CFW SYNC                                          |
> >>    |++++++++++++++++++++++++++++++++++++++++++++++++++>|
> >>    |                                                   |
> >> 
> >> item 45) section 7.2.2
> >> 
> >>   An AS willing to issue a Concumer request by means of SIP, has to do
> >> ----------------------------^
> >> This should be "Consumer".
> >> 
> >>   envisages two kind of SIP dialogs a Consumer request may be sent
> >> -----------------^
> >> This should be "kinds".
> >> 
> >>   setup a control channel) or a UAC media dialog (a SIP dialog the AS
> >> ---^
> >> This should be "set up".  ("set up" functions like a verb; "setup"
> >> functions like a noun.)
> >> 
> >>   The behaviour in the two cases, which are called respectively CFW-
> >> -------^
> >> Probably better to say "behaviours" here.
> >>   based and Media dialog-based approach, is only slightly different,
> >> ------------------------------------------^
> >> Use "are", to go with "behaviors".
> >> 
> > 
> > 
> > [LM] OK.
> > 
> > 
> >> item 46) section 7.2.2.1, section 7.2.2.2
> >> 
> >>   Please note that, to ease the reading of the protocol contents, a
> >>   simple '=_Part' is used whenever a boundary for a 'multipart/mixed'
> >>   payload is provided, instead of the actual boundary that would be
> >>   inserted in the SIP messages.
> >> 
> >> This seems like a poor strategy, as the resulting figures are not
> >> strictly correct.  Perhaps use "Part" as the boundary value, which
> >> would result in figures that look like the following, which strictly
> >> correct and are just as easy to read:
> >> 
> >>   [..]
> >>   Content-Type: multipart/mixed;boundary="Part"
> >> 
> >>   --Part
> >>   Content-Type: application/sdp
> >> 
> >>   v=0
> >>   o=- 2890844526 2890842807 IN IP4 as.example.com
> >>   [...]
> >> 
> >>   --Part
> >>   Content-Type: application/mrb-consumer+xml
> >> 
> >>   <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
> >>   <mrbconsumer version="1.0"
> >>                xmlns="urn:ietf:params:xml:ns:mrb-consumer">
> >>      [...]
> >>   </mrbconsumer>
> >> 
> >>   --Part--
> >> 
> > 
> > 
> > [LM] I think we did it this way after a comment received on the list:
> > Chris and I did the same for the examples in the MRB draft, for instance.
> > If you think it might improve the readibility of the document we'll
> > change this.
> > 
> > 
> >> In both of these sections, just before the message listings, there is
> >> a line containing only:
> >> 
> >>   o
> >> 
> > 
> > 
> > [LM] Probably a leftover, we'll remove it.
> > 
> > 
> >> In the following message titles, "SDP" appears in lower case:
> >> 
> >> section 7.2.2.1:
> >>    3. MRB -> MS (INVITE sdp only)
> >>    5. MRB <- MS (200 OK sdp)
> >> section 7.2.2.2:
> >>    5. MRB -> MS (INVITE sdp only)
> >>    7. MRB <- MS (200 OK sdp)
> >>    11. UAC <- AS (200 OK sdp)
> >> 
> >> item 47) section 7.2.3
> >> 
> >>   pick a MS rather than another.
> >> --------^
> >> Probably should be "one", to contrast with "another".
> >> 
> > 
> > 
> > [LM] OK.
> > 
> > 
> >> item 48) section 7.2.3
> >> 
> >> This example does not give the content of the messages, unlike the
> >> previous two examples.
> >> 
> > 
> > 
> > [LM] It's because in the IUMM mode no Consumer transaction is involved.
> > It's a normal RFC6230 Control Channel negotiation where the MRB acts
> > as an intermediary, that is, picking a MS for the AS according to some
> > logic. In this case, in fact, the AS does not support the MRB
> > specification, and so just tries to set up a control channel the way
> > it knows.
> > 
> > 
> >> item 49) section 7.3.1
> >> 
> >> This section is titled "Query/IAMM".  The call flow does mesh with the
> >> call flow in section 7.2.1, "Query Mode", but it does not mesh with
> >> the call flow in section 7.2.2.1, "Inline-aware Mode: CFW-based
> >> approach" nor with the call flow in section 7.2.2.2, "Inline-aware
> >> Mode: Media dialog-based approach".
> >> 
> >> It would probably be best to change the title of the section to
> >> "Query".  If necessary, an additional section should be added giving
> >> examples relevant to inline-aware mode.
> >> 
> >> item 50) section 7.3.1, section 7.3.2
> >> 
> >> The use of "IAMM" and "IUMM" is a bit opaque here, as those acronyms
> >> are not explicitly expanded anywhere in this document.  They seem to
> >> mean what is called "inline-aware mode" and "inline-unaware mode", but
> >> the acronyms of those phrases aren't the same as the acronyms used.
> >> 
> >> Perhaps these section titles could be changed to resemble those of
> >> 7.2.*, "7.3.1. Query and Inline-aware Mode" and "7.3.2. Inline-unaware
> >> Mode".  That doesn't fix the problem with the acronyms per se but does
> >> make the titles clearer.
> >> 
> > 
> > 
> > [LM] You're right about both comments, we'll try to make this clearer
> > and more consistent across the document.
> > 
> > 
> >> item 51) section 7.3.1
> >> 
> >> We might want to mention that in this scenario, the AS obtains
> >> assignment of an MS *before* any UAC makes a request, in order to have
> >> facilities to satisfy future SIP requests.  That is probably how AS's
> >> operate in practice, but a naive reader might expect that the AS will
> >> make the consumer request only after the AS receives a demand for its
> >> services.
> > 
> > 
> > [LM] Actually both Fig.53 and 54 show the AS creating a control channel
> > before receiving an INVITE from the UAC. Or was your point about a
> > different aspect?
> > 
> > 
> >> 
> >>   Nevertheless, there are cases when having an MRB in the signalling
> >>   path ...
> >> 
> >> You might want to say "the SIP signalling path" here.  By my count,
> >> there are *three* different signalling paths:  the COMEDIA negotiation
> >> (INVITE with application/cfw SDP), the CFW connection, and the SIP
> >> signalling (INVITE with audio/etc. SDP).
> >> 
> > 
> > 
> > [LM] OK.
> > 
> > 
> >> item 52) section 7.3.2
> >> 
> >>   As mentioned previously, in such a case the AS would interact with
> >> What case is "in such a case"?  (This is the first sentence of a
> >> section.)  It seems that this paragraph is trying to contrast "such a
> >> case" with "IUMM", but it's not clear what is going on.
> >> 
> > 
> > 
> > [LM] It's referring to the case described by the section title, which is
> > a poor editing choice. We'll make this more explicit.
> > 
> > 
> >>   That said, the IUMM case is also very interesting with respect to the
> >>   media dialogs management.  In fact, in the MRB-unaware mode there
> >> ---------^
> >> This should be "dialog".
> > 
> > 
> > [LM] OK.
> > 
> > 
> >>   would be no Consumer request and an AS would actually see the MRB as
> >>   an MS.  This means that, unlike the previous scenarios, there is
> >>   actually no choice, meaning the MRB would likely be in the signaling
> >> ------------^
> >> What is there "no choice" of?  The obvious choice is that of a MS, but
> >> the MRB clearly can choose which MS to sent the request to.
> > 
> > 
> > [LM] Probably a poorly translated sentence, as this makes more sense in
> > Italian. The sentence is trying to say that there is no active selection
> > process driven by an AS<->MRB interaction so yes, something eventually
> > leading to choosing a specific MS according to that. That's why the
> > document then explains a potential approach to take care of this.
> > 
> > 
> >>   path anyway.  The MRB could either redirect the AS to a MS directly
> >>   or transparently act a proxy/B2BUA and contact a MS (according to
> >>   implementation-specific policies) on behalf of the unaware AS.
> >> 
> >>   To overcome the scalability limitations of such an approach, the MR
> >> --------------------------------------------------------------^
> >> You should add here "at least in regard to the MRB being in the SIP
> >> signalling path for all calls" -- as far as I can tell, this is the
> >> only scaling problem this approach removes.  (The major one is that
> >> all calls handled by the AS have to be handled by only one MS.)
> >> 
> > 
> > 
> > [LM] OK.
> > 
> > 
> >>   Rather than recurring to explicit redirection, or always
> >> ---------------^
> >> This isn't the right word.  Perhaps "resorting" was intended?
> >> 
> > 
> > 
> > [LM] Yes, we'll fix this.
> > 
> > 
> >> item 53) section 7.3.2
> >> 
> >>   While apparently not a problem, this raises an issue when the same
> >>   unaware AS has several sessions with different MS: the AS would only
> >>   see one "virtual" MS (the MRB) and so it would relay all calls there,
> >>   making it hard for the MRB to understand where these media dialogs
> >>   should belong: specifically, whether the UAC calling belongs to the
> >>   AS application logic leading to MS1 or MS2, or wherever else.
> >> 
> >> This seems to be a deficiency in the CFW protocol:  If the AS
> >> establishes a CFW channel with the MS (via a SIP URI to an MRB), and
> >> then later the AS wants to addresses a SIP INVITE to the MS, it has no
> >> choice but to use the same SIP URI (which routes to the MRB).  This
> >> makes it impossible for the MRB to associate the SIP INVITE with the
> >> CFW connection, and thus it is difficult for the MRB to route the
> >> INVITE to the same MS.
> >> 
> >> What seems to be needed is for either the COMEDIA response
> >> (application/cfw) or CFW connection to provide a SIP URI that is the
> >> "real" SIP URI of the far-end of the CFW channel.
> >> 
> >> Actually, this seems to be a problem even if an AS is addressing an MS
> >> URI, but the URI resolves to a redundant set of MSs:  There seems to
> >> be no way to ensure that when a CFW channel is established that a
> >> subsequent SIP INVITE can be sent to the same MS.  This issue seems to
> >> be discussed in RFC 6230 section 3, but I can't find any solution
> >> there.
> >> 
> > 
> > 
> > [LM] The way it works now is that, for a specific MS, the same SIP URI
> > is used for both negotiating a control channel and attaching media
> > dialogs, yes. A way to overcome this may having the MS redirect media
> > dialogs to a different SIP URI when it receives them (that is, treat
> > control and media dialogs differently) but I realize how this sounds
> > like an implementation hack rather than a real solution.
> > 
> > 
> >> item 54) section 8
> >> 
> >>   receiving requests that may cross the bounds each AS is constrained
> >>   into.
> >> ---^
> >> Probably better as "within".
> >> 
> > 
> > 
> > [LM] OK.
> > 
> > 
> >> item 55) section 8
> >> 
> >> The detailed discussion of how the MS enforces security against the
> >> ASs is helpful, but it does not mention how the MS discerns which
> >> requests come from AS1 and which come from AS2.
> >> 
> >> Dale
> > 
> > 
> > [LM] Thanks again for your detailed review: this is exactly the kind of
> > thorough feedback we were looking for, as so far we had to rely on our
> > own, a bit biased and probably not very objective review process :-)
> > 
> > Lorenzo
> > 
> > 
> >> _______________________________________________
> >> MEDIACTRL mailing list
> >> MEDIACTRL@ietf.org
> >> https://www.ietf.org/mailman/listinfo/mediactrl
> >> Supplemental Web Site:
> >> http://www.standardstrack.com/ietf/mediactrl
> > 
> > 
> > -- 
> > Lorenzo Miniero, COB
> > 
> > Meetecho s.r.l.
> > Web Conferencing and Collaboration Tools
> > http://www.meetecho.com
> > _______________________________________________
> > MEDIACTRL mailing list
> > MEDIACTRL@ietf.org
> > https://www.ietf.org/mailman/listinfo/mediactrl
> > Supplemental Web Site:
> > http://www.standardstrack.com/ietf/mediactrl
> 


-- 
Lorenzo Miniero, COB

Meetecho s.r.l.
Web Conferencing and Collaboration Tools
http://www.meetecho.com