[MEXT] [Technical Errata Reported] RFC5648 (1904)
RFC Errata System <rfc-editor@rfc-editor.org> Thu, 08 October 2009 14:55 UTC
Return-Path: <web-usrn@ISI.EDU>
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 E29D628C1B5 for <mext@core3.amsl.com>; Thu, 8 Oct 2009 07:55:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.911
X-Spam-Level:
X-Spam-Status: No, score=-16.911 tagged_above=-999 required=5 tests=[AWL=0.688, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15]
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 LTK90As9iYMj for <mext@core3.amsl.com>; Thu, 8 Oct 2009 07:55:54 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id F32823A68C9 for <mext@ietf.org>; Thu, 8 Oct 2009 07:55:53 -0700 (PDT)
Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n98EutP5029512; Thu, 8 Oct 2009 07:56:56 -0700 (PDT)
Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id n98Euqtl029492; Thu, 8 Oct 2009 07:56:52 -0700 (PDT)
Date: Thu, 08 Oct 2009 07:56:52 -0700
Message-Id: <200910081456.n98Euqtl029492@boreas.isi.edu>
To: ryuji.wakikawa@gmail.com, vijay@wichorus.com, Tsirtsis@gmail.com, thierry.ernst@inria.fr, nagami@inetcore.com, rdroms@cisco.com, jari.arkko@piuha.net, marcelo@it.uc3m.es, julienl@qualcomm.com
From: RFC Errata System <rfc-editor@rfc-editor.org>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: web-usrn@boreas.isi.edu
Cc: ah@TR-Sys.de, rfc-editor@rfc-editor.org, mext@ietf.org
Subject: [MEXT] [Technical Errata Reported] RFC5648 (1904)
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/mail-archive/web/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>
X-List-Received-Date: Thu, 08 Oct 2009 14:55:55 -0000
The following errata report has been submitted for RFC5648, "Multiple Care-of Addresses Registration". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5648&eid=1904 -------------------------------------- Type: Technical Reported by: Alfred Hoenes <ah@TR-Sys.de> Section: 6.2, pg.25 Original Text ------------- a) In Section 4.3, the description of the 'Care-of Address' field in the Binding Identifier Mobility Option specifies: Care-of Address If a Binding Identifier mobility option is included in a Binding Update for the home registration, either IPv4 or IPv6 care-of addresses for the corresponding BID can be stored in this field. For the binding registration to correspondent nodes (i.e., route optimization), only IPv6 care-of addresses can be stored in this field. If no address is specified in this field, the length of ! this field MUST be zero (i.e., not appear in the option). If the ! option is included in any messages other than a Binding Update, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ! the length of this field MUST also be zero. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ b) Contrary to the "MUST" in the last line, Section 6.2 of the RFC says, on mid-page 25, where it elaborates on Binding Acknowledgement messages: If all the above operations are successfully completed and the 'A' flag is set in the Binding Update, a Binding Acknowledgement containing the Binding Identifier mobility options MUST be sent to ! the mobile node. Whenever a Binding Acknowledgement is sent, all the ^^^^^^^^^^^^^^^^^^^^^^^ ! Binding Identifier mobility options stored in the Binding Update MUST ! be copied to the Binding Acknowledgement except the Status field. ! The Care-of Address field in each Binding Identifier mobility option, | however, MAY be omitted, because the mobile node can match a ^^^ ! corresponding Binding Update List entry using the BID. Corrected Text -------------- a) << no change >> b) If all the above operations are successfully completed and the 'A' flag is set in the Binding Update, a Binding Acknowledgement containing the Binding Identifier mobility options MUST be sent to the mobile node. Whenever a Binding Acknowledgement is sent, all the Binding Identifier mobility options stored in the Binding Update MUST be copied to the Binding Acknowledgement except the Status field. The Care-of Address field in each Binding Identifier mobility option, | however, MUST be omitted, because the mobile node can match a corresponding Binding Update List entry using the BID. Notes ----- Rationale: The inconsistency is described with the Original Text. The Corrected Text proposed gives preference to the requirement from Section 4.3, which seems to be reasonable for efficiency and consistent with other parts of the specification. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5648 (draft-ietf-monami6-multiplecoa-14) -------------------------------------- Title : Multiple Care-of Addresses Registration Publication Date : October 2009 Author(s) : R. Wakikawa, Ed., V. Devarapalli, G. Tsirtsis, T. Ernst, K. Nagami Category : PROPOSED STANDARD Source : Mobility EXTensions for IPv6 Area : Internet Stream : IETF Verifying Party : IESG
- [MEXT] [Technical Errata Reported] RFC5648 (1904) RFC Errata System