Subject: BOUNCE [email-masked]: Non-member submission from [mose <[email-masked]>]

From: [email-masked]
Date: Sat, 03 Jan 2004 07:53:04 -0500

>From [email-masked] Sat Jan 03 07:53:04 2004
Date: Sat, 3 Jan 2004 13:48:16 +0100
From: mose <[email-masked]>
To: Paul Robinson <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [isdf] Re: www.internetforce.org
Mail-Followup-To: Paul Robinson <[email-masked]>,
	[email-masked], [email-masked]

le Mon, Dec 29, 2003 at 02:19:33PM +0000 par Paul Robinson :
> Franck Martin wrote:
> 
> >Who are we to recommend things as Mike Todd suggests?
> >
> End-users. We're end-users of the Internet. Everybody who uses it should 
> be entitled to join any body that determines it's future, and any body 
> that has influence that is free to join therefore has the right to 
> recommend actions for it's future. Think of it as an abstract form of 
> democracy. I live in the UK and Paliament has every right to pass laws 
> because I voted them into that position, and likewise if I want to 
> become a politician I can do so and pass my own laws... Same thing here, 
> except you actually need a clue to participate in IETF rather than just 
> look good kissing babies.

- I have to say something there. 

No internet user is an end-user very long. The broadcast era of massmedia 
is still in people habits but it's from the last century and there is no 
technical reason anymore to limit the decisionnal/informational processes 
to an elit of either good-looking babes either wise diplomed experts.

About politician, I don't vote them because they vote their own laws,
not mine. I don't understand how it would be a solution if I switch
and become politician to vote my own laws. Politics is very cool for
peace in material world because it's a convention to make everybody to 
say 'yes' before knowing what will be decided (notice that the 'no' 
alternative usually requires unusual creative abilities or direct 
exclusion, with various degrees of subtility in the way to exclude).

I think that online it's different. People decide by 'not saying no', as
it's rather pointless to say 'yes' when you are in a consensual situation 
with thousand, millions or more of people it would be very noisy. It's
working like that for more than 30 years now and I think we could learn
from it.

Every standard proposed can be of any quality, if nobody apply them
it's only intellectual research with no societal impact. I take as 
example the ipv6 implementation that we wonder "why we don't have it 
yet" for years, the story of the HTML specifications and the respect
of it.

In such context, a more participative behaviour should be welcome. Elits 
should help and educate rather than keeping the steering so firmly.
RFC aren't they meaning "Request For Comments" ? Why did I never find 
the button "add your comment", yet, on any of them ?

my $cents = 2;
mose

---

From: Mark Smith <[email-masked]>
Date: Mon, 5 Jan 2004 22:45:43 +1030

On Sat, 03 Jan 2004 07:53:04 -0500
> 
> In such context, a more participative behaviour should be
> welcome. Elits should help and educate rather than keeping the
> steering so firmly. RFC aren't they meaning "Request For
> Comments" ? Why did I never find the button "add your comment",
> yet, on any of them ?

Because that is not how they are updated.

The RFC faq would a place to seek your ansers.

http://www.rfc-editor.org/rfcfaq.html

Regards,
Mark.

---

From: Wawa Ngenge <[email-masked]>
Date: Thu, 8 Jan 2004 12:50:50 -0600 (CST)

> The RFC faq would a place to seek your ansers.

The original question is : "Why do they not operate that way", if they are 
indeed REQUESTS?
w
 
> _______________________________________________
> Isdf mailing list
> [email-masked]
> http://www.isoc.org/mailman/listinfo/isdf
> 

-- 
Wawa Ngenge (Ph.D.)
Internet Society Trustee Emeritus
WorldComputerExchange.org  Director
www.worldcomputerexchange.org/board_staff/ngenge-resume.htm
[email-masked]

---

From: John C Klensin <[email-masked]>
Date: Thu, 08 Jan 2004 15:45:17 -0500

--On Thursday, 08 January, 2004 12:50 -0600 Wawa Ngenge 
<[email-masked]> wrote:

> The original question is : "Why do they not operate that way",
> if they are  indeed REQUESTS?
> w

Hi.

A better answer would have been "the term 'request for comment' 
is historical, dating from a time when the preferred way to make 
a formal comment on a document involved writing another 
document, which then was numbered into the series".  That 
mechanism is still available, although usually very slow.  But 
documents that become RFCs are now first posted as Internet 
Drafts (see http://www.ietf.org/ID); comments on those are both 
solicited and, usually, handled very quickly.

Today, the RFC Series, despite retention of the original name 
and numbering series, acts as a permanent, archival, repository 
of information, decisions taken, and standards published.  As 
such, documents in the series are subjected to review and 
editing processes (which differ somewhat depending on the type 
of document and are appropriate for conventional references from 
conventional documents.  Running conversations, logs of 
comments, etc., are not well suited for that archival and 
reference role, regardless of their other advantages and 
disadvantages.

regards,
    john

---

From: Fred Baker <[email-masked]>
Date: Thu, 08 Jan 2004 13:47:36 -0800

Wawa:

Is this a relay of a question from the ISDF list to the IETF list? I don't 
seem to have the context of the conversation.

I gather that the question has something to do with the management of RFCs. 
It would be good to read the discussion at http://www.rfc-editor.org/ for 
what the RFC Editor thinks the RFC Series is.

As to the name, you need to understand both the origins and the history of 
the series: the series was originally an archive of notes among friends, 
and (per Steve Crocker, the guy who named them) was called "Request for 
Comments" as much as anything to downplay the concept of "we are now 
publishing Something Immutable and Really Important". That was in 1969. By 
the time I became associated with the IETF in 1989, there was a running 
joke that the letters really stood for "Requirements for Compliance", and 
today we often have a hard time convincing the ignorant that a published 
RFC - even when it opens with the words "this is not a standard" or "this 
is a bad idea that we are archiving so we don't forget why it is a bad 
idea" - is in fact not a standard. http://www.ietf.org/rfc/rfc2026.txt 
describes the current use of the RFC series, in terms of standards track 
specifications (about 1/3 of the RFCs), history, experiments, white papers 
on networking, poetry, and April Fool's jokes.

Fred

At 10:50 AM 1/8/2004, Wawa Ngenge wrote:
>This message was passed through [email-masked], which 
>is a sublist of [email-masked]. Not all messages are passed. Decisions on 
>what to pass are made solely by IETF_CENSORED ML Administrator 
>([email-masked]).

---

From: Franck Martin <[email-masked]>
Date: 09 Jan 2004 10:45:08 +1200

http://www.internetforce.org/tiki/tiki-index.php?page=Technology

I put some of your comments there....

Hope you don't mind...

Cheers

> seem to have the context of the conversation.
The archive is only open to ISDF members, unfortunately.... Which is
still better than no ISTF archives.... ;)
----
Franck Martin
[email-masked]
SOPAC, Fiji
GPG Key fingerprint = 44A4 8AE4 392A 3B92 FDF9  D9C6 BE79 9E60 81D9 1320
"Toute connaissance est une reponse a une question" G.Bachelard

---

From: jfcm <[email-masked]>
Date: Thu, 08 Jan 2004 23:32:43 +0100

At 21:45 08/01/04, John C Klensin wrote:
>A better answer would have been "the term 'request for comment' is 
>historical, dating from a time when the preferred way to make a formal 
>comment on a document involved writing another document, which then was 
>numbered into the series".  That mechanism is still available, although 
>usually very slow.  But documents that become RFCs are now first posted as 
>Internet Drafts (see http://www.ietf.org/ID); comments on those are both 
>Today, the RFC Series, despite retention of the original name and 
>numbering series, acts as a permanent, archival, repository of 
>information, decisions taken, and standards published.  As such, documents 
>in the series are subjected to review and editing processes (which differ 
>somewhat depending on the type of document and are appropriate for 
>conventional references from conventional documents.  Running 
>conversations, logs of comments, etc., are not well suited for that 
>archival and reference role, regardless of their other advantages and 
>disadvantages.

Could it not be useful to have a "List of Comments" (LOC) for each RFC? 
Where experience about the RFC reading, testing and implementation could be 
listed by the authors (or a successor) from experience and questions 
received. It would avoid the same questions to be debated again and again 
and it would help further thinking. These comments could start with a 
summary of the WG debated issues, explaining the whys of some options. I 
suppose the implementation would be easy enough since it would follow the 
same numbering scheme and titles. Such a LOC being an updated appendix 
could be reviewed and help preparing replacements.
jfc

---

From: Fred Baker <[email-masked]>
Date: Thu, 08 Jan 2004 15:37:18 -0800

At 02:32 PM 1/8/2004, jfcm wrote:
>Where experience about the RFC reading, testing and implementation could 
>be listed by the authors (or a successor) from experience and questions 
>received.

These are usually found in the form of working group archives and 
subsequent RFCs that update or obsolete the older ones, especially in the 
case of standards track documents. The RFC Editor also keeps a log of notes 
on RFCs when asked to.

It's not obvious, at least to me, why a second mechanism is required if th 
one that is there works...

---

From: [email-masked]
Date: Thu, 08 Jan 2004 22:25:07 -0500

> case of standards track documents. The RFC Editor also keeps a log of notes 

Actually *finding* something in the working group archive can be.. interesting.

There is much that happens during the editing of a reply to an e-mail message
that is totally different than the sort of expository writing that a LOC would
need in order to be useful. They're different skill sets, they're different
mindsets, and vastly different assumptions.

For instance, this note probably won't stand well by itself 5 years from now,
because I'm writing to an audience that has Fred Baker's and jfcm's comments
fresh in their minds, and presumably have an interest in both the thread and
what I have to say in reply to Fred Baker (hopefully, those that aren't have
some combination of threading, killfiles, and delete keys ;)

I remember a few times going back to the big-internet and MIME/ESMTP mailing
lists, and even with the assist of actually having been a participant the first
time around, was unable to track down specific things I remember having been
written. Approaching it with nothing more than "Somebody mentioned something
about that issue way back when", if that much - now that would be downright
scary.

The recent discussion about RFCs, 'Updates', and similar topics would probably
be equally difficult to track down several years down the road.

---

From: jfcm <[email-masked]>
Date: Fri, 09 Jan 2004 07:03:19 +0100

At 00:37 09/01/04, Fred Baker wrote:

>case of standards track documents. The RFC Editor also keeps a log of 
>notes on RFCs when asked to.
>
>one that is there works... .

Let say that an RFC is an IETF deliverable. After-delivery 
support/maintenance is not a requirment for the delivery to exist but an 
usual user expectation. An RFC is a project imposed to the world before it 
is validated. A market standard is the desciption of what works and is 
adopted. We might find this way a fortunate compromise?

---

From: John C Klensin <[email-masked]>
Date: Fri, 09 Jan 2004 03:15:16 -0500

--On Thursday, 08 January, 2004 23:32 +0100 jfcm <[email-masked]> 
wrote:

>> A better answer would have been "the term 'request for
>> comment' is  historical, dating from a time when the
>> preferred way to make a formal  comment on a document
>> involved writing another document, which then was  numbered
>> into the series".  That mechanism is still available,
>> although  usually very slow.  But documents that become RFCs
>> are now first posted as  Internet Drafts (see
>> http://www.ietf.org/ID); comments on those are both
>> and  numbering series, acts as a permanent, archival,
>> repository of  information, decisions taken, and standards
>> published.  As such, documents  in the series are subjected
>> to review and editing processes (which differ  somewhat
>> depending on the type of document and are appropriate for
>> conversations, logs of comments, etc., are not well suited
>> for that  archival and reference role, regardless of their
>> other advantages and  disadvantages.
>
>
> Could it not be useful to have a "List of Comments" (LOC) for
> each RFC? Where experience about the RFC reading, testing and
> implementation could be listed by the authors (or a successor)
> from experience and questions received. It would avoid the
> same questions to be debated again and again and it would help
> further thinking. These comments could start with a summary of
> the WG debated issues, explaining the whys of some options. I
> suppose the implementation would be easy enough since it would
> follow the same numbering scheme and titles. Such a LOC being
> an updated appendix could be reviewed and help preparing
> replacements.

Jefsey,

There are many ways by which almost any system could be, or 
could have been, designed or evolved.  Typically each has its 
advantages and disadvantages, even if, overall, the difference 
in effect is slight.  Certainly the Internet standards and 
definitions process could have evolved with RFCs and LOCs or 
some other pieces.  Certainly the idea of "standards" could have 
been put in place early in the process, and we could have called 
what are now "Internet-Drafts" "RFCs" instead, could have had 
standards in a separate series, and had an additional separate 
series for experimental and informational documents (we might 
even have followed the lead of some other bodies and called the 
latter series "technical reports", which they are definitely 
not).    And certainly we could have adopted a distinct 
numbering system and document series for standards along with a 
regular review model, standing WGs to which each standard is 
applied, and revisions that share the number but have different 
dates or revision numbers.

In some cases, the fact that we didn't go down those paths is an 
historical accident.  In others, it was a very deliberate 
decision.  And, in some cases, the path that was chosen was very 
important in shaping how the IETF operates or reflects the 
nature of those operations (e.g., the fact that we generally 
close WGs that have finished their work, rather than encouraging 
them to find new things to keep them busy has, I believe, been 
very important in keeping us from developing many standards that 
no one wants and that are out of touch with reality).

But we do things in a particular way that mostly works (although 
it should probably be more effectively and accessibly 
documented), and, while we might tune things differently or use 
different terminology if we were starting over today, what 
purpose would it serve to develop redundant mechanisms that 
would require extra volunteer or staff effort to make work and 
keep working and that would leave people uncertain as to where 
to go for information?  And what purpose is served by proposing 
such an action?

Regards,
    john

---

From: [email-masked]
Date: Fri, 09 Jan 2004 10:13:54 -0500

> adopted. We might find this way a fortunate compromise? 

Unfortunately, "market standards" often include borken things that are adopted
via forced-feeding.  More than one vendor has done this, and some research
would probably find at least one example at each of the 7 OSI layers.

Current pet peeve - 100BaseT auto-negotiation on older gear, especially when
"the other end" is nailed to something other than auto. (Co-worker's comment on
that one - "Didn't we go through that whole subnet and clean that up twice
already?" :)  So much for market "standards". (Yes, I know it's better now.
The hardware involved is many moons old).

---

From: Fred Baker <[email-masked]>
Date: Fri, 09 Jan 2004 12:02:46 -0800

May I suggest you become familiar with the IETF process before commenting 
on it? The RFCs on the standards track are generally field tested before 
deployment at Proposed Standard, and the various standardization levels 
specifically address the issue you raise.

Read RFC 2026.

At 10:03 PM 1/8/2004, jfcm wrote:
>>It's not obvious, at least to me, why a second mechanism is required if 
>>th one that is there works... .
>

---

From: jfcm <[email-masked]>
Date: Sat, 10 Jan 2004 14:18:04 +0100

At 02:30 10/01/04, Wawa Ngenge wrote:
>I suspect that any approach that was chosen was the result of negotiations
>and discussions among those who took part in the discussion at that time.
>Any solution would raise questions in a societal setting, since unanimity
>is not the norm in a democratic process.  The RFC process has extended so
>deep and so far that change may be difficult, though not impossible.

You are right and Fred's and John's comments below show it. The RFC system 
is part of the legacy technology, is defined by an RFC and will die with 
TCP/IP, or kill it.

Is this a reason to come back and stay in 1983 (I would then chose another 
technology :-). The same reasons are given here as to keep the DNS as it 
is: 800.000 nameservers out there - yet IDNA came. The same reason as about 
LHS, yet John wants to go ahead.  Experience does not mean fossilization.

>specifically address the issue you raise.

Unnecessary comment. "generally field tested" is not a QA definition of 
what I call serious experimentation and not of what I call global user 
approbation. Even a braod user acceptance is not the proof of valid 
proposition. The current e-mail is universally accepted but it is not a 
good solution as spam shows it every day.

I spent time enough on a DNS experimentation test bed project these past 
two tyears to know that real life technical, societal and governantal 
experimentation is a concept foreign to the internet community.

>But we do things in a particular way that mostly works (although it should 
>probably be more effectively and accessibly documented), and, while we 
>might tune things differently or use different terminology if we were 
>starting over today, what purpose would it serve to develop redundant 
>mechanisms that would require extra volunteer or staff effort to make work 
>and keep working and that would leave people uncertain as to where to go 
>for information?  And what purpose is served by proposing such an action?

Let just consider the standard path, not the reducing exceptions. The RFC 
system suffers from being mainly a mental exercise between two realities it 
does not relate very well with (the demand and the operational supply). 
When I rise the question "what to do to restore a situation where RFC are 
not respested" the only response I get is "stick to the RFC". When someone 
says "I have two hours to work I want to know the IETF state of art/mind on 
a matter", the response is "spend months reading every elucubration in a 
old WG mailing list".

Up to now users are absent in the IAB/IETF process.
Operations, R&D, deployement etc. calls for more. I did not say a change.

On 16:13 09/01/04, [email-masked] said:
>Unfortunately, "market standards" often include borken things that are 
>adopted via forced-feeding.  More than one vendor has done this, and some 
>research would probably find at least one example at each of the 7 OSI layers.

True. This is why I talk of compromise. To take the beast from both.

What I see is that WGs lack serious market/user demand studies. They 
replace that with their own evaluation of their reasonable proposition. 
This permits evolution, not innovation, no break through.

IMHO, there should be two documents/prcess added to an RFC (not replacing it):

1. Up stream: a Users Needs Summary. Including what WG may propose, market 
studies, visionnaries suggestions, etc.
2. down he stream: a List of Comments by authors, implementers,users; etc. 
The LOC will comment how the RFC addresses the UNS.

The authors/mainteners of such documents should be professionals. There are 
tools to help.
Closing a WG maens that the RFC porcess is closed. This is whan RFC support 
is to take over.
jfc

---

From: Wawa Ngenge <[email-masked]>
Date: Fri, 9 Jan 2004 19:09:35 -0600 (CST)

Thank you. This does answer the question, and is a good example of how to 
approach questions in a societal forum like ISDF where even rhetorical 
questions may hide a cry for information.  Once again, thank you.
w

 On Thu, 8 Jan 2004, John C 
Klensin wrote: > --On Thursday, 08 January, 2004 12:50 -0600 Wawa Ngenge

---

From: Wawa Ngenge <[email-masked]>
Date: Fri, 9 Jan 2004 19:30:35 -0600 (CST)

wawa

---

From: veni markovski <[email-masked]>
Date: Sat, 10 Jan 2004 07:00:19 +0100

Dear Wawa, John, and colleagues,
Talking about approaching questions in a societal forum like the ISDF...
I am following your discussion but don't feel certain I should write to the 
IETF mailing list, so I will only respond in the list where I am subscribed 
- the ISDF.

veni