Subject: [Pesci-discuss] [Fwd: I-D ACTION:draft-davies-pesci-initial-considerations-01.txt]

From: Brian E Carpenter <[email-masked]>
Date: Sat, 14 Jan 2006 17:55:55 +0100

Here is a much slimmer draft than the pre-BOF one:

-------- Original Message --------
Subject: I-D ACTION:draft-davies-pesci-initial-considerations-01.txt
Date: Fri, 13 Jan 2006 15:50:01 -0500
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Moving Forwards with IETF Process Evolution
	Author(s)	: E. Davies
	Filename	: draft-davies-pesci-initial-considerations-01.txt
	Pages		: 15
	Date		: 2006-1-13
	
This document provides a summary of previously identified problems
    with the Internet Engineering Task Force (IETF) process for
    developing standards and other specifications; and then identifies a
    set of goals to aim at, and guidelines that should be followed during
    any activity seeking to revise and update this process.  It does not
    propose specific changes to the process, which should be the subject
    of future documents.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-davies-pesci-initial-considerations-01.txt

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

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

---

From: Pekka Savola <[email-masked]>
Date: Mon, 16 Jan 2006 16:00:58 +0200 (EET)

On Sat, 14 Jan 2006, Brian E Carpenter wrote:
>...

Thanks for the revision.  It'd be interesting to know what the next 
steps with this are..

I've re-read the document.  I agree with Bert's comments.  In 
particular, sections 1-3 seem like a bit lengthy introduction to the 
topic, but in the interest of ensuring clarity for those who consider 
proposing process change processes, I don't find it too objectionable.

>From Principles, P4 is indeed a tricky one.  I'd say that "Formal 
consent from [current leadership]" is too strong wording.  I'd say 
that they must be allowed to comment on the proposal.  Whether they 
could consent to it or not is IMHO irrelevant.  The whole point is 
that if there would be IETF consensus for making the choice, I'm not 
sure whether it's OK that any of {IESG,IAB,IAOC} alone should be able 
to block the process.  (I'd be OK if some form of consent was needed 
from a majority of the bodies.)

As my own major comments,

1) I still can't believe P6 wasn't removed already.  The bar for 
making process change proposals is too high already -- why should we 
need to add, "oh by the way, please redesign our current process 
documents while you're at it.. THANKS!".  This doesn't seem 
productive.

    P6. The revised process should be documented in a new set of coherent
        and comprehensive documents, rather than updates to the existing
        ad hoc set.

2) I think the wording of principles is intentionally very subtle or 
it should be clarified or split in two.  Some of the principles talk 
about the IETF process change, some seem to talk about process for 
developing the process change, e.g.:

    P1. Changes to the IETF process must themselves be agreed by an open
        process approved by the IETF community.
    P2. The process for developing and agreeing these changed processes
        must itself be the subject of IETF rough consensus.

Is having two different principles intentional?  If different 
principles apply to the different steps of the process (or 
process-development process) I'd encourage splitting up the principles 
so it becomes clearer how the principles apply.

As it is, I'm confused about the applicability of the listed 
principles and one way or the other, this seems to call for rewording.

editorial
---------

    At the time of writing, two process related working groups exist:
    newtrk (New IETF Standards Track Discussion) and ipr (Intellectual
    Property Rights).  Their charters, mailing lists, etc., may be found
    via http://www.ietf.org/html.charters/wg-dir.html#General%20Area.

==> this is an example of text that IMHO can be removed.

    P2. The process for developing and agreeing these changed processes
        must itself be the subject of IETF rough consensus.

==> s/agreeing/agreeing to/ (or something else missing?)

Appendix A.  PESCI Announcement

==> this could be replaced with a link to the message in the 
IETF-announce archives.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Elwyn Davies <[email-masked]>
Date: Mon, 16 Jan 2006 14:12:28 +0000

Pekka Savola wrote:

> documents while you're at it.. THANKS!".  This doesn't seem productive.
>
Apologies; That is a dropoff.  P6 was *supposed* to have vanished.  I 
think that actually this a part of the problems and you will find that 
there is a new item 10 in the problems.

Regards,
Elwyn

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 16 Jan 2006 16:03:10 +0100

--On mandag, januar 16, 2006 16:00:58 +0200 Pekka Savola 
<[email-masked]> wrote:

> consent from [current leadership]" is too strong wording.  I'd say that
> they must be allowed to comment on the proposal.  Whether they could
> consent to it or not is IMHO irrelevant.  The whole point is that if
> there would be IETF consensus for making the choice, I'm not sure whether
> it's OK that any of {IESG,IAB,IAOC} alone should be able to block the
> process.  (I'd be OK if some form of consent was needed from a majority
> of the bodies.)

Formally, I think we either need to have formal consent or a revolution.... 
remember that at the time of Kobe, the IAB formally accepted the output of 
the POISED process, so we have a tradition of being formally correct when 
we revolutionize....

If the next steps are the right ones, IESG consent will be obtainable, I 
think; some procedures for getting it are messier than others.

I regard that as a minor problem.

                       Harald

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 16 Jan 2006 16:36:38 +0100

Pekka,

> there would be IETF consensus for making the choice, I'm not sure 
> whether it's OK that any of {IESG,IAB,IAOC} alone should be able to 
> block the process.  (I'd be OK if some form of consent was needed from a 
> majority of the bodies.)

Yes, this is certainly a tricky point. You can imagine the mess if a
change was agreed by a new process that the IESG decided was completely
unworkable, or that would cost $500,000 extra in secretariat work. But note,
this does not say *approval* by [current leadership]. It says consent.
We could define the rules for consent in a different way from the normal
rules for approval of technical documents (e.g. a simple majority vote,
with nothing like a Discuss option).

     Brian

---

From: Pekka Savola <[email-masked]>
Date: Mon, 16 Jan 2006 17:37:43 +0200 (EET)

On Mon, 16 Jan 2006, Harald Tveit Alvestrand wrote:
> --On mandag, januar 16, 2006 16:00:58 +0200 Pekka Savola <[email-masked]> 
> wrote:
> the POISED process, so we have a tradition of being formally correct when we 
> revolutionize....
>

Indeed, I don't think this is a major problem.  In my opinion, what's 
more important would be that IAOC, IESG, IAB etc. know that they 
will be asked to COMMENT, but not DISCUSS.

I believe this may have a positive impact on the amount of time spent 
obtaining consensus and/or consent.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 18 Jan 2006 14:40:14 +0100

Pekka Savola wrote:
>>> whether
>> Formally, I think we either need to have formal consent or a 
>> revolution.... remember that at the time of Kobe, the IAB formally 
>> accepted the output of the POISED process, so we have a tradition of 
>> being formally correct when we revolutionize....
>>
>> If the next steps are the right ones, IESG consent will be obtainable, 
>> I think; some procedures for getting it are messier than others.
> 
> 
> more important would be that IAOC, IESG, IAB etc. know that they will be 
> asked to COMMENT, but not DISCUSS.
> 

It just needs to be written in a way that means that reasonably
objective statements like "we don't have enough money for this" or "this will
increase the IESG workload by about 33%" are in effect blocking comments.
I though "consent" captured that quite well.

     Brian

---

From: Scott W Brim <[email-masked]>
Date: Fri, 20 Jan 2006 09:09:42 +0100

> there is a new item 10 in the problems.

But P6 is still a good idea, wouldn't you say?

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 20 Jan 2006 10:32:09 +0100

> But P6 is still a good idea, wouldn't you say?

as a good idea (guidance), yes.
as a requirement for getting anywhere, no.

my thought.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 20 Jan 2006 13:44:08 +0100

> as a requirement for getting anywhere, no.

My thought is that the spaghetti-like nature of the current documents is
actually a problem, especially for newcomers. But it's separate from
the core problem. It's why I wrote draft-carpenter-procdoc-roadmap and why
I intend to maintain that draft.

     Brian

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 20 Jan 2006 06:54:25 -0600

From: "Brian E Carpenter" <[email-masked]>
> I intend to maintain that draft.

Just to chime in here, since both the IETF home page and the RFC Editor page 
point directly to RFC 2026 with no qualifiers as "the Standards Process", it 
is possible that we are confusing more than newcomers :-(

Just for fun, follow the "updates/obsoletes" chain for 2026, and see how 
clear our document structure really is to anyone who doesn't do IETF for a 
living.

Spencer

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Sun, 22 Jan 2006 02:16:30 +0100

At 13:54 20/01/2006, Spencer Dawkins wrote:

>Just to chime in here, since both the IETF home page and the RFC 
>Editor page point directly to RFC 2026 with no qualifiers as "the 
>Standards Process", it is possible that we are confusing more than 
>newcomers :-(
>
>Just for fun, follow the "updates/obsoletes" chain for 2026, and see 
>how clear our document structure really is to anyone who doesn't do 
>IETF for a living.

Correct!
May be this input can give some ideas? May be a (manual) work on RFC 
2026 along these lines could be of interest? .

I first semi-clarified the IETF IPR issue with Brian. Then we started 
trying to build a DNS compendium in a way we could "automate" for 
other topics (and multilingualise  [not internationalise] meaning 
that we could both translate RFC inputs but also add non-English 
inputs, for example ccTLD rules, terms and conditions, tables, 
charsets, etc. treating every language on an equal basis, what 
creates additional problems).

We went on the RFC -Editor and searched fro "DNS". We took the list 
of RFCs (obsolete as well) and made a list. Then we took all their 
ASCII text and tried to work out some automated structuring from the 
TOC. Then we built a registry, indexing all the paragraphs with the 
number of the RFC, if it is obsolete or not, reserving a ThematicID. 
Then we started trying to build the Registry meta-model (the works 
goes in parallel with the development of a registry manager - this 
DNSreg is one of the test application).

The main problem we observe right now is the obvious lack of 
cross-rfc meta-model to describe the covered topics. There are 
Introduction, TOC, security and IANA considerations, links. This is a 
beginning. We should totally rebuild the titles of the parts to get 
some consistency. Our first analysis shows that we should probably 
rewrite many "blocks" to keep them consistent and address repeats. We 
need a "confusion waiver" system of rules. Then there is the update 
problem when information is not renewed in the new version. We had an 
English variation n-gram run which shows there is no really 
consistent style (far less than in ISO or ETSI documents). We were 
told this may indicate less precise documentation.

Obviously we could have chosen a simpler case than the DNS, but we 
need to have a good command of the whole experience for our work 
taowards a DRS  (distributed registries system) moke-up. This was 
also the topic where we could have the largest number of relevant 
entries in the largest number of languages, and therefore ways to 
test the LNS DRS core (language naming system).

We would like to see how we can get applications from this. A DNS 
ontology? One of the target is to investigate a digital ecosystem 
multitechnology documentation registry. The target is also to include 
the DNS registries in the system. We would structure for that the top 
zone information we maintain (http://afrac.org/intlfile.txt) on a 
daily basis. Using our own formating generator for parallel multiple 
language structures. From then on, ISO 11179 compatibility, using ISO 
639-6 language codes for example, and some geographic registries [or 
telephone numbering plans] could permit local roots and PADs [private 
alias directories] easier management, and ML.ML naming support. We 
would like to see if we can get a root matrix from all this (all the 
top zone ML.ML and ML.LOCAL variations - and transtechnology 
services). The standard name resolution would be carried via DNS 
servers or access engines. The whole thing would permit, for our 
Naming Registry Manager generic system, to propose an online support 
complete documentation.

Associated thematic grids could permit to produce easily specialised 
abstracts or aggregats. In the way Doug Engelbart's Augment system 
did. This could be used for trouble shooting; all the documentation 
would progressively follow the investigation.

I hope we will compile experience during this quarter, adding the 
first propositions for the IGF, and get something online in May/June. 
It would be embryonic but a moke-up for comments (that is if 
competition does not push me out the IETF before or pump too much on 
my time/budget).

jfc

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 23 Jan 2006 15:19:43 +0100

I've just submitted an update for the IETF site (attached fyi).

     Brian

Spencer Dawkins wrote:
> Just to chime in here, since both the IETF home page and the RFC Editor 
> page point directly to RFC 2026 with no qualifiers as "the Standards 
> Process", it is possible that we are confusing more than newcomers :-(
> 
> clear our document structure really is to anyone who doesn't do IETF for 
> a living.
> 
> Spencer
> 
The IETF Standards Process

The basic definition of the IETF standards process is
in RFC 2026 (BCP 9).
However, this document has been amended several times.
The intellectual property rules are now separate, in
BCP 78 (rights in contributions) and
BCP 79 (rights in technology).
Another update is
BCP 92 (independent submissions to the RFC Editor).
An overview of many process documents is available as a

work in progress.

---

From: Susan Harris <[email-masked]>
Date: Mon, 23 Jan 2006 10:31:00 -0500 (EST)

> I've just submitted an update for the IETF site (attached fyi).

May be just me, but the html attachment doesn't seem to display anything 
but control characters.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 24 Jan 2006 14:37:07 +0100

Ho-hum. Somehow it got encoded in UTF-16. I really should
stop playing with character sets...

Here it is again in an 8 bit character set. Sorry.

    Brian

work in progress.

---

From: Susan Harris <[email-masked]>
Date: Tue, 24 Jan 2006 09:43:08 -0500 (EST)

> Here it is again in an 8 bit character set. Sorry.

A non-English one, though :)

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 26 Jan 2006 08:41:08 -0000

It seems to me that P3 already covers taking advice from the IESG.

Further P2 requires rough consensus of the IETF. It seems unlikely to me
that if the IESG objected this would not influence the formation of rough
consensus because they would state their opinions in a public forum and
their opinions would carry weight appropriate to their positions. If, in
Brian's example, the effect of a change was considerable (30% increase in
IESG time, massive cost, etc.) I would expect to see this pointed out by
the IESG during the discussion phase with the effect that either the
proposal was modified or the rough consensus was not achieved.

This, IMHO, is how the IETF rough consensus process is supposed to work.
Thus, while we would clearly want to have buy-in from the IESG and other
bodies, it is relatively unlikely that we would have gotten to the stage
of needing buy-in unless:
- there was already IESG support
- there was massive IETF support
- the difference in opinion was minor and on some small point

Thanks,
Adrian

----- Original Message ----- 
From: "Brian E Carpenter" <[email-masked]>
To: "Pekka Savola" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, January 16, 2006 3:36 PM
Subject: Re: [Pesci-discuss] [Fwd:I-D
ACTION:draft-davies-pesci-initial-considerations-01.txt]

> > consent from [current leadership]" is too strong wording.  I'd say
that