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!