Re: [Mobopts] Re: draft-irtf-mobopts-l2-abstractions-04.txt comments

"Rajeev Koodli" <rajeev.koodli@gmail.com> Mon, 28 January 2008 18:08 UTC

Return-path: <mobopts-bounces@irtf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJYPh-00014a-NU; Mon, 28 Jan 2008 13:08:57 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJYPg-00014K-FP for mobopts@irtf.org; Mon, 28 Jan 2008 13:08:56 -0500
Received: from wr-out-0506.google.com ([64.233.184.234]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJYPf-0006n4-Mq for mobopts@irtf.org; Mon, 28 Jan 2008 13:08:56 -0500
Received: by wr-out-0506.google.com with SMTP id 58so860964wri.10 for <mobopts@irtf.org>; Mon, 28 Jan 2008 10:08:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=29ByegMoM93sW8ySo7ZaesPDIzUKhq3VKbpY2MJcdeE=; b=kSjfPFS0mxBLDLEq8zmbBWJE/6cIBEMSD2EUU21XEqpJP7CEhrtxwvSolc80skLMg8Fn5tsBrHGd+RemVF7ZZJ4D18eMYoEyIAEXpZVRk/BB6qK624vwKNeDskMTzhxUV+Ij2X7GiJgzXMoiNAJCOIdokvBYT38vWQIvNBUA8fM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=dD3ro5XCWuN+ILD6q3zI1SprQCBGf2/lYQUGhtlR3A9rVzt4acI+e8DhuPEnFY7L162NO1MEWJHNYlOGBjtOFF3Wyq1uV3bl4/PiToMdZzpRONAg9U10COQp5PM3cv6cOlTNQUq/RsINwWfvl1RN3FjEhNOJzDANXZEpGa6b7Q0=
Received: by 10.142.125.5 with SMTP id x5mr2555772wfc.124.1201543733045; Mon, 28 Jan 2008 10:08:53 -0800 (PST)
Received: by 10.142.47.18 with HTTP; Mon, 28 Jan 2008 10:08:53 -0800 (PST)
Message-ID: <3d57679a0801281008k21537bb8u7b273ce5d184b4cb@mail.gmail.com>
Date: Mon, 28 Jan 2008 10:08:53 -0800
From: Rajeev Koodli <rajeev.koodli@gmail.com>
To: Fumio Teraoka <tera@ics.keio.ac.jp>
Subject: Re: [Mobopts] Re: draft-irtf-mobopts-l2-abstractions-04.txt comments
In-Reply-To: <6.2.3.4.2.20080115000659.085e8240@localhost>
MIME-Version: 1.0
References: <C368CFA5.1D589%rajeev.koodli@nokia.com> <4761A5BE.8050509@piuha.net> <6.2.3.4.2.20080106232845.079864c0@localhost> <4784CDE1.5050105@piuha.net> <6.2.3.4.2.20080115000659.085e8240@localhost>
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3
Cc: "Romascanu, Dan (Dan)" <dromasca@avaya.com>, Rajeev Koodli <rajeev.koodli@nokia.com>, "mobopts@irtf.org" <mobopts@irtf.org>
X-BeenThere: mobopts@irtf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mobility Optimizations <mobopts.irtf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mobopts>, <mailto:mobopts-request@irtf.org?subject=unsubscribe>
List-Post: <mailto:mobopts@irtf.org>
List-Help: <mailto:mobopts-request@irtf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mobopts>, <mailto:mobopts-request@irtf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2134358820=="
Errors-To: mobopts-bounces@irtf.org

Hi Jari,
could we close this one? We could then send the revised ID for publication.

Thanks,

-Rajeev



On Jan 14, 2008 7:32 AM, Fumio Teraoka <tera@ics.keio.ac.jp> wrote:

> Jari,
>
> Thanks for comments. Replies are inline:
>
> At 08/01/09 15:36 +0200, Jari Arkko wrote:
> (snip)
>
> >> We modified the document as follows:
> >>
> >> - Sec. 4.5 L2-LinkUp (Type 2):
> >>   - old: The L2-LinkUp.indication primitive is asynchronously provided
> to
> >>          an upper layer when a new link is connected.
> >>
> >>   - new: The L2-LinkUp.indication primitive is asynchronously provided
> to
> >>          an upper layer when a new link is connected and IP packets can
> be
> >>          transmitted through the new link. As described in RFC 4957[7],
> >>          what "link is connected" means depends on link types.
> >
> >Good.
> >
> >>  For example,
> >>          in case of the infrastructure mode in IEEE802.11 (WiFi), this
> >>          primitive is provided when an association to an access point
> is
> >>          established.
> >>
> >
> >Really? I was under the impression that association was an early phase
> >and you would need to wait for something else if security was applied. I
> >could be mistaken, but this discussion is an example of the sort of
> >detail level that a fully defined interface would have to go to.
>
> In my understanding of the IEEE802.11 infrastructure mode, at first,
> a mobile node is in Unauthenticated & Unassociated State. Next,
> the mobile node is authenticated and then the state changes to
> Authenticated & Unassociated State. Finally, an association is
> established with the AP and then the state changes to Authenticated
> and Associated state. Thus, we defined that L2-LinkUp is provided
> when an association is established in WiFi.
>
> (snip)
>
> >> The quality levels of a device are independent of those of other
> devices.
> >> We added sentences at the last of "Sec. 6.2 Condition" as follows:
> >>
> >>   The quality levels of a L2 device are independent of those of other
> >>   devices.  An example of the thresholds among the five levels are
> described
> >>   in Appendix E.
> >>
> >> We also added the description about the example thresholds in Appendix
> E.
> >>
> >
> >The added text is good, but I'm still not convinced that you have a
> >generic solution capable of operating in different conditions. It might
> >be more useful to simply acknowledge that making decisions based on
> >these metrics is error prone and not guaranteed to result in optimal
> >choice of links.
>
> I agree that "decisions based on these metrics is error prone and
> not guaranteed to result in optimal choice of links."
> I'll attend this sentence at the last of "6.2 Condition".
>
> (snip)
>
> Best Regards,
>
> Fumio Teraoka
>
>
> _______________________________________________
> Mobopts mailing list
> Mobopts@irtf.org
> https://www1.ietf.org/mailman/listinfo/mobopts
>
_______________________________________________
Mobopts mailing list
Mobopts@irtf.org
https://www1.ietf.org/mailman/listinfo/mobopts