ietf
[Top] [All Lists]

Re: 2026, draft, full, etc.

2007-10-30 16:43:58
[I'm changing the subject and cutting off the references list as we seem
to have changed topic.]

Simon,

DS designates a mature standard.  If you read the requirements in RFC
2026 for a mature standard it is clear that few of the modern IETF
protocols live up to that standard -- you need to demonstrate
interoperability between two completely independent implementations of
_all_ features in the protocol standard.


I think we can all agree that the calendaring standard is mature.  We
are in the process of doing what I would consider to be a relatively
minor update to it, and yet it is only PS.

It is less clear, however, that all of its many features have been implemented
interoperabiy.

IMAPv4 is only PS and yet has MASSIVE deployment.

The main barrier to IMAP moving to draft is the large number of normative
references that first need to move first. Getting RFC 2822 to draft is a
necessary first step and we're working on that. But what about TLS? The
now-widespread use of TLS+plain has solved a lot of problems for appplications
but has created a serious obstacle to standards track advancement.

Perhaps a downreference exception needs to be made here, but if so that needs
to be approved in advance because nobody is going to bother going through all
the pain of documenting interoperability without first being sure that a
normative reference issue isn't going to render their work meaningless.

LDAP is only PS and is MASSIVELY deployed.

I suspect the main issue is the same as for IMAP.

SIP
is all over the place and it is only PS as well.  And so it's pretty
clear that nobody cares about DS or IS.

I really don't think that's true. The problem is rather than people have
(correctly IMO) assessed that while the benefits of DS are real they just
aren't worth the cost. The question, then, is whether or not the cost can be
lowered without compromising the status, and if so, how. My personal opinion is
that major loosening of the downref rules as well as less nit-picking on
feature lists would help a lot without damaging the brand in any significant
way.

What's more, why should they?
What benefit does it bring to anyone to advance a standard to DS?  AND
it's a whole lot of work.

So why are we even having an argument about what gets stuck into
requirements for DS?  Shouldn't we instead be eliminating it entirely?

I agree with Brian that this isn't the answer. But the current situation isn't
right either. We need to focus on what's important, which is real world
interoperability. Things have gotten too complex for a more exhaustive academic
approach to be viable.

                                Ned

P.S. I actually started working on a feature checklist for RFC 3501 at one
point but after looking at the issues with normative refrences I simply gave
up.

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>