Alex,
[clipped]...
Again, I was not on the IESG when PPVPN was started, however, I
think that naturally well-scoped technologies with a clear direction
in the solution space very often do not need requirements and
frameworks.
....
It seems that the VPN problem and solution spaces are large and
complex enough to warrant both requirements and framework documents.
That said, these documents do not have to be long and fat, and it
should be possible to produce an acceptable quality document within
6 months.
Regarding IESG feedback (where my piece was probably the biggest):
Predicated on the assumption that reqs/fw documents are not needed,
any feedback, whether it is from the IESG or not, will be perceived
as a rock fetch. If we assume those are useful, IESG review is part
of the process of ensuring high quality of these documents.
In fact the reason why the PPVPN wg was created is because there were
two solutions (VR and 2547) already defined with some known
*deployment* already happening. That's what motivated the ADs
to scope the WG to just standardize these two solutions which
at that time the WG was called "NBVPN" for network-based VPNs.
There was in fact no need for the framework and requirements drafts
since day one there was no objective to create the "best/optimum"
approach and the wg didn't debate at all the question
of which one is best VR versus 2547. It was pretty much left to
the market to decide.
I am pretty sure that the feedback on that was given initially
to the ADs/IESG, and I don't understand why it was ignored
(at least from my perception).
I think the chairs were just following the advice of the IESG
on that (that the framework and requirements are necessary before
any solution is considered).
If you notice the ppvpn charter included a statement
that indicates that no new protocols will be developed.
This was added because of the existence of the solutions (well
before the working group was created), and there was a feeling that
if the wg allows for new protocols, etc, the delay for getting
the solutions standardized for the providers would have been
much bigger.
It is ironic that the wg members initially
tried to address the potential technical reasons that can happen for
delaying the work but couldn't predict that the
IESG request to develop the framework and requirements drafts
are mostly the reasons for the actual delay.
And it is unfortunate that the recent ppvpn decisions just ignored
and didn't explicitly acknowledged that fact.
I think the delay situation and its impact on the
IESG decision on what to do with ppvpn wg should have taken into account
the actual history of ppvpn working group...
Hamid.