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

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Thu, 15 Jun 2006 08:44:49 -0500

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 15 Jun 2006 11:07:59 -0400

As I said in my comments, there is a big difference in the situations.
Currently, if the RFC Editor misses something in the PDF applied 
corrections, that is unfortunate but not fundamentally significant, 
in that the text file is normative, not the PDF.
With your proposed change, the PDF would be normative, not the 
text.  As such, the degree of care and review required for the PDF 
document is much higher.

Similarly, the issue of version change and feature set is not central 
when one is dealing with informative PDF.  But becomes critical if 
the PDF is normative.  (It is extremely undesirable for a normative 
document to be inaccessible.)  As such, your persistent comparisons 
with the current state are at best misleading.

As an example of the necessity of profiling the PDF, at the very 
least we would want searchable PDF.  (Some PDFs with text are 
searchable, some are not.)

Yours,
Joel M. Halpern

---

From: Thomas Narten <[email-masked]>
Date: Thu, 15 Jun 2006 11:12:18 -0400

> comments were posted to the list on this version.

Maybe reviewer fatigue?

One thing missing from this discussion (that I think would have been
helpful) is running all the previous comments through an issue
tracker, so folk could go review the history, and most important of
all, those who raised issue can go see if they believe their issues
have been dealt with appropriately. One of the most frustrating and
demoralizing aspects of IETF participation is spending time doing a
careful review, and then feeling like your comments have been blown
off. Trackers make it much harder for that to happen, which in my
experience is a very good thing for all involved.

Thomas

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 15 Jun 2006 10:00:13 -0700

Hi -

> From: "Thomas Narten" <[email-masked]>
> To: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
> Cc: "Bob Braden" <[email-masked]>; <[email-masked]>
> Sent: Thursday, June 15, 2006 8:12 AM
> Subject: Re: Last Call: 'Proposed Experiment: Normative Format in Additionto ASCII Text' to Experimental RFC
(draft-ash-alt-formats)
...
> experience is a very good thing for all involved.
...

Since there appears to be some disagreement about whether comments
received were adequately addressed by the draft now under last call,
and whether the manner in which they were addressed represents a
consensus view, perhaps we should consider the possibility that the
question of whether and how to conduct this experiment could be given to
a WG (IRTF, rather than IETF, I'd think), in order to ensure that the
experiment's general parameters meet with community approval.

Randy