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

> As the author notes, there was 
> indeed a replay 
> of the usual
> discussion about RFC formats in winter 2006.  The author 
> says, "... the 
> quite thoughtful,
> extended, and detailed discussion ... resulted in no change". 
>  There is a 
> reason it did
> not result in change... there were cogent arguments against 
> all proposals 
> that were
> made. 

Cogent arguments against?  Very few people came out and said that we
need nothing beyond ASCII art.  OTOH, many supported the need for
something better than archaic ASCII art/equations, given that almost all
of us recognize the limitations of ASCII art/equations, generate/use
complex graphics every day (in many formats), and very few of us
generate/use stick figures beyond IETF.

> So, when it has no good ideas, the IETF randomly picks 
> one of the bad 
> ones?
> That is apparently happening here.
> 
> How DID it get last called, by the way?  If I write up a 
> arbitrary process 
> experiment,
> will the IESG automatically last call it?  Yummy.

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.  

In addition, you/RFC Editor were asked to comment on this version
(before it was submitted), starting on May 5, but you did not comment.
There was an exchange with the AD during this period regarding his
concerns RE RFC Editor buy-in, but you still did not comment.  We could
have incorporated your comments into the LC version had we known them.

> The experiment picks on  two working groups and specifies 
> that for one year review
> it will
> treat the results of these working groups differently from all other 
> working group
> output. 

Only 2 drafts are involved, and both WGs have agreed.  Both of these
drafts are good examples of where .pdf is preferable to ASCII art.

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

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

> As Joel mentions, this experiment will have a negative impact on
> RFC Editor throughput.  Shouldn't the IAB and perhaps the IAD
> have some part in this?

.pdf is allowed now for drafts and RFCs.  There are procedures in place
for .pdf output.  In fact, the proposed experiment uses exactly the same
procedures followed now wrt RFC Editor processing of .pdf output
documents.  As stated in the draft:

  "These documents will be progressed through WG review, IESG review,
   and RFC Editor review and approval.

   The method to progress the PDF format version is as specified in
   [RFC2223bis]:

   When the .pdf version is submitted with the .txt version, the RFC
   Editor will first edit the .txt version.  The final form of the .txt
   version (or, when feasible, the diffs) will be returned to the
   author.  The author must then update the .pdf files to match, as
   closely as possible, the content and format of the ASCII .txt file.
   When the RFC Editor agrees that the .pdf version is acceptable, it is
   published simultaneously with the .txt version."

Since these same procedures are specified in [RFC2223bis]
http://www.ietf.org/internet-drafts/draft-rfc-editor-rfc2223bis-08.txt,
authored by the RFC Editor, it is reasonable to assume they are OK for
our experiment.  It is also hard to see how these procedures will lead
to more work for the RFC Editor given they are used now.

In addition, tools can be developed to assist the authors and RFC editor
if necessary.  It is straightforward to specify required .pdf
versions/formats if that is essential, as some have suggested (although
there is no such requirement now on .pdf drafts and RFCs AFAIK).

> For all the reasons that Joel said, plus the reasons I have given, I
> request that the IESG reject this last call.  At the very least, the
> base document needs more work, and the implications need
> more mature thought.  And it seems to there is a badly broken
> process lurking here.
> 
> I am somewhat astonished that the IESG chose to last call
> 'this document.

It's quite legitimate to last call this (6 months of discussion, several
weeks to comment on this version, etc.).  I'm rather astonished that you
ignored specific requests to comment on this version when you had so
many comments (changes could have been incorporated before LC).

Several people recognized the need for a way for IETF to overcome the
stone-age ASCII art/ASCII equations format.  Hopefully some people that
agreed with the obvious need will speak up again in support.  Several
people agreed that normative .pdf was the simplest way to this end.  It
is certainly in the interest of IETF to improve its processes.
'Experiments' are not an ideal way to do that, but that's all we have
right now.

Jerry Ash

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf