Re: [MEDIACTRL] Call Flows Document

["Even, Roni" <[e-mail]>]

Hi,

I did not volunteer to read the draft, but still think that before accepting a document as a WG item it must get some reviews that will be reflected on the list even if it just says "I read the draft and find it as a good start for call flows document"
 
Roni

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of [e-mail]
> Sent: Thursday, July 31, 2008 12:52 PM
> To: [e-mail]
> Subject: Re: [MEDIACTRL] Call Flows Document
> 
> That's great news! Someone finally read our draft! Thanks Roni for
> your comments. We'll discuss them and fix the potential nits you
> identified.
> 
> Cheers,
> 
> Simon
> 
> Quoting "Even, Roni" <[e-mail]>:
> 
> > Hi,
> >
> > I can accept Mary's comments.
> >
> >
> >
> > My humble input is that the current ecs document cannot serve as a
> > starting point, it is not just a media control example flows
> document.
> >
> > I assume we want to have basic call flows examples yet the document
> does
> > not supply simple examples but goes to a detailed analysis of the
> media
> > control architecture based on the authors interpretation.
> >
> >
> >
> > The comments are partial and do not even address the syntax of the
> > examples. I accept that other people will review the ecs draft before
> we
> > can decide if this is a good start for a WG document.
> >
> >
> >
> > The abstract of the document says that this is not just call flows.
> >
> > "It aims at being a simple guide throughout the use of   the
> interface
> > between Application Servers and MEDIACTRL-based Media  Servers, as
> well
> > as a hopefully helpful base reference documentation  for both
> > implementors and protocol researchers."
> >
> >
> >
> > Section 4 is not relevant to call flows since it describes an
> > implementation
> >
> >
> >
> > Even though the document claims to have simple call flows it goes to
> > high details based on a specific implementation, the text is not
> > describing the flow but gives interpretation of the normative text in
> > the framework document
> >
> >
> >
> > Figure 6 and the text describes one way to establish 3pcc and not the
> > media control flow. 3pcc is described in other RFCs and there is more
> > than one way to do it.
> >
> >
> >
> > Echo test is not related to the media control call flows.
> >
> >
> >
> > The phone call scenario starts with a SIP 3pcc  flow describing 3pcc
> and
> > the whole example is not a typical AS-MS call flow. In figure 20 it
> > shows the flow of the media control but missing the step where the UA
> > using SIP connects to the MS. This is important since we have
> assumption
> > that the Mediactrl JOIN arrives before the SIP invite
> >
> >
> >
> > Roni
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > From: [e-mail] [mailto:[e-mail]]
> On
> > Behalf Of Mary Barnes
> > Sent: Thursday, July 31, 2008 12:00 PM
> > To: Eric Burger; [e-mail]
> > Subject: Re: [MEDIACTRL] Call Flows Document
> >
> >
> >
> > Thanks for the detailed (and accurate) summary of this issue. My
> > responses are below [MB].
> >
> >
> >
> > Mary.
> >
> >
> >
> > ________________________________
> >
> > From: [e-mail] [mailto:[e-mail]]
> On
> > Behalf Of Eric Burger
> > Sent: Wednesday, July 30, 2008 12:48 PM
> > To: [e-mail]
> > Subject: [MEDIACTRL] Call Flows Document
> >
> > At the meeting today, we discussed at length the issues around adding
> > <http://www.ietf.org/internet-drafts/draft-miniero-mediactrl-escs-
> 02.txt
> >> , "Media Control Channel Framework (CFW) Call Flow Examples" as a
> work
> > group item.
> >
> >
> >
> > To recap:
> >
> > 1. Just about everyone stated it is extremely useful to have call
> flows.
> >
> >    a. Important for us as protocol developers to debug the
> > specification,
> >
> >       e.g., "Oops - we forgot that message"
> >
> >    b. Important for some developers with interpretation of the
> > specifications
> >
> >    c. Important for interoperability testing
> >
> >
> >
> > 2. Many people pointed out call flow documents have their drawbacks.
> >
> >    a. Some people will code to the call flows and not to the
> > specification.
> >
> >       i.  If the call flows are wrong, the developer will code the
> wrong
> > thing.
> >
> >       ii. Call flows cannot capture the nuances of the protocol, such
> as
> >
> >           non-deterministic message order or legal, but not shown in
> a
> >
> >           call flow, messages that pop up
> >
> >    b. When people see a call flow document, they may not read the
> >
> >       specification at all.
> >
> >    c. When people see a Work Group *draft*, they may consider it to
> be
> >
> >       a stable, authoritative reference.
> >
> > [MB] IMHO, there's not much we can do nor do we have much control
> over
> > any of the above - it is what it is.  I don't disagree at all that
> call
> > flows cannot at all capture all the normative details of the protocol
> > that must be implemented. However, for folks that are visual
> learners,
> > the flows are an invaluable guide to work one's way through the
> specs.
> > And, none of our specs are ever perfect and the flows can sometimes
> be a
> > source of identifying those bugs (even after publication).  [/MB]
> >
> >
> >
> > It would be safe to say that no matter what we decide here, there
> will
> > be a call flows document.  The questions to decide are:
> >
> >
> >
> > 1. What document(s) will we produce?  Will we produce:
> >
> >    a. A basic call flows document, illustrating some examples of
> >
> >       how the protocol works (see draft-ietf-sipping-service-
> examples-15
> >
> >       for an example)
> >
> > [MB] IMHO, this is most important for now in developing in parallel
> with
> > the protocol and is an invaluable reference for implementations.   I
> > also do not believe that even with the flows you will NOT get
> identical
> > broken implementations from the flows as there are always gaps that
> must
> > be filled in based on the normative details in the protocol spec.
> [/MB]
> >
> >    b. A torture test document, illustrating examples of malformed
> >
> >       messages or messages seriously out of order, that stacks
> >
> >       must not barf on (see RFC 4475 for an example)
> >
> > [MB] I think it would be very difficult to produce this (and not
> > necessarily useful) until after there's been some basic interop
> testing
> > and folks can see what are the most common errors and perhaps add
> > variations of such. [/MB]
> >
> >
> >
> >    c. A test suite document, describing how to achieve
> interoperability
> >
> >       (see
> > http://www.msforum.org/techinfo/approved/MSF-IA-SIP.015-FINAL.pdf)
> > <http://www.msforum.org/techinfo/approved/MSF-IA-SIP.015-FINAL.pdf>
> >
> >
> >
> > [MB] This seems to be something well beyond the completion of the
> > protocol and maturity of implementations.  And, maybe would be more
> of a
> > SIPForum activity.[/MB]
> >
> >    d. A plurality of a, b, or c
> >
> >    e. All of a, b, and c
> >
> >
> >
> > Note all call flow documents are Informational (not Normative) by
> > definition.
> >
> >
> >
> > 2. Will the work group produce these documents?  No matter what,
> > individuals
> >
> >    from the work group will write the document(s), and people in the
> > work
> >
> >    group (many have already volunteered) will review the document(s).
> >
> >    a. Do they need to be Work Group documents?
> >
> > [MB] I honestly can see no problems in making them WG documents and
> alot
> > of positive reasons: folks pay more attention, the review is more
> > rigorous (by all review teams AFAIK) and it acknowledges the work
> done
> > by authors/editors. [/MB]
> >
> >    b. Is it OK for them to be Individual documents, for now.
> >
> > [MB] In my view, as long as we get a milestone for 1a, then I'm not
> so
> > concerned. I did speak to Roni after the meeting and I believe his
> > concern over inconsistencies between the protocol and the current
> call
> > flow document are valid and should be addressed and if it makes the
> WG
> > more comfortable having this done prior to adopting as a WG document,
> > that's okay.  There is precedence in the past to adopt a document
> with
> > an agreement to update per WG input and concerns.  [/MB]
> >
> >
> >
> >
> >
> > Please RSVP with your views on the above questions.
> >
> >
> >
> > Thanks.
> >
> >
> 
> 
> 
> --
>                              _\\|//_
>                              ( O-O )
>     ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
>                      Simon Pietro Romano
>                Universita' di Napoli Federico II
>                   Computer Science Department
>          Phone: [phone] -- Fax: [phone]
>                  e-mail: [e-mail]
> 
>      <<Molti mi dicono che lo scoraggiamento è l'alibi degli
>     idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
>                           oooO
>     ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
>                            \ (    (   )
>                             \_)    ) /
>                                   (_/
> _______________________________________________
> MEDIACTRL mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/mediactrl
_______________________________________________
MEDIACTRL mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl