On Thu May 5 18:31:33 2011, Dave CROCKER wrote:
On 5/5/2011 10:22 AM, Dave Cridland wrote:
On balance, whilst I appreciate the aims of this document, I think
the proposals
are not suitable for adoption.
1) This document radically lowers the quality of Proposed
Standards.
What, specifically, are the parts of the proposal that you believe
will lower the quality of a Proposed Standard?
The parts unmentioned in the document, in effect.
It states:
2.1. The First Maturity Level: Proposed Standard
The stated requirements for Proposed Standard are not changed; they
remain exactly as specified in RFC 2026 [1]. Various influences
have
made publishing a Proposed Standard much harder than the stated
requirements in RFC 2026. The intention of the two-tier maturity
ladder is to restore practice to the requirements for Proposed
Standard from RFC 2026, and stop performing more scrutiny than
intended in IETF working groups and the IESG. No new requirements
are introduced; no existing published requirements are relaxed.
RFC 2026 essentially defines a PS document as being a first cut,
likely to change, and as such unsuitable for production deployment.
In particular:
Implementors should treat Proposed Standards as immature
specifications. It is desirable to implement them in order to gain
experience and to validate, test, and clarify the specification.
However, since the content of Proposed Standards may be changed if
problems are found or better solutions are identified, deploying
implementations of such standards into a disruption-sensitive
environment is not recommended.
So this clearly states that should we revert to RFC 2026, then we
should immediately consider that HTTP, IMAP, and XMPP, for instance,
should not be deployed in disruption-sensitive environments. Are you
really sure that's what you think our consensus opionion is? It
certainly isn't mine.
I don't think this reflects the current status quo in the slightest.
I think our current PS maturity is essentially considered production
quality, although we anticipate that clarifications in the
specification may be required, and consultation with other
implementors is likely to be beneficial.
In particular, for better or worse, the wider internet technical
community - ie, the people who are aware of, but not involved in, the
IETF - expect our PS documents to have high quality, and would be
caught unawares by a sudden shift back to this stance.
So to make this clear, I think that as the requirements and scrutiny
of PS documents have increased, the quality has as a result, and -
undoubtedly more important - the expected quality has also. I am
suprised that you don't see this as quite apparent.
We have, in general, raised the bar over the years for PS documents,
and - whether or not you think this was a good idea - this horse has
left the station, and it's too late to put the lid back on - the
wider world now expects this.
Dave.
--
Dave Cridland - mailto:dave(_at_)cridland(_dot_)net -
xmpp:dwd(_at_)dave(_dot_)cridland(_dot_)net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf