Subject: Re: RFC Editor RFP Review Request

From: Bob Braden <[email-masked]>
Date: Thu, 20 Jul 2006 13:30:43 -0700 (PDT)

*> From [email-masked]  Thu Jul 20 13:20:59 2006
  *> X-Spam-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,
  *> 	RCVD_IN_BSP_OTHER autolearn=ham version=3.1.0
  *> Date: 20 Jul 2006 20:09:21 -0000
  *> From: John Levine <[email-masked]>
  *> To: [email-masked]
  *> Content-transfer-encoding: 7bit
  *> X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
  *> Cc: 
  *> Subject: Re: RFC Editor RFP Review Request
  *> List-Id: IETF-Discussion <ietf.ietf.org>
  *> X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean
  *> 
  *> >I used to use ftp all the time to access the RFCs but then it stopped
  *> >working about two months ago and messages on this list, from others
  *> >as well as me, and to the relevant e-mail address have had no effect.
  *> 
  *> That's strange.  It's always worked fine for me.  I just tried it two
  *> seconds ago and FTP retrieval from ftp.isi.edu worked just fine.  I'm

Note that the RFC Editor switched this path from ftp.isi.edu to
ftp.rfc-editor.org, some years ago.  This soon may be highly relevant,
depending upon the results of the competive bidding for the RFC Editor
function.

RFC Editor/bb

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

---

From: Allison Mankin <[email-masked]>
Date: Tue, 25 Jul 2006 12:08:10 -0700

Hi, Ray, and all,

I read the SOW earlier to check that it matched with the
draft-mankin-pub-req-10 (output of techspec), but I've now
given a read to other matters in the RFP.  

If anyone wants to discuss points from this mail other than those
specifics to the RFP, I suppose we should do so on [email-masked].

1. Some wording under Independent Submissions is still a bit 
   confusing.  2.a. states the optional presentation of the document
   to the IESG for end-run evaluation while it is in the RFC Editor's
   initial review.  2.e states the mandatory presentation which is
   called for by RFC 2026.  2.a says see 2.e.  In a non-sequential
   reading, which is possible, 2.e does not sound mandatory.  But it
   is firmly required by RFC 2026.

   [And while I have this topic:  this is not because of power
    projection for anyone, but because the WGs' labors are heavily
    invested in RFCs as an end-product, and their charters and work
    need to be consulted by their AD]

   So I'd like to suggest that 2.e be changed a little bit:
 OLD:
     Submit document to IESG for review of
     conflicts or confusion with IETF process, end runs around working
     group activities, and obvious and significant harm to the Internet

 NEW:
     As required by RFC 2026, submit document to IESG for review of
     conflicts or confusion with IETF process, end runs around working
     group activities, and obvious and significant harm to the Internet

2.
>    g. Final Editing and Publication 
>       1) Edit and publish as for IETF community documents

This publication process is not identical to IETF community documents. 
IETF has a BCP (3932) which currently specifies differences, but we're in
some debate now (expressed during the Thursday plenary in Montreal)
about its full applicability to the independent submissions.  There
should be some statement in the SOW about how the differences, such as
a boilerplate stating the nature of the independent submissions, or
a specific type of identifier within the RFC series, will be further
resolved.  How about wording like:

NEW:
       1) Edit and publish with the same steps as IETF community
          documents but with clear indications that these belong to
          an independent series.  Specifics of these indications will
          be authorized by the appropriate IETF community parties.

> h. Coordination with Other Document Streams 
>   1) Coordination with and prioritization of other document streams is the 
>       prerogative of the IAB 

I'm assuming that h.1 is not intended to cover the document differentiation
issue, but in any event, it would not do it well.  The IESG and
the BCP-approving community hasn't finished discussing (by approving a changed
BCP) a view that the IAB is now arbiter of the IETF's public messaging on
independent RFCs.  Due to independent RFC's potential close involvement with
working group RFCs, there are reasons for WG folks to really think about this.
I don't think there's any intention to affect a standards-related issue by
placing language in the RFP/contract, but we should really watch that we do not.

Allison

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 26 Jul 2006 13:30:01 +0200

I'm going to comment on Allison's original posting, since the target
is specific text changes to the RFP. (I have read the follow-ups).

>      group activities, and obvious and significant harm to the Internet

On balance I don't think the 2026 reference is needed - we will say anyway
that IETF BCPs apply as relevant. And the "harm to the Internet"
clause is plain wrong - it isn't mentioned in 2026 and is excluded
explicitly by 3932.

>           be authorized by the appropriate IETF community parties.

As was said, that is still an open discussion, so I don't think we
can specify it today.

> placing language in the RFP/contract, but we should really watch that we do not.

Indeed. On the other had, since the IAB has its oversight role, I don't see
the word 'prerogative' as out of place. It makes it clear in fact that
the prerogative *doesn't* belong to the source of funds.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Jul 2006 11:08:10 +0200

> Where will it say that IETF BCPs apply as relevant?

That is in the markup I have sent to Ray, so I hope
it will be in the next version...

---

From: Todd Glassey <[email-masked]>
Date: Thu, 27 Jul 2006 08:18:23 -0700 (GMT-07:00)

Nice Andy... bravo!

T

-----Original Message-----
>From: Andy Bierman <[email-masked]>
>Sent: Jul 26, 2006 8:23 PM
>To: todd glassey <[email-masked]>
>Cc: John C Klensin <[email-masked]>, Ted Hardie <[email-masked]>, Jeffrey Hutzelman <[email-masked]>, Allison Mankin <[email-masked]>, IETF Administrative Director <[email-masked]>, [email-masked], [email-masked]
>Subject: Re: RFC Editor RFP Review Request
>
>todd glassey wrote:
>> So let me ask the obvious thing... why is the RFP content being voted on?
>> This is a business decision in regard to services and process. Why is any of
>> it open to review inside the IETF?
>
>
>Because the lunatics want to run the asylum?  ;-)
>
>Seriously though, it seems to me that most people agree
>with us, and want to let the IAD and IESG do their jobs,
>and stop all this obsessing over every detail of our "Process".
>
>How about if we get that "quality" and "timeliness" thing
>under control before spending a lot of time agreeing on
>the 427 most important factors in selecting IETF meeting locations?
>
>(Just my $0.02.  OK, maybe it's the whole dollar :-)
>
>
>> 
>> Todd
>
>Andy
>
>
>> ----- Original Message ----- 
>> From: "John C Klensin" <[email-masked]>
>> To: "Ted Hardie" <[email-masked]>; "Jeffrey Hutzelman" <[email-masked]>;
>> "Allison Mankin" <[email-masked]>; "IETF Administrative Director"
>> <[email-masked]>
>> Cc: <[email-masked]>; <[email-masked]>
>> Sent: Wednesday, July 26, 2006 2:56 PM
>> Subject: Re: RFC Editor RFP Review Request
>> 
>> 
>>>
>>> --On Wednesday, 26 July, 2006 13:58 -0700 Ted Hardie
>>> <[email-masked]> wrote:
>>>
>>>> At 3:28 PM -0400 7/26/06, John C Klensin wrote:
>>>>> The other is that, to some readers, it appears to impose
>>>>> binding requirements on how the RFC Editor deals with input
>>>>> from the IESG, either directly (as in "if we recommend that
>>>>> this text be inserted, you must insert it or not publish") or
>>>>> indirectly (as in "if you don't follow our recommendations,
>>>>> we will see to it that your funding is cut off").  For those
>>>>> of us who believe that it is important to the Internet that
>>>>> the RFC Editor function as an independent, cooperating,
>>>>> entity rather than as a subsidiary of the IETF, that level of
>>>>> requirement is not acceptable (that consideration is the
>>>>> source of this discussion about aspects of the RFP and what
>>>>> should, or should not, be in it).  While the IETF can attempt
>>>>> to establish links to particular funding sources and apply
>>>>> leverage that way (which some of us are trying to
>>>>> discourage), it is also beyond the ability of the IETF to
>>>>> give itself the authority to impose such requirements
>>>>> directly, any more than approval of a document as an IETF
>>>>> Standard can force someone to conform to it.
>>>> I don't agree with this understanding, but I appreciate your
>>>> taking the time to clarify it.  The "imposition of binding
>>>> requirements" you cite above is, from my way of looking at it,
>>>> instead a description of how the two cooperating entities
>>>> cooperate.  Putting descriptions of that kind into the RFP
>>>> (or, rather, references to them) is useful for a potential
>>>> respondent so that know what timelines and level of external,
>>>> unpaid effort to expect from the IETF.  Other ways around this
>>>> seem to have their own headaches. For example, requiring  the
>>>> publisher of the independent stream to establish that a
>>>> document  does not inappropriately usurp an unregistered
>>>> standards-dependent  IANA  namespace or  reserved protocol
>>>> bits would otherwise take the time and talents of the
>>>> publisher's review teams.  That slows the stream or increases
>>>> costs in a different way.
>>> Then I think we are more or less on the same page.  The
>>> challenge now is to get the RFP to appropriately reflect that
>>> shared understanding.
>>>
>>>     john
>>>
>>>
>>>
>>>