Dave CROCKER wrote:
Jim,
Jim Fenton wrote:
Having just reviewed yet another document referring to "recent activity
by the Internet Engineering Task Force (IETF) to create protocol
standards around SPF and DKIM", I am reminded how little the community
outside IETF grasps the difference between Informational, Experimental,
and Standards Track, never mind the differences between Proposed,
Draft,
and Full Standard. So I agree that, largely, no one cares whether DKIM
is PS or DS.
Taken as stated, your example actually implies that we shouldn't
bother with standards effort at all, since the folk you cite consider
anything with 'RFC' in the name to be a standard. Are you suggesting
that because some people do not understand (or care about) the IETF
standards imprimatur, no one else does?
I'm saying (recognizing this is well outside the scope of the working
group) that IETF has a problem in that it publishes informational,
experimental, and historic RFCs and many people outside IETF immediately
think anything with an RFC number is an "IETF standard". That dilutes
the value of the IETF standards process and (talking like a marketing
person) the IETF "brand".
The distinctions between Proposed, Draft, and Full Standard are finer yet.
Ultimately, a standards process is whatever it is and the outside
world chooses how to deal with it. A standards group can only define
itself as it sees fit and try to conform to that. Some people ignore
whether a document is standards track. Some ignore level of
maturity. Others pay close attention to these distinctions.
In the IETF, the purpose of moving to Draft is to formally declare
that a specification has reached an additional level of maturity.
IETF standards differ from ITU standards, for example, by having
maturation levels. ITU standards, from one version to the next, can
be dramatically different and fundamentally incompatible. IETF
standards cannot.
I have been seeing significant uptake in DKIM adoption and am concerned
that, if we are seen to be making large changes to the specification,
we're likely to induce another round of waiting until we're "done" on
the part of implementers and adopters. Regardless of how we describe
the compatibility between -bis and 4871, it's all about the perception
if large changes are being made.
Basic concern about perceptions of substantial change is generic,
serious and of course legitimate, IMO.
But how does it apply to what might be done to move the specification
from Proposed to Draft? What particulars are you worried about?
Referring back to my message, I'm advocating that if we do anything, we
move to Draft Standard, and advocating that we not do another spin at
Proposed Standard. So are we agreeing?
IETF rules are rather forceful in this regard. The only substantive
changes permitted, for a specification moving from Proposed to Draft,
is to remove unused or problematic features. That is, the only
substantive changes permitted make a specification simpler.
If, indeed, a feature is unused or problematic, then how will dropping
it hurt adoption? A simpler specification typically aids adoption,
rather than hurting it.
Dropping unused features won't hurt adoption, so long as we handle the
backwards-compatibility issues properly (the dropped feature has
suitable defaults, and the IANA registries prevent re-use of previously
used names). I'd need specifics to address the "problematic" case, though.
And just to keep things real, can you cite some examples of the effect
you are concerned about?
The example here would be a specification that was updated at Proposed
Standard where that caused deployment to stall. No, I don't have the
depth of experience in IETF to cite any. But I feel that if we go
directly to DS, the constraints in that process will help assure that
doesn't happen.
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html