Subject: Re: [idn] Future of the requirements document

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Wed, 12 Dec 2001 06:57:55 -0500

James,

> The decision to drop requirements is explained in the wg chairs
> statement and is independent of your appeal.

Chairs do not decide, they attempt to observe and correctly state the
rough consensus of a working group.

> But your (and David) volunteer to take over as editor of requirements is
> also noted. Nevertheless, the value of requirements is lesser now and it
> is agreed in Salt Lake to drop the requirements. (Minutes will be
> available soon).

Face to face meetings do not decide, they reach (or don't) some consensus,
which the working group may (or may not) affirm, again, by rough consensus.

Eric

---

From: "James Seng/Personal" <[email-masked]>
Date: Wed, 12 Dec 2001 21:42:18 +0800

> rough consensus of a working group.

Of course. We proposed and we observe how the group see our proposal. As
I said, your objection is noted. We have also observed others reaction
to this, not neccessary on the mailing list.

But my note is to explain the reason behind this proposal is has nothing
to do with your appeal nor any indication of the editors conduct as you
suggested.

> which the working group may (or may not) affirm, again, by rough
consensus.

Of course. But members feedback to the wg chairs in the face-to-face
meeting, in corridor/bar converdation and in private emails is as
important as the mailing list. All these are feedback to the chairs on
the group rough consensus.

Your objection is noted. This is why it is "rough".

-James Seng

---

From: [email-masked] (J. William Semich)
Date: Wed, 12 Dec 2001 09:30:30 -0500

>to this, not neccessary on the mailing list.

I think that it is *very* important that any "reactions" be posted to the 
public list, especially if they are being used to form a decision as to 
what a "rough consensus" is on these matters

<snip>

>the group rough consensus.

Again, I believe it is not appropriate for the chairs to determine "rough 
consensus" based on private communications - all should come from public 
input, not secret comments which can not be discussed in the open.

Bill Semich

---

From: "James Seng/Personal" <[email-masked]>
Date: Thu, 13 Dec 2001 00:58:35 +0800

> what a "rough consensus" is on these matters

Within IETF framework, there is nothing which say that "rough consensus"
are determined only by public lists discussion.

However, given the sensitivity of the work we doing, I certainly agree
with you that comments should (not must) be made as public, either
mailing list or face-to-face meeting, as possible. Private discussion
opinion will also be considered but we certainly place more value in
public discussion, either on the mailing list or face-to-face meeting.

I would prefer we drop this IETF process discussion (which is best deal
with in another group) and get back to our technical work.

-James Seng

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Wed, 12 Dec 2001 12:16:39 -0500

James,

Please compare your response to Ms. Ye, and your response to Mr. Semich.

Ms. Ye's draft's "supporters" must meet a criteria.
Mssrs. Seng and Blanchett's rough consensus "commentors" need not.

Even if Ms. Ye's draft was worth reading (IMO it is not, having done so),
and even if I'd blind faith in the intelligence, judgement, and humor of
Mssrs. Seng and Blanchett (I don't, and I get no pleasure from that), it
would still be a dubious proposition that either could offer anonymous
(and possibly ficticious) personas as being sufficient to meet either a
test for community interest (in a draft) or community consensus (in an act).

If there really is consensus that "the IDN WG doesn't need any requirements"
or that "the requirements for the IDN are self-evident to the WG", or any
variation on the theme of "badges, we don't need no stinkin' badges", then
fine. So state and be done with it.

Eric

---

From: "James Seng/Personal" <[email-masked]>
Date: Thu, 13 Dec 2001 01:24:14 +0800

The minutes of the meeting will be posted soon. You can draw your own
conclusion on the "rough consensus" then.

But your objection to drop requirements is noted.

ps: comparing criteria for wg i-ds and WG co-chairs proposed next step
is apple and orange.

-James Seng

----- Original Message -----
From: "Eric Brunner-Williams in Portland Maine" <[email-masked]>
To: "James Seng/Personal" <[email-masked]>
Cc: <[email-masked]>; "Eric Brunner-Williams in Portland Maine"
<[email-masked]>; "J. William Semich" <[email-masked]>;
<[email-masked]>
Sent: Thursday, December 13, 2001 1:16 AM
Subject: Re: [idn] Future of the requirements document

---

From: [email-masked] (J. William Semich)
Date: Wed, 12 Dec 2001 12:30:51 -0500

Thanks for the clarification.

Regards,

Bill

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Sat, 15 Dec 2001 08:26:13 -0500

James,

> conclusion on the "rough consensus" then.

You are referring to the "rough consensus" of those contributors who were
in a room in Salt Lake City. While interesting, the working group process
places the venue in which "rough consensus" authoritatively forms in the
working group itself.

> But your objection to drop requirements is noted.

Good.

> ps: comparing criteria for wg i-ds and WG co-chairs proposed next step

The issue here is the openness of the process of the IDN WG.

Please see rfc2026, section 6.5.

Your failure to observe open review will result in a my making a second
assertion of process error.

Eric

---

From: "James Seng/Personal" <[email-masked]>
Date: Sat, 15 Dec 2001 22:40:23 +0800

> in a room in Salt Lake City.

Yes.

> While interesting, the working group process

No, as I said, your objection is noted.

> The issue here is the openness of the process of the IDN WG.

They are fundamentally different. One is a process which the group have
agreed upon to narrow down our focus on I-Ds. The other is a process
which the co-chairs do to make progress. Their is nothing "close" or
"secretive" about it. All co-chairs statement are made public.

> assertion of process error.

Anyone can make process error appeal, anytime, anywhere, whenever he/she
feel it, with valid reasons or without.

While I am not suggesting you to do so, this is not a basis of argument
to prevent us from moving forward. Someone here once said "the fear of
lawsuit should not prevent the business moving on".

IDN is a sufficient important enough working group that we have enough
members from IAB & IESG who is monitoring this group. If there is indeed
any process error as you indicated, I am sure we will hear from them so
fast before you need to say it.

So, having said that, I do not see any technical value in this argument
in IDN anymore nor is this in the core-interest of the group. I suggest
you bring this thread offline or to another group (poised comes to mind)
if you wish to continue this. It is disruptive to those who wish to make
progress here.

-James Seng

---

From: "ben" <[email-masked]>
Date: Sat, 15 Dec 2001 11:10:46 -0500

I apologize for wasting bandwidth, but this reminds me of a little
story I heard when I was a kid...

In China, many people are vegetarians because they believe it is a sin
to kill any living thing.  So the story goes... two men are crossing
the river with a boat.  One man is a passenger and the other is the
skipper.  The passenger is a business man who desperately wanted to
get to the other side quickly and asked the skipper to paddle as fast
as he can possibly paddle.  The motive of the skipper is ofcourse to
earn as much money as he could, so he is more then happy to oblige to
this wealthy businessman.  Standing on the shore observing the boat
were 2 other people.  One is a very old wise man and the other is a
guy named "Mr. Troublemaker".  Mr Troublemaker, true to his name,
asked the old wise man, "There is no doubt that the paddle hitting the
water with such force will kill some fishes.  Who is then *more* at
sin for the death of the fishes- is it the skipper who actual killed
the fishes or is it the businessman who paid the skipper to do it?"
Mr. TroubleMaker then had a very satisfying and evil grin on his face
because he though his question had stumbled the old wise man.  Instead
the old wise man calmly responded, "Neither, because the motive of the
businessman is to cross the river and the motive of the  skipper is to
make money.  Neither had the intention of killing the fishes.
Instead, *you* are the one who is sinned for the death of the
fishes... because if *you* did not deliberately bring up this idea of
dead fishes under water, then no one would even know nor care and
everyone would be happily on their way."

Thanks,
Ben

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Sat, 15 Dec 2001 11:33:32 -0500

James,

2026 is there to help you conduct the affairs of the WG, whether you like
it or understand it.

Eric

---

From: "James Seng/Personal" <[email-masked]>
Date: Sun, 16 Dec 2001 03:05:29 +0800

And chairs job is to help the process to get to rough consensus, whether
the rough consensus is one you like or or understand it.

Thank you for your reminder on 2026. We are still within the process as
far as we know.

Let me remind you again that this is not core interest to the wg. Bring
it offline or bring it elsewhere. Thank you.

-James Seng

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Sat, 15 Dec 2001 14:44:18 -0500

James,

On what date did the chairs determine that there was rough consensus to
abandon the IDN WG requirements draft?

Eric

---

From: "James Seng/Personal" <[email-masked]>
Date: Sun, 16 Dec 2001 04:18:05 +0800

AFAIK, Not yet.

james

----- Original Message -----
From: "Eric Brunner-Williams in Portland Maine" <[email-masked]>
To: "James Seng/Personal" <[email-masked]>
Cc: "Eric Brunner-Williams in Portland Maine" <[email-masked]>;
<[email-masked]>; "J. William Semich" <[email-masked]>;
<[email-masked]>
Sent: Sunday, December 16, 2001 3:44 AM
Subject: Re: [idn] Future of the requirements document

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Sat, 15 Dec 2001 15:40:17 -0500

James,

If the chairs haven't made such a determination, then what did this bit
you wrote earlier today mean?

	Let me remind you again that this is not core interest to the wg.
	Bring it offline or bring it elsewhere. Thank you.

If you two haven't made a claims that consensus exists several times since
Monday, then someone is fairly good at forging your mail.

Is there some reason why the contributors who didn't attend the Salt Lake
meeting haven't been asked the same question those who attended were asked?

Eric

---

From: Dave Crocker <[email-masked]>
Date: Sat, 15 Dec 2001 11:57:07 -0800

>rough consensus of a working group.

Eric, he said an *explanation* was in the wg chair statement, not that the 
decision was simply or purely a wg chair decision.

In fact there was significant discussion in the wg meeting in 
SLC.  (Personally, I would have rather spent the time on actual technical 
advancement discussions, but there is equally a good argument for touching 
all the bases that needed to be pruned and solidified, including this one.)

It is quite common -- and acceptable -- for IETF meeting discussion and 
rough consensus to be used as establishing a prima facie basis for a 
decision.  That is, rather than needing to do an open-ended query of the 
mailing list, IETF meeting consensus is often taken as the de facto 
decision, only pending extensive objection on the list. If there is no 
extensive objection, the decision stands.

Working Group chairs are charged with making forward progress.  Asserting a 
positive decision, and waiting for objections, is just as valid as 
asserting a multi-valued choice and asking everyone to express favor for 
one value or another.  The former is more efficient, albeit riskier.  It 
therefore needs to be used selectively.  In my opinion, its use here is 
entirely appropriate.

>which the working group may (or may not) affirm, again, by rough consensus.

To the extent that there is a mail-swell -- the Internet version of a 
ground-swell -- of list support for your concerns, that will of course be 
significant and probably decisive.  To the extent that this thread 
continues to be a concern expressed by only one or two participants, this 
will demonstrate a de facto list *concurrence* with the meeting consensus.

For everyone:  the line of discussion about use of private comments is a 
complete and immediate rathole.  It needs to be dropped unless and until 
there is a strong basis for claiming that rough consensus is not 
visible.  So far, there is no such ambiguity.  Instead, there is extended 
theoretical debate about a theoretical problem.  Not a constructive path, 
folks.

As to the matter of whether IDN process is sufficiently open, I'll note 
that I think it has, if anything been TOO open.  And, no, I do not really 
mean that.  What I mean is that it has spent too much time constantly 
taking in everyone's comments and not enough time making forward progress.

This working group is pursuing a technically very difficult and socially 
very sensitive topic.  Hence it is essential that there be even more 
listening and discussing than is typical for IETF groups.  We usually do 
quite a bit.  Here, we have needed to do even more.  Still, there comes a 
time to stop listening and start deciding.

A wg chair's task is particularly difficult because they must balance 
between taking that input and moving the wg forward.  Too much of either 
one defeats success.  In my view -- even given the requirement that the IDN 
wg do more listening than usual -- we have done too much of it, and not 
enough deciding.

And just to underscore how extreme the disparity of perceptions between 
Eric B-W and myself I will comment that I was considering filing an appeal 
about IN-action!  (The Monday IDN meeting eliminated that consideration; I 
am mentioning it just to underscore a very different perspective on the wg.)

The wg chairs have now started forcing progress.  As to whether it is 
premature, I will simply state that I think it is one year overdue.  Again, 
I mention this not to complain but to demonstrate an alternate perspective.

A test of whether it is being done "correctly" is to consider the tone of 
the group in a face-to-face meeting.  In my opinion, the tone in SLC was 
fine.  Not without people making objections, of course, but overall it was 
comfortable and relatively efficient.  Both are excellent indicators of 
acceptable process.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Sat, 15 Dec 2001 15:56:41 -0500

Dave,

I don't need, or expect, a ground swell. This isn't a popularity contest.

There are some questions:

	are requirements a technical necessity?

	is the process of transition from a WG with a document under the
	change control of the WG, to a WG without that document, within
	what we know of as the IETF's process?

In my opinion, absence of requirements is a technical error.

In my opinion, the transition attempted is a process error.

Thanks for the note. I appreciate your views. You've mine.

Eric

---

From: Dave Crocker <[email-masked]>
Date: Sat, 15 Dec 2001 13:31:15 -0800

(my last posting on this thread.)

>I don't need, or expect, a ground swell. This isn't a popularity contest.

Any one person may (and should) post a notice whenever they discover that a 
technical specification is fatally flawed.  That is, a claim that a 
technical solution "will not work" is may be posted at any point in the 
process, and it does not matter whether there is one person or many people 
posting that view.

On the other hand, matters involving more flexibility than outright failure 
ARE really a popularity contest.  That is what Rough Consensus is about.

We do not use the term "popularity" because it is vulgar and demeaning, but 
ultimately, it is a practical view of the way IETF choice is made.

Of course, we hope and expect that rough consensus popularity is due to 
practical superiority of a technical idea, rather than personal or business 
factors.  Ultimately, however, we have no control over people's criteria.

>         are requirements a technical necessity?

Yes, but requirements *documents* are not.

d/

----------

---

From: Rick H Wesson <[email-masked]>
Date: Sat, 15 Dec 2001 16:41:18 -0800 (PST)

Eric,

> In my opinion, absence of requirements is a technical error.

the absence of requirements is not a technical error. the requirements are
out of sync with reality, and as I said at the meeting in SLC,

   Its too late to write the recipie when the cake is nearly fished
   baking.

> In my opinion, the transition attempted is a process error.

hmmm, i believe as I feel others do too, that its not a process error, but
reasonable to drop the requirments as we are nearly done with a solution
and the requirements are out of touch with reality. Writing the
requirements as a port-mortum excercise we shouldn't call them
requirements and IMHO, we don't need to bring them into sync just to get
the consensus documents pushed to the IESG.

-rick

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Sat, 15 Dec 2001 20:25:19 -0500

Rick,

Is that your best engineering judgement, that absence of requirements is
not, in general, a technical error? Is there something self-evident about
IDN in particular that makes the absence of requirements a non-error?

I'm quite sure you feel as others do, that there is no process error. The
authors of 2026 felt that if one did, that was sufficient to afford for a
review mechanism.

As the subject was not broached to the list prior to the meeting, and was
presented as a fait-accompli, the sudden optimism that requirements are a
distraction, and progress self-illuminating and certain, is a surprise.

Each of you must be very certain of your actions, and secure in their
outcomes, and unconcerned by the possibility of error.

Eric

---

From: Rick H Wesson <[email-masked]>
Date: Sat, 15 Dec 2001 18:58:39 -0800 (PST)

Eric,

> IDN in particular that makes the absence of requirements a non-error?

yes, i'm quite confident in my assertion that the requirements should be
dropped; I do wish you could have been there for the meeting we had a nice
debate about the topic.

> distraction, and progress self-illuminating and certain, is a surprise.

hmm I remember seeing it in the chairs notes before the meeting, and as a
topic on the agenda, so there was time for you to raze the issue.

> outcomes, and unconcerned by the possibility of error.

hey, i make mistakes all the time and if i do i try to do them in the full
public view just so i can be ridiculed; and i usually take the time to say
i made a mistake, but this time i don't think i have. i think we are
finally and appropriately focused.

-rick

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 18 Dec 2001 07:40:25 +0100 (CET)

Eric,

As John pointed out on Dec 10 it was the ADs and technical advisors
that (reluctantly) recommended that the WG abandon the requirements document.

While the initial process that lead to the requirements draft where quite
useful by developping a common way to talk about things and a common
understanding of the issues around the DNS, it isn't obvious to me that
investing the WG cycles to get closure on all aspects of the requirements
draft would be worth the effort.

I yet haven't seen an email explaining how the WG would *use* a requirements
document moving forward given that the document
hasn't been used as a reference when analysing proposals so far.
(The requirements in the document have been used but not by actually
referring to the document.)

   Erik

---

From: "Soobok Lee" <[email-masked]>
Date: Wed, 19 Dec 2001 04:47:47 +0900

----- Original Message -----
From: "Erik Nordmark" <[email-masked]>

> referring to the document.)

Erik,

I would suggest one *usage* of IDN requirement document.

It's well known that the enclosed IDN requirement items are not fully satified by current set of IDNA protocol drafts. It's too
early to drop the requirements document , because we haven't finishef reviewing and assessing future final versions of those drafts,
some of which are still under revision .

If some requirements are turn out to be practically unsatisfiable at last,
those final protocol drafts should clearly describe  what requirements they cannot
satify  based on those requirement document  and  should wait judgements
from IESG  on whether those consequences are neglectable or not.

Writing another new shorter requirements document, intentionally avoiding the following hot-debated yet-unsatisfied requirement
issues, looks poor and is unlikely to succeed. No one would like to go to this path. It is not a "path".

Regards,

Soobok Lee
==========

[11] The protocol should handle with care new revisions of the CCS.
Undefined codepoints should not be allowed unless a new revision of
the protocol can handle it. Protocol revisions should be tagged.

[23] If other canonicalization is done, it MUST be done before the
domain name is resolved. Further, the canonicalization MUST be easily
upgradable as new languages and writing systems are added.

[24] Any conversion (case, ligature folding, punctuation folding, etc)
from what the user enters into a client to what the client asks for
resolution MUST be done identically on any request from any client.

http://www.ietf.org/internet-drafts/draft-ietf-idn-requirements-09.txt

----- Original Message -----
From: "James Seng/Personal" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Wednesday, October 03, 2001 1:56 PM
Subject: [idn] Request to advance "Requirements of Internationalized Domain

> Names"
> Date: Wed, 3 Oct 2001 09:04:35 +0800
> Sender: [email-masked]
> Precedence: bulk
>
> Erik & Thomas,
>
> The chairs of the International Domain Names Working Group, on the
> behalf of the working group, request that the following document be
> published as a Informational RFC:
>
> Title : Requirements of Internationalized Domain Names
> Author(s) : Z. Wenzel, J. Seng
> Filena    me : draft-ietf-idn-requirements-08.txt
> Pages : 8
> Date : 22-Jun-01
>
> A working group last call was conducted on 13th Feb 2001. "-08" on 22th
> Jun 2001 was produced in responsed to the comments made and subsequence
> discussion. The wg agreed in the London IETF meeting to advance this
> document.
>
> James Seng / Marc Blanchet
> IDN Working Group Co-chairs
>
>

----- Original Message -----
From: "John C Klensin" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, December 11, 2001 12:47 AM
Subject: [idn] Future of the requirements document

> As one of the people who (reluctantly) advised the co-chairs to
> drop this, let me clarify my position at least...
>
> * Requirements documents are good.
>
> * Requirements documents that are either seriously
> ambiguous are not so good.
>
> * When there is a requirements document, protocol
> documents that don't satisfy those requirements are
> really, really bad.
>
> Now, our current situation, as I see it, is:
>
> (i) The WG is long overdue for getting results out.  We need to
> finish and wind it down.  Things that block moving forward had
> best be really, really, important.
>
> (ii) If there is a requirements document in the queue that
> doesn't appear consistent with the protocol documents, it is
> unlikely that the latter will move forward before the differences
> are resolved.  That is called "more delay".
>
> (iii) The current requirements draft has some writing problems
> and dangling references, some technical problems, contains some
> requirements statements that the current proposed protocols don't
> satisfy.   And we (the co-chairs, the technical advisors, the
> ADs) don't believe there is real WG consensus around the current
> document (silence or nods from people who haven't read it
> carefully don't count).   Fixing it would take significant time
> and energy.  The experience of the past two years leads us to
> believe that the energy isn't present, even if we were willing to
> invest the time (and delay with WG).
>
> On the other hand, one of the most important values of a
> requirements document is that it provides a foundation for, and a
> record of, a statement about the problem the WG tried to solve.
> Having that seems quite important to us, but we think that
> writing it and getting consensus on it would likely be a much
> quicker process than cleaning up the requirements piece and
> getting consensus on it.
>
> That is, again, subject to discussion.  But I'd hope that those
> who advocate keeping/ fixing the requirements doc explain why it
> is important enough to keep the WG in operation --and hold up the
> protocol documents-- for what I think would be many extra months.
>
>       john
>
>

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 19 Dec 2001 23:29:47 +0100 (CET)

> It's well known that the enclosed IDN requirement items are not fully
> satified by current set of IDNA protocol drafts. It's too early to drop the
> requirements document , because we haven't finishef reviewing and assessing
> future final versions of those drafts, some of which are still under
> revision .
> 
> those final protocol drafts should clearly describe  what requirements they
> cannot satify  based on those requirement document  and  should wait
> judgements from IESG  on whether those consequences are neglectable or not.

It's also believed that the set of solutions that satisfy the requirements
document in its current form is the null set.
If that is indeed the case there should be no suprise that IDNA, just
like any other proposal, can't satisfy all of them.

*If* the requirements document indeed captured the minimum requirements
and there were multiple fully worked out proposals then the document could be
useful as a guide in selecting between the proposals.
But given that the requirement document doesn't appear to (correctly) capture
the minimum requirements it would seem like this approach assumes that the
WG would spend time first on correcting the requirements document then
looking around for additional fully specified proposals.
This would not be fast process.

Thus assuming we all actually want to see an IDN solution soon it seems
to make a lot more sense to drop the requirement document.
The WG last call, IETF last call, and IESG review can then focus on 
more basic questions like:
1. Does the proposed protocol work?
2. Can it be introduced in some incremental fashion?
3. Can it deal with the future?

> Writing another new shorter requirements document, intentionally avoiding
> the following hot-debated yet-unsatisfied requirement issues, looks poor and
> is unlikely to succeed. No one would like to go to this path. It is not a
> "path".

Note that John and the chairs did not suggest a shorter requirements document
but instead a document which describes the problem the WG set out to solve
(and presumably something about the believed constraints for solving the
problem).

If it happens to be that the requirements document, even after resolving
the hotly debated issues you are alluding to, ends up so strict that there
still does not exist a solution, what would we have accomplished?

   Erik

---

From: "Soobok Lee" <[email-masked]>
Date: Thu, 20 Dec 2001 22:02:05 +0900

----- Original Message -----
> This would not be fast process.

If we drop the agreed-on requirement document that solutions can't satify yet, we will look like a ostrich who buries its head in
the sand  before a tiger.

What really matter is whether or not we should ignore unsatisfied requirement
items. Fixing old one and writing new one, either one  cannot avoid this issue.

> to make a lot more sense to drop the requirement document.

No one would like to eat unbaked or half-baked or rotten cakes, however soon they come out. If IETF is ever driven by consumers and
work for consumers,
current provider-centric haste and biases in IDN WG could not have been tolerated.

> still does not exist a solution, what would we have accomplished?

I am  not so pessimistic, if we become less political than now and in SLC.

Soobok Lee

---

From: John C Klensin <[email-masked]>
Date: Thu, 20 Dec 2001 10:27:38 -0500

Length and tedium warning: I'm going to try to explain the
reasons I recommended dropping the requirements doc, and what I
really recommended instead, one more time.  Those who have
ceased caring should hit "delete" now.

--On Thursday, 20 December, 2001 22:02 +0900 Soobok Lee
<[email-masked]> wrote:

>> It's also believed that the set of solutions that satisfy the
>> requirements document in its current form is the null set.
>> If that is indeed the case there should be no suprise that
>>...
> If we drop the agreed-on requirement document that solutions
> can't satify yet, we will look like a ostrich who buries its
> head in the sand  before a tiger.

If we had an agreed-on requirements document, the above might be
true.  Or relevant.  But we don't.  What we have, as far as I
can tell, is a document that few people in the WG have recently
read carefully and "agreement", if any exists, that it isn't
worth the time for such reading and comment.  

It is perhaps interesting that those who have been reading the
thing carefully seem to include those who are most unhappy about
some of the recent WG directions and decisions. You, Eric, and
myself are clearly in that category, although for different
reasons.  But, unless we have reached the point of preferring no
result from the WG, or indefinite delay, if we cannot get the
solutions we each prefer --I have not-- then it is probably
better to argue about substance than about requirements
documents, especially if we can get others to read carefully and
engage in discussions on the former and not on the latter.

Speaking personally, I would have preferred that the WG not have
started on any protocol work until it agreed on a requirements
statement.  I said that at the time the switch was made.  On the
other hand, the pressures to develop protocols were very high
and it is possible that, had we taken a firm "requirements
first" course, we would still be debating them and nothing else.

> What really matter is whether or not we should ignore
> unsatisfied requirement items. Fixing old one and writing new
> one, either one  cannot avoid this issue.

Again, if I really saw informed and considered agreement about
those items, I would feel differently about trying to retain and
repair the document.
 
>> Thus assuming we all actually want to see an IDN solution
>> soon it seems to make a lot more sense to drop the
>> requirement document.
> 
> No one would like to eat unbaked or half-baked or rotten
> cakes, however soon they come out. 

At the risk of being very blunt, I believe that the real
"requirement" for the WG, as seen by a number of people, is that
it emit a standard, _any_ standard, and do so soon.  For them,
meeting one functionality goal or another may be less important.
If you think their desire is for unbaked cakes as an improvement
over eating raw and unground grain, I might agree with you.  But
the evidence from discussions in the WG and elsewhere is that
"they" outnumber "us".

> If IETF is ever driven by
> consumers and work for consumers,

Well, that is impressive.  At one time or another, the consumer
demand has been at least as strong as the provider demand, and
less patient.  I suggest that different consumers want different
things (just as different providers do) and that the differences
are among the reasons why it has been hard to converge on a
requirements document for which there is general agreement.  I
think some of those consumers had best be [more] careful about
what they wish for, but I've been saying that for a couple of
years now.

>> Note that John and the chairs did not suggest a shorter
>> requirements document but instead a document which describes
>> the problem the WG set out to solve (and presumably something
>> about the believed constraints for solving the problem).
>> 
>> If it happens to be that the requirements document, even
>> after resolving the hotly debated issues you are alluding to,
>> ends up so strict that there still does not exist a solution,
>> what would we have accomplished?
> 

And I am more pessimistic than Erik because:

	* I don't know where to find some mechanism or drug that
	would make IDN "less political".  Instead, I see it as
	becoming more political the more time elapses before we
	have a solution.
	
	* The people who appear to be most in favor of working
	on the requirements document are those whose substantive
	positions have already been abandoned or ignored by the
	WG.

Again, I count myself, and both the "don't use tricks, use a new
Class" and the "if one needs to do some of this in a
directory/search layer, then do all of it there and don't put
the DNS at risk" positions to be in that second category.  But,
as you have noticed, I've concluded that the WG doesn't want to
address those alternatives, so I am not raising them every week,
nor am I trying to sneak them back in via a "requirements"
document.  I might feel differently about that document if the
WG were interested -- with "interest" measured in terms of
careful reading and discussion by more than a few people -- but
I don't see that interest.

And, as Erik suggests, I'm not advocating a stripped-down
requirements document, or giving up entirely.  I think that most
of the authors of the remaining proposals recognize that they
are not solving the whole problem (those who don't have probably
not been paying enough attention).  So I would like those
authors or their supporters to write introductions to their
particular proposals that document the problems they think they
are solving (and, to the extent possible, those they are not).
Such statements would give the WG, and the IETF, a much stronger
basis for evaluation than a requirements document that has, at
best, lukewarm consensus: they would permit asking, in a focused
way, whether the problem being solved was worth the trouble and
whether the proposed solution actually solved that problem.

    john

---

From: Rick H Wesson <[email-masked]>
Date: Thu, 20 Dec 2001 07:59:59 -0800 (PST)

Soobok Lee:

On Thu, 20 Dec 2001, Soobok Lee wrote:

[snip]
>
> If we drop the agreed-on requirement document that solutions can't
> satify yet, we will look like a ostrich who buries its head in the
> sand before a tiger.

we don't agree that we should have the document, this is just one reason
why we don't have a requirement document.

> What really matter is whether or not we should ignore unsatisfied
> requirement items. Fixing old one and writing new one, either one
> cannot avoid this issue.

why don't you draft up the requirements document and see if you can get
everyone to agree to it? Since you have the energy, direct it in a
positive fassion and write.

> No one would like to eat unbaked or half-baked or rotten cakes,
> however soon they come out. If IETF is ever driven by consumers and
> work for consumers, current provider-centric haste and biases in IDN
> WG could not have been tolerated.

ummm, ok thats my quote you are butchering, but thats ok. The point is
we don't need to write requirements that we can'e agree on after we agree
on our final set of documents. look, everyone has had alot of time to work
out these matters. If you want the requirement document so badly get
everyone to agree, write the doc, then get everyone to postpone while we
evaluate if the proposals fit the requirements. sure, you get everone else
to agree with you and i'm in too.

-rick

---

From: "ben" <[email-masked]>
Date: Thu, 20 Dec 2001 11:18:07 -0500

Hi Soobok,

> current provider-centric haste and biases in IDN WG could not have
been tolerated.

I am sure your concern for the users/consumers is truly appreciated by
everyone.  I understand how you feel as I too have been fighting for
users as they are the ones who should ultimately benefit from our work
in this IDN WG.  However, the WG *has decided* and we are now at the
point where both your and my kind intentions will very soon become
"digging up dead fishes" if we don't stop.

Instead, it is now important for us to come up with ways/ideas to wrap
this up as quickly as possible.

Thanks,
Ben

---

From: Dave Crocker <[email-masked]>
Date: Thu, 20 Dec 2001 08:24:46 -0800

Folks,

If those who are so strongly in favor of a requirements document had put 
their energy into writing a new one, rather than posting messages to this 
long thread, they probably would be done by now.

d/

---

From: "ben" <[email-masked]>
Date: Thu, 20 Dec 2001 14:19:12 -0500

> this up as quickly as possible.

By the way, I just want to make it clear that this is in no way
"giving up" the needs of the users.  It is just that if this WG (which
we are all part of) will *never* accept those proposals (but will
rather drag things on forever then to accept them),  then it is much
better for everyone (including the users) that this WG make that final
decision (and indeed it has) and we all contribute to help it wrap up
as quick as possible.

The needs of the users *will be* satisfied with alternatives.

Thanks,
Ben

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 20 Dec 2001 18:49:10 +0100 (CET)

> If we drop the agreed-on requirement document that solutions can't satify
> yet, we will look like a ostrich who buries its head in the sand  before a
> tiger.

My concern is not "can't satisfy yet" - it is that there might not ever
be a solution which satisfies all the requirements in the draft.

> No one would like to eat unbaked or half-baked or rotten cakes, however soon
> they come out. If IETF is ever driven by consumers and work for consumers,

But, continuting your analogy, keeping the cake in the oven for too long
might not be ideal either. The result could be an overcooked or burned cake,
or the people that originally wanted to eat the cake might have gone elsewhere
for norishment.

Ignoring the analogy, I don't think we can delay this work forever until
it is viewed to be perfect. 

> I am  not so pessimistic, if we become less political than now and in SLC.

I think what you refer to as "political" is really that there is a rich set
of different assumptions, as well as views on what the "real" problem to
solve, among the WG participants. While the WG discussions have let to
better shared understanding of the issues, I haven't seen any indication
that the richness in assumptions has decreased over time. (But of
course I could be wrong on this.)

But even if this issue was not present there would be significant work to
actually get the requirement document to provide the right level of
requirements i.e. walk the fine line between capturing the critical and
important requirements and overconstraining the problem by placing too many
and/or to detailed requirements.

   Erik

---

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 20 Dec 2001 15:02:10 -0600

Erik Nordmark wrote:

> The result could be an overcooked or burned cake, or the people that
> originally wanted to eat the cake might have gone elsewhere for
> norishment.

Hmm, or the people get served wet dough under the pretense of cake, and go
somewhere else for the cake they really wanted.

> it is viewed to be perfect.

I don't think any of us expect anything to be perfect (lack of uppercase
non-ASCII is an obvious example of trade-offs already encountered). The
problem we have at this point is that there isn't even a "good enough"
specification. I mean, on the surface we have something that may work for
IDN zone delegation with legacy servers, but SRV owners, legacy ASCII
mixed case in PTR, valid mailboxes in SOA, legacy eight-bit domain names
are all invalid in the model. This is without even discussing potential
future problems. Incredible.

As to whether or not a requirements document is necessary, note that
several modifications were suggested which would have made it relevant,
the suggestions were ignored, and then the document was shelved by an
external committee. Well yeah, it's irrelevant without the changes, but
why exactly are we prohibiting the changes that would make it relevant? If
the only reason is to allow the advancement of an early solution that is
incompatible with existing and future usage models, well, that's a bad
call on multiple fronts, imo.

If people want to go some other path, let them. My guess is that the
squeaky wheels have sunk a considerable amount of time and capital into a
single likely outcome, and that anything outside of the head-start
advantage afforded by that outcome is going to be problematic for them.
Too bad, So sad, should have waited.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 20 Dec 2001 23:10:45 +0100 (CET)

Eric,

I didn't say that the discussion about IHN vs. IDN syntactic restrictions
are unimportant. Carefully defining this is important IMHO but most of
the discussion in the WG until recently has been about host names. 

Carefully definiting this doesn't mean we need the requirements document.

> external committee.

Not an external committee but the ADs for the working group.
I think the ADs are allowed to talk to people to get advise, which
is what happened in this case. And we're listening to the WG comments
on the suggestion to drop the requirements document. 
 
> advantage afforded by that outcome is going to be problematic for them.

I don't understand the above reference to "squaky wheel" - are you
referring to the proponents of the IDNA solution? (They seem to be relatively
quiet which is why I don't understand the reference.)

  Erik

---

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 20 Dec 2001 16:56:20 -0600

Erik Nordmark wrote:

> I didn't say that the discussion about IHN vs. IDN syntactic
> restrictions are unimportant.

Perhaps it would be best to table this aspect of the discussion until the
minutes from the meeting are posted, so that quotes other than those found
in trade press articles can be analyzed. "Final touches" doesn't sound
like there is much room for further analysis.

> > several modifications were suggested which would have made it
> > relevant, the suggestions were ignored, and then the document was
> > shelved by an external committee.
> 

My comment for consideration is as follows: if the critics are willing to
sink time and energy into making the guiding document relevant, they
should be allowed to do so. Give them plenty of rope to hang themselves,
as it were. Of course, if quotes like "Our basic architecture is done" are
accurate, then there is no point in it.

Somebody please post the minutes.

---

From: "ben" <[email-masked]>
Date: Fri, 21 Dec 2001 09:17:36 -0500

> this up as quickly as possible.

To put my money where my mouth is, here is my contribution to wrapping
this up ASAP:

It has become obvious that to re-write this requirement document at
this stage truly means that this requirement document has no practical
purpose... but is for formalities only.  If infact we are re-writing
this document for fomalities, then it would make sense to strip it
down to its bare minimum.  Such a document will be easy to write and
will be easily agreed by everyone (since there is nothing to disagree
with).

Thanks,
Ben