[Seamoby] CAR Discovery Draft

"James Kempf" <kempf@docomolabs-usa.com> Fri, 11 January 2002 19:03 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 OAA25945 for <seamoby-archive@odin.ietf.org>; Fri, 11 Jan 2002 14:03:01 -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 NAA11851; Fri, 11 Jan 2002 13:52:01 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA11822 for <seamoby@optimus.ietf.org>; Fri, 11 Jan 2002 13:51:59 -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 NAA25465 for <seamoby@ietf.org>; Fri, 11 Jan 2002 13:51:57 -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 g0BIpNS11655; Fri, 11 Jan 2002 10:51:23 -0800 (PST)
Message-ID: <016f01c19ad0$bdd5e030$7e6015ac@T23KEMPF>
From: James Kempf <kempf@docomolabs-usa.com>
To: "Hesham Soliman (ERA)" <hesham.soliman@era.ericsson.se>, "'Trossen Dirk (NRC/Boston)'" <Dirk.Trossen@nokia.com>, Govind Krishnamurthi <govs23@hotmail.com>, seamoby@ietf.org
References: <4DA6EA82906FD511BE2F00508BCF053801C4C1E7@Esealnt861.al.sw.ericsson.se>
Date: Fri, 11 Jan 2002 10:49:46 -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
Subject: [Seamoby] CAR Discovery Draft
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

Hesham,

OK, this sounds like some comments on
draft-ietf-seamoby-cardiscovery-issues-01.txt.

It certainly would have been helpful if you had posted your comments
during the Last Call period.
Last Call expired Jan. 4 on this document. I don't believe comments sent
in after
Last Call necessarily need to be accommodated, but, if these are simple
editorial changes that can be
 resolved in the next day or two, then I think we can accommodate them.
However, I do not want to get into a
 long discussion about requirements prior to releasing the problem
statement. If we can't resolve these
editorial issues by Tuesday, the draft will go to the IESG as it
currently stands.

Here are some suggestions about changes in the wording.

> => To me the following text from the draft suggests
> that the AR knows ALL GAARs. I think that's unrealistic.
>
>   4.1 Anticipated CAR Discovery
>
>    In this approach, an AR currently serving the MN identifies all
CARs
>    for the MN's handoff, at some point prior to handoff.
>

How about:

    In this approach, an AR currently serving the MN identifies some set
of
    suitable CARs for the MN's handoff, at some point prior to handoff.

If this text is unsatisfactory, please feel free to propose an
alternative.

> => anticipation should not be associated with the
> case where the MN does not signal, you can have
> anticipation when the MN signals also. Therefore
> associating 'anticipation' with a certain model
> where the MN does not signal, does not seem right.
>
> I'm referring to the title of ch 4.1
>

One of the problems with not having a consistent set
of terminology for wireless networking in the IETF
is that it becomes difficult to find a word that describes
the concept you are trying to get at without impinging
on what somebody else thinks a particular word
means. I believe this is the case here. The "anticipated"
here has nothing to do with "anticipated handover."
Here, the AR is anticipating the need for CARs
by performing discovery prior to the MN needing
them. The anticipation is exactly the same anticipation
as occurs for distribution of routing information prior
to a packet arriving at a router that requires that
routing information.

Perhaps another word would be suitable? Please
feel free to suggest one. Perhaps "router based"?

            jak


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