Subject: draft-ietf-multi6-multihoming-requirements-04.txt

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 25 Oct 2002 14:35:00 +0200 (CEST)

Ok, I've taken the 03 requirements and made some changes:

3.2.7 "within the IESG" removed (Tony Hain)

2 Normativity removed (Brian E Carpenter)

"3.1.7 Alternate path visibility" added (Craig A. Huegen)

3.2.6 Added no cooperation with non-transit ISPs text  (Craig A. Huegen)

It is available for your perusal at
http://www.muada.com/drafts/draft-ietf-multi6-multihoming-requirements-04.txt

The most important difference with 03 is:

   The use of the words "must", "must not", "required", "shall",
   "shall not", "should", "should not", "recommended", "may" and
   "optional" is not meant to be interpreted as described in
   RFC 2119 [4]. The words "should" and "must" and "required" should
   be interpreted to indicate the described functionality is very
   important, and should be included if at all possible. However,
   lacking the indicated functionality doesn't automatically remove
   a potential solution from consideration as it may be impossible
   to create a solution that completely satisfies all requirements.

I think this is enough to make sure no solution will be killed over
technicalities. Does this mean everyone is inagreement now?

I assume the chairs will know what to do next?

Iljitsch

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 30 Oct 2002 03:48:26 -0500

On Friday, Oct 25, 2002, at 08:35 America/Montreal, Iljitsch van 
> 2 Normativity removed (Brian E Carpenter)

I actually object to this change.  It is *desirable* that approaches
which substantially don't meet the requirements get disallowed.
That is in fact the main reason for doing requirements in the first
place.

Ran

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 30 Oct 2002 10:25:48 +0100 (CET)

> which substantially don't meet the requirements get disallowed.

The IETF doesn't get to disallow things.

> That is in fact the main reason for doing requirements in the first

I'm missing the part where you say what should be in the requirements
instead.

I'm also missing the part where the chairs help move all of this along,
one way or another.

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 30 Oct 2002 05:14:34 -0500

On Wednesday, Oct 30, 2002, at 04:25 America/Montreal, Iljitsch van 
> The IETF doesn't get to disallow things.

IETF WGs have used requirements documents to disallow proposals for 
years,
not sure why you have concluded otherwise.

> I'm missing the part where you say what should be in the requirements

I've made numerous comments on the requirements draft over the life of 
this WG,
as the archives clearly show.  Not sure how you missed all of them,
but checking the WG archives should reveal them all.

Ran

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 30 Oct 2002 11:47:50 +0100 (CET)

> years, not sure why you have concluded otherwise.

Yes, the IETF has jurisdiction over its wgs, but not over much of
anything else. People ignore IETF wisdom all the time. That's why the
IETF is under the obligation to come up with solutions that are so good
people really want them, rather than adopt them because they're told to.

> but checking the WG archives should reveal them all.

Without going back and reading everything, I think it's safe to say it
would be impossible to include all the comments everyone made over the
life time of this wg into the requirements. So if you could state in
which way you'd want the requirements to change, based on the current
situation, that would be good.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 30 Oct 2002 15:37:01 +0100

Ran,

> That is in fact the main reason for doing requirements in the first

In some kind of free space, I'd agree with you. But given that this
WG has been manifestly hung up on this point since Salt Lake City,
I think we need to move on, and this is the only way I can see to
do so. The perceived requirements overconstrain the solution space,
and the only exit from that box is pragmatism.

   Brian

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 30 Oct 2002 11:38:21 -0500

On Wednesday, Oct 30, 2002, at 05:47 America/Montreal, Iljitsch van 
Beijnum wrote:
>  So if you could state in

	Restore the normative nature of the requirements document
-- including changing "may/should/must" back to "MAY/SHOULD/MUST".

Ran

---

From: Pekka Savola <[email-masked]>
Date: Wed, 30 Oct 2002 18:52:22 +0200 (EET)

> -- including changing "may/should/must" back to "MAY/SHOULD/MUST".

What do you suggest _when_ (not if) we run into the situation that we 
can't think of any solution which would satisfy all MUST's?

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 31 Oct 2002 09:47:09 +0859 ()

Ran;

> -- including changing "may/should/must" back to "MAY/SHOULD/MUST".

The problem is that the draft already contains mutually
exclusive requirements.

Requiring a requirement document is to suppress discussion.

It is a political way to autoritate an existing proposal, by a
list of requirements biased for the proposal.

Technically, it is harmful and, for problems related to multiple
areas of expertise, hopeless.

						Masataka Ohta

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 30 Oct 2002 21:20:59 -0500

On Wednesday, Oct 30, 2002, at 19:48 America/Montreal, Masataka Ohta 
> The problem is that the draft already contains mutually

It would be helpful if you would list any that you find
so any that exist can be resolved.  Details help.

Cheers,

Ran

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 31 Oct 2002 12:04:26 +0859 ()

Ran;

> so any that exist can be resolved.  Details help.

Search ML log.

						Masataka Ohta