Subject: RE: Last Call: 'Proposed Experiment: Normative Format in Additionto ASCII Text' to Experimental RFC (draft-ash-alt-formats)

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Sun, 25 Jun 2006 16:41:32 +0200

> 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.

> 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.

/L-E

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Stewart Bryant <[email-masked]>
Date: Sun, 25 Jun 2006 16:26:22 +0100

>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.

>too much complexity in one picture and should thus be
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

---

From: "Randy Presuhn" <[email-masked]>
Date: Sun, 25 Jun 2006 09:07:19 -0700

Hi -

> From: "Stewart Bryant" <[email-masked]>
...
> Sent: Sunday, June 25, 2006 8:26 AM
> Subject: Re: Last Call: 'Proposed Experiment: Normative Format in Additionto ASCII Text' to Experimental RFC
(draft-ash-alt-formats)
...
> to produce precision specifications when the other SDOs do?
...

Though other organizations use fancy graphics to various degrees,
in the cases where I have first-hand experience (ITU, ISO, DMTF) it's not
clear to me that they actually *needed* to use them.  I think the UML
diagrams that pervade CIM are a good demonstration of how the "need"
to use graphics indicates that something else isn't quite right.

As for traditional mathematical notation, I think resorting to it for
all but the simplest formulas, e.g. "y =(m * x) + b)", often
does a grave disservice to all readers who are not mathematicians.

Randy

---

From: Carl Malamud <[email-masked]>
Date: Sun, 25 Jun 2006 09:22:09 -0700 (PDT)

> does a grave disservice to all readers who are not mathematicians.

"RFC authors MUST NOT use calculus or matrix algebra.  Addition and
subtraction MAY be expressed as formulas but authors SHOULD NOT
use formulations sufficiently complex to make a reader's head hurt."

Carl

---

From: "Stephen Sprunk" <[email-masked]>
Date: Sun, 25 Jun 2006 14:55:34 -0500

Thus spake "Carl Malamud" <[email-masked]>
> use formulations sufficiently complex to make a reader's head hurt."

IMHO, this would be a very good rule; the IETF is supposedly about running 
code, and complex equations that the average programmer cannot understand 
without digging up a college math book are unimplementable in the real 
world.  Pseudocode is far, far more valuable than pretty equations.

IMHO, a direct result of the above is that any math that cannot be described 
adequately in ASCII text does not belong in an RFC.  This is similar to the 
view that diagrams that cannot be represented in ASCII art are too complex 
to be meaningful to the reader.

Every time this debate comes around, I am struck by the notion that 
normative formats other than ASCII are a solution in search of a problem. 
About the only argument I've read to date that makes sense is to allow UTF-8 
to access characters that do not exist in ASCII, such as for authors' names 
or better line-drawing characters.  Everything else seems to fall into the 
"our specs aren't as pretty as other SDOs' specs" category.

S

Stephen Sprunk        "Stupid people surround themselves with smart
CCIE #3723           people.  Smart people surround themselves with
K5SSS         smart people who disagree with them."  --Aaron Sorkin

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 25 Jun 2006 22:16:00 +0200

On 25-jun-2006, at 21:55, Stephen Sprunk wrote:

> IMHO, this would be a very good rule; the IETF is supposedly about  
> running code, and complex equations that the average programmer  
> cannot understand without digging up a college math book are  
> unimplementable in the real world.  Pseudocode is far, far more  
> valuable than pretty equations.

I agree one hundred percent. (Or 100%.)

> IMHO, a direct result of the above is that any math that cannot be  
> described adequately in ASCII text does not belong in an RFC.  This  
> is similar to the view that diagrams that cannot be represented in  
> ASCII art are too complex to be meaningful to the reader.

I'm not sure if I fully agree with that, maybe there are useful  
diagrams that can't be preserved in ASCII. But nobody has presented a  
convincing example so far.

The fact that other standards organizations and/or engineering  
disciplines make extensive use of diagrams doesn't mean we should do  
the same. It makes a lot of sense to describe a building with a  
blueprint, because meaningful aspects of a building easily translate  
into a graphical representation. This is not the case with a protocol  
= software design. Traditionally, many kinds of diagrams have been  
used here, but in my experience, with the exception of header format  
diagrams, they rarely clarify as much as they seem to on first glance.

> normative formats other than ASCII are a solution in search of a  
> problem. About the only argument I've read to date that makes sense  
> is to allow UTF-8 to access characters that do not exist in ASCII,  
> such as for authors' names or better line-drawing characters.   
> Everything else seems to fall into the "our specs aren't as pretty  
> as other SDOs' specs" category.

My conclusion, having participated in this discussion the past week  
or so, is that there is that limiting ourselves to ASCII does indeed  
cause inconvenience, but changing to a new format would cause MANY  
more problems than it solves.

---

From: "Robert Sayre" <[email-masked]>
Date: Sun, 25 Jun 2006 16:57:07 -0400

> to produce precision specifications when the other SDOs do?

I think Ned's message sums it up... even if you agree that the current
situation is suboptimal, and you agree with all of the assertions
above, this experiment will tell us nothing useful. However, it will
publish one or more RFCs in a format that the IETF as a whole has not
endorsed as acceptable.

In that context, the socratic questioning and heated rhetoric from the
draft's authors can only be seen as energetic handwaving.

-- 

Robert Sayre

---

From: Scott W Brim <[email-masked]>
Date: Mon, 26 Jun 2006 08:06:51 -0400

On 06/25/2006 15:55 PM, Stephen Sprunk allegedly wrote:
> the IETF is supposedly about
> running code, and complex equations that the average programmer cannot
> understand without digging up a college math book are unimplementable in
> the real world.  Pseudocode is far, far more valuable than pretty
> equations.

Good point.  While I agree completely with the proponents of richer
formats that plaintext is poor for communicating how things work, it
can't be beat for discipline in creating implementation specs.
Perhaps we should have rich formats for background documents,
framework documents, etc., but stick to plaintext for documents that
actually  define protocols for implementation.

---

From: "David Harrington" <[email-masked]>
Date: Mon, 26 Jun 2006 08:07:14 -0400

Hi,

I agree equations should be written in ASCII pseudocode so it is
easier to convert it to code.
Pretty pictures, provided for the mathematicians, can be done as
non-normative additions to the spec.

Diagrams can be done as non-normative additions to the spec, which may
help people think through various aspects of the design, but the spec
should contain a normative ascii representation of the logic, and/or
pseudocode, so people can actually implement the spec. If it is too
difficult for the authors to convert from the complex diagram to an
ascii text or ascii art representation of the logic, then maybe this
is not a good choice for a spec.

Even though I have been inconvenienced by having to develop ascii art,
and spell out difficlut logic in text, I am not convinced we actually
**need** normative pictures or equations. To quote from
draft-ash-alt-formats-02.txt, in many, many, previous discussions on
the IETF meiling lists trying to justify the need for additional
normative formats, "quite thoughtful, extended, and detailed
discussion on the IETF discussion list resulted in no change."
Apparently, a large number of readers of and contributors to the IETF
discussion list are also unconvinced such a change is needed.

Experience with other SDOs' publication processes does not make me
want to adopt them for the IETF - just the opposite. Having been a MIB
Doctor for IEEE 802.1, I needed to deal with the fact I could not
extract portions of the normative PDF files to include in my comments.
The 802.1 WG produced ASCII versions of the MIB specifications so we
IETFers could access them more easily, and the existing MIB processing
tools could work with the specs more easily, but often the
non-normative ascii version was not kept up-to-date with the PDF
version by the authors. This made it difficult to do IETF-style
reviews on a timely basis, to automate the syntax validation of the
specification, or to use the normative PDF as input to tools that
generated code from the MIB specification. The PDF definitely got in
the way of providing industry reviews, generating valid
specifications, and implementing the specs.

But this last call is about a specific document proposing a specific
experiment.

I think a proposed experiment that "fixes diagram issue" and "fixes
equations issue" really would need to prove there is a need for
normative diagrams and equations to produce an IETF technology
specification. That is, it would need to prove it is not possible to
specify a particular technology using pseudocode, ascii text, and
ascii diagrams. I think the only thing such an experiment would be
likely to prove is that the proposed technology that requires complex
graphics and equations to describe the involved logic is really not
ready to be specified in an IETF specificiation.

I think that proving complex diagrams and equations MIGHT be used with
implementable specs, and may help understanding of the design, is not
adequate; we already have the ability to include non-normative
diagrams and equations to aid understanding.

I don't think the proposed experiment as designed is useful. I do not
see consensus on the IETF discussion list that the "problems to be
solved" are actually problems to be solved. 

I do not feel the particular criteria chosen to determine experiment
success are appropriate to IETF documents. Could PDF and other formats
produce documents that are clearer, easier for authors to write, and
easier to read? Sure. And if the difference is adequate, the authors
should consider providing non-normative PDF to improve clarity, and
ease of writing and reading. But that doesn't prove it should be
normative.

But the job of the IETF is not to publish pretty documents that are
easy to write and read; it is to produce specifications of useful
implementable standards for use in the Internet on a timely basis. I
do not see those listed as "particular criteria" for measuring
effectiveness. The criteria seem to miss the whole point of our
working on standards.

I do not believe it would be a worthwhile use of community resources
to run this experiment as designed.

David Harrington
[email-masked] 
[email-masked]
[email-masked]

> -----Original Message-----
> From: Iljitsch van Beijnum [mailto:[email-masked]] 
> Sent: Sunday, June 25, 2006 4:16 PM
> To: Stephen Sprunk
> Cc: IETF-Discussion Discussion
> Subject: Re: Last Call: 'Proposed Experiment: Normative 
> Format in AdditiontoASCII Text' to Experimental RFC 
> (draft-ash-alt-formats)
>

---

From: Tony Finch <[email-masked]>
Date: Mon, 26 Jun 2006 16:29:10 +0100

On Sun, 25 Jun 2006, Stephen Sprunk wrote:
> without digging up a college math book are unimplementable in the real world.
> Pseudocode is far, far more valuable than pretty equations.

It's often the case that there can be a fair amount of maths that explains
why a bit of really simple code does what it is supposed to, and this
should be part of the specification.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
HUMBER THAMES: NORTH 4 OR 5, OCCASIONALLY 6 AT FIRST, DECREASING 3. RAIN DYING
OUT. MODERATE OR POOR BECOMING GOOD.