Re: [Gen-art] Gen-ART Last Call review for draft-ietf-netlmm-pmip6-ipv4-support-12

Sri Gundavelli <sgundave@cisco.com> Mon, 18 May 2009 18:47 UTC

Return-Path: <sgundave@cisco.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 2617D3A68FB for <gen-art@core3.amsl.com>; Mon, 18 May 2009 11:47:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.444
X-Spam-Level:
X-Spam-Status: No, score=-6.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 tOnopLc77qmW for <gen-art@core3.amsl.com>; Mon, 18 May 2009 11:47:49 -0700 (PDT)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 157763A67D8 for <gen-art@ietf.org>; Mon, 18 May 2009 11:47:49 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.41,210,1241395200"; d="scan'208";a="187058901"
Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 18 May 2009 18:49:25 +0000
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n4IInPpq022944; Mon, 18 May 2009 11:49:25 -0700
Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n4IInO3g014579; Mon, 18 May 2009 18:49:25 GMT
Date: Mon, 18 May 2009 11:49:24 -0700
From: Sri Gundavelli <sgundave@cisco.com>
To: Jari Arkko <jari.arkko@piuha.net>
In-Reply-To: <4A11AC12.2080506@piuha.net>
Message-ID: <Pine.GSO.4.63.0905181144291.16006@irp-view13.cisco.com>
References: <DB4D9BF777D1481FA7E5CC0FED4813E3@china.huawei.com> <4A119BD4.3090204@piuha.net> <CEC24D64C63D4A0697F1DA0D249CA4DE@china.huawei.com> <4A11AC12.2080506@piuha.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3079; t=1242672565; x=1243536565; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20<sgundave@cisco.com> |Subject:=20Re=3A=20Gen-ART=20Last=20Call=20review=20for=20 draft-ietf-netlmm-pmip6-ipv4-support-12 |Sender:=20; bh=Wx2EawIARUOwCD22zBzSWBClglG7O/tGhOy/MdxZzTg=; b=XUzyCG8wmzMKk7epTaRYuxKk58erBRqI2bUBWi9aBA0dYiHQV7zaqj+XvL 03oVFjuOhGSPZJBPc+u1CUh96T0EVN6YZ8pTzcIdd5El4tmhg1fNgTYNDGVE o+1FZnCXhGp8Aydz/GR/+5vXDO3qy2RJPo0WneR6RjKwcGtkWasPs=;
Authentication-Results: sj-dkim-1; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; );
Cc: Jonne Soininen <jonne.soininen@nsn.com>, Ryuji Wakikawa <ryuji@jp.toyota-itc.com>, General Area Review Team <gen-art@ietf.org>, Vidya Narayanan <vidyan@qualcomm.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 18:47:50 -0000

Hi Jari/Spencer,

Just one comment below. Will respond to the other comments
later, to most part, agree to all the comments. Will try
to resolve them.


On Mon, 18 May 2009, Jari Arkko wrote:

>> > >    applied with the following exceptions.
>> > > 
>> > >  Spencer (minor): not sure why the next two bullets are SHOULD NOTs - 
>> > >  we
>> > >  usually provide at least one example of why an implementation would 
>> > >  choose
>> > >  not to perform SHOULD NOTs, for background.
>> > > 
>> > >    o  If the received Proxy Binding Acknowledgement message has the
>> > >       Status field value set to 
>> > >       NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS(The
>> > >       mobile node is not authorized for IPv4 home address), the mobile
>> > >       access gateway SHOULD NOT send a Proxy Binding Update message
>> > >       including the IPv4 Home Address option [ID-DSMIP6] till an
>> > >       administrative action is taken.
>> > > 
>> > >    o  If the received Proxy Binding Acknowledgement message has the
>> > >       Status field value set to 
>> > >       NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS(The
>> > >       mobile node is not authorized for the requesting IPv4 home
>> > >       address), the mobile access gateway SHOULD NOT request for the
>> > >       same address again, but MAY request the local mobility anchor to
>> > >       do the assignment of address by including exactly one instance of
>> > >       IPv4 Home Address option [ID-DSMIP6] with the IPv4 home address
>> > >       and the prefix length fields in the option set to ALL_ZERO value.
>> > 
>> >  While adding rules about when taking a SHOULD is useful, I do not think 
>> >  it is an absolute rule. Generally speaking, SHOULD says that you can 
>> >  disobey it but only if you fully understand the implications.
>>
>>  I should have also asked if it's clear what the other party does when the
>>  SHOULD NOT is violated. A MUST NOT is a clear protocol violation, so the
>>  choices are usually something like (1) send appropriate error response, or
>>  (2) drop silently. An implmentation that violates a SHOULD NOT is still
>>  conforming to the specification, so these choices aren't the right answers
>>  - is the appropriate reaction obvious?
>>
>>  I'm not smart enough about PMIP6 to know whether it's clear or not - but I
>>  should have asked the question. If you guys tell me "no problem", no
>>  problem.
>
> The authors should tell us how it really is, but my understanding is that the 
> above issues are related to management (mis)configurations that you generally 
> do not want to repeatedly attempt to ask for.
>

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.


Sri