Re: Draft -16 out now

(forwarding to the list, as requested by Cullen)

Cullen Jennings schrieb:
> 
> On Nov 28, 2006, at 11:17 AM, Julian Reschke wrote:
> 
>> Ted Hardie schrieb:
>>> For some reason, I am only seeing Julian's replies to Cullen; this reply
>>> is really to Cullen, but applies to the whole thread.
>>
>> Yes, there's a known issue with Cullen's emails; maybe Jim Whitehead 
>> has got an idea why they aren't reaching the mailing list.
>>
> 
> Jim and I are working on this but in the mean time, Julian or Lisa, feel 
> free to forward this to the list.
> 
>>> At 11:29 AM +0100 11/28/06, Julian Reschke wrote:
>>>> Cullen Jennings schrieb:
>>>>> Ok - I see your point. At this point, my primary goal is getting a 
>>>>> document that is better than RFC 2518 off to the IESG.
>>> I'm glad that this issue seems to have been so quickly resolved, and 
>>> I hope others
>>> can comment about whether the new text is okay.  But I think folks 
>>> should really
>>> be narrowing focus at this point.  This effort has been around for a 
>>> long time, and
>>> we agreed nearly a year ago to get this document through the last 
>>> hump and out
>>> the door.  The chair and document author both getting put on the IESG 
>>> at the
>>
>> 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 ...
> 
>>> same time pulled critical energy from the group during what should 
>>> have been
>>> its final clean-up.   Since that point, we have had only occasional 
>>> bursts of energy,
>>> and some of that has focused on areas that were not truly core to the 
>>> work
>>> (like the WEBDAV capabilities in HTML thread Jim raised--these are 
>>> interesting,
>>> but not chartered work).
>>
>> Yes.
>>
>> From my point of view, activities went away when it became clear that 
>> no matter how much work is done in categorizing the issues and 
>> discussing resolutions, none of that work made it into the WG's draft. 
>> Which, in fact, just expired a few weeks ago, so there was no 
>> "official" WG activity on the draft for over 6 months.
>>
>> As a matter of fact, I was seriously considering submitting "my" 
>> version of the draft as a private submission just this weekend, just 
>> to get things going again.
>>
>>> I believe that we have had strong consensus for a long time to 
>>> replace RFC 2518,
>>> and I think the focus at this point has to narrow to places where the 
>>> current document
>>> isn't as clear as 2518.  Given the traffic since the WGLC on -14 back 
>>> in February,
>>> I just don't see the energy to take on more at this point.  I think 
>>> putting the document
>>> in front of the larger community and acknowledging that it isn't  
>>> perfect but
>>> is a needed improvement is the way to go.
>>
>> 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.
> 
>>
>>> If the group cannot do that in a short period of time, I would have 
>>> to seriously
>>> consider closing it.  The amount of energy here would clearly not 
>>> justify a new
>>> working group; this one has continued despite that participation 
>>> level partially
>>> because of continuity and partly because of the issues in 2518.  I am 
>>> not sure,
>>> however, that there is enough energy to survive another AD 
>>> transition, and
>>> handing off to a new AD is March is a certainty.
>>> I encourage everyone to focus on the highest priority items *only* at 
>>> this point
>>> and to keep in mind that not getting this out means 2518 stays as the 
>>> standard
>>> for this.  I do not think that is anyone's interest at this point.
>>
>> 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.
> 
> 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.
> 
> 
>> 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).
> 
> 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.
> 
> 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>
> 
> 
>

Received on Wednesday, 29 November 2006 09:13:19 UTC