Subject: Re: I-D ACTION:draft-alvestrand-ipod-01.txt

From: Dave Crocker <[email-masked]>
Date: Thu, 18 May 2006 19:27:03 -0700

[email-masked] wrote:
> 	Title		: IETF Operational Notes
> 	Author(s)	: H. Alvestrand
> 	Filename	: draft-alvestrand-ipod-01.txt
> 	
> This document describes a new document series intended for use as a
> repository for IETF operations documents, which should be more
> ephemeral than RFCs, but more referenceable than internet-drafts, and
> with more clear handling procedures than a random Web page.
>   

This proposal considers using all of the existing mechanisms, except the
one that seems most appropriate:  BCPs.

New publication mechanisms incur incremental overhead.

Why is it not sufficient to have the operational notes be published as
BCPs? What problem is this solving and is it really that important to
the IETF?

d/

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

---

From: Dave Crocker <[email-masked]>
Date: Thu, 18 May 2006 19:27:03 -0700

d/

---

From: John C Klensin <[email-masked]>
Date: Fri, 19 May 2006 07:48:55 -0400

--On Thursday, 18 May, 2006 19:27 -0700 Dave Crocker
<[email-masked]> wrote:

>> This document describes a new document series intended for
>> use as a repository for IETF operations documents, which
>> should be more ephemeral than RFCs, but more referenceable
>> than internet-drafts, and with more clear handling procedures
>> than a random Web page.
>>   
> 
> This proposal considers using all of the existing mechanisms,
> except the one that seems most appropriate:  BCPs.
> 
> BCPs? What problem is this solving and is it really that
> important to the IETF?

Dave,

I wonder if we are reading the same document.  While the
comments below highlight the differences from BCPs that seem
most important to me, it appears to me that these differences,
and others, appear fairly clearly in section 5 of the I-D.

(i) BCPs are, by precedent and as provided for by 2026,
published by the RFC Editor, formatted as RFCs, and go through
standard RFC processing, albeit with the BCP designation.  These
documents are published by the secretariat, using mechanisms
determined from time to time by the IESG.   Presumably, that
change in mechanism permits nearly-immediate publication of
changed "ION" documents, which would serve the community much
better than the opportunity to wonder whether the current
published document or some approved I-D is actually in effect.

(ii) While BCP numbers move from one RFC to another as content
is updated, these documents do not have archival designation or
numbers.  Personally, that scares me a little bit: I would
prefer to see these documents numbered or designated in a way
that makes version identities absolutely clear.  The I-D sort of
suggests that, but is insufficiently specific to know for sure
(see below).

(iii) BCPs are constrained to a rather specific approval process
involving Last Call and community consensus.  IONs are permitted
to be approved and published by the IESG alone, or other bodies
designated by the IESG, thereby sweeping up a variety of IESG
statements and assorted conventions that are now carried around
as semi-permanent I-Ds or random web pages.   While one can
debate the approval system, it is clear to me that having IETF
procedural materials for which people are held responsible
gathered together into a single document series and place is an
improvement.

I have two concerns about this document and the way in which it
is being processed.  For everyone's convenience, I'll put them
into a separate note.

    john

---

From: Dave Crocker <[email-masked]>
Date: Fri, 19 May 2006 08:40:37 -0700

John C Klensin wrote:
> I wonder if we are reading the same document.  

We are.  But you read it rather carefully than I...

> While the

What I noted in section 5 was that the first part listed existing 
choices and the second part listed reasons not to use them, notably 
missing reference to BCPs.  what I missed was that the first part 
included some cryptic dismissals of existing mechanisms, too.

The reasons the document offers for not using BCP status are:

      1.  usually a great deal of debate and effort to change
      2.  bind up editing resources in the final edit stage
      3.  as well as being limited (in practice) to ASCII
      4.  not available for Info documents
      5. "updates/obsoletes" ...can also be quite confusing to follow

Does anyone think that the new mechanism will not suffer #1 and #2?

#3 is a universal issue; if anything, IETF process documents need more powerful font and 
graphics capabilities less than our more interesting technical specifications, so it is 
difficult to guess why this new mechanisms warrants a new formatting convention.

#4 is the interesting objection, because it appears to have real substance.  However 
the new series is for operations documents, not "informational" ones.

#5 implies that the updates/obsolets mechanism is generally problematic, but I do not 
recall hearing about this before.  Is there some undercurrent of community dissatisfaction 
with it?  

On reflection, the proposal could easily be taken as intended to begin an end-run around the RFC 
editor process. If indeed the RFC Editor process is problematic for IETF documents, then we
need to worry about it more for our primary output than our internal process documents.

And, by the way, the premise of the proposal is that we need to be more agile in being able to 
produce process documents.  

As if producing new and different process documents is somehow a current problem in the IETF???

d/

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 19 May 2006 11:16:46 -0500

I can't promise that the best is always the enemy of the good, but I think 
that ION is at least good, and worry that making it much better will not 
help us any time soon.

To pick one example - one might hope that working group chairs and document 
authors would be aware of current IESG practices on DISCUSSes ("why would 
this be wrong?"). The IESG (past and present members) have graciously 
written down what those practices are. Starting now, can you find them? and 
how long did it take?

When *I* was looking for them last week, I checked the IESG web page, where 
they are NOT listed (duh), and then did the I-D database search for "iesg 
DISCUSS". That works (sort of), and I can make the simplifying assumption 
that the current practices are reflected in the current draft (note that 
this is a stretch, because there are long-lived "drafts" that haven't been 
submitted as I-Ds for a while, so maybe I even found the current ones).

It is slightly more challenging to tell someone (in, say, the Working Group 
Leadership tutorial) where to find them in six months.

(Just FYI, the DISCUSS criteria ARE currently llisted on the IETF Chair web 
page, but that's not the first place I might look for the *IESG* criteria, 
and they don't have any author or date listed, so it's something of a pain 
to figure out if this IS the same version of the criteria that's in the 
draft.)

So, I'm worried that we are going to glue up ION in every discussion we've 
(sort of) had in Newtrk before anyone can find anything. Versioning and "who 
approves" were great time sinks for ISD/SRD discussions. Let's not have them 
again while discussing ION.

What I liked about Dave's note below is that it does point out that there 
are concerns about ION that are also more general concerns. My suggestion is 
that we focus on the ION-specific concerns (like, who approves them, and 
whether the IESG has time to flesh the idea out or not), and punt version 
tracking and updates/obsoletes back to Newtrk, where these concerns belong 
because, once again, I have found a working group draft that refers to TCP 
as "RFC 793", so I would really like to solve these concerns more generally, 
so that we stop standing oun our own shoelaces.

And, just to follow up on John's note - it is not necessary for the current 
ADs to figure out every detail of the experiment in order to run the 
experiment. We have a large number of recently-serving ADs, and the process 
hasn't changed THAT much since March, in addition to other people who could 
help flesh out the details. I agree that the IESG has to be OK with the 
details of the experiment at some point, but this doesn't have to be the 
sinkhole that it could be, if the current IESG are looking at each other in 
a room with no outside assistance. AD time and attention are precious.

Thanks,

Spencer

> What I noted in section 5 was that the first part listed existing choices 
> and the second part listed reasons not to use them, notably missing 
> reference to BCPs.  what I missed was that the first part included some 
> cryptic dismissals of existing mechanisms, too.
>
> #3 is a universal issue; if anything, IETF process documents need more 
> powerful font and graphics capabilities less than our more interesting 
> technical specifications, so it is difficult to guess why this new 
> mechanisms warrants a new formatting convention.
>
> #4 is the interesting objection, because it appears to have real 
> substance.  However the new series is for operations documents, not 
> "informational" ones.
>
> #5 implies that the updates/obsolets mechanism is generally problematic, 
> but I do not recall hearing about this before.  Is there some undercurrent 
> of community dissatisfaction with it?
>
> On reflection, the proposal could easily be taken as intended to begin an 
> end-run around the RFC editor process. If indeed the RFC Editor process is 
> problematic for IETF documents, then we
> And, by the way, the premise of the proposal is that we need to be more 
> agile in being able to produce process documents.

---

From: John C Klensin <[email-masked]>
Date: Fri, 19 May 2006 12:38:21 -0400

Dave,

I think one can like, or dislike, this proposal.  My first
objective was to make sure we were complaining about what was
there/ intended, rather than what wasn't.  It is not the best
document I've ever seen wrt specifics and explanation
(including, I imagine, some of what you describe as "cryptic"),
but, to some degree, that is part of the point.  Specific
comments below...

--On Friday, 19 May, 2006 08:40 -0700 Dave Crocker
<[email-masked]> wrote:

>...

For #1, it removes the requirements for Last Call and
demonstration of community consensus that apply to BCPs.   If I
were advising the IESG, I'd suggest that there were many
documents that would fall into this category for which the right
procedure would be to expose a draft, announce intent to
publish, wait two weeks (or some other short period), and do it.
I.e., we would shift, for some of these materials, to more of a
"take action and back away if the community finds problems"
approach, rather than the BCP pattern.   There are issues in
knowing which things should be handled that way and which ones
should still get BCP-equivalent processing (see my other note
about the issue of specifics and this proposal), but I note
that, if all policy documents were handled according to this
outline, it would eliminate the "IESG makes decision, quietly
puts up a document without telling anyone, then yells 'gotcha'
when anyone violates one of those rules".   I think the IESG is
moving away from that approach, which is good; anything that
reinforces that trend is, IMO, very good.

For #2, this gives the IESG the ability to figure out when
something is "good enough", post it, and tune as needed.   That
is a very different model from the RFC Editor's determination to
have all documents be of uniform high editorial quality and of
archival quality and stability.  I think that separation is also
a benefit... see below.

># 3 is a universal issue; if anything, IETF process documents
># need more powerful font and graphics capabilities less than
># our more interesting technical specifications, so it is
># difficult to guess why this new mechanisms warrants a new
># formatting convention.

Part of the reason for the ASCII focus on RFCs (and RFC
Editor-published archival documents should we ever invent other
kinds) is that they need to be archival.  Historically, methods
for providing  more powerful fonts, graphics, etc., is that they
get tied to software that doesn't stand the test of time
(whether we have gotten past that with PDF is the subject of a
different conversation).   These documents are not archival and
hence not subject to the same constraints.  That said, if the
only reason for this was more flexibility about formatting and
presentation, I'd be violently opposed to it -- just not work
the marginal effort of doing something different.

># 4 is the interesting objection, because it appears to have
># real substance.  However the new series is for operations
># documents, not "informational" ones.

But we are publishing tools documents and similar things as
informational now, if we publish them at all.

># 5 implies that the updates/obsolets mechanism is generally
># problematic, but I do not recall hearing about this before.
># Is there some undercurrent of community dissatisfaction with
># it?  

For procedural materials, I think "yes".  One example is what it
takes to figure out what our procedures actually are, given the
number of things that have updated, modified, or fine-tuned RFC
2026.

> On reflection, the proposal could easily be taken as intended
> to begin an end-run around the RFC editor process. If indeed
> the RFC Editor process is problematic for IETF documents, then
> we

Interestingly, I'd argue exactly the opposite.  As another
recent thread points out, the RFC Editor's special expertise is
in the vetting, editing, and publishing of technical, archival,
documents.  These documents are neither.  Getting them out of
the RFC Editor's processing queue could free up resources that
would be better spent on our primary output materials.  If that
sped those up, even a little bit, it would be, I think, a net
gain.  And certainly separating IETF procedural documents from
the RFC process is not an end run around what other documents
call the "technical publisher" role associated with the RFC
Editor.

> And, by the way, the premise of the proposal is that we need
> to be more agile in being able to produce process documents.  

I think maybe it is, at least if part of our goal is to have our
processes described in some coherent and accessible way.

Is this the highest priority I can imagine?  No.  But I find the
arguments for separating this work from the more technical
publications that the RFC Editor handles and putting it under
the more direct control of the IESG and Secretariat seem to me
to be, on balance, constructive and time-saving steps.

      john

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 21 May 2006 21:45:41 +0200

>reinforces that trend is, IMO, very good.
For documents that the community does not see before approval, there 
will obviously be no delay in publication because of public discussion.
Some IONs will be appropriate for such processing. Some will not be.

>archival quality and stability.  I think that separation is also
If the published document is identical to the approved document, there 
is no post-approval editing.

>the marginal effort of doing something different.
Today's practice is that several of the documents that could qualify for 
the ION series are published as HTML (web pages) - sometimes as the 
output of the "note" variant of xml2rfc. I did not want to force what 
some people would think of as a step backwards on those documents.

>informational now, if we publish them at all.
What I was getting at was that an Info document (like the IESG charter, 
or the RFC Editor's instructions to authors) has no stable identifier 
except its current RFC number. If there is a new version, there is no 
stable identifier that will continue to point to the "current" version.

>call the "technical publisher" role associated with the RFC
I'll happily leave the discussion of RFCs to Techspec. My intention was 
to get something done about operational notes, not to change the RFC series.

>to be, on balance, constructive and time-saving steps.
IONs are not a very big deal. But unlike some of our other problems that 
need solving, it seems to be possible to make things a little bit better 
in this area.

And after running the experiment for 12 months, we *might* know more 
about how it works.

                           Harald

---

From: Dave Crocker <[email-masked]>
Date: Mon, 22 May 2006 07:47:41 -0700

> demonstration of community consensus that apply to BCPs.   

In other words, these are IESG Operational Notes, not IETF Operational Notes.

d/

---

From: John C Klensin <[email-masked]>
Date: Mon, 22 May 2006 12:02:29 -0400

> In other words, these are IESG Operational Notes, not IETF

Some of them certainly are.  Some of them aren't what I would
describe as "operational notes" at all.  Others might well be
IAOC documents, secretariat procedural documents, or basic IETF
consensus documents that specify the standards process.    But
creating separate document sets for each of those hair-splitting
categories doesn't seem consistent with either efficiency or
keeping a primary focus on products.

It is worth noting in practice that handling some of these
documents as BCPs is not strictly consistent with that term
either.  Most of them are procedures, not practices; we adopt
them and then start using them, which makes "current" somewhat
questionable; and applying "best" to our own procedures is
organizationally arrogant: they are just what we do.  But
spending time splitting those hairs doesn't seem productive.

I assume that, were you to suggest a better term or acronym,
Harald and the IESG would be receptive.    We could, of course,
call them "IETF Procedural Requirements" (IPR) and really create
confusion.

    john

---

From: Dave Crocker <[email-masked]>
Date: Mon, 22 May 2006 09:17:15 -0700

> keeping a primary focus on products.

If they are not all operational notes, then the series should not be called 
operational notes.

Whatever their source and whatever their focus, they are approved by the IESG 
and not the IETF.  They are roughly equivalent to Presidential Executive Orders, 
in the U.S.  That is rather different from a law or constitutional amendment.

> call them "IETF Procedural Requirements" (IPR) and really create

They are IESG documents, not IETF documents.  The name needs to be accurate with 
respect to the basis of authority, as well as the scope of content.

---

From: John C Klensin <[email-masked]>
Date: Mon, 22 May 2006 13:23:17 -0400

--On Monday, 22 May, 2006 09:17 -0700 Dave Crocker
<[email-masked]> wrote:

>> IAOC documents, secretariat procedural documents, or basic
>> IETF consensus documents that specify the standards process.
>> But creating separate document sets for each of those
>> hair-splitting categories doesn't seem consistent with either
>> efficiency or keeping a primary focus on products.

> If they are not all operational notes, then the series should
> not be called operational notes.

I can't speak for Harald or the IESG, but I would personally
welcome a constructive suggestion.

> Whatever their source and whatever their focus, they are
> approved by the IESG and not the IETF.  They are roughly
> equivalent to Presidential Executive Orders, in the U.S.  That
> is rather different from a law or constitutional amendment.

Since it is not relevant to this thread, I will skip making an
obvious comment about the present Administration and its
attitudes and behavior.  But I would have chosen other analogies.

Regardless of that, in the IETF, the IETF doesn't really approve
anything.  We can't, we don't vote.  What we do is to charge the
IESG with interpreting community consensus and making decisions
on behalf of the IETF based on that consensus.  Historically,
looking at practices rather than documented procedures, the IESG
has done that in three ways:

(1) Issue a Last Call, review the comments and general
impressions of community opinion, and decide on that basis.

(2) Decide what they community would like, or on a procedure
consistent with community inclinations, and then announce it...
without a Last Call but presumably subject to appeal.

(3) Decide what they would like, assume that what they want is
either consistent with what the community wants, or consistent
with what the community would want if it were better informed,
or that their preferences supercede any preferences the
community might have, then optionally announce it and, announced
or not, assume that the decision is not subject to appeal.

Now, as I read the I-D, it isn't intended to have any procedural
impact at all.   I think it might reinforce a general trend to
get rid of the third category, pushing things that might
previously have been handled that way into the second one.  If
it does, I think that would be A Good Thing.

But I find an effort to distinguish between the first two
categories in terms of what is "IESG approval" and what is "IETF
approval" to be unpersuasive.  For relatively minor procedural
changes or specification of details, I actually prefer the
second because I think it wastes less of the community's time.
If the IESG can't get "relatively minor" right, I think we have
other problems that document categories are not going to fix.

And I continue to be a little surprised that we are disagreeing
about this one: mutual teasing notwithstanding, I'm usually
reasonably good at predicting where we will disagree, and would
not have predicted this one.  To me, it seems like a fairly
low-impact way to excise the wart of having IETF procedures,
technical recommendations, and applicability statements
intermixed under the "BCP" label; to reduce slightly the load on
work on the RFC Editor and permit them to concentrate a larger
fraction of resources on the types of output we both consider
productive; and to get more of the IETF procedural stuff out in
the sunshine and organized so it can be found.   

I don't think it is hugely important or that its impact will be
very significant: if we didn't have yet another revision to the
the IPR rules coming up, a revision to RFC 2223 bouncing arouhd
the system along with the techspec draft, my "independent
submissions" draft, and some other RFC Editor procedures in the
pipe, and pressure mounting for a comprehensive revision of RFC
2026, I might contend it wasn't worth the trouble to make any
change at all (and I expect all, or nearly all, of those
documents to be subject to at least an approximation to Last
Call).  But precisely because those things are in the queue and
the details that will follow them are probably not far behind,
it feels to me that may be the right time to do this and see if
it accomplishes anything useful.

       john

---

From: Dave Crocker <[email-masked]>
Date: Mon, 22 May 2006 11:03:53 -0700

> welcome a constructive suggestion.

Steering Group Administrative Notes (SGAN)

> attitudes and behavior.  But I would have chosen other analogies.

Any mechanism can be abused.  For mechanisms involving people, the likelihood 
that it will eventually happen is quite high, so it is important to deal with 
that potential when designing the mechanism.  It is one of the reasons that it 
is important to have the mechanism make clear what its basis of authority is.

 > on behalf of the IETF based on that consensus.

We do not do precise, objective measurements of the sort usually called voting, 
but we absolutely DO do community approval.  The iterative working group rough 
consensus assessments, the working group last call, and the IETF last call are 
all used to formulate an aggregate assessment of community approval.

One of the major power changes in the IETF has been treating IESG approval as 
something higher than community approval.  It is precisely what empowers Area 
Directors to feel that they are the personal Keepers of Quality rather than 
(merely) the agents of the community.  Most area directors are excellent at 
their technologies, but it really is a bit much to expect or require them to be 
superior to the collective wisdom of the community seeking to use the work being 
standardized.

In any event, the proposed mechanism is not burdened with the patina of 
community review and approval.  This means that approval process solely subject 
to the desires of IESG.

The name of the mechanism should make that distinction clear.

> impact at all.

That hardly seems possible, given the scope and content of the documents 
intended for the series.

> not have predicted this one.

If our agreeing were entirely predictable, it would cease to be "interesting"...

In any event, I suspect the reason I am motivated to criticize the current 
proposal is that it is yet-another focus on creating a mechanism about form, 
rather than anything that has substantive relevance to timeliness or utility of 
IETF output.  Certainly it is always a good thing, to rationalize a 
documentation process, but new mechanisms are expensive. Hence, not "low impact".

Where we probably differ is in our view of the strategic cost of creating a 
mechanism that is secondary to the IETF's strategic problems.

d/

---

From: John C Klensin <[email-masked]>
Date: Mon, 22 May 2006 17:09:00 -0400

> Steering Group Administrative Notes (SGAN)

I could live with this (or, probably, any of a few dozen other
things).

>...
>> Regardless of that, in the IETF, the IETF doesn't really
>> approve anything.  We can't, we don't vote.  What we do is to
>> charge the
> We do not do precise, objective measurements of the sort
> usually called voting, but we absolutely DO do community
> approval.  The iterative working group rough consensus
> assessments, the working group last call, and the IETF last
> call are all used to formulate an aggregate assessment of
> community approval.

Agree so far, with the understanding that the IESG is, for these
sorts of matters, the body charged with evaluating and assessing
that approval.   I also believe that there are cases in which it
is more rational for the IESG to take an action, publicize it,
and see if anyone complaints than to attempt to determine how
the community  would react to that action in advance.   I
suspect you might agree with that because the alternative leads
to paralysis.  However, I presume we might disagree about the
boundary between the cases in which that is appropriate and
those in which it is not.

> One of the major power changes in the IETF has been treating
> IESG approval as something higher than community approval.  It
> is precisely what empowers Area Directors to feel that they
> are the personal Keepers of Quality rather than (merely) the
> agents of the community.  Most area directors are excellent at
> their technologies, but it really is a bit much to expect or
> require them to be superior to the collective wisdom of the
> community seeking to use the work being standardized.

We are in complete agreement on this subject, and I have tried
to write my comments in strict conformance with the notion of
the IETF as evaluator of community consensus, rather than that
of a higher or independent authority.

Moving the next few comments out of order, and deleting what I
think are side-discussions, for reasons that will be obvious...

>...
> In any event, I suspect the reason I am motivated to criticize
> the current proposal is that it is yet-another focus on
> creating a mechanism about form, rather than anything that has
> substantive relevance to timeliness or utility of IETF output.
> Certainly it is always a good thing, to rationalize a
> Where we probably differ is in our view of the strategic cost
> of creating a mechanism that is secondary to the IETF's
> strategic problems.

Actually, probably not.   Where I think we differ is that I see
three aspects of the status quo as problematic and
unsatisfactory.  If I thought they were working well, I would
consider this proposal a waste of time and hence too costly to
be worth the investment in either change or even this
discussion.  Those aspects are:

	(i) Excessive time between determination of a procedural
	change and formal publication of a document describing
	the current (revised) policy and waste of RFC Editor
	resources on documents that are not either technical or,
	in the RFC sense, archival.
	
	(ii) Excessive difficulty in determining what rules and
	procedures actually apply as the reader tries to thread
	RFCs and sections of RFCs together.
	
	(iii) The current system provides an incentive, however
	limited, for the IESG to decide on changes in procedural
	details in private and then announce (or not) those
	changes that encourages what appears to be a game of
	"gotcha" with the community.  I believe that IESG's
	tendency to actually do this has been declining (after
	some community outcry) but eliminating any procedural
	characteristics that encourage it seems desirable.

In combination, I consider those three issues to be significant
enough to overcome the presumption that a new mechanism is, a
priori, simply not worth the trouble.

> In any event, the proposed mechanism is not burdened with the
> patina of community review and approval.  This means that
> approval process solely subject to the desires of IESG.

> The name of the mechanism should make that distinction clear.

Ok.  I now understand where we disagree.  That is probably as
much progress as we can make and I, at least, will now leave
further discussion to others.

I am making two assumptions, which you may not share:

(1) We already have procedures that were approved solely subject
to the desires of the IESG (or the secretariat in combination
with the IESG).  I believe that various format-checking tools,
the document historically called "id-nits", the I-D posting
deadlines prior to IETF meetings, the "two BOF" restriction and
exceptions to it, the rules about interim meetings, and so on,
all fall into that category, at least in the sense that the IESG
decided on and implemented them without benefit of WG process,
Last Call, or other mechanisms for formally determining
community consensus.

(2) For those documents that we have traditionally handled with
the full rituals, checks, and evidence of community consensus
that are normally associated with BCPs, the approval process
will not change.  I believe for example, that were the IESG to
approve a significant change to RFC 2026 on its own initiative
without community exposure of the ideas and community consensus
on them, the action would be immediately followed by procedural
appeals and, potentially, group recalls or a general bloodbath.
Conversely, because the IESG ultimately makes the decision,
subject to community push-back, as to which documents and
procedures require BCP treatment and which ones can be handled
as in (1), we have the potential for that sort of pushback
today... as well as the demonstrated potential for the IESG to
simply ignore the rules.  

Because of those two assumptions, I do not see this as a large
procedural change: abuses that can occur with the proposed
system can occur with the existing one.  We have documents and
procedures that are approved strictly on the IESG's initiative
today: the proposed system doesn't make that worse and might
help by providing a centralized way to at least locate and
identify those procedures.

Now, one might also sensibly believe (although I do not) that
documents covered by that first assumption should not exist and
that everything should go to some process that permits formal
assessment of community consensus.    But, if so, it seems to me
that the way to pursue that is not to worry about this document
but to clarify 2026 and various other procedural, charter, and
authority documents to prohibit IESG decisions of that point.  

      john

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 25 May 2006 10:54:33 +0200

Note:

The IPOD draft says that these notes can be approved by multiple 
entities - I did not see any reason to insist that the mechanism impose 
a further burden on the IESG for *every* document that needs to be 
issued in the course of IETF operations.

So the reason for the "IETF" in "IETF Operational Notes" is "related to 
the IETF", not "approved by the IETF".

Much like the way "Internet Engineering Task Force" is related to the 
Internet, not approved by the Internet......

                           Harald

---

From: Dave Crocker <[email-masked]>
Date: Sat, 27 May 2006 07:00:07 -0700

> Internet, not approved by the Internet......

1. The Internet is not an organized, decision-making body. The IETF and the IESG 
are.

2. It has already been noted that the series will contain documents that are not 
operational.

3. The question is how the title of the series will actually be interpreted by 
average folk on the Internet, not what you might have intended.

d/

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Sat, 27 May 2006 19:07:33 +0200

At 16:00 27/05/2006, Dave Crocker wrote/
>Harald Alvestrand wrote:
>>So the reason for the "IETF" in "IETF Operational Notes" is 
>>"related to the IETF", not "approved by the IETF".
>>Much like the way "Internet Engineering Task Force" is related to 
>>the Internet, not approved by the Internet......
>
>
>1. The Internet is not an organized, decision-making body. The IETF 
>and the IESG are.
>2. It has already been noted that the series will contain documents 
>that are not operational.
>3. The question is how the title of the series will actually be 
>interpreted by average folk on the Internet, not what you might have intended.

Harald,
You have a complete and consistent IETF and Internet vision you try 
impose step by step. I have objections to the vision and no objection 
to the try, but why to hide it? IONs root in RFC 3935 part 3.

In using your own wording: you think the IETF participants are to 
help their leaders influencing the world in the way to design, use 
and manage the global digital ecosystem, for an Internet made of the 
global collection of machines, etc. to work better, along the core 
values of the IETF. This is because there are many reasons why 
decisions may have to be made by these chosen trusted leaders 
exercising their good judgement, doing the right thing according to 
the common mission, and acting on behalf of the IETF without 
consulting the entire IETF first. These reasons include the 
near-impossibility of getting an informed consensus opinion on a 
complex subject of several thousand people in a short time. I object 
to quite everything, but I agree that IETF needs a delegation doctrine.

Your proposition is to provide these leaders with the necessary 
framework to sign "presidential orders" in their area of authority. 
OK, but you do not document:
- the rules to assign someone or some body ION approval authority,
- the IETF control and renewal mechanism,
- the subsidiarity rules to apply.
Without them, instead of a simplifying system we would implement 
feudalism. Each ION approval body acquires the privilege to issue 
document series which may create conflicts, confusions and feuds. 
This may significantly increase the number of appeals. It may also 
lead to alternative reference sources invading the RFC territories (I 
see for example that you want to address via ION your problems with 
RFC 3683, ...)

This would lead to a barbarization of the IETF. But I see you foresaw 
this in 2.2. and a further IETF rebuild (from one of the created ION 
p principalities?). I would suggest these points to be addressed 
before enacting this system.

jfc

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Sat, 27 May 2006 12:43:36 -0400

Disclaimer: I haven't read Harald's document yet.

> interpreted by average folk on the Internet, not what you might have

Average folk on the Internet have never even _heard_ of the IETF, let alone 
understand the difference between the IETF, IESG, etc.  I'd expect the 
majority of those who have to interpret "IETF Operationsl Notes" as "notes 
about the operation of the IETF".  A few may interpret the series title to 
mean "notes from the IETF about the operation of the Internet".  For anyone 
not involved in the IETF, the first meaning is sufficient, and they're not 
going to care what the process is for approving new ION's or updates to 
existing ones, or how that impacts the title.

I think it's been stated several times that the intent is not to grant 
sweeping new powers to the IESG, but to have a document series which 
encompasses _all_ of our process, practices, and procedures, regardless of 
approval level.  For the purpose of a process experiment, I think we can 
apply a fairly simple rule - if it would have required a BCP before, it 
still requires IETF concensus onder the experiment; the document just gets 
published in the new series instead of the old one.  Anything that 
previously would not have required a BCP still doesn't.

For the long term, if the experiment proves successful, we probably need a 
more well-defined policy.  One approach might be to adopt a model in which 
all authority derives from the IETF, by IETF consensus model.  So, anything 
which changes he structure or overall process of the IETF requires IETF 
consensus, but bodies like the IESG, IAB, or IAOC can publish documents on 
policy or procedure which they are empowered by IETF process to set (e.g. 
IESG balloting procedures, i-d nits, or criteria for selecting meeting 
locations) or which are descriptive rather than prescriptive (e.g. the 
Tao).  This probably needs to be formulated better, but I don't think it's 
necessary to wait for that before beginning the experiment.

-- Jeff

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Mon, 29 May 2006 01:08:42 +0200

>Disclaimer: I haven't read Harald's document yet.

May be you should do that: the problem is not what is in the 
document. But what is not in it. Controls. Rules of approvals. What 
it replaces. It should not increase but decrease the pile of IETF 
documents. The outcome also misses the option that we keep and change 
it. I do not say it will create havoc, but I experimented the IETF 
enough to know it could block it and how.
jfc

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 29 May 2006 02:17:05 -0700

Note - I did not intend to advocate starting off by moving all BCPs into 
IONs.

Some pieces of some BCPs may be better off as IONs. But I think that 
having the "basic rules" as BCPs that are published as RFCs is something 
that we shouldn't be too quick to change.

                        Harald

Jeffrey Hutzelman wrote:

> Average folk on the Internet have never even _heard_ of the IETF, let 
> alone understand the difference between the IETF, IESG, etc.  I'd 
> expect the majority of those who have to interpret "IETF Operationsl 
> Notes" as "notes about the operation of the IETF".  A few may 
> interpret the series title to mean "notes from the IETF about the 
> operation of the Internet".  For anyone not involved in the IETF, the 
> first meaning is sufficient, and they're not going to care what the 
> process is for approving new ION's or updates to existing ones, or how 
> that impacts the title.
>
> encompasses _all_ of our process, practices, and procedures, 
> regardless of approval level.  For the purpose of a process 
> experiment, I think we can apply a fairly simple rule - if it would 
> have required a BCP before, it still requires IETF concensus onder the 
> experiment; the document just gets published in the new series instead 
> of the old one.  Anything that previously would not have required a 
> BCP still doesn't.
>
> For the long term, if the experiment proves successful, we probably 
> need a more well-defined policy.  One approach might be to adopt a 
> model in which all authority derives from the IETF, by IETF consensus 
> model.  So, anything which changes he structure or overall process of 
> the IETF requires IETF consensus, but bodies like the IESG, IAB, or 
> IAOC can publish documents on policy or procedure which they are 
> empowered by IETF process to set (e.g. IESG balloting procedures, i-d 
> nits, or criteria for selecting meeting locations) or which are 
> descriptive rather than prescriptive (e.g. the Tao).  This probably 
> needs to be formulated better, but I don't think it's necessary to 
> wait for that before beginning the experiment.
>
> -- Jeff
>