ietf
[Top] [All Lists]

Re: 2026, draft, full, etc.

2007-11-01 23:55:03
Simon,

I'm not convinced these protocols qualify for DS status.  DS status
requires a lot, specifically that ALL features in the document have been
demonstrated interoperable, and that their normative references are DS.
I implemented IMAP and wrote
<http://josefsson.org/nnimap/buggy-imap-servers.html>, I'm pretty sure
others implementing other protocols have had similar experiences and
frustration.
  

In the case of the base IMAP there are SO many implementations that I'm
going to guess (not being fully conversant in IMAP) that the vast
majority of the base specification is well covered.  We are aware of
some interoperability issues with Calendaring, and you're probably right
on that one.  My guess is that LDAP is closer to IMAP than Calendaring. 
But what you write is even true with HTTP, which *is* DS.  There are
lots of little nits with that protocol that the community has expressed
in interest in seeing corrected.

But let me turn it around.  If ALL it takes are two or even three
implementations to demonstrate interoperability, that really says
nothing about maturity.  Take for example SNMPv3.  It was rushed through
to full standard, and yet the deployment issues remainsubstantial, and
are only now being addressed in ISMS.  And SNMPv3 is a full standard. 
[I'm not really trying to pick on v3, but to make the point that what we
have by way of markers in RFC 2026 isn't useful].

Shouldn't we instead be eliminating it entirely?
  

I'm not sure about this.  I used to think DS was useless, but it doesn't
seem actively harmful.  I think the problem is that we don't have a
replacement for it today.  If we can come up with a scheme to allow the
community to know which standards are mature and which are not, and that
scheme actually works, I think we could eliminate the DS way.  But until
that happens, I'm not sure.
  

In the case of SNMPv3, I could argue that the premature declaration was
actually harmful because it stalled development of workable solutions
that integrated security on the device.  I was specifically told that
people wanted to let the standard bake in code before allowing for any
sort of updates.  Again, I am not saying that SNMPv3 is bad, but that it
needed to continue to evolve in some areas, and was prevented from doing
so by premature ossification.  Now one could argue that this is not the
general case with our process, but we have so few examples to pick from ;-(

I like the idea that we are reviewing proposals that have been put
before us in the past (Larry Masinter's was just mentioned), and I am
hopeful that we can DEossify our own process ;-)

Eliot

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

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