Re: [Gen-art] Gen-ART Last Call review for draft-ietf-netlmm-pmip6-ipv4-support-12
Ryuji Wakikawa <ryuji@jp.toyota-itc.com> Mon, 18 May 2009 19:46 UTC
Return-Path: <ryuji@jp.toyota-itc.com>
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 D45CC3A6CA0 for <gen-art@core3.amsl.com>; Mon, 18 May 2009 12:46:33 -0700 (PDT)
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=[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 JUFo9dvStwtp for <gen-art@core3.amsl.com>; Mon, 18 May 2009 12:46:33 -0700 (PDT)
Received: from komaba.jp.toyota-itc.com (komaba.jp.toyota-itc.com [IPv6:2001:268:124:1::143]) by core3.amsl.com (Postfix) with ESMTP id 78B103A6AD8 for <gen-art@ietf.org>; Mon, 18 May 2009 12:46:32 -0700 (PDT)
Received: from [192.168.110.115] (host18.iij-america.net [206.132.173.18] (may be forged)) (authenticated bits=0) by komaba.jp.toyota-itc.com (8.13.6/8.13.6) with ESMTP id n4IJlxxj024497 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 19 May 2009 04:48:01 +0900 (JST) (envelope-from ryuji@jp.toyota-itc.com)
From: Ryuji Wakikawa <ryuji@jp.toyota-itc.com>
To: Spencer Dawkins <spencer@wonderhamster.org>
In-Reply-To: <A64845646F474853994E76C9B012A446@china.huawei.com>
X-Priority: 3
References: <DB4D9BF777D1481FA7E5CC0FED4813E3@china.huawei.com> <4A119BD4.3090204@piuha.net> <CEC24D64C63D4A0697F1DA0D249CA4DE@china.huawei.com> <4A11AC12.2080506@piuha.net> <Pine.GSO.4.63.0905181144291.16006@irp-view13.cisco.com> <787EE0072E8C4FB5AC2EC9FC7AB489F4@china.huawei.com> <C1510DD7-6AF2-4DC1-9D6F-17179971D936@jp.toyota-itc.com> <A64845646F474853994E76C9B012A446@china.huawei.com>
Message-Id: <296AFEAA-4861-4F2B-8D94-DC9803A1A30F@jp.toyota-itc.com>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Date: Mon, 18 May 2009 12:47:39 -0700
X-Mailer: Apple Mail (2.935.3)
Cc: Jonne Soininen <jonne.soininen@nsn.com>, Vidya Narayanan <vidyan@qualcomm.com>, Jari Arkko <jari.arkko@piuha.net>, General Area Review Team <gen-art@ietf.org>, Sri Gundavelli <sgundave@cisco.com>
Subject: Re: [Gen-art] Gen-ART Last Call review for draft-ietf-netlmm-pmip6-ipv4-support-12
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/mail-archive/web/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>
X-List-Received-Date: Mon, 18 May 2009 19:46:33 -0000
Hi Spencer, Thanks, We will update the document according to your other comments. thanks ryuji On 2009/05/18, at 12:38, Spencer Dawkins wrote: > Hi, Ryuji, > > Thanks for explaining - SHOULD NOTs will be fine (with me). > > Spencer > > >> Hi Spencer, >> Thanks for the detailed comment. >> On 2009/05/18, at 12:02, Spencer Dawkins wrote: >>> Hi, Sri, >>> >>> (Thanks to everyone for the quick responses - I can still >>> remember the review without having to re-read it ;-) >>> >>>> If the request is rejected with a specific reason, there is not >>>> point >>>> for the requester to continue to send the messages for the exact >>>> same >>>> service. Its ok to resend the message when some thing changes. >>>> Ex: An >>>> administrative action allowing the user for that service. >>>> So, the "SHOULD NOT" is with the goal to avoid unnecessary >>>> messaging. >>>> Otherwise, the requester will recv the same error code. >>> >>> I'm sorry, I'm not asking the question clearly - I'm asking why >>> these SHOULD NOTs aren't MUST NOTs. Is there a reason why the >>> requestor would resend the messages for the same service, without >>> changing anything? >>> >>> If there's a reason, SHOULD NOT would be appropriate. If there's >>> not a reason, perhaps MUST NOTs would be more appropriate. >> The "MUST NOT" is too strict in this case. >> As Sri mentioned, it is just for optimization by skipping >> unnecessary messaging. >> After operational action is taken by LMA and error is fixed, MAG >> should be able to retry the registration of the home address which >> was previously rejected with NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS. >> The retry timing depends on operation and administrative matter. >> It might be the next registration or 1 hour later.. >> That's why we just put SHOULD NOT here. >> We will work on the other comments. >> regards, >> ryuji >>> >>> >>> Thanks, >>> >>> Spencer >>> >> >
- [Gen-art] Gen-ART Last Call review for draft-ietf… Spencer Dawkins
- Re: [Gen-art] Gen-ART Last Call review for draft-… Jari Arkko
- Re: [Gen-art] Gen-ART Last Call review for draft-… Spencer Dawkins
- Re: [Gen-art] Gen-ART Last Call review for draft-… Jari Arkko
- Re: [Gen-art] Gen-ART Last Call review for draft-… Sri Gundavelli
- Re: [Gen-art] Gen-ART Last Call review for draft-… Spencer Dawkins
- Re: [Gen-art] Gen-ART Last Call review for draft-… Ryuji Wakikawa
- Re: [Gen-art] Gen-ART Last Call review for draft-… Spencer Dawkins
- Re: [Gen-art] Gen-ART Last Call review for draft-… Sri Gundavelli
- Re: [Gen-art] Gen-ART Last Call review for draft-… Sri Gundavelli
- Re: [Gen-art] Gen-ART Last Call review for draft-… Ryuji Wakikawa