Message-Id: <6.2.1.2.2.20050530035204.042aa920@mail.jefsey.com>
Date: Mon, 30 May 2005 04:30:09 +0200
To: Keith Moore <moore@cs.utk.edu>, Dave Crocker <dcrocker@bbiw.net>
From: "JFC (Jefsey) Morfin" <jefsey@jefsey.com>
In-Reply-To: <C0D01C0B-33A1-41B5-93BA-20928D294EC7@cs.utk.edu>
References: <200552885516.916263@bbfujip7>
	<C0D01C0B-33A1-41B5-93BA-20928D294EC7@cs.utk.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: ietf@ietf.org, Eliot Lear <lear@cisco.com>
Subject: Re: research in IETF (was: Re: Unnecessary slowness)
Precedence: list
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Dear Keith,

At 18:14 29/05/2005, Keith Moore wrote:
>>In the larger and more diverse IETF, I must entirely disagree with any
>>suggestion that IETF working groups can operate in a research mode
>>of any sort.
>
>I think you're simply wrong about that, for the reason that research
>and engineering are not mutually exclusive and it's difficult to draw
>a definite line between the two.  In particular, almost no IETF
>working group really understands the nature of the problem it is
>trying to solve at the time it is chartered, and to gain the
>appropriate level of understanding will often require some
>research.

Unless the WG is lead by a group which want to force an external 
proposition through.

>  I am also inclined to believe that protocol engineering
>almost inherently involves _more_ research than many other forms of
>engineering.  Designing protocols is not like designing bridges or
>automobiles in that most of the design constraints are understood
>when the effort is undertaken.  Every new protocol that is designed
>requires a new learning experience.  This is true even if there is a
>legacy protocol in the same space - because often that legacy
>protocol was not well-designed and does not adequately serve the
>needs of the broader Internet community.  Indeed, one of the "value
>adds" that IETF provides is the vetting of a design across a broad
>set of interests.  Denying the ability of IETF WGs to conduct
>"research" would remove much of that added value and impair IETF's
>ability to do a good job.

One of the form of this pre-research should be community experimentation. 
ICANN called upon such an experimentation in one of its reference document 
(ICP-3 Part 5/conclusion). It calls for it to be controlled by 
organisations such the IETF. Prior to launching such an experimentation in 
2001/2003, and from time to time, I recalled the ICANN's call on this list. 
The response was always that this is not the role of the IETF as a standard 
organisation to carry an operational test. However ICANN makes a very good 
point that Internet always developed that way...

The experimentation we carried shown that ccTLDs and national internet 
communities have the need for a permanent test-bed and for guidelines that 
only such an experimentation can really document and check. This is in 
domains I feel not covered by an IETF area (national security, naming and 
addressing sovereignty, multilingual ethics, service innovation, cultural 
empowerment and support, ICT convergence, user-centric network 
architecture, CRCs, externets, naming PADs, impaired users-support, network 
interoperating system, etc.) with possibly deep architectural and technical 
consequences in many areas.

I have undertaken the writing of a Draft on this. I can document what ICANN 
and our experimentation identified. I am embarrassed in documenting the way 
IETF should share in this experimentation and in its support. And how to 
include the work on resulting best practices in the IETF Internet standard 
process.

Some of the main problems I see are:
- which organising entity: ICANN calls (so it will not take the lead) for a 
community effort, IETF can advise but not organise? A specialised TF?
- which IETF area is/are concerned (IMHO every of them and more)?
- changes in the Internet usage architecture.
- probable involvement of other SDOs (ISO, MPEG, WSIS, WIPO, WTO, ICANN, etc.)?

>The existence of IRTF doesn't change any of this.  Nor would it be
>beneficial to anyone - IETF, IRTF, or the community of users - to
>require that every IETF WG be preceded by an IRTF RG so that the
>"research" phase of the engineering effort could be done in the
>"right place".  IRTF seems like a good place to do research in areas
>where we don't have a good grasp of the problem we want to solve and/ or 
>we don't have a good idea what the eventual engineering solution
>should look like.  But this doesn't mean that all research should be
>done in IRTF.

Another problem is the "time to the market" issue. There are areas like 
multilingual internet where the urgency of the need or commercial interests 
lead to the risk of propositions that no existing R&D can advise.

jfc


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf