Re (2): Status of RFC2518Bis

Julian Reschke <julian.reschke@gmx.de> schrieb:
> Locking has been optional in RFC2518, so there shouldn't be any problem 
> whatsoever having a RFC2518bis-minus-locking going to draft. In fact 
> it'll be easier because locking is the area that needs most attention.
>
> That being said, what *is* your position regarding separating locking 
> into a separate document?
I wonder at the moment what we win by locking ?
Roughly speaking it's for avoiding collaborative workers to damage other peoples
work.
But it seems defining and implementing locks successfully is very difficult.
OTOH there is DeltaV which also is a means (Albeit more complex, but servers and
clients are coming) to avoid collaborative conflicts.
So who needs locking ? Me definitely not.
I would be happy to implement DeltaV and the underlying RFC2518 stuff without having
to implement locks.
So doing a RFC2518bis-minus-locking would be fine with me.
And whoever wants locks because he doesn't like DeltaV can work on a lock spec.
This also would help BIND, which wouldn't need to say anything about locks
anymore.
Locking has been a pain in the ass for years. So let's get rid of it in RFC2518bis !
This really could help us to make progress because many disagreements will
disappear.
Just my 2 cent without giving it a lot of thought.

Cheers, Edgar