Subject: [Techspec] Review of draft-mankin-pub-req-04

From: Eric Rescorla <[email-masked]>
Date: Mon, 06 Mar 2006 18:27:48 -0800

Overall, this document seems pretty sound. I've got one meta-issue
and a bunch of smaller issues. The meta issue is the labelling
of the requirements. You have "current" and "potential" but I
think it would be good to distinguish three cases:

1. Requirements that you believer are commonly accepted.
2. Requirements that you believe we currently have but that
   not everyone agrees with.
3. Requirements that you're proposing we may or may not need
   sometime in the future.

It's not clear to me whether "Current" embodies both (1) and (2)
or...

Figure 1 could use a little clarification, since the actual
IANA parameter assignnment is done after approval, no?

S 3.3:
Can you define "substantive" changes please. Do you mean "significant"
or "ones that affect the actual meaning of the documents"?

I don't understand the difference between Req-POSTEDIT-3 and Req-POSTEDIT-4.

S 3.7:

   o  Potential Req-POSTCORR-3 - The IETF technical publisher should 
      have the discretion to reject post-approval corrections as too 
      late in the process and propose that it be handled as errata. 

I'm not sure I agree with this. Fundamentally, that seems like the
kind of discretion that should rest with the IESG. The publisher
can of course say "this will require reflowing the document" or
"this will delay the document X weeks" but up until the moment
of publication I'm not sure why IESG shouldn't be able to direct
changes.

S 3.9:

   o  Current Req-DOCCONVERT-1 - The IETF technical publisher should 
      accept as input ascii text files and publish documents as ascii 
      text files, postscript files, and pdf files. 

I think this needs some clarity. It's one thing to publish the documents
in PDF file that looks exactly like the ASCII, as RFC-Ed does now. But
that's not really what most people would expect when they wanted it
done in PDF or PS. 

S 3.12:

   approving organization to request expedites publication of a 

This should read "expedited", no.

S 4:
I'm not sure I agree that this kind of metric granularity is
appropriate in this document. I would prefer it set general
policy and leave the IAD/IASA to formulate specific metrics
in the technical publisher contract as appropriate.

S 7.

   There is a tussle between the sought-for improvements in readability 
   and the specific language that has often been negotiated carefully 
   for the security content of IETF documents.  As with other text, 

I'm not sure I would use the word "tussle" here. There's a tension,
true, but a tussle involves divergent interests, which isn't quite
what's going on here.

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