apologies for a long delay in responding.... I am not the responsible AD
for this WG, and have not been closely involved, so I may not have all my
facts straight, especially for the Time Before The ID-Tracker.....
--On mandag, juni 30, 2003 11:26:12 -0400 Eric Rosen <erosen(_at_)cisco(_dot_)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