Re: [Pesci-discuss] Principles for the process vs Principles for Process Change

["JFC (Jefsey) Morfin" <[e-mail]>]

At 11:33 14/10/2005, Brian E Carpenter wrote:
>As I said to you privately, it proves hard to write down principles
>for change in a vacuum, but our desire is absolutely to focus
>on principles for change.




Brian,
not exactly a vacuum. Your own RFC 1958 basic principle seems to give 
a good historic ground.

Changes are to match problems and opportunities. It would be non 
committing change to add to the process a serious way to know and 
quantify reality. Also, the Internet has acquired enough importance 
in the current society to create and support changes in the world 
reality. There is therefore a need to qualify changes against 
something external to its own loop: a politic ethic. The case of RFC 
3066 bis is of interest. IESG refused to consider the change and 
sided in a main politic/commercial camp. It is likely it will hit 
back: may be a good occasion for experience.

The Internet standard process and the IETF culture is incredibly 
affected in its own past because its deliverables never change (once 
an RFC always an RFC). This drags down innovation and I am not sure 
it preserves retro-compatibility. But it preserves status quo to the 
benefit of stakeholders. The digital divide starts to be political 
and soon architectural (balkanisation). Now, let consider a IETF 
context where RFCs would be Internet Book updates (what the users are 
used to and expect). The change in the culture would probably be 
important. Including about progressive non-committing changes too 
(what you look for) in process and in architecture.

The impact of changes in architecture goes with and induces changes 
in process. There are many parallel concepts, option and processes. 
How many RFC are effective? May be 2000? Who can even read 2000 RFCs 
and actually more as deprecated RFC are still documented in further 
documents and debates? Let imagine the architecture would change and 
accept parallel links (at lowest level), i.e. multi-internet instead 
of mono-for-ever-internet. Many processes/concepts would be seen 
differently. The corresponding architectural culture would 
contributed to the general process. Instead of seeing alternatives as 
conflicting, they would be seen as complementary.

>To the extent that we've failed, the draft will need more work.

May be a good occasion to read Derrida too? (deconstruction)

IMHO the first IETF problem is the efficiency of its own deliverable: 
the Internet. Internet (as a whole set of propositions) should be 
useful to communities (like IETF). So, the efficiency of the IETF 
solutions and management is the very gauge of the IETF success. Seen 
as this the question is reduced to the Internet tools which should 
support and lead the process changes.

In addition if we are to change so many things because we want to 
change a process, we will never change the process. BTW this 
translates in a lack of update policy in the Internet systems, and 
97.5% of illegitimate calls on the root servers mostly because 
machines have not been updated for years and continue issuing 
erroneous requests.

The first need IMHO is to work on the IETF deliverables. What are 
they, how should they be presented, how can they be expected to 
change. From this, how can they be produced, and enhanced (for 
example where is experimentation to fit). In all that what are the 
invariants, what are the components, the parameters, etc. What can be 
independently changed. Then let see the underlying object structure, 
work on the metadata, build an ontology, and from this let build a 
management networked language to write/update management tools 
everyone can use, the IETF first.

Once you have that, you can discuss what is done today. Test the 
management language to replace current tools by a unified similar 
system. Then use the debate on process change to adapt and test small 
changes, which will test your management language. etc. Then adapt 
and come back if it does not work. You "enhance", you do not "change" 
anymore. You do not have IETF specific and may be erroneous 
solutions, like crazy RFC 3683, you have a source forge based 
community effort for a serious development culture instead of status 
quo smart maintenance as documented by Harald's "last" mail as IETF Chair.

jfc


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