That may be true, but it has long been the case that a
state-machine may completely and accurately be defined as a
(relatively) simple symbolic expression - requiring no figure
at all. Assuming that such an expression is included in the
normative text, then reference to an illustrative figure would
be an appropriate non-normative reference.
--> -----Original Message-----
--> From: ietf-bounces(_at_)ietf(_dot_)org
--> On Behalf Of Marshall Eubanks
--> Sent: Wednesday, November 16, 2005 11:00 AM
--> To: Stewart Bryant
--> Cc: Lars-Erik Jonsson (LU/EAB); ietf(_at_)ietf(_dot_)org
--> Subject: Re: Diagrams (Was RFCs should be distributed in XML)
--> I suspect that there is a lot more reliance of non-ASCII
--> art out there than is officially admitted.
--> I do not know how, for example, you can understand the
--> PIMv2 state machine without reference to the (non-ASCII)
--> diagrams provided in the
--> (non-ASCII) version of the draft.
--> Marshall Eubanks
--> On Nov 16, 2005, at 7:29 AM, Stewart Bryant wrote:
--> > It's interesting that when authors turn up at IETF to
--> explain their
--> > work/resolve issues etc they use colored diagrams to do
--> so - not ASCII
--> > art.
--> > Some of this is fashionable, but in many cases it is to clearly
--> > articulate a point in the very little time made available.
--> > I don't see why such powerful techniques shouldn't be
--> applied to the
--> > specifications themselves to allow the reader to most
--> grasp what is
--> > being said with the minimum effort.
--> > I am afraid that I don't subscribe to the hair shirt approach to
--> > drawings. I think that they should be exactly fit for
--> purpose neither
--> > too complex, nor too simple, and that the need to work round the
--> > limits of 72 ASCII characters should not be a constraint
--> that limits
--> > the clarity of expression.
--> > For example look at slides 5 and 6 in
--> > http://www3.ietf.org/proceedings/05nov/slides/pwe3-2.ppt
--> > and compare to figure1 in
--> > http://www.ietf.org/internet-drafts/draft-balus-bocci-martini-dyn-
--> > ms-pwe3-00.txt
--> > The latter shows the components of the system, but it is
--> impossible to
--> > put the detail shown in the slides into the diagrams in the
--> > specification itself with our current tools.
--> > Look at the figures in
--> > http://www.ietf.org/internet-drafts/draft-bocci-bryant-pwe3-ms-pw-
--> > arch-01.txt
--> > particularly figure 8. We are at the limit of what we can
--> describe in
--> > these diagrams.
--> > I can also find examples in the IP Fast Re-route work where we
--> > struggle to show network snippets in ASCII with the associated
--> > addressing and subsequent tunneling, and yet the
--> operation is simple
--> > to show in ppt, pdf, etc etc, particularly with colour.
--> > Another example - many of the ideas that we talk about in
--> the IETF
--> > start life as a few coloured lines on a large whiteboard
--> - because
--> > that is the simplest way to visualise these ideas and to
--> express them
--> > for the first time to our peers. That style of expression
--> > seems to the specifications themselves and for exactly
--> the same reason
--> > - clarity.
--> > Perhaps it is because the work that I do is mainly on
--> overlay network
--> > techniques where it is necessary to describe how the
--> virtual network
--> > maps onto the physical network that I find difficulty
--> producing clear
--> > ASCII art, but I would be surprised if I were alone in that view.
--> > If we think that ASCII art is all that is needed, perhaps - as an
--> > experiment - we should forbid the use of anything other
--> than ASCII art
--> > in presentations at the next IETF?
--> > - Stewart
--> > _______________________________________________
--> > Ietf mailing list
--> > Ietf(_at_)ietf(_dot_)org
--> > https://www1.ietf.org/mailman/listinfo/ietf
--> Ietf mailing list
Ietf mailing list