Re: [Seamoby] comments on the paging protocol assessment draft

Yoshihiro Ohba <yohba@tari.toshiba.com> Fri, 21 December 2001 21:52 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 QAA02808 for <seamoby-archive@odin.ietf.org>; Fri, 21 Dec 2001 16:52:10 -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 QAA17146; Fri, 21 Dec 2001 16:38:58 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA17113 for <seamoby@ns.ietf.org>; Fri, 21 Dec 2001 16:38:56 -0500 (EST)
Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02648 for <seamoby@ietf.org>; Fri, 21 Dec 2001 16:38:51 -0500 (EST)
Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id fBLLboJZ011496; Fri, 21 Dec 2001 16:37:50 -0500 (EST)
Received: from localhost (ohba@tari-dhcp1.research.telcordia.com [207.3.232.115]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id QAA11834; Fri, 21 Dec 2001 16:37:44 -0500 (EST)
Date: Fri, 21 Dec 2001 15:36:45 -0500
To: James Kempf <kempf@docomolabs-usa.com>
Cc: seamoby@ietf.org, Yoshihiro Ohba <yohba@tari.toshiba.com>
Subject: Re: [Seamoby] comments on the paging protocol assessment draft
Message-ID: <20011221203645.GD709@catfish>
Mail-Followup-To: James Kempf <kempf@docomolabs-usa.com>, seamoby@ietf.org, Yoshihiro Ohba <yohba@tari.toshiba.com>
References: <20011221000542.GE1492@catfish> <021401c18a56$97540110$7e6015ac@T23KEMPF>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-2022-jp"
Content-Disposition: inline
In-Reply-To: <021401c18a56$97540110$7e6015ac@T23KEMPF>
User-Agent: Mutt/1.3.24i
From: Yoshihiro Ohba <yohba@tari.toshiba.com>
X-Dispatcher: imput version 20000414(IM141)
Lines: 124
X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/)
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

Jim,

Thanks for the response.

Additional comments are in-line.  Note that I'm not objecting the
selection since it would be better to be constructive, but just to
make things clearer and have a correct understanding of the result 
as much as possible.

On Fri, Dec 21, 2001 at 11:35:05AM -0800, James Kempf wrote:
> Yoshi,
> 
> 
> > First thing is the process of selection. The criteria for selection
> > from the proposals, and the result should be included in the
> > assessment draft.  Specifically, the selected protocol is the one
> > having the largest number of the lowest ratings, i.e., containing six
> > 1's, and neither having the largest number of the highest ratings nor
> > having the highest avarage rate.  There is a logical leap between the
> > ratings and the final selection. So I think that selection team had
> > some criteria other than the ratings.
> >
> 
> Yes, this wasn't clear. As I believe was discussed on the list, the
> final decision was not made by the selection team, it was made
> in consultation between the WG chairs and our AD. We based
> our decision on the selection team's assessment and recommended
> course of action(s). There was a judgement call involved, and the
> judgement was based to a certain degree on what requirements
> we felt were most important, in addition to process considerations.
> 
> In particular, as I mentioned in my previous email to Behcet,
> independence
> from mobility protocol was considered a first priority requirement,
> because
> this has been a foundational principle of all Seamoby work. In addition,
> we

As assessment team correctly evaluated,
draft-ohba-seamoby-last-hop-dmha-02.txt also satisfies independency
from mobility protocol.

> did not want the protocol to be encumbered by or dependent upon the
> process of another working group, as this would set up a dependence
> between our work and the work of another working group that could
> result in delays. Finally, requirements originating out of the problem
> statement
> had higher priority than other requirements. So, for example, the
> requirement of indepenence of paging area from subnet topology
> was identified in the problem statement and therefore had higher
> priority. These requirements are ones that we believe will give IP
> paging
> an advantage over current practice, and therefore are likely to serve as
> an
> incentive for implementation and deployment.

draft-ohba-seamoby-last-hop-dmha-02.txt also satisfies indepenency of
paging area from subnet topology, but unfortunately the selection team
seems to misunderstand that the protocol does not satisfy this
requirement, which I also pointed out this both on the mike in the SLC
meeting and in my comments posted before the SLC meeting.  Actually,
we paid a special care on this point, for example we explitly
mentioned in the draft that:

   Paging Area

     (snip)

     An arbitrary mapping between subnets and paging areas is allowed in
     this protocol.

Additional comments:

Jim also mentioned in the SLC meeting that our protocol requires
extranous signaling (among separate agents), which is not desirable.
This is not exactly correct because our protocol allows elimination of
extranous signaling by implementing those agents in a single box (for
small size networks).  Extranous signaling is inevitable if
scalability matters.  For the same reason, extranous signaling is also
described in the selected protocol if PA is hierachically configured.
There is always tradeoff between scalability and centralized agent.

Jim also mentioned in the SLC meeting that our protocol does not
support time-slotted dormant mode at L3.  This is true, but
time-slotted dormant mode at L3 was not explicitly described in the
requirements document, and I don't think the basic issue of how to
synchronize at L3 can be solved by just definig a set of
synchronization timing parameters.  Additional consideration of
hardware-based IP-paging implementation and interference with other
traffic, etc. would be still necessary if we really want to archive
it.


Regards,
Yoshihiro Ohba


> 
> > And the second thing is that the comments that were posted by some of
> > the authors of the candidate protocols before the SLC meeting should
> > also be reflected to the assessment draft, if those comments are
> > relevant.
> >
> 
> The assessment is meant to be a record of the assessment team
> deliberations
> and not a complete transcript of the working group's dialog on the
> process.
> The comments posted by the authors are part of the mailing list archive.
> 
> However, I should probably remove the sentence in the abstract that says
> the assessment draft will make a recommendation, since it doesn't.
> 
> Thank you for posting this. It is very important that the decision
> making process
> be transparent, and I agree that the WG chairs have not done a very good
> job of explaining it. I hope this makes things clearer.
> 
> 
>                 jak
> 
> 
> 
> 

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