[lisp] Alvaro Retana's No Objection on draft-ietf-lisp-rfc6833bis-13: (with COMMENT)

Alvaro Retana <aretana.ietf@gmail.com> Mon, 10 September 2018 21:43 UTC

Return-Path: <aretana.ietf@gmail.com>
X-Original-To: lisp@ietf.org
Delivered-To: lisp@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 153A5130DE1; Mon, 10 Sep 2018 14:43:45 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Alvaro Retana <aretana.ietf@gmail.com>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-lisp-rfc6833bis@ietf.org, Luigi Iannone <ggx@gigix.net>, lisp-chairs@ietf.org, lisp@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.83.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153661582508.16057.11407647013027747215.idtracker@ietfa.amsl.com>
Date: Mon, 10 Sep 2018 14:43:45 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/YudaAofK2JtVAQHZjz5aJXm1SL0>
Subject: [lisp] Alvaro Retana's No Objection on draft-ietf-lisp-rfc6833bis-13: (with COMMENT)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Mon, 10 Sep 2018 21:43:45 -0000

Alvaro Retana has entered the following ballot position for
draft-ietf-lisp-rfc6833bis-13: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


There are several issues in §5.1 (LISP Control Packet Type Allocations) that
need to be fixed.  I don't think any of them raise up to a DISCUSS, but I would
like to see them resolved before publication.

§5.1 "defines the LISP control message formats and summarizes for IANA the LISP
Type codes assigned by this document".

(1) Instructions (or anything directed) to IANA should be in the IANA
Considerations section.  There isn't even a pointer to this section later on
for IANA to look at it.

(2) The text seems to imply ("Message type definitions are") that the types are
defined here (or at least in rfc6833, which this document Obsoletes), but they
are defined in rfc6830, rfc8111 and rfc8113.  Please properly identify the
source (only the rfc8113 line has a reference).

(3) Even though draft-ietf-lisp-rfc6830bis is tagged as Obsoleting rfc6830, I
think that, because of how the contents of that RFC were distributed, this
document should also be tagged as Obsoleting rfc6830.

(4) The LISP Packet Types registry was set up in rfc8113.  This document asks
that IANA "refers to this document as well as [RFC8113] as references" (§11.2),
and it seems to try to change the registration (or the text is incomplete) in
(§5.1): "Values in the "Not Assigned" range can be assigned according to
procedures in [RFC8126]."  Which procedure?  s/Not Assigned/Unassigned (§6 in

(5) Because of the point above, this draft should (at least) Update rfc8113
(see also below).

(6) This document says that "Protocol designers experimenting with new message
formats SHOULD use the LISP Shared Extension Message Type".  I think this
statement makes rfc8113 a Normative reference -- which results in a DownRef. 
Suggestion: given that this document already updates the registry set up in
rfc8113, and recommends the use of the Shared Extension Message, it may be a
good idea to simply adopt the contents of that document here (grand total of 6
pages) and declare it Obsolete.

(7) Type 7 is missing.