--On Tuesday, September 17, 2013 11:32 +0100 Dave Cridland
<dave@xxxxxxxxxxxx> wrote:
> I read John's message as being against the use of the phrase
> "in exceptional cases". I would also like to avoid that; it
> suggests that some exceptional argument may have to be made,
> and has the implication that it essentially operates outside
> the process.
Exactly.
> I would prefer the less formidable-sounding "on occasion",
> which still implies relative rarity.
And "on occasion" is at least as good or better than my
suggestions of "usually", "commonly", or "normally" although I
think any of the four would be satisfactory.
--On Tuesday, September 17, 2013 07:06 -0400 Scott Brim
<scott.brim@xxxxxxxxx> wrote:
>...
> Exceptions and arguments for and against are part of the
> process. Having a process with no consideration for exceptions
> would be exceptional.
Scott, it an IETF technical context, I'd completely agree,
although some words like "consideration for edge cases" would be
much more precise if that is actually what you are alluding to.
But part of the intent of this revision to 2026 is to make what
we are doing more clear to outsiders who are making a good-faith
effort to understand us and our standards. In that context,
what you say above, when combined with Olaf's text, is likely to
be read as:
"We regularly, and as a matter of course, consider
waiving our requirements for Proposed Standard entirely
and adopt specifications using entirely different (and
undocumented) criteria."
That is misleading at best. In the interest of clarity, I don't
think we should open the door that sort of interpretation if we
can avoid it.
I don't think it belongs in this document (it is adequately
covered by Olaf's new text about other sections), but it is
worth remembering that we do have a procedure for making
precisely the type of exceptions my interpretation above
implies: the Variance Procedure of Section 9.1 of 2026. I
cannot remember that provision being invoked since 2026 was
published -- it really is "exceptional" in that sense. Its
existence may be another reason for removing "exceptional" from
the proposed new text because it could be read as implying that
we have to use the Section 9.1 procedure for precisely the cases
of a well-documented, but slightly incomplete, that most of us
consider normal. In particular, it would make the approval of
the specs that Barry cited in his examples invalid without
invoking the rather complex procedure of Section 9.1. I'd
certainly not like to have text in this update that encourages
that interpretation and the corresponding appeals -- it would
create a different path to the restriction Barry is concerned
about.
john