Subject: [INDEP] individual/independent/direct (was: Workload management)

From: "Robert Sayre" <[email-masked]>
Date: Fri, 9 Jun 2006 20:00:37 -0400

Brian Carpenter wrote:
> Joe Touch wrote:
>
> >The RFC-Editor queue shows 8 non-WG standards-track docs,
>
> None of which, *by definition*, are independent submissions.
> They are direct submissions to the IESG, as allowed by RFC 2026,
> and are in scope for draft-mankin-pub-req but not for
> draft-klensin-rfc-independent.
...
> That being said, could we talk about the issues of principle?

Yes, "direct submissions" are allowed by RFC 2026. What makes them
substantively different from independent submissions in your mind? As
a whole, I don't think one could say the AD-shepherded drafts are
higher-quality or reflect IETF consensus, so they seem to reflect
individual connections and influence. That's OK. That's how the world,
including the IETF, works. When standards bodies take that too far,
their reputation suffers.

I'm missing a problem statement from the IETF chair and/or IESG. Other
documents I've read indicate that the IESG would like more control of
the RFC series. The Klensin document seems to propose they should get
a little less control than they have now, and I haven't the foggiest
idea of who doles out the authority.

Do you think the current arrangement is problematic? Have you seen
evidence of "end runs" on the IETF process?

-- 

Robert Sayre

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

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Mon, 12 Jun 2006 11:20:30 +0200

> evidence of "end runs" on the IETF process?

I may misinterpret your question, but the purpose of the whole  
exercise is to document the submission streams for RFCs. This is all  
done in order for the IASA to be able to carry out an RFP[1]. On this  
particular list we discuss the independent submissions process.  
Klensin's document is closest to what we have describing the current  
process. In my opinion it is not the intention to overhaul what is  
being done now. But while we are documenting the process we may find  
places where clarification or improvements seem in order.

This list is supposed to attract the stake holders for the  
independent submission track; a wider audience than the IETF. Based  
on the consensus discussion on this list the IAB plans to publish a  
document, probably evolved out of Klensin's document, that describes  
the general policy followed by the RFC editor for independent  
submissions (cf rfc2850).

As for the "who doles out the authority" question. I hope this  
answers: "The RFC Editor [...] operates under the general direction  
of the IAB." [2].

I hope this clarifies.

--Olaf

[1] http://www1.ietf.org/mail-archive/web/ietf-announce/current/ 
msg02524.html
[2] http://www.rfc-editor.org/DOCUMENTS/purpose.html

-----------------------------------------------------------
Olaf M. Kolkman
NLnet Labs
http://www.nlnetlabs.nl/

---

From: John C Klensin <[email-masked]>
Date: Mon, 12 Jun 2006 09:27:26 -0400

--On Monday, 12 June, 2006 11:20 +0200 "Olaf M. Kolkman"
<[email-masked]> wrote:

>> I'm missing a problem statement from the IETF chair and/or
>> IESG. Other documents I've read indicate that the IESG would
>> like more control of the RFC series. The Klensin document
>> seems to propose they should get a little less control than
>> they have now, and I haven't the foggiest idea of who doles
>> out the authority.
>> 
>> Do you think the current arrangement is problematic? Have you
>> seen evidence of "end runs" on the IETF process?
 
> exercise is to document the submission streams for RFCs. This
> is all  done in order for the IASA to be able to carry out an
> RFP[1]. On this  particular list we discuss the independent
> submissions process.  Klensin's document is closest to what we
> have describing the current  process. In my opinion it is not
> the intention to overhaul what is  being done now. But while
> we are documenting the process we may find  places where
> clarification or improvements seem in order.

And, indeed, my document proposes some small changes and
clarifications from current procedures, mostly in the hope of
creating a more open and cooperative arrangement with more
opportunity for IAB and community input (to the extent that they
want more input in practice).

> independent submission track; a wider audience than the IETF.
> Based  on the consensus discussion on this list the IAB plans
> to publish a  document, probably evolved out of Klensin's
> document, that describes  the general policy followed by the
> RFC editor for independent  submissions (cf rfc2850).
> 
> answers: "The RFC Editor [...] operates under the general
> direction  of the IAB." [2].

Just to get a stake in the ground on this, and at the risk of
reiterating what I take to be one of the points Mike St. Johns
has been trying to make on the IETF list...

It is my belief that the RFC Editor has always (since long
before the post-Kobe changes) "reported to" the IAB, but within
the definition of "reported" that involves periodically telling
the IAB what is going on and having discussions of status,
priorities, and strategy when appropriate.  I believe the RFC
Editor has generally followed advice from the IAB, but that they
have done so because that advice has been sensible and
representative of the community, rather than because the IAB has
special power.  

With regard to "authority" and independent submissions, the IAB
has only one source of power wrt the RFC Editor and that is to
go to ISOC and say "please cut off their funding until they do
what we say".  That would be a very unfortunate state to reach
from all possible perspectives: ISOC is not, as far as I can
tell, obligated to follow that advice and, were ISOC to do so,
there is some possibility of a campaign being started with some
of the ISOC members to the effect that the IETF had finally
passed all limits of propriety and no longer deserved high
levels of funding.  Of course, if ISOC failed to comply with
such a request from the IAB, it would presumably be harmful to
IETF-ISOC relations.    No matter how that worked out, everyone
would lose.

So my draft was written, not in the spirit of figuring out who
controlled whom, but on several assumptions outlined below.  The
overview document, draft-iab-rfc-editor..., necessarily has a
somewhat different tone (since it is intended specifically as
input to a contracting process), but my hope is that the IAB
shares those assumptions.

The assumptions are, approximately...

	* both the current RFC Editor organization and the IAB
	(and broader Internet community) have the same basic
	goals for review and publication of independent
	submissions
	
	* the ISI-based RFC Editor staff want to do what is best
	for the Internet community and will do whatever is best
	for the community.  In particular, I believe that if the
	RFC Editor staff were convinced that some functions now
	being performed internally to ISI or under their
	supervision would better serve the community if handled
	in some other way, they would actively cooperate in
	facilitating the appropriate changes.
	
	* clarity about procedures and criteria is almost
	always in the best interests of all concerned.
	
	* if there were differences of opinion about either
	review processes or what materials were appropriately
	published, those differences can and should be resolved
	by mutual discussion and understanding, rather than
	trying to figure out who is in charge.

All of the distinctions that those assumptions imply are much
more closely bound to the independent submission function of the
RFC Editor than to the "publisher of IETF-approved materials"
one.  Whether or not it would be wise, the IETF clearly has the
ability to appoint anyone it likes at "IETF Technical
Publisher".  It is presumably not an accident that the Techspec
effort and document use that term.  It is certainly not an
accident that the independent submission document deliberately
uses the term "RFC Editor"

I fear that, if any of the groups or people involved here decide
to turn this effort into a fight over authority rather than a
cooperative effort to figure how best to move forward to serve
the community, we will all lose.  I hope and trust that can be
avoided and that we can move forward in the spirit of working
out, together, what is best to be done and then execute on
whatever model comes out of that process.

     john

> [1]
> http://www1.ietf.org/mail-archive/web/ietf-announce/current/
> msg02524.html

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 12 Jun 2006 15:41:15 +0200

Robert Sayre wrote:
> individual connections and influence. 

I'm sorry, but no. There is of course a risk that a document that
has not been through WG discussion gets less community review, which
is why RFC 2026 calls for a double-length IETF Last Call. But such
documents do get full review by the IESG and by whichever specialist
or generalist reviewers the ADs choose to consult. No doubt
authors who know the IETF well, and therefore know the shepherding
AD personally, find it easier to pull the various levers that have
to be pulled, but that doesn't justify your allegation.

> That's OK. That's how the world,

For what follows, see Olaf's response.

     Brian

---

From: Michael Richardson <[email-masked]>
Date: Mon, 12 Jun 2006 18:48:25 -0400

>>>>> "Olaf" == Olaf M Kolkman <[email-masked]> writes:
    Olaf> discuss the independent submissions process.  Klensin's document is closest
    Olaf> to what we have describing the current  process. In my opinion it is not the
    Olaf> intention to overhaul what is  being done now. But while we are documenting
    Olaf> the process we may find  places where clarification or improvements seem in
    Olaf> order.

  Is it in scope to narrow the scope of what is possible to what is
actually done?
  i.e. the RFP shouldn't ask for things we actually never do, even if we
can. (No, I don't have an example)

- -- 
]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] [email-masked]      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

    "The Microsoft _Get the Facts CD_ does not work on Linux." - orospakr