--On Friday, September 13, 2013 16:56 +0200 Olaf Kolkman
<olaf@xxxxxxxxxxxx> wrote:
>...
> Based on the discussion so far I've made a few modifications
> to the draft. I am trying to consciously keep this document
> to the minimum that is needed to achieve 'less is more' and
> my feeling is that where we are now is close to the sweetspot
> of consensus.
Olaf,
I'm afraid I need to keep playing "loyal opposition" here.
> * Added the Further Consideration section based on
> discussion on the mailinglist.
Unfortunately, IMO, it is misleading to the extent that you are
capture existing practice rather than taking us off in new
directions. You wrote:
> While commonly less mature specifications will be published as
> Informational or Experimental RFCs, the IETF may, in
> exceptional cases, publish a specification that does not match
> the characterizations above as a Proposed Standard. In those
> cases that fact will be clearly communicated on the front page
> of the RFC e.g. means of an IESG statement.
On the one hand, I can't remember when the IESG has published
something as a Proposed Standard with community consensus and
with an attached IESG statement that says that they and the
community had to hold our collective noses, but decided to
approve as PS anyway. Because, at least in theory, a PS
represents community consensus, not just IESG consensus (see
below), I would expect (or at least hope for) an immediate
appeal of an approval containing such as statement unless it
(the statement itself, not just the opinion) matched community
consensus developed during Last Call.
Conversely, the existing rules clearly allow a document to be
considered as a Proposed Standard that contains a paragraph
describing loose ends and points of fragility, that expresses
the hope that the cases won't arise very often and that a future
version will clarify how the issues should be handled based on
experience. That is "no known technical omissions" since the
issues are identified and therefore known and not omissions. In
the current climate, I'd expect such a document to have a very
hard time on Last Call as people argued for Experimental or even
keeping it as an I-D until all of the loose ends were tied up.
But, if there were rough consensus for approving it, I'd expect
it to be approved without any prefatory, in-document, IESG notes
(snarky or otherwise).
The above may or may not be tied up with the "generally stable"
terminology. I could see a spec with explicit "this is still
uncertain and, if we are wrong, might change" language in it on
the same basis as the loose end description above. Such
language would be consistent with "generally stable" but, since
it suggests a known point of potential instability, it is not
consistent with "stable".
Additional observations based on mostly-unrelated recent
discussions:
If you are really trying to clean 2026 up and turn the present
document into something that can be circulated to other groups
without 2026 itself, then the "change control" requirement/
assumption of RFC 2026 Section 7.1.3 needs to be incorporated
into your new Section 3. It is not only about internal debates,
it is our rule against why we can't just "endorse" a standard
developed elsewhere as an IETF standards track specification.
Along the same lines but more broadly, both the sections of 2026
you are replacing and your new text, if read in isolation,
strongly imply that these are several decisions, including those
to approve standardization, that the IESG makes on its own
judgment and discretion. I think it is fairly clear from the
rest of 2026 (and 2028 and friends and IETF oral tradition) that
the IESG is a collector and interpreter of community consensus,
not a body that is someone delegated to use its own judgment. I
believe that, if an IESG were ever to say something that
amounted to "the community consensus is X, but they are wrong,
so we are selecting or approving not-X", we would either see a
revolution of the same character that brought us to 2026 or the
end of the IETF's effectiveness as a broadly-based standards
body.
More important --and related to some of my comments that you
deferred to a different discussion-- the "IESG as final
_technical_ review and interpreter of consensus" model is very
different from that in some other SDOs in which the final
approval step is strictly a procedural and/or legal review that
is a consensus review only in the sense of verifying that the
process in earlier stages followed the consensus rules and is
not technical review at all. I don't think you need to spend
time on that, but you need to avoid things that would make your
document misleading to people who start with that model of how
standards are made as an initial assumption.
best,
john