ietf
[Top] [All Lists]

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

2006-06-26 05:09:30
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
dharrington(_at_)huawei(_dot_)com 
dbharrington(_at_)comcast(_dot_)net
ietfdbh(_at_)comcast(_dot_)net


-----Original Message-----
From: Iljitsch van Beijnum [mailto:iljitsch(_at_)muada(_dot_)com] 
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)

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.

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.

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.

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf



_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>