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

[Stewart Bryant <stbryant at cisco.com>]

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.org
https://www1.ietf.org/mailman/listinfo/ietf