Re: [lisp] [Technical Errata Reported] RFC7052 (4256)

Brian Haberman <brian@innovationslab.net> Fri, 06 February 2015 13:25 UTC

Return-Path: <brian@innovationslab.net>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53F8D1A1AAC for <lisp@ietfa.amsl.com>; Fri, 6 Feb 2015 05:25:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UFZMWbOocO0l for <lisp@ietfa.amsl.com>; Fri, 6 Feb 2015 05:25:23 -0800 (PST)
Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39C271A1A17 for <lisp@ietf.org>; Fri, 6 Feb 2015 05:25:23 -0800 (PST)
Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 043F0880E2; Fri, 6 Feb 2015 05:25:23 -0800 (PST)
Received: from clemson.local (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 2175C136829E; Fri, 6 Feb 2015 05:25:22 -0800 (PST)
Message-ID: <54D4C0BB.3030906@innovationslab.net>
Date: Fri, 06 Feb 2015 08:25:15 -0500
From: Brian Haberman <brian@innovationslab.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: gschudel@cisco.com, atjain@juniper.net, vimoreno@cisco.com, ted.lemon@nominum.com, jmh@joelhalpern.com, ggx@gigix.net
References: <20150204092419.B7DE3180092@rfc-editor.org>
In-Reply-To: <20150204092419.B7DE3180092@rfc-editor.org>
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="HgVWEWEwe2prun4wMSqdJno5KhnsgmaO6"
Archived-At: <http://mailarchive.ietf.org/arch/msg/lisp/25MvCGoBB5gldpTf1D1EDJgrUzM>
Cc: lisp@ietf.org
Subject: Re: [lisp] [Technical Errata Reported] RFC7052 (4256)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Feb 2015 13:25:26 -0000

Hi Isidor,
     I think we need to discuss this to really see if this is a problem.
 Can you give an example where the minimum length doesn't work?  I
looked through all instances of LispAddressType and would expect NULL
entries to still have some info needed in the LispAddressType variable.
 Additionally, it appears that all instances of a mib variable of type
LispAddressType has an associated length field that is also constrained
to values (5..39).  If the LispAddressType TC needed to be changed to
(0..39), wouldn't all those length fields need to change as well?

Regards,
Brian

On 2/4/15 4:24 AM, RFC Errata System wrote:
> The following errata report has been submitted for RFC7052,
> "Locator/ID Separation Protocol (LISP) MIB".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=7052&eid=4256
> 
> --------------------------------------
> Type: Technical
> Reported by: Isidor Kouvelas <kouvelas@cisco.com>
> 
> Section: 7
> 
> Original Text
> -------------
>     REFERENCE
>         "RFC 6830, Section 14.2 and
>          LISP Canonical Address Format (LCAF), Work in Progress,
>          March 2013."
>     SYNTAX OCTET STRING (SIZE (5..39))
> 
> 
> Corrected Text
> --------------
>     REFERENCE
>         "RFC 6830, Section 14.2 and
>          LISP Canonical Address Format (LCAF), Work in Progress,
>          March 2013."
>     SYNTAX OCTET STRING (SIZE (0..39))
> 
> 
> Notes
> -----
> The minimum octet string length of 5 specified for the LispAddressType is incorrect. The smallest non-empty address is an IPv4 address that is not using the LCAF format to include an instance ID. This requires 8 octets (see example 1 above keeping in mind that the AFI requires 2 octets). However, in many places in the MIB definition the LispAddressType is used as the type for attributes where “unspecified” is a valid return. For example in lispEidRegistrationLastRegisterSender, an EID prefix that is configured on a Map-Server may not have any active registrations. To encode the absence of an address the minimum length of zero should be allowed.
> 
> Instructions:
> -------------
> This erratum 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. 
> 
> --------------------------------------
> RFC7052 (draft-ietf-lisp-mib-13)
> --------------------------------------
> Title               : Locator/ID Separation Protocol (LISP) MIB
> Publication Date    : October 2013
> Author(s)           : G. Schudel, A. Jain, V. Moreno
> Category            : EXPERIMENTAL
> Source              : Locator/ID Separation Protocol
> Area                : Internet
> Stream              : IETF
> Verifying Party     : IESG
>