[email protected] wrote:
> Dave Crocker wrote:
>
>> 2. The RFC Editor publishes rules for Errata. So does the IESG.
>> You indicate that Pasi is refusing to process
>> draft-ietf-dkim-rfc4871-errata-02 for two reasons: It introduces new
>> terminology and it makes too many changes. Neither of these is
>> included (or excluded) from the RFC Editor or IESG Errata rules.
>> Pasi should explain his basis for adding these constraints.
>
> I do not believe the errata meets this criteria, agreed by the IESG
> for IETF Stream RFCs:
>
> http://www.ietf.org/IESG/STATEMENTS/iesg-statement-07-30-2008.txt:
Pasi,
That document contains specifics. I am asking you to cite the specifics that
cover the reasons given for your refusal to process this as an Errata.
To make this simpler:
Let's say you refused to process the Errata because the Errata contained
the
word "the". And when asked to explain your reason, you said:
"I do not believe the errata meets this criteria, agreed by the IESG
for IETF Stream RFCs:
http://www.ietf.org/IESG/STATEMENTS/iesg-statement-07-30-2008.txt";
No one would find that an adequate explanation.
Yet this is exactly what you have just done, since I do not see any way to
interpret the text of the IESG statement as covering the conditions Barry cited.
You obviously do see a way and I am asking you to explain it, by providing the
details.
>> 7. Changes that modify the working of a protocol to something that
>> might be different from the intended consensus when the document
>> was approved should be either Hold for Document Update or
>> Rejected. Deciding between these two depends on judgment.
>> Changes that are clearly modifications to the intended consensus,
>> or involve large textual changes, should be Rejected. In unclear
>> situations, small changes can be Hold for Document Update.
>
> We have already exchanged many off-list emails about this topic, and
> I get the impression that you disagree both with the IESG statement
> itself and my judgement call.
I haven't commented on the adequacy of the statement.
In fact I keep trying to reconcile the reasons you cite with the content of
that
statement. That's the failure that /I/ keep citing and that's why I'm asking
you to be specific, rather than just invoking the IESG statement in its
entirety.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
