Harald> did any of the technologies change because of issues that were
Harald> discovered in the discussions that were needed to clarify the
Harald> requirements and framework?
Harald> If no - why did it take any time at all to produce them?
Not sure what you mean, it always takes time to produce a document, even if
the document is just a "rock fetch".
Harald> there is little that the IESG can do when the WG knows what the
Harald> comments are and chooses not to act upon them for 2-5 months.
This reminds me of Dilbert's pointy-haired boss, who says "your project is
late, so I want you to give me hourly status reports." When we have
documents which aren't really necessary in the first place, which ultimately
will not have any impact on the technology, but which need to be massaged
and remassaged so as to get them past the IESG, I think it's quite clear
where the responsibility for the delay is coming from.
Harald> And I don't understand why WG updates to fix problems take 2-3
Harald> months per cycle when the WG thinks that it's important to be
Harald> finished with the docs.
Well, each objection from the IESG needs to be discussed and a response
Harald> is the IESG supposed to care about inconsistencies between the
Harald> requirements (which are what the *WG* thinks should be satisfied)
Harald> and the technologies that will be proposed for standardization?
Sure; but the reqs, framework, protocol specs, and applicability statements
were all ready 18 months ago. They could have been submitted as a group.
But we were told, "first you need to submit the first document, then a year
or so later you can submit the second". This is a very peculiar way to
encourage progress ;-) From the WG perspective, the specs have been ready
for review forever, but the IESG has refused to look at them because of
bogus process issues. And then they turn around and accuse the WG of making