Re: [Seamoby] CAR Discovery Requirements

"James Kempf" <kempf@docomolabs-usa.com> Tue, 12 March 2002 21:40 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 QAA08865 for <seamoby-archive@odin.ietf.org>; Tue, 12 Mar 2002 16:40:09 -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 QAA13760; Tue, 12 Mar 2002 16:28: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 QAA13729 for <seamoby@optimus.ietf.org>; Tue, 12 Mar 2002 16:28:52 -0500 (EST)
Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08481 for <seamoby@ietf.org>; Tue, 12 Mar 2002 16:28:48 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2CLSJI01860; Tue, 12 Mar 2002 13:28:19 -0800 (PST)
Message-ID: <02cb01c1ca0c$9a6ae6c0$7e6015ac@T23KEMPF>
From: James Kempf <kempf@docomolabs-usa.com>
To: Dirk.Trossen@nokia.com, seamoby@ietf.org
References: <DC504E9C3384054C8506D3E6BB01246008D5B2@bsebe001.NOE.Nokia.com>
Subject: Re: [Seamoby] CAR Discovery Requirements
Date: Tue, 12 Mar 2002 13:26:42 -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

> I don't see that the requirement is addressing the distribution
> of the information. There is another requirement for this, namely
> 3.4. The present one is merely addressing that a solution has to
> match the set of GAAR+capabilities with MN's requirements to determine
> the set of CARs. This is essentially what CAR discovery is about,
isn't
> it?
>

What 3.4 states is:

    3.4. CAPABILITY DISCOVERY

    The other fundamental function of CAR discovery protocols is that of
    identifying the capabilities of GAARs. The protocol MUST provide
    functionality to allow ARs to discover their GAAR's capabilities.
These
    capabilities MUST be communicated in a secure fashion.

This says nothing about the MN's capability requirements.

In fact, if you look at the last item in Section 3 of
draft-ietf-seamoby-cardiscovery-issues-02.txt, TAR Selection Algorithm,
the selection of a target router, which would involve matching the MN's
requests with the AR capabilities, is explicitly excluded from the
problem
statement.

> Whether you use existing protocols for certain parts is not
> prohibited by the chosen wording. You might use AAA to express
> the requirements. Still, a CAR discovery protocol has to match
> these requirements onto the available GAAR+cap info. How this
> is done depends on the solution.
>

According to Section 3 of draft-ietf-seamoby-cardiscovery-issues-02.txt,
this is out of scope of the problem.

            jak



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