Re: Gen-ART Last Call review of draft-korhonen-mip4-service-06
"Spencer Dawkins" <spencer@wonderhamster.org> Tue, 30 December 2008 14:32 UTC
Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2102F3A6864; Tue, 30 Dec 2008 06:32:34 -0800 (PST)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E0563A6864; Tue, 30 Dec 2008 06:32:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H0qbUzOxbPY3; Tue, 30 Dec 2008 06:32:31 -0800 (PST)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 856233A67E1; Tue, 30 Dec 2008 06:32:31 -0800 (PST)
Received: from S73602b (cpe-72-190-78-151.tx.res.rr.com [72.190.78.151]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1LHfdk2peR-0007Ey; Tue, 30 Dec 2008 09:32:17 -0500
Message-ID: <6463F5BEDBC64AD9A573E099D6E8393E@china.huawei.com>
From: Spencer Dawkins <spencer@wonderhamster.org>
To: jouni korhonen <jounikor@gmail.com>
References: <EA1CC945E09A4F71BF15D64495ACAF0C@china.huawei.com> <3fe59bfe0812022250k3264bb39jc43b2ae8689af62c@mail.gmail.com> <FA0D430C47FA4DB5AD4339CA4DE493F3@china.huawei.com> <B6561815-71BA-4E6A-9297-01E37474E76A@gmail.com>
Subject: Re: Gen-ART Last Call review of draft-korhonen-mip4-service-06
Date: Tue, 30 Dec 2008 08:31:48 -0600
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5512
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
X-Provags-ID: V01U2FsdGVkX1/xmqFzmM2OA3ReIjciadd/BZaryjF9gI7oRIc h5WcBtoEF7C6lrYThGyMoQTkulrlbQrRZy4vgGwtQ+vhxL1tTA VLdeVvF4q2TyFN32hFJEzM7Go1IzufEAqBoZIX/pLs=
Cc: General Area Review Team <gen-art@ietf.org>, ulf.s.nilsson@teliasonera.com, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org
Hi, Jouni, Both of these are clearer - thanks for your patience. Spencer > Hi Spencer, > > > On Dec 29, 2008, at 6:13 PM, Spencer Dawkins wrote: > >> Hi, Jouni, >> >> Thanks for your quick response - I'm OK with most of your proposed >> changes. >> >> I should emphasize that my comments here are Last Call comments that >> you (and the document shepherd, and the AD) can decide to ignore - >> I'm just telling you what I'm seeing when I read the text. >> >> Just to finish up: >> >>>> Some of the potential use-cases were listed earlier in this section. >>>> The general aim is better manageability of services and service >>>> provisioning from both operators and service providers point of >>>> view. >>>> However, it should be understood that there are potential deployment >>>> possibilities where selecting a certain service may restrict >>>> simultaneous access to other services from an user point of view. >>>> For example, services may be located in different administrative >>>> domains or external customer networks that practice excessive >>>> filtering of inbound and outbound traffic. >>>> >>>> Spencer: I wasn't clear on who this understanding is directed to - >>>> it almost reads like you're warning users that bad things might >>>> happen if you use a specific service, but surely the user >>>> specifies the service because an operator requires this? >>> >>> We had this discussion earlier on RFC5149.. and concerns were raised >>> whether the Service Selection is a potential tool for enabling walled >>> gardens etc. Thus this note here was added to emphasize that point. >> >> I understand your point from your explanation, but can't get that >> understanding from the draft text. If you said >> >> s/from a user point of view/from a user point of view (for example, >> a "walled garden")/ >> >> that would be as clear as your explanation. > > Ok. Thanks. Will add this. > > >> >> >>>> 3. Service Selection Extension >>>> >>>> At most one Service Selection extension MAY be included in any >>>> Mobile >>>> IPv4 Registration Request message. It SHOULD be included at least >>>> in >>>> >>>> Spencer: seems to be missing a qualifier: "When a non-default >>>> service is selected, the Service Selection extension SHOULD be >>>> included ..."? >>>> >>>> Spencer: If this is qualified, could the SHOULD be a MUST? >>> >>> Hmm.. right. New text would be: >>> >>> At most one Service Selection extension MAY be included in any >>> Mobile >>> IPv4 Registration Request message. When a non-default service is >>> selected, >>> the Service Selection extension SHOULD be included at least in >>> the Registration Request message that is sent for the initial >>> binding >>> registration when the mobile node and the home agent do not have an >>> existing binding. The Service Selection extension MUST be placed in >>> the Registration Request message as follows: >>> >>>> >>>> Spencer: If it remains as SHOULD, what happens if the Service >>>> Selection extension is not included in the initial binding >>>> registration, but is included in subsequent binding registrations? >>> >>> The first RRQ would be treated as the selection of the "default >>> service". The subsequent RRQs with the service selection would cause >>> reauthorization & evaluation of the requested service. If the newly >>> requested service conflicts with the "default service" from the HA >>> point of view, then an appropriate error is returned and the binding >>> is dropped. >> >> I'm still confused by >> >>> When a non-default service is selected, >>> the Service Selection extension SHOULD be included at least in >>> the Registration Request message that is sent for the initial >>> binding >>> registration when the mobile node and the home agent do not have an >>> existing binding. >> >> My understanding from your explanation is that, by definition, if >> you don't include the Service Selection extension, you aren't >> selecting a non-default service until you DO send an RRQ that >> includes the Service Selection extension - right? If I'm tracking >> you, you're talking about two cases at the same time - what happens >> if you DO include the extension in the first RRQ, and what happens >> if you DON'T include the extension in the first RRQ, then switch to >> a non-default service by including the Service Selection extension >> in a subsequent RRQ - that would be why I was confused. >> >> I think your explanation is way clearer than the draft text - >> perhaps you could insert it into the draft text? > > A new try: > > At most one Service Selection extension MAY be included in any > Mobile > IPv4 Registration Request message. The Service Selection extension > SHOULD be included at least in the Registration Request message that > is sent for the initial binding registration when the mobile node > and > the home agent do not have an existing binding. In absence of a > specifically indicated service in the Registration Request for the > initial binding registration, the home agent MUST act as if the > default > service, such as plain Internet access had been requested. The > absence > of the Service Selection extension in a Registration Request that > refreshes an existing binding MUST be treated as if the existing > service > selection is maintained. The Service Selection extension MUST be > placed > in the Registration Request message as follows: > > > Cheers, > Jouni > > >> >> >> Thanks, and Happy New Year, >> >> Spencer >> > > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
- Gen-ART Last Call review of draft-korhonen-mip4-s… Spencer Dawkins
- Re: Gen-ART Last Call review of draft-korhonen-mi… jouni korhonen
- Re: Gen-ART Last Call review of draft-korhonen-mi… Spencer Dawkins
- Re: Gen-ART Last Call review of draft-korhonen-mi… Spencer Dawkins
- Re: Gen-ART Last Call review of draft-korhonen-mi… jouni korhonen