Lars-Erik Jonsson (LU/EAB) wrote:
Cogent arguments against? Very few people came out and
said that we need nothing beyond ASCII art.
If you ask people whether *we* need nothing more than ASCII,
I would guess most of us would not claim that, since even
if *I* have not had a single case where something beyond
ASCII has been preferable, I would not be willing to state
what *we* need based only on my experience. Personally, I do
not see the point of more complex graphics, and I would
prefer not to introduce more complexity into our documents.
That does not mean I am saying there can not be a need, so
I would not claim that *we* need nothing beyond ASCII.
However, I am personally very sceptical to the arguments
in favour of more complexity, i.e. I am far from convinced
there is a real need here.
I wonder how often IETFers skate over detail because they do not have
the tools to provide a complete specification?
Sometimes a more complex diagram leads to a simpler, more precise
specification.
The state tables that Bill Fenner showed were much clearer to me than
the accompanying text.
As we said in the draft we are on the limit with equations - do we not
need equations?
The area where I ran into the limit was in describing fast-reroute where
you have to show the relationship between the base, repair and new topology.
This is very much an area where if you focus on the very simple
topologies that ASCII encourages you to draw you may miss the
interesting ones that are just a bit harder to draw.
Another example there is a school of thought that G.805 graphics - which
as far as I can see are circuit diagrams for protocol engineers - leads
to less muddled thinking - for example less layer violations - when it
comes to designing protocol layering. You cannot do G.805 in ASCII,
so we can't even experiment with it during our design process.
It is quite reasonable to last call this draft at this
point. It has been reviewed for ~6 months. This version
posted to the list for comments more than 3 weeks ago,
plenty of time for more comments, but no comments were
posted to the list on this version.
Just because people do not comment/contribute one can
not expect documents to be progressed. It is the proponent
of an idea that has to get support in favour of it, and we
have not seen much support for this suggested experiment
during previous discussions.
How will a future implementor know which version is
normative? At present, there is a simple rule... it
is always the ASCII version. If this exercise goes
ahead, some PDF files (which ones?) will be normative,
and some ASCII files won't.
I'm sure with all the brain power at hand we can solve
that daunting riddle with another simple rule.
I do not think this is about brain power, it is a matter
of increasing the formal complexity of our documents.
the I-D has some misleading examples of bad ASCII art.
You cannot honestly prove that ASCII art is unusable
by abusing it. I spent a few minutes cleaning up the
terrible example in the I-D (Sorry, I am in Washington
and don't have ready access to it; I will forward it
when I get back.)
Yes please send us the competing ASCII diagrams. We
can provide you with even more complex artwork/diagrams
to convert to ASCII art -- this will allow you to
further prove your point.
I do not doubt it is possible to come up with artwork
that can not be easily captured in ASCII art, but that
is rather irrelevant. The relevant question is whether
there is meaningful and essential complex artwork needed
in our documents that we can not capture in ASCII-art.
My personal feeling is that graphics with too much
complexity to capture in ASCII-art is trying to describe
too much complexity in one picture and should thus be
simplified.
Or are using many words to replace the graphic - perhaps with less precision
and greater probability of error?
Let me ask a question that has been puzzling me for some time:
I am going to assert that the people that go to the various SDO are all of
approximately the same ability - indeed many IETFers go to more than
one SDO, so there is a sort of existance proof.
I am going to also assert that the work of most of these SDOs is of
equivalent sophistication and complexity.
What is unique about the work of the IETF that it does not need graphics
to produce precision specifications when the other SDOs do?
- Stewart
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf