Subject: RE: Normative figures

From: "Gray, Eric" <[email-masked]>
Date: Mon, 9 Jan 2006 14:47:29 -0500

Stewart,

	There's a joke that goes something like this: there are three 
kinds of people in this world - those that are good at Math and those
that are not.

	Funny thing is that there are at least three ways in which
people approach mathematical expressions:

1) Some see a nice, clean, symbolic expression and mentally reject it 
   out of hand (for these people, a "summation symbol" terminates a
   line of readable text);
2) Some see a symbolic expression, look at it briefly and become (as
   one person said earlier about figures) convinced they understand 
   it while actually they do not (this can be established by a simple
   search for published material in which non-sensical mathematical
   expressions were included without comment in peer reviews);
3) Some people see any symbolic expression and play with it until 
   either they understand it or they know what is wrong with it.

In the first two cases - in which, I think we can agree, most people
would fall - it is much better to have made the effort to put the
expression in "plain English" - however much prettier it would have
been in symbolic representation.

--
Eric

--> -----Original Message-----
--> From: [email-masked] [mailto:[email-masked]] 
--> On Behalf Of Stewart Bryant
--> Sent: Monday, January 09, 2006 2:22 PM
--> To: Bob Braden
--> Cc: [email-masked]; [email-masked]; 
--> [email-masked]; [email-masked]
--> Subject: Re: Normative figures
--> 
--> Bob Braden wrote:
--> 
--> >  *> 
--> >  *> Normative figures perhaps.  Normative equations definitely.
--> >
--> >Scott,
--> >
--> >How about Sections 4.2.3.3 and 4.2.3.4 of RFC 1122 (1889), 
--> for examples
--> >of readable equations in ASCII?  I my experience, 
--> normative protocol
--> >technical specifications rarely need equations much more 
--> complex than
--> >these examples.  The only significant exception I can 
--> think of is the
--> >NTP spec.
--> >
--> >People who REALLY use equations generally prefer LaTeX.
--> >
--> >Bob Braden
--> >
--> >
--> >  
--> >
--> The draft has expired so I need to point to an external 
--> version. This draft
--> which is looking at the properties of a routing network 
--> under conditions of
--> failure would have been much clearer if it could have used 
--> mathematical
--> notation rather than ASCIIised equations
--> 
--> http://www.faqs.org/ftp/pub/internet-drafts/draft-atlas-ip-l
--> ocal-protect-uturn-02.txt
--> 
--> Of course the diagrams could have also been clearer, as is seen by
--> comparing them to the ones that Alia used in her presentatons on the
--> subject.
--> 
--> - Stewart
--> 
--> 
--> _______________________________________________
--> Ietf mailing list
--> [email-masked]
--> https://www1.ietf.org/mailman/listinfo/ietf
--> 

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

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 09 Jan 2006 23:36:33 +0000

Dassa wrote:

>|> -----Original Message-----
>|> From: [email-masked] [mailto:[email-masked]] 
>|> On Behalf Of Stewart Bryant
>|> Sent: Tuesday, January 10, 2006 6:47 AM
>|> To: Sam Hartman
>|> Cc: Harald Tveit Alvestrand; [email-masked]
>|> Subject: Re: Normative figures
>|> 
>|> Sam Hartman wrote:
>|> 
>|> >Hi.  With the exception of packet diagrams, I think all the 
>|> examples 
>|> >you bring up benefit significantly from clear textual description.
>|> >
>|> Sam
>|> 
>|> I am not saying that clear text is not needed to accompany a diagram.
>|> However a diagram allows a lot less text to be written 
>|> producing a shorter clearer draft with less clutter.
><SNIP>
>
>Perhaps this is getting to the crux of the issues.  I see the IETF documents
>as breaking down the problems into smaller chunks that can be dealt with one
>at a time and which add up to a big picture description of the whole Internet.
>I see each individual document as being simple within itself, limiting the
>context to the smallest level an issue may be dealt with.  By adding more
>complexity to the documents I feel it is allowing more complex issues to be
>described in the documents but the documents then become larger, more
>difficult to comprehend and will be more difficult to process.
>
>Using the example you gave for routing costs, I see the description of routing
>cost basics or specifics as one document and the description of how they may
>be dealt with as another.
>
>By forcing the documents to be in a simple format, there are limitations on
>the complexity that may be explained in a single document, but I consider this
>a good thing.  It forces everyone to break the problems and issues down to
>their lowest levels and forces simple explanations that make it easier for
>everyone to understand.
>  
>
That does not work if you need the costs to set up a scenario that you 
are about to describe
the solution to.

>If more complex documents with full diagramatic process flows are required,
>these could be books written linking a number of IETF documents together to
>describe a more general practical picture of their implementation.
>
>  
>
It may not be possible to do that. It depends on what we are describing.

- Stewart

>Darryl (Dassa) Lynch

---

From: "Gray, Eric" <[email-masked]>
Date: Tue, 10 Jan 2006 11:38:47 -0500

Stewart,

	Yes, you are correct.  But, if you had correctly understood
the comment you quote below, you would realize that we're clearly
in agreement already - at least on that aspect of the discussion.

	:-)

	My point is that we make inclusion of elaborate figures more
difficult because elaborate figures don't necessarily make for a
better understanding - any more than complicated equations do.  If
people generally agree that complicated diagrams, tables, figures
or equations is necessary to understanding a specification - then
it is quite possible to do so.

	The fact that this makes it (at least slightly) harder to
write a specification if it must include complex art, does not 
impact on the difficulty in reading the resulting specification.
However, as pointed out several times, making it trivially easy
to include complex art MAY make reading specifications that do
not require it much harder.

	Since the vast majority of documents produced by the IETF
do not appear to require complex art, our process is optimized
for the normal case - just as it should be...

--
Eric

--> -----Original Message-----
--> From: Stewart Bryant [mailto:[email-masked]] 
--> Sent: Monday, January 09, 2006 11:40 PM
--> To: Gray, Eric
--> Cc: [email-masked]
--> Subject: Re: Normative figures
--> 
--> 
--> >We write specifications so that they are easier to read, validate 
--> >and understand, not so that they are easier to write.
--> >
--> >  
--> >
--> 
--> Eric
--> 
--> We write specs so that they will be correctly implemented.
--> Anything that makes a specification easier to correctly understand
--> surely makes it more likely that it will be correctly implemented?
--> 
--> The cost of incorrect implementation is so high that we can
--> can afford to pay a relatively high cost in the effort and
--> technology needed to read and write the specification.
--> 
--> - Stewart
--> 
--> 
--> 
--> 
-->

---

From: Bob Braden <[email-masked]>
Date: Wed, 11 Jan 2006 11:42:27 -0800 (PST)

*> > Scott,
  *> > 
  *> > How about Sections 4.2.3.3 and 4.2.3.4 of RFC 1122 (1889), for examples
  *> > of readable equations in ASCII?  I my experience, normative protocol
  *> > technical specifications rarely need equations much more complex than
  *> > these examples.  The only significant exception I can think of is the
  *> > NTP spec.
  *> 
  *> RFC 3247 is quite tricky too.
  *> 
  *> > 

Yes, in fact, the RFC Editor could have been persuaded that this
particular document fell into the RFC 1119 category -- PDF-only.
But note that it is not a standards track document, and that
very few areas of IETF endeavor have the mathematical depth
of queue management algorithms.

Bob