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