[Seamoby] AD: more about draft-ietf-seamoby-cardiscovery-issues-03.txt

Allison Mankin <mankin@psg.com> Sun, 13 October 2002 16:06 UTC

Received: from www1.ietf.org (ietf.org [] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21450 for <seamoby-archive@lists.ietf.org>; Sun, 13 Oct 2002 12:06:37 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain []) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9DG80v03720; Sun, 13 Oct 2002 12:08:00 -0400
Received: from ietf.org (odin.ietf.org []) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9DG61v03133 for <seamoby@optimus.ietf.org>; Sun, 13 Oct 2002 12:06:01 -0400
Received: from psg.com (ietf-mx.ietf.org []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21374 for <seamoby@ietf.org>; Sun, 13 Oct 2002 12:03:48 -0400 (EDT)
Received: from localhost ([] helo=psg.com ident=mankin) by psg.com with esmtp (Exim 3.36 #2) id 180lFc-000F3k-00; Sun, 13 Oct 2002 09:05:56 -0700
To: seamoby@ietf.org
Cc: kempf@docomolabs-usa.com, pcalhoun@bstormnetworks.com, sob@harvard.edu
Reply-To: mankin@psg.com
Date: Sun, 13 Oct 2002 09:05:56 -0700
From: Allison Mankin <mankin@psg.com>
Message-Id: <E180lFc-000F3k-00@psg.com>
Subject: [Seamoby] AD: more about draft-ietf-seamoby-cardiscovery-issues-03.txt
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-BeenThere: seamoby@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>, <mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>, <mailto:seamoby-request@ietf.org?subject=subscribe>


There was a bit more IESG discussion of 
draft-ietf-seamoby-cardiscovery-issues since I wrote to
the list with Steve Bellovin's and my comments.  This note is
to convey the few more IESG comments, which must be addressed by
by the rev of cardiscovery-issues.

The new comments are from Randy Bush.  I interleaved some 
guidance as your AD.

The editors of -issues and -requirements* should get their revs
in asap now.  I plan to approve -issues.  IESG won't review it

Here are Randy Bush's IESG comments:
> in sec 3 scenario 2, if
>   it is possible that the new AR does not have the capability to
>   support the MN's application. The MN can then be informed about
>   this fact when it is still connected to the current AR.
> what the heck might the MN do?  maybe give a clue, e.g., push it up
> the stack and tell the user not to move, advise on which sub-choice
> in direction to move might give the best, though insufficient,
> service, etc.

[My guidance here:  the issues document should note there are issues 
 around what to do with a failure of the capability match - this is related
 to the complexity point I raised - the requirements editor needs to 
 mention that there is some requirement on this - it's not mentioned.]

> sec 5, might you want to certify MNs, ARs, and APs?  i.e. don't
> allocate resources to an illegitimate MN, detect an intruder AP or
> AR, etc.

[AD: The issues draft should consider how much ARs and APs in CAR
 discovery also certify/authorize the MNs...Steve's request has
 already asked for you to put in issues about certify/authorize/sign
 info on the AR/AP]

Seamoby mailing list