FSM Minutes
IETF 68  Tuesday 1740-1840  Karlin I

Pete Resnick reviewed the agenda briefly


Motivation and Problem Statement -- Stephane Bortzmeyer
- presented draft-bortzmeyer-language-state-machines-01
- presented problem statement

Discussion of Motivation and Problem Statement
- Aaron Silverton: sees a gap between IETF specs and what it takes to implement them.  More formal specifications would be useful.
- Pete R: The word "forced"; what are we proposing.  A tool for spec writers, of something more?  
- Ted Hardie (sponsoring AD): not talking about a tool that will be enforced on spec writers.  BoF could come to a conclusion that it is developing a mandatory tool, but this is not going to happen.

- Stephane: specifying all specs, or every part of new specs, is a non-goal.
- Ron Jacob (sp?): opportunity for b2b commerce.  Having a state machine combined with SOA would help provisioning and protocol choice.
- Michael Richardson: NO
- Marcus Stenberg: Huge gap between a executable state diagram and something useful ("hello word" == 600 pages)
- Moshe Suberti: uses UML diagrams which support code generation
- Stephane: few RFCs use UML modeling of state machine; UML is a candidate. First discuss if we need a language, then which one.
- Eric Burger: clear it would be beneficial for professional protocol developers
- Pete: lot of comments that it would be good to have a language available for use in documentation.  Have heard frm other people that this is not a good idea.
- Ruediger Volk: adding multiple tools for the same task would not be a good service.
- Aaron S: heard the same thing before; we have to produce a formal state machine before we can start writing code.
- Ted H: criticism has been the bar to attend the IETF.  Hobbying/open source developer may be burdened if they have to learn a formal language.
- Dave Crocker: anyone read entire set of email specs recently?  Ted is right; it is not possible to have a small effort in the IETF; this won't change, don't want to make it worse.  People against the work need to explain why this would be damaging.
- Pete: does having a formal tool that can be used to generate code (unlike ABNF) encourage us to write specs that increase in complexity exponentially?
- Aaron: don't think so; formality of the process forces you to be concise. Precedent to do this in IEEE (SDL state charts).
- Pete: making IETF like other SDOs not a good way to encourage an outcome.
- Dave C: sometimes it is.
- Aaron: been done before, could be done here also
- Dave C: Pete raised perfect strawman; reasonable fear.  Don't know for certain what would happen as an outcome (good or bad effects).
- Eric B: hugest failing of ABNF is that you can't compile it.  Some of our protocols would have benefited from trying to model them.
- Pete: in summary, sense of the room that having such a tool would be useful, risks of bad side-effects on the IETF are low.
- Stephane: already use a dangerous tool to write specs: English.  If we fear that more powerful tool would be dangerous, then we shouldn't use English, but some tiny language.  Explanations are complicated, not necessarily protocols). IETF not using most advanced tools.
- Pete: objections to proceeding with Stephane's presentation (on draft)? Consensus is to proceed.

Stephane continues presentation
- invented Cosmogol
- gives example of Neighbor Discovery for IPv6 (RFC2461)
- must declare list of state, list of possible messages

- Aaron S: very supportive of the effort, execution is important, should adopt a standard solution (ITU-T SDL, UML; SDL is the executable portion of UML).  Can convert Cosmogol quickly into a subset of SDL.  Could use SDL, subset of SDL, or UML profile
- Dave C: subset of means it is simpler.  Anyone can use one of the existing tools can go ahead already.  Popularity will decide the issue.
- Aaron S: reason I haven't used them in my drafts is ... [scribe confused by speaker's point.]
- Pete: separate the desirability of Cosmogol from the issue of whether an existing standard language. 
- Michael Richardson: how sensitive to line wrapping?  If using this with xml2rfc, the syntax is a problem.
- Stephane: lawyer said not to discuss syntax at this time (laughter)
- Dave C: did you do the syntax?
- Eric B: can we see Cosmogol?

- Stephane: proposed roadmap of the discussion:
  - do we want a formal SM language?
  - If so, develop one?
    - Is Cosmogol a good candidate?
      - If yes, following issues for the wg to work on:
        - named sets of states/messages?
	- substates?
	- syntax details?
	- unicode identifiers?
  - If not, which one to use (State Chart XML, UML, Z.100/SDL)
  
- Aaron S: should adopt a standard language
- Tony Hansen: one of the IETF premises is working code.  Do you have a protocol that is a good candidate for using this in draft stage?  Anyone interested in trying this tool to see if it is a decent language?
- Pete: is anyone using it right now?
- Stephane: no
- Dave C: this is brand new; don't care that no-one is using it.  Chicken-n-egg problem.  Question as to whether anyone has expressed interest is valid. Certain amount of upfront work that needs to be done in advance before others will be interested.  Expect that those working on this will need to do marketing.  Have existing tools, now a new member of that list.  A piece of the process is an effort to persue the debate of whether a new tool is better than the existing alternatives.
- Chris Newman: new Apps AD, a state machine getting his attention is the IETF standards process.  Good test case. (laughter)
- Harald Alvestrand: this transition is always possible upon error (laughter).
- Elwyn Davies: previous experience that some of the alternative tools are expensive.
- Pete: part of the process is this discussion
- Aaron S: SDL is an ITU-T spec.  sdl-forum.org has freely available, unencumbered tools; UML tools.
- Mark Handley: author of RFC 4601 (PIM Sparse Mode); 25 state machines. work from the diagrams; implementors need the pdf version of the spec. Used tables for text representation of the RFC.  Cosmogol looks accessible. More formalism would not be a bad thing.  If there had been a prior IETF recommendation on conventions, they would have been used.  Tables required no learning curve; they are not create.  A community around a particular standard would be good, but multiple options will result in tables still being in RFCs.
- Chris N: speaking as AD, don't have a requirement to use ABNF.  People found ABNF useful and started using it and recommending it.  It's likely that any attempt to require a language will fail.
- Pete: we understand this
- Ted H: IPR - SC-XML developed under W3C patent policy.  IETF value is review community, cross-area review.  In favor of a community culture; no one will have to bring themselves up to speed.  The simpler the tool, the better it will be to develop a community culture; otherwise will miss out on review. If we do choose to pick one of the "more expressive" languages, then we will want to profile it for simplicity.  Starting fresh might be simpler.
- Hannes Tschofenig: state machine documents written in NSIS.  People only read the pdf version of the documents, not to interested in the automatic code generation.  Nightmare converting ascii version to pdf.  Used TeX tools. xml2rfc support for state machines would be very helpful.
- Eric B: ABNF not mandated; what is the chance of a protocol spec that doesn't use it.  How do you create a draft: use an existing one as a template.  Only a smattering of documents use a state description language.  Would be useful to run the experiment.
- Moshe: surprised that state chart is one of the heaviest areas of resource. Instead of looking at something new; look at W3C draft or something standard. Agree on methodology first, and then tool.
- Pete: time's up.
- Harald A: SDL, no filings on patents in 2003.  ITU has copyright on it.
- Pete: haven't heard anything regarding working group.  If we choose an existing language, no wg needed (except for profiling?).
- Aaron S: point of experiment is to validate the approach, not the language. Feature creep is an issue with subsetting.  An existing language already has things defined that are not initially in the subset.  Phrase representation and graphical representation.
- Stephane: have asked RFC authors about new language.  Since they haven't used SDL (for example) previously is because they didn't like the existing  tools.  Cosmogol design goal is something simple in the spirit of the IETF.
- Dave C: most interesting statement is about something Cosmogol can't do; this is a strength.
- Pete: show of hand: do we need a formal wg to have this discussion? or mailing list?
  - formal wg: one hand
  - formal wg not required (yet): few hands
  - not sure: many hands
  Continue discussion on the mailing list.  May have another BoF in Chicago.