John, Support for the xml2rfc tool was discussed on the IETF mail list when Marshall Rose indicated he could no longer support the tool. Several people volunteered to maintain the tool, and they recommended the it be rewritten. That recommendation plus the realization that this tool had become critical to IETF operations resulted in the IAOC deciding to issue a public RFP for a rewrite. The Statement of Work in the xml2rfc RFP was reviewed and modified by the people on the tool-development list. You can read the discussion at: http://www.ietf.org/mail-archive/web/tools-development/current/maillist.html There was an active discussion that resulted in many changes from what was first proposed. While this wasn't the whole community I think it a good representation of the people who are interested in the xml2rfc tool. I will send you the list members off line. Also, we will use a subset of this group to review the bids. The legal services RFP was developed inside the IAOC/Trust. To be honest, I didn't see very much value in doing a community review for this. We will consider it in the future. I do note that this work was previously done without a public RFP (dating back to when Wilmer-Hale was providing the service) so I think this is a better process than what was used earlier. In the future, we will strive to give more notice to the community on planned RFPs. Bob p.s. I will forward your specific comments to tools-discuss. On Feb 19, 2011, at 8:49 AM, John C Klensin wrote: > Hi. > > This is not an attempt to derail either of these RFPs, nor is it > a formal appeal (request for review). However, these two RFPs > raise an issue that may be worth some consideration. > > The clear intent of the discussions leading up to RFC 4071/ BCP > 101, and some of text in that document, was that the IASA was to > act with maximum transparency to the community and openness to > community comment. It is especially important that substantive > decisions be open for community review and discussion before > they are made because, especially for those that are eventually > represented by contracts, there is no mechanism for review later. > > IASA has recently issued two RFPs -- for legal services and for > a reprogrammed version of xml2rfc -- with no advance indication > to the community (at least that I can find) that they were > coming or opportunity for the community to review draft > provisions. The clear expectation is that proposals will be > submitted (on a fairly short timeframe) and that the IAD and > IAOC will do whatever they do to evaluate the proposals and > establish contracts. I don't know whether that is harmful in > these particular cases, but I don't believe it is how the > community had intended that things be done. > > FWIW, community discussion might have improved at least the > XML2RFC one -- either the details of the RFP or community > confidence that it addresses/includes the right specifications. > For example, of the very large number of extensions or additions > that have bee requested over the years, the RFP selects two > (explicit line breaks in titles) and alternate anchors for > citations/references) but ignores the others. I know that the > ability to easily index and cross-reference items in bulleted > lists, to easily generate numbers for ABNF productions (rules) > and build an index of productions, to have indexing reflect > section (and other subdivision) numbers rather than page numbers > (as various RFC style guides have required for years and that > becomes particularly important as people contemplate > non-paginated output formats), the ability to properly reference > books and journal articles without resorting to odd tricks > involving seriesInfo, and better handling of widows and orphans > (especially with regard to section title-text and lists with > undented headings top my personal list, but there are certainly > others. > > In addition, one of the two extensions that was specified > involves the addition of a new format-specific directive that is > exclusive to xml2rfc, not the DTD/Schema, thereby making > equivalent processing by other, XML-standard, processors > problematic and violating the fundamental principle that generic > markup does not specify formatting. Perhaps community members > might have been able to propose design models that are more > friendly to XML principles and other tools (even I can think of > one or two). > > The two extensions that were chosen may be the most important > ones, and there may be a reason why two extensions were chosen > rather than one or five. But it seems to me that the community, > and perhaps even the text of the RFP and the proposals that will > arrive in response, would have benefited from some opportunity > for review and discussion. > > Can we at least agree to more openness about draft RFP contents > in the future? Or get an explanation from the IAOC as to why > the procedural model now seems to include issuance of RFPs > without any opportunity for community review of their > substantive provisions? > > thanks, > john > > > > > > _______________________________________________ > IAOC mailing list > IAOC@xxxxxxxx > https://www.ietf.org/mailman/listinfo/iaoc _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf