[Gen-art] Gen-ART Last Call review of draft-korhonen-mip4-service-06
"Spencer Dawkins" <spencer@wonderhamster.org> Tue, 02 December 2008 21:19 UTC
Return-Path: <gen-art-bounces@ietf.org>
X-Original-To: gen-art-archive@optimus.ietf.org
Delivered-To: ietfarch-gen-art-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9286B28C203; Tue, 2 Dec 2008 13:19:30 -0800 (PST)
X-Original-To: gen-art@core3.amsl.com
Delivered-To: gen-art@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4789C28C1F3; Tue, 2 Dec 2008 13:19:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.948
X-Spam-Level:
X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001]
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 Z5l-BJHYoCxS; Tue, 2 Dec 2008 13:19:21 -0800 (PST)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) by core3.amsl.com (Postfix) with ESMTP id DCB6928C0F7; Tue, 2 Dec 2008 13:19:20 -0800 (PST)
Received: from S73602b (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1L7ceE0vmB-0001G2; Tue, 02 Dec 2008 16:19:15 -0500
Message-ID: <EA1CC945E09A4F71BF15D64495ACAF0C@china.huawei.com>
From: Spencer Dawkins <spencer@wonderhamster.org>
To: jouni.nospam@gmail.com, ulf.s.nilsson@teliasonera.com
Date: Tue, 02 Dec 2008 15:18:56 -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+8JOxKUjQ/TfA733e/k++PnGxYWagJVEO4Wy/ 6y5DsIfFTmBraGbOeM/5ADUZ8oc1PV9jo5vm/gPRQ8TJ111EZS HIASmxdqAHciTmi4TQZVHmNgIVfkE2laiNiTLKiQZ4=
Cc: General Area Review Team <gen-art@ietf.org>, ietf@ietf.org
Subject: [Gen-art] Gen-ART Last Call review of draft-korhonen-mip4-service-06
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: gen-art-bounces@ietf.org
Errors-To: gen-art-bounces@ietf.org
I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-korhonen-mip4-service-06 Reviewer: Spencer Dawkins Review Date: 2008-12-02 IETF LC End Date: 2008-12-24 IESG Telechat date: (not known) Summary: This draft is on the right track for publication as Informational (should it be standards-track, if you're expecting this to be widely deployed? But I'll leave that to the IESG). I do have comments, especially involving 2119 language. Comments: (Can Jouni's e-mail address really be Email: jouni.nospam@gmail.com ?) 1. Introduction This document describes a Service Selection Extension for Mobile IPv4 that is intended to assist home agents to make specific service selections for the mobility service subscription during the registration procedure. The service selection may affect home agent routing decisions, Home Address assignment policies, firewall settings, and security policies. The Service Selection extension SHOULD be used in every Registration Request that makes a new registration to the home agent. The Service Selection extension from the Registration Request MAY be echoed back in the Registration Reply. Spencer: I don't usually see 2119 normative language in the introduction of Internet Drafts... at a minimum, these statements appear before the requirements key words are introduced in section 2. I THINK most of these requirements are restated later in the document anyway, so they could probably be dropped here. In absence of a specifically indicated service the home agent MUST act as if the default service, plain Internet access had been requested. There is no absolute requirement that this default service be allowed to all subscribers, but it is highly RECOMMENDED in order to avoid having normal subscribers employ operator-specific configuration values in order to get basic service. 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? 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? 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 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: o When present the extension MUST appear after the MN-NAI extension, if the MN-NAI is also present in the message o If the extension was added by the mobile node to a Registration Request it MUST appear prior any authentication-enabling extensions [RFC3344][RFC4721] Spencer (editorial): s/prior/before/ or s/prior/prior to/ o In the event the foreign agent adds the Service Selection extension to a Registration Request, the extension MUST appear prior to any Foreign-Home authentication-enabling extensions [RFC3344] 4.1. Mobile Node Considerations A mobile node or its proxy representative MAY include the Service Selection extension into any Registration Request message. The Service Selection extension can be used with any mobile node identification method. The extension is used to identify the service to be associated with the mobility session and SHOULD only be Spencer: this seems to be more restrictive than previous text that allowed the extension to be included in non-initial registration request messages... included into the initial Registration Request message sent to a home agent. If the mobile node wishes to change the selected service, it is RECOMMENDED that the mobile node de-register the existing binding Spencer: why RECOMMENDED and not REQUIRED? RECOMMENDED means that home agents must handle the case where the SHOULD isn't observed anyway. with the home agent before proceeding with a binding registration for a different service. The provisioning of the service identifiers to the mobile node or its proxy representative is out of scope of this specification. 6. IANA Considerations A new Mobile IPv4 skippable Extension type is required for the following new Extension described in Section 3. The Extension type must be from the 'skippable Extension' range (128-255): Service Selection Extension is set to TBD A new Mobile IPv4 registration denied by home agent error code is required. The error code must be allocated from the 'Error Codes from the Home Agent' range (128-192): SERVICE_AUTHORIZATION_FAILED is set to TBD Spencer: (if you revise this draft, you probably want to use "TBD1", "TBD2", etc. so that it's clearer to IANA which "TBD" gets replaced with each allocated value) _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
- [Gen-art] Gen-ART Last Call review of draft-korho… Spencer Dawkins
- Re: [Gen-art] Gen-ART Last Call review of draft-k… jouni korhonen
- Re: [Gen-art] Gen-ART Last Call review of draft-k… Spencer Dawkins
- Re: [Gen-art] Gen-ART Last Call review of draft-k… jouni korhonen
- Re: [Gen-art] Gen-ART Last Call review of draft-k… Spencer Dawkins
- Re: [Gen-art] Gen-ART review of draft-korhonen-mi… Spencer Dawkins