Subject: xml2rfc and legal services RFPs

From: John C Klensin <[email-masked]>
Date: Sat, 19 Feb 2011 11:49:01 -0500

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

---

From: Bob Hinden <[email-masked]>
Date: Mon, 21 Feb 2011 11:23:28 -0800

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:

> _______________________________________________
> IAOC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/iaoc

---

From: John C Klensin <[email-masked]>
Date: Mon, 21 Feb 2011 15:20:12 -0500

--On Monday, February 21, 2011 11:23 -0800 Bob Hinden
<[email-masked]> wrote:

> 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.
>...

Bob,

Thanks for the reply.  Let me stress again that, even where I
might have a different opinion on some matters, I do not
question the IAOC's right to consult whomever (or whatever
lists) it thinks appropriate in  the process of developing draft
RFPs or draft SOWs.

I have opinions about the process used too, but they aren't very
significant.  For example, I note, in conjunction with your
comment...
 
> 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.

that there are 18 people on that list.  Unless I'm miscounted,
of the 18, 7 are AMSL or IETF professional staff, two more are
ISOC professional staff, and 5 (not counting overlaps) are IAOC
and/or IESG members.  This isn't quite the composition I would
have chosen for a group I expected to be representative of
either the broader IETF community or the community of active
writers of I-Ds.  But, again, that isn't the point, IMO.

>...

Perhaps I'm the only member of the community who cares any more.
If I am, maybe you should just ignore this.  But I believe that
the intent of the community at the time BCP 101 was written was
that the IAOC should not just be providing "notice" (although
that is desirable), or the opportunity to participate in the
specification-development process or watch it unfold (although I
think that would be desirable too), but that you post the text
of proposed RFPs for community comment.   Most of the time,
those comments won't yield anything.  But, just like Last Call
on standards track documents, exposure of a draft that is
believed to be finished to the community might turn something up
that the development process (no matter how good) didn't catch.
That "something" might be substantive; it might even be a detail
of specification style that was somehow overlooked.  As we all
known, this is a rather diverse community with a broad
collection of skills and experience that will never be
completely reflected in a small draft development or review
group, no matter how carefully chosen.  When it occurs, that is
valuable.  Even when it does not occur, it helps us all
understand that the IASA is operating as openly and
transparently as I think we all desire.

 best,
   john

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 22 Feb 2011 09:40:14 +1300

Bob,

On 2011-02-22 08:23, Bob Hinden wrote:
> 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:
> 
> members off line.  Also, we will use a subset of this group
> to review the bids.

I think the tools development list was a good venue for the
detailed discussion. Was the process mentioned on tools-discuss
too? (I dropped off that one a while back, due to lack of
cycles, but it does seems the obvious place, not to mention the
xml2rfc list, where I don't recall it being mentioned).

> 
> 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.
> 

I think that is appropriate, given the comments in BCP 101
about transparency. But I agree that for legal services, our
community doesn't particularly have the skills to wordsmith
an RFP.

   Brian

>> 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.
>> 
>> 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.
>> 
>> 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 [email-masked] 
> _______________________________________________ Ietf mailing
> list [email-masked] https://www.ietf.org/mailman/listinfo/ietf
> 
>

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 21 Feb 2011 15:18:54 -0600

For what it's worth,

I agree that when you're talking to the community about RFPs, it's great if 
that doesn't turn into a wordsmithing exercise on the ietf mailing list,

And I agree that providing a list of things that lawyers have already done 
for us is a very reasonable basis for an RFP about what we expect lawyers to 
do for us,

But I do think posting draft text does allow you to say "and the community 
saw this" if you guys get any pushback at all...

Thanks,

Spencer

> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: Doug Barton <[email-masked]>
Date: Mon, 21 Feb 2011 13:30:08 -0800

> Perhaps I'm the only member of the community who cares any more.

Nope, I'll give a +1 to that as well.

I don't have anything intelligent to say about either RFP, but I'm more 
concerned about the fact that the IAOC thought that releasing them 
without wider community review was something that the community would 
accept and/or tolerate. I first grew concerned about this with the 
"network registration" donnybrook at the China IETF. I didn't speak up 
then because I wasn't there, didn't know the details, and figured that 
based on the response from both the community and the IAOC that it was a 
lesson learned.

For future reference, erring on the side of more communication with the 
community is probably the right way to go, regardless of how 
inconvenient it may be.

Doug

-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/

---

From: [email-masked]
Date: Mon, 21 Feb 2011 16:43:21 -0800 (PST)

> community is probably the right way to go, regardless of how

+1

				Ned

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Tue, 22 Feb 2011 10:25:11 -0500

> From: [email-masked] On Behalf Of Bob Hinden [[email-masked]]
> 
> The Statement of Work in the xml2rfc RFP was reviewed and modified
> by the people on the tool-development list.  [...]
> 
> 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.

Yeah, and the features list for the next version of MS Word will be
decided by polling the MS Word developers.

You need to poll the *users* of the tool, not the *developers* of the
tool, to find out what is needed.

Dale

---

From: Julian Reschke <[email-masked]>
Date: Tue, 22 Feb 2011 16:42:48 +0100

> tool, to find out what is needed.

Both, actually.

That being said: do you have specific suggestions? How about posting 
them to the xml2rfc mailing list?

Best regards, Julian

---

From: Russ Housley <[email-masked]>
Date: Tue, 22 Feb 2011 10:54:00 -0500

> tool, to find out what is needed.

The xml2rfc tool was declared critical to the IETF because of the use by the RFC Production Center.  The volunteers that stepped forward to maintain the code when Marshall Rose declared that he was finished recommended the rewrite.  Therefore, the things that the enhancements proposed by the RFC Production Center have priority, but the entire community will benefit from a tools that is easier to maintain and enhance.

Russ

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Tue, 22 Feb 2011 10:55:41 -0500

________________________________________
From: Russ Housley [[email-masked]]

The xml2rfc tool was declared critical to the IETF because of the use by the RFC Production Center.
________________________________________

Not because a large fraction of the draft authors use it?

Dale

---

From: Russ Housley <[email-masked]>
Date: Tue, 22 Feb 2011 11:05:57 -0500

> The xml2rfc tool was declared critical to the IETF because of the use by the RFC Production Center.

Yes and no.  If so many authors we not using it, then xml2rfc would not be important to the RFC Production Center.  There are many tools used by I-D authors, including nroff/troff/groff, NroffEdit, MS Word templates, LaTex, and a plethora of editors.  The IETF cannot take on every tool that seems popular.  In this case, the RFC Production Center will become more effective, and that represents a return on the investment, and it will also help many I-D authors.

Russ

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 22 Feb 2011 11:15:50 -0500

On 2/22/2011 11:05 AM, Russ Housley wrote:
>  There are many tools used by I-D
> authors, including nroff/troff/groff, NroffEdit, MS Word templates, LaTex,
> and a plethora of editors.  The IETF cannot take on every tool that seems
> popular.

Isn't the statistic of xml2rfc use somewhere around 50-60%?

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Russ Housley <[email-masked]>
Date: Tue, 22 Feb 2011 11:18:04 -0500

> Isn't the statistic of xml2rfc use somewhere around 50-60%?

Roughly half.  Again, that is why there is a value to the RFC Production Center.

Russ

---

From: Ole Jacobsen <[email-masked]>
Date: Tue, 22 Feb 2011 09:33:33 -0800 (PST)

On Mon, 21 Feb 2011, Doug Barton wrote:

> I don't have anything intelligent to say about either RFP, but I'm 
> more concerned about the fact that the IAOC thought that releasing 
> them without wider community review was something that the community 
> would accept and/or tolerate. I first grew concerned about this with 
> the "network registration" donnybrook at the China IETF. I didn't 
> speak up then because I wasn't there, didn't know the details, and 
> figured that based on the response from both the community and the 
> IAOC that it was a lesson learned.

For the record: THe network registration was announced BEFORE 
Maastricht and tested there, not in China. So, your statemenet is 
highly misleading. There were plenty of comments etc one whole meeting 
cycle ahead of time.

If you are talking about the badge checking in Beijing, that's another 
matter, but also not an IAOC policy matter that was "planned".

> Doug

Ole J. Jacobsen 
Editor and Publisher,  The Internet Protocol Journal
Cisco Systems
Tel: +1 408-527-8972   Mobile: +1 415-370-4628
E-mail: [email-masked]  URL: http://www.cisco.com/ipj

---

From: Doug Barton <[email-masked]>
Date: Tue, 22 Feb 2011 10:43:19 -0800

> matter, but also not an IAOC policy matter that was "planned".

That is what I was talking about, yes. Sorry the 2 things got conflated 
in my mind. And in fairness to the IAOC, as I pointed out previously 
without knowing all the details of that incident I didn't feel 
comfortable speaking out about my concerns at the time. Looking back now 
it _seems_ to have been a step on the slippery slope.

... but even if I'm still totally wrong about that, the current 
situation (publishing the RFPs without wider community input) is 
definitely in the category of "needs feedback."

Doug

--

---

From: "J.D. Falk" <[email-masked]>
Date: Tue, 22 Feb 2011 10:44:31 -0800

On Feb 21, 2011, at 1:18 PM, Spencer Dawkins wrote:

> For what it's worth,
> 
> I agree that when you're talking to the community about RFPs, it's great if that doesn't turn into a wordsmithing exercise on the ietf mailing list,
> 
> And I agree that providing a list of things that lawyers have already done for us is a very reasonable basis for an RFP about what we expect lawyers to do for us,
> 
> But I do think posting draft text does allow you to say "and the community saw this" if you guys get any pushback at all...

+1

The same process internet-drafts go through, right?  Or as close as makes sense.

--
J.D. Falk
the leading purveyor of industry counter-rhetoric solutions

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 22 Feb 2011 12:55:49 -0600

Hi, J.D.,

>> But I do think posting draft text does allow you to say "and the 
>> community saw this" if you guys get any pushback at all...
>
> +1
>

If "process" means "a chance for the community to look and comment before 
it's too late", yes, exactly.

That's what we do for Internet Drafts, and it's almost certainly easier to 
make a contract that's in effect go away, than to make an RFC go away :D

My sense is that the community is trained to back off (not completely, but 
at least significantly) when told "yeah, and the working group considered 
that", "yeah, and the NomCom considered that", or even "yeah, that came up 
in IETF Last Call", and the IAOC might benefit if they could make the same 
point about RFPs.

Thanks,

Spencer

---

From: Julian Reschke <[email-masked]>
Date: Wed, 23 Feb 2011 10:46:52 +0100

> Roughly half.  Again, that is why there is a value to the RFC Production Center.

Can the RFC Production Center remind us about what the actual numbers 
are, and also whether they ever generate an XML version if the authors 
didn't supply one?

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 23 Feb 2011 11:09:54 +0100

> are, and also whether they ever generate an XML version if the authors

I just realized that I have an archive of XML versions of RFCs in AUTH48 
state; so I *can* report the percentage of XML versions since ~RFC5000.

Note that these may be inaccurate (for instance, not all RFC numbers get 
assigned, right?); it just observes how much XML files ended up in AUTH48.

Here are the numbers:

RFC5000 - RFC5099: 41
RFC5100 - RFC5199: 44
RFC5200 - RFC5299: 47
RFC5300 - RFC5399: 48
RFC5400 - RFC5499: 64
RFC5500 - RFC5599: 59
RFC5600 - RFC5699: 58
RFC5700 - RFC5799: 64
RFC5800 - RFC5899: 63
RFC5900 - RFC5999: 68
RFC6000 - RFC6099: 69

Best regards, Julian