IETF Logo Mail Archive

[MEXT] Comments on draft-ietf-mext-binding-revocation-02

"Stupar, Patrick" <pstupar@qualcomm.com> Thu, 11 December 2008 01:20 UTC

Return-Path: <mext-bounces@ietf.org>
X-Original-To: mip6-archive@megatron.ietf.org
Delivered-To: ietfarch-mip6-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C15893A6983; Wed, 10 Dec 2008 17:20:59 -0800 (PST)
X-Original-To: mext@core3.amsl.com
Delivered-To: mext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C58AC3A6934 for <mext@core3.amsl.com>; Wed, 10 Dec 2008 17:20:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 KUKHMAPg-xUl for <mext@core3.amsl.com>; Wed, 10 Dec 2008 17:20:56 -0800 (PST)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 765623A6B84 for <mext@ietf.org>; Wed, 10 Dec 2008 17:20:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=pstupar@qualcomm.com; q=dns/txt; s=qcdkim; t=1228958441; x=1260494441; h=x-mimeole:content-class:mime-version:content-type: content-transfer-encoding:subject:date:message-id: x-ms-has-attach:x-ms-tnef-correlator:thread-topic: thread-index:from:to:cc:x-originalarrivaltime: x-ironport-av; z=X-MimeOLE:=20Produced=20By=20Microsoft=20Exchange=20V6.5 |Content-class:=20urn:content-classes:message |MIME-Version:=201.0|Content-Type:=20text/plain=3B=0D=0A =09charset=3D"us-ascii"|Content-Transfer-Encoding:=20quot ed-printable|Subject:=20Comments=20on=20draft-ietf-mext-b inding-revocation-02|Date:=20Thu,=2011=20Dec=202008=2001: 19:19=20-0000|Message-ID:=20<A39C75E50DED4C43A4B0EA9B51B0 B6B340478F@EUEX02.eu.qualcomm.com>|X-MS-Has-Attach:=20 |X-MS-TNEF-Correlator:=20|Thread-Topic:=20Comments=20on =20draft-ietf-mext-binding-revocation-02|Thread-Index:=20 AclbLn3taqHuU6TUSgeN3dxQhl2ykQ=3D=3D|From:=20"Stupar,=20P atrick"=20<pstupar@qualcomm.com>|To:=20<amuhanna@nortel.c om>|Cc:=20<mext@ietf.org>|X-OriginalArrivalTime:=2011=20D ec=202008=2001:20:35.0748=20(UTC)=20FILETIME=3D[AB4F1640: 01C95B2E]|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5100,188,546 0"=3B=20a=3D"13834178"; bh=B4C79wjEXe6QPRt8CMko9qJynpGg4QHfV1yYUFNkbxU=; b=tFlQh5eA1cEj/QPTdrpx5uDb6TbETuOxjOIUY9GIGKbCElAkVvAsxjRm sLED546S/dUgodtH0Hguazy7BuD33089pN9x5KW6DILtewOa9A7snQPf1 o1os3lvUGTLdJsYw3L/HMCfvr7CrOVj55q8p2pnqQWfmv0wjwvw7Q75Do k=;
X-IronPort-AV: E=McAfee;i="5100,188,5460"; a="13834178"
Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Dec 2008 17:20:40 -0800
Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mBB1KeU9016480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 10 Dec 2008 17:20:40 -0800
Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mBB1KZK3027041; Wed, 10 Dec 2008 17:20:40 -0800
Received: from EUEX02.eu.qualcomm.com ([10.222.228.34]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Dec 2008 17:20:35 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 11 Dec 2008 01:19:19 -0000
Message-ID: <A39C75E50DED4C43A4B0EA9B51B0B6B340478F@EUEX02.eu.qualcomm.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Comments on draft-ietf-mext-binding-revocation-02
Thread-Index: AclbLn3taqHuU6TUSgeN3dxQhl2ykQ==
From: "Stupar, Patrick" <pstupar@qualcomm.com>
To: amuhanna@nortel.com
X-OriginalArrivalTime: 11 Dec 2008 01:20:35.0748 (UTC) FILETIME=[AB4F1640:01C95B2E]
Cc: mext@ietf.org
Subject: [MEXT] Comments on draft-ietf-mext-binding-revocation-02
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/mext>
List-Post: <mailto:mext@ietf.org>
List-Help: <mailto:mext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: mext-bounces@ietf.org
Errors-To: mext-bounces@ietf.org

Hi Ahmad,

I have reviewed binding revocation draft and have the following
comments/questions. 

- In MIPv6, Binding Update and Binding Ack have two different MH type
values. Why isn't the same approach taken for BRI and BRA and only one
value is used? 

- BRI has a revocation trigger field which is used for two main usages.
One is the provisioning of the reason why the revocation was sent (e.g.
inter-MAG handoff) and the other is related to specific binding
revocation procedures (e.g. IPV4 HoA Binding only, Per-Peer Policy). I
think it would be cleaner if the two concepts remain separated in the
messages, for instance defining additional flags for Per-peer policy or
IPv4 HoA Binding only.

- In the draft you refer to MAG identity, where is this term defined? I
wasn't able to find it in RFC 5213. 
 

Some other comments related to specific sections:

- page 21: in the first section after the bullet list, there is the
following sentence:
"As described in Section 7.3, the LMA SHOULD retransmit this BRI to
   the MAG before deleting the mobile node IP tunnel to the mobile
   access gateway until it receives a matching Binding Revocation
   Acknowledgement or the BRIMaxRetransmitNumber is reached. "
But this doesn't always apply, e.g. in case of inter-mag handoffs. What
am I missing?

- why is the A bit setting mandatory in case of IPv4 HoA binding only
revocation?

- section 10.1.1: 
"BRI MUST be formatted as in Section 6.1 and if the (P) bit is set,
      the mobile access gateway must validate that the impacted binding
      have the proxy binding flag set."
MAG is not supposed to have any proxy binding flag or is it? How can it
validate this flag?


-section 11.1
" If the Acknowledgement (A) bit is set in the Binding Revocation
      Indication and the MN has the BCE in registered state, the mobile
      node MUST send a Binding Revocation Acknowledgement."

MN has no BCE, it has a binding update list.

-section 11.1
"If the Revocation Trigger field value is "Administrative Reason",
      the mobile node MUST NOT try to re-register with the home agent
      before contacting its home operator."

I don't think that BRI specs have to mandate the MN to contact the home
operator, the text at the end of section 11.1 is enough IMO.

I have some typos and editorial corrections as well, I will send them
off-list.

Regards,

Patrick
_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext

v2.23.0 | Report a Bug | By Email