--On mandag, juni 30, 2003 11:26:12 -0400 Eric Rosen <erosen@cisco.com> wrote:
Harald> It might have something to do with the fact that the WG has not requested that the IESG process these drafts.... if the WG has not come to consensus on asking for the drafts to be published, I'm afraid the IESG cannot do anything.
I consider this answer to be rather disingenuous.
It was; I missed the context, which I should have been aware of. Back to the arguments on requirements documents and dependencies...
The WG has not requested that the IESG process these drafts because the WG chairs have told the WG that the ADs have told them that the drafts in question cannot be submitted to the IESG until numerous other drafts that no one will ever read (requirements, framework, architecture) have been approved by the IESG. Of course, most of those numerous other drafts were completed about 18 months ago, though a few of them have now come out of the seemingly endless "IESG reviews, WG makes minor change, IESG reviews, WG change" cycle.
to be specific - are you talking about draft-ietf-ppvpn-requirements and draft-ietf-ppvpn-framework? (I couldn't find a ppvpn-architecture in the tracker). Are there others in the set?
For -requirements, the tracker shows to be first submitted for IESG evaluation on June 21, 2002 (version 04), comments sent to author on July 29, with a comment from the WG chair saying "2 months' work" on July 30, and the next mention in the tracker on February 17. Still issues with version -06; the tracker has interesting comments to read.
For -framework, the tracker shows it first submitted for IESG evaluation on June 21, 2002 (version 05). Version -08 was approved on May 23 this year.
I'll agree that these have been in the IESG spin cycle 12 months. But I won't agree that they were *completed* either 12 or 18 months ago.
And I don't understand why WG updates to fix problems take 2-3 months per cycle when the WG thinks that it's important to be finished with the docs.
So you can't honestly answer Yakov by saying "the WG hasn't asked us to process these drafts"; the answer to Yakov's question would be an explanation of (a) why all these prior drafts are really necessary, (b) why it is reasonable for such a long review cycle, and (c) why it is reasonable to delay starting to process the protocol specs until the prior specs are already on the RFC Editor's queue.
(a) did any of the technologies change because of issues that were discovered in the discussions that were needed to clarify the requirements and framework?
If yes - I rest my case.
If no - why did it take any time at all to produce them?
(b) 3-6 month cycles are not reasonable.
Unfortunately, there is little that the IESG can do when the WG knows what the comments are and chooses not to act upon them for 2-5 months. Yelling more at the people responsible (WG chairs and document editors) might have helped. But whose job is that, really?
(c) is the IESG supposed to care about inconsistencies between the requirements (which are what the *WG* thinks should be satisfied) and the technologies that will be proposed for standardization?
if yes - how can the IESG do that when the requirements are not stable?
if no - I do not understand what "WG consensus on requirements" can mean.
I think we have unanimous agreement that the PPVPN WG's framework documents have taken far too long. We probably also agree that it's rare that blame-shifting on a public mailing list improves communication.
But I think it's too simplistic to say that "the IESG is the problem".
Harald