Re: Draft -16 out now

Cullen Jennings schrieb:
> ...
>> The problem here is that once we got it out of the door (WGLC-wise), 
>> almost no follow up activities happened. There *were* LC comments, and 
>> most of them haven't been acted upon.
>>
>> I spent a considerable amount of time maintaining a version of the 
>> draft  with issues and many potential resolutions, but, quite frankly, 
>> this doesn't seem to help in fixing the problems in the WG's version 
>> of the draft. I really have no idea why.
>>
> 
> I'm appreciative of the review and raising issues you do - and do 
> quickly. I view the problem as, for many of the issues, we can't get to 
> the point where more than a handful of people agree on the resolution to 
> them. More below ...

Well, as a matter of fact it seems we don't even have a handful of 
people reviewing that stuff anymore. I think that one of the reasons is 
that people just think: "what's the point?". In the last months, many 
issues have been raised, but nothing has been done. Why should people 
continue to participate if there's no sign that this leads anywhere?

> ...
>> The problem aren't things that haven't improved, but changes that 
>> actually make it worse (in some parts). For instance, I'm insisting on 
>> exact language about locking *because* the lock of clarity was a 
>> problem in RFC2518.
> 
> We have spent a huge number of hours discussing locking - I doubt that 
> more time on this is going to significantly change people from their 
> current position.

The things I was referring to are actual *bugs* in the spec. That is, 
the spec doesn't say what the consensus was.

For instance:

Issue 244: 
<http://ietf.osafoundation.org:8080/bugzilla/show_bug.cgi?id=244> (lock 
creator vs owner)

Issue 251:
<http://ietf.osafoundation.org:8080/bugzilla/show_bug.cgi?id=251> (lock 
root being a URI, not a resource)

I do agree that there are other issue with locking which will be harder 
to resolve, but just because some of the open issues are harder 
shouldn't stop us from resolving the simpler ones right away (and 
discuss the harder ones separately).

> ...
>> I would suggest to review the changes proposed in 
>> <http://greenbytes.de/tech/webdav/draft-reschke-webdav-rfc2518bis-latest.html>. 
>>
> 
> I went through every change in the version of this from a week or so ago 
> and compared them to the draft. For each one I asked myself, is this 
> critical that we fix this before publication? Is their clear consensus 
> on how this should be? is this a "typo" type change that everyone would 
> agree to and we just need to fix? For the ones that I came up with a 
> "Yes" to one of these questions, I asked Lisa to change and she did. 
> Now, I no doubt made some mistakes along the way but we have to realize 
> this document would be better finished than perfect. I tried to focus on 
> things that would cause implementers to end up creating software that 
> did not interoperate.

Well, it seems that I need to do a better job in explaining *why* many 
of these are critical, then. When I have time, I will go through the 
list myself and re-raise the issues on the mailing list then.

> The one change that did not fall into one of these categories was the 
> change around the basic with secure/TLS. You rightly pointed out that 
> change did not have consensus and was a non trivial normative change.

Thanks.

>> That document also lists open LC issues (with no proposed resolution), 
>> and any kind of constructive feedback on those would be very welcome. 
>> Alternatively, reviewing the open issue list at 
>> <http://ietf.osafoundation.org:8080/bugzilla/buglist.cgi?product=WebDAV-RFC2518-bis> 
>> would be useful as well.
> 
> I also when thought that whole list (but not the stuff that was added in 
> November) and asked similar questions. I tried to focus on issues that 
> were raised before the end of the WGLC. One of the problems with any 
> document is we can always find yet one more problem with it so I try to 
> focus on things before WGLC. I do realize that if we fine a total show 
> stopper bug at any point, we do have to deal with it. (I just had to 
> deal with a very bad bug that was found promptly after the RFC was 
> published).

Cullen, the date when something was entered into Bugzilla doesn't 
indicate when it was raised first. Keep in mind that people raised 
issues on the mailing list, not Bugzilla. The fact that they *are* in 
Bugzilla at all is because I tried to keep track of open issues in a 
systematic way.

> Once we sort out this secure network text, I want to request publication 
> of this. All complex drafts reach a point where you need to enough has 
> been done, it's not perfect, but it is worth publishing. I feel the time 
> has come for this draft (actually I think it is long past). The rate of 
> incremental improvement is approaching the limit. The time and energy 
> the WG has is small. The draft is a significant improvement over the 
> previous RFC. Publishing this does not mean we can' every publish a bis 
> draft to fix/improve the problems with this draft.

I respectfully disagree. Many parts of the current document are a mess, 
and although it fixes many issues from RFC2518, it introduces lots of 
new ones. At this stage, I think a short errata document for RFC2518 
would be much more valuable than publishing this draft.

> Once publication is requested, Ted as the AD would have the opportunity 
> to review and ask us to correct problems and it would go for IETF LC. 
> This would be another opportunity to identify any true show stopper 
> problems that absolutely needed to be fixed.
> 
> Cullen <with me chair hat on>

My experience is that comments sent during IETF Last Call aren't 
tracked, and the people submitting them frequently get zero feedback 
from the authors and the IESG (last experienced with XCAP). That being 
said, I don't think it's a good quality check for a document anymore.

Best regards, Julian

Received on Wednesday, 29 November 2006 13:00:52 UTC