[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