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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf