Re: [Seamoby] Paging Protocol Decision Description

"James Kempf" <kempf@docomolabs-usa.com> Wed, 16 January 2002 22:24 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22307 for <seamoby-archive@odin.ietf.org>; Wed, 16 Jan 2002 17:24:33 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA20819; Wed, 16 Jan 2002 16:45:16 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA20788 for <seamoby@optimus.ietf.org>; Wed, 16 Jan 2002 16:45:14 -0500 (EST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21605 for <seamoby@ietf.org>; Wed, 16 Jan 2002 16:45:04 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126]) by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g0GLfxS20763; Wed, 16 Jan 2002 13:41:59 -0800 (PST)
Message-ID: <022701c19ed6$6646a3e0$7e6015ac@T23KEMPF>
From: James Kempf <kempf@docomolabs-usa.com>
To: Behcet Sarikaya <behcet.sarikaya@alcatel.com>, seamoby@ietf.org
References: <018c01c19ec7$6d761420$7e6015ac@T23KEMPF> <3C45E485.2010400@alcatel.com>
Subject: Re: [Seamoby] Paging Protocol Decision Description
Date: Wed, 16 Jan 2002 13:40:21 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Content-Transfer-Encoding: 7bit
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting <seamoby.ietf.org>
X-BeenThere: seamoby@ietf.org
Content-Transfer-Encoding: 7bit

Behcet,

> 1. This text is not consistent with the minutes and the slides on
which
> your presentation was based at WG meeting in IETF 52.

The text I posted was my recollection, confirmed by Pat and
Allison, about the process we went through to make the decision.
There was a lot more detail than in my slides, because I wanted
to make sure that the authors of the proposals that were not
selected understood the decision process thoroughly. To the extent
that material from the slides was covered, I believe it is consistent.
For
example, the last paragraph cites a few examples of good
features in the various drafts that we would like to see in
the final result.Of those, only the security features from
draft-ohba were not on the slides, and that was an oversight
on my part, for which I apologize.

> 2. Regarding newly introduced comments on draft-guri, how come an
aspect
> that is good to have in the final draft becomes the reason for
rejection
> to select it?
>   Since you made no comments on draft-guri at SLC I could not raise
this
> question there, sorry about that :)

As I have told you before on this list, and as was stated in the
text I posted, draft-guri deals only with supporting L2 paging.
This is too limited to be the basis for the Seamoby IP paging protocol.
The text states that we want to see the ideas in draft-guri incorporated
into the final Seamoby protocol, and, as I have also told you before
on this list, we are working on
trying to organize a L2 Triggers BOF in Minneapolis so we can
discuss the kind of L2 triggers that are discussed on page 6 of
draft-guri. Seamoby is not the right place for this kind of work,
but we are trying to get one set up, and the L2 triggers work
for paging in draft-guri could be an important contribution. If, of
course,
you decide to participate.

> 3. The comments on hmipv6 belong to you personally, please check the
> slides on WG document status of MIP WG, you should be able to see the
> official opinion of WG chairs of MIP WG. I think that it is a serious
> problem to state strong opinions on the business of other WGs
especially
> if they are flawed.
>

I don't understand this comment. There is currently a draft,
draft-ietf-mobileip-lmm-requirements-00.txt, in the MIP
WG that outline requirements for an LMM solution. This
draft has not yet gone through WG Last Call, nor through
IETF Last Call, and so it does not yet have an RFC number.
That means that LMM is not yet out of the requirements phase.
This is what I said. We can't base the Seamoby paging
protocol on a protocol in another WG that isn't yet out
of requirements phase. The other WG might go through
the same kind of requirements assessment process for
competing protocols we've gone through
and come up with another protocol instead of HMIPv6
as the selected LMM protocol. Where would that leave
us?


> 4. The text does not mention the simple sum of the marks given to each
> draft?
>

A simple sum shows nothing. How should one rate under- versus
over-specification? In some cases, underspecification can be
a good thing, in other cases not. Same with overspecification.

In retrospect, I see now that putting numbers on these was a mistake.
It led people to believe that one could simply sum the numbers
and come up with a decision. Unfortunately, it was not so easy.
You can be assured that I will never use that technique again.

>   In short this text adds to the controversy failing to resolve
> anything.Regardless of what people say the conclusion is not going to
> change, right? Then why ask opinion of WG members? Is this normal? I
do
> not think such a system can be maintained.
>
>

Any such decision is always subject to WG concensus.
Unfortunately, the only voice we are hearing on the mailing list
right now is yours. One voice isn't enough for concensus, nor
is text from a private email forwarded and posted apparently without the
author's permission. Goodness knows, we have enough vocal
people on this list. It took us a year to get CT requirements
done (and we still don't have them in IESG Last Call!) because
everybody had an opinion. If I were seeing some of these people, who
were not authors of competing proposals coming forward and
saying that we should change the decison, it would be another
matter.

                    jak


_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby