Re: [MEDIACTRL] Call Flows Document

["Mary Barnes" <[e-mail]>]

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.

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