Eric,
Looking at this from the high-level perspective...
Though I became the responsible AD for PPVPN just recently, I was
exposed to certain aspects of interaction between ADs are PPVPN WG
chairs. There was clearly a communication problem there. I believe
it's been solved and we are in a much better shape now. Trying to
investigate who said what and whose fault that was in the past will
not be pretty, so I suggest we don't go there. One thing I can say
for sure is that we (IESG) don't say things like "first you need to
submit the first document, then a year or so later you can submit
the second."
Regarding requirements and framework documents being "rock fetching"
in general:
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. If the problem space is reasonably big and/or there are
multiple possible solutions that address seemingly identical
problems, clearly documented requirements may help the IETF decide
whether different solutions represent major approaches providing
different coverage of the problem space (and hence satisfying
requirements of different subsets of customers) and thus make sense
to be progressed in parallel as independent technologies.
Requirements may also help the SP decide which technology to deploy
in their networks by checking how requirements important to them are
addressed in each technology.
A framework document seems to be a good idea when the technology is
composed of multiple pieces that are not obviously related to each
other and/or the relationship aspects among them are not clearly
visible.
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.
Regards,
--
Alex
http://www.psg.com/~zinin/
Monday, July 7, 2003, 1:19:35 PM, Eric Rosen wrote:
Eric>> Not sure what you mean, it always takes time to produce a document,
Eric>> even if the document is just a "rock fetch".
Harald>> sorry; "rock fetch" is beyond my scope of American idiom.
"Rock fetch": when the "boss" sends the workers out on useless but
time-consuming tasks.
Harald>> But version -01 of the framework document is dated July 19, 2001,
Harald>> and the first version submitted to the IESG is dated February 15,
Harald>> 2002.
About six months to get the WG to agree on the framework, that doesn't seem
excessive for a document. It's a rock fetch though because there is no real
need for a framework document.
Harald>> I took that as a hint that there might have been controversy in the
Harald>> working group about it.
It was never a very controversial document. My recollection is that
framework and requirements were ready about January of 2002, which is why I
said that they were ready about 18 months ago. So were the protocol specs,
applicability statements, etc.
Eric>> Well, each objection from the IESG needs to be discussed and a
Eric>> response crafted.
Harald>> which should take approximately 3 days of work, IMHO. Comments that
Harald>> translate to "you are referencing an obsolete version of LDAP"
Harald>> should take approximately 2 minutes to fix.
Comments which were received last fall (I first saw them a few weeks prior
to the Atlanta IETF meeting) required a considerable reworking of the
document. (Sisyphus comes to mind here ;-))
Harald>> Did the WG declare consensus on all those documents 18 months ago
Harald>> (January 2002)?
The WG was told by the WG chairs that the IESG would not allow the WG to
even consider the solutions documents until the framework and requirements
documents were approved by the IESG. Something is very wrong with the
process here.
The L3VPN protocol specs themselves haven't changed in years, which is a
good thing, given the large amount of interoperable deployment by multiple
vendors!