Subject: [idn] Future of the requirements document

From: John C Klensin <[email-masked]>
Date: Mon, 10 Dec 2001 10:47:06 -0500

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: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Mon, 10 Dec 2001 11:27:22 -0500

Morning John,

Finding some editors who might be "better" isn't a delaying tactic.

Having a final work product that can't be compared with some set of
requirements (meeting most, hopefully, failing some, hopelessly) is
not something worth hurring towards.

The day to abandon a requirements draft unconditionally, is one day 
after the last draft with a dependency upon it is abandoned. If the
WG finds itself in the situation of being unnaturally prolonged in
life by an orphaned requirements draft, then by all means, send it
back to individual submission status.

Eric

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 10 Dec 2001 18:41:24 +0100 (CET)

> back to individual submission status.

Eric,

I haven't seen the WG make any use of the requirements document to date.
For instance, there has been no discussion saying something like
"your proposal doesn't satisfy requirement NN".
This makes we wonder whether the requirement document serves a useful purpose.

The original intent of this document was to get it agreed to and published
before the the solutions. You seem to suggest that the requirements document
could be used internally in the WG as it continues to work on solutions
and later be discarded (i.e. not published as an RFC).
Since the WG hasn't used the document in such a fashion until now what makes
you believe that things will change in this respect?

I think the discussion that lead up to the requirements document 
was quite useful but the current document has significant issues.
I think it makes more sense to spend the WG cycles on refining the 
and clarifying the WG work items. 

   Erik

---

From: David Hopwood <[email-masked]>
Date: Mon, 10 Dec 2001 21:59:40 +0000

-----BEGIN PGP SIGNED MESSAGE-----

Here is my position on the requirements document, FWIW:

 - I read the document very thoroughly when preparing the changes I
   suggested on 9 October, and I think that adopting those changes would
   fix all of the overspecifications and technical errors. No-one has
   objected to any of those changes, and none of them are particularly
   controversial.

 - as well as overspecifications, there are arguably some under-
   specifications in the document, but this is much less of a problem.
   I don't think it needs to be solved completely; just add a disclaimer
   that the requirements listed are necessary, but that there may be
   disagreement on their sufficiency.

 - there is value in publishing the document despite the previous point,
   as a historical record if nothing else. Its description of the
   relation between domain names and hostnames, and of the DNS
   architecture, is accurate and useful.

 - writing a new document to replace the requirements doc would take
   longer than fixing it. In fact, it could have been fixed a month ago
   if the authors had been more responsive.

> protocol documents-- for what I think would be many extra months.

The requirements doc isn't on the critical path for approving protocol
documents at all. If the authors don't feel they have time to fix it,
send me the nroff source and I'll make the changes.

- -- 
David Hopwood <[email-masked]>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Tue, 11 Dec 2001 10:14:39 -0500

Erik,

When I made my notice under 2026 of a process issue I tried to keep
both the issue, its background, and the proposed remedy as narrow
and as constructive as I could.

I asserted that the was a process error in the co-chairs failure to
direct the editors to be responsive to two specific comments, and
that the remedy could be as simple as the co-chairs direction to the
editors to be responsive, and that until the document reflects the
requirements of the WG that the IESG defer its action on the draft.
This would have captured my test-case, comments by others, and had
as small a consequential scope as could reasonably be expected to
fix the document, and fix nothing else.

It is a fact that a co-chair is a co-editor.

It is a fact that the co-chairs don't think that the editors have
been non-responsive.

Accepting documents by a working group, and discarding documents
by a working group, are working group actions. Every contributor,
chair, AD, etc., may hum one way or another on the consensus to
act on the question.

Now that the response to one or more process demands for either a
change, or an accountability for changes, or lack of changes, is
known to be abandonment in-place by the current editors, the only
proper course of conduct open is to find new editors.

I suggest that David Hopwood and I take on the responsibility of
being editors of the requirements draft, and that he and I bear the
responsibility for ensuring that only the necessary WG time is used
to make only the necessary changes in the requirements draft. I've
not asked David, but I have seen his note of today, and his prior
notes, both on changes and the frustration with non-response.

Assuming that Seng and Wenzel have expressed a desire to cease the
duty of being editors for a requirements document for this working
group, I volunteer. David has as well. There may be others able and
willing to do so as well.

The editors need only provide access to the current nroff source.

Eric

---

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

Your assertion of process error under 2026 have been noted by the ADs.
Explaination of your incorrect assertion have also been noted by the
ADs. AFAIK, the ADs have not make any conclusion of that assertion.

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

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).

You may disagree with the decision, of course.

-James Seng

---

From: David Hopwood <[email-masked]>
Date: Wed, 12 Dec 2001 00:40:59 +0000

-----BEGIN PGP SIGNED MESSAGE-----

> notes, both on changes and the frustration with non-response.

I'd just like to confirm that I'm happy to act as a co-editor for this
document (whether the current editors' names continue to be attached to
it or not).

- --