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
>>>
>>
>