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

Alvaro Retana <> Tue, 11 September 2018 14:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5A0B6130DDB; Tue, 11 Sep 2018 07:05:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id X5YbtzYlsjfl; Tue, 11 Sep 2018 07:05:06 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D015F12F1A2; Tue, 11 Sep 2018 07:05:05 -0700 (PDT)
Received: by with SMTP id l202-v6so47325820oig.7; Tue, 11 Sep 2018 07:05:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=JsqMBmMDQnFn4jwPYW0Xv33AX706UKK+7BOKCLNR81s=; b=rFoKaoxiJEY90H96+28F5s7+E7PFDO3zcPnn5XvSJb+cq74RjVYAQTXyXYhdmqhS29 wh+sMs15XOI/yzlBML2y8AK6SxzYaTa3vkP4Ko3rscJZ0Iy1d6gP6P/VeP1IMTCu38Lf m7JyZSybP8dsb5LoQXPlvE+fgKV0UXUgP+2MjYrL4+joVu5ttsRvjPxyRpvRClWQGAV5 DL9tOfdVVZg8JgdAPXeSLMreHFsdiFqJowlW2EJ6HfuTPcHbERaR2kvn+SpXakYBlsj1 i37ZfpSOt3P+ZMWVBEqcZ/bVMFPrLoXv1e9vQ19+7VERhCbfyTTYY2VbKe2kym1HzTGE kLYg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=JsqMBmMDQnFn4jwPYW0Xv33AX706UKK+7BOKCLNR81s=; b=iphuQ3WNMFIObuhqKS8xfr2O1or4Tx2/i4mLir4RGZ9N5u7hptUGGeihIiJ57IdeZy GVgv2IQICLr2YX8PMw+edz2j9/z/wZGYRFZbgQ0TIHAtsAqERA2zlOJtxQ926M3K8LuK eWh7/kdRscgDeI1+e87LPpks0q3UU74MPKIOWvRBvxTigxU1sgWLZ0AyajGnhf+IGLLH xFky2Ly6ND460qFGLDrn63WN3/IO0BNSDdsujlwIELShQa7Ecf2eLANRQPGdn0EIyul4 8gzdj2U0gCdUzql20trHxHUeCwvhtoRP0q4brIw6I1S76nvNtsj9/4PzXLSsWHUX0bdS 4z/Q==
X-Gm-Message-State: APzg51CQvg/pjPX7pgUYJInLL4G4N+0a3Cl3Duz7MsK2Ul14qmCzg7dO ZEPV2Dhj3/L/tzgQlBPkAd+Ozlofe8Ff9oON4FaYNQ==
X-Google-Smtp-Source: ANB0VdZJ7Uur2TfgxFFLZsMLpuGMwNXDm2C5+/gJSuGEWftqSRZmr4lTvySxdIa4fOndfPmLeuO0szqgSqVNBsOsdaY=
X-Received: by 2002:aca:a12:: with SMTP id 18-v6mr28052905oik.292.1536674704954; Tue, 11 Sep 2018 07:05:04 -0700 (PDT)
Received: from 1058052472880 named unknown by with HTTPREST; Tue, 11 Sep 2018 10:05:03 -0400
From: Alvaro Retana <>
In-Reply-To: <>
References: <> <>
X-Mailer: Airmail (506)
MIME-Version: 1.0
Date: Tue, 11 Sep 2018 10:05:03 -0400
Message-ID: <>
To: Luigi Iannone <>
Cc:, The IESG <>,,
Content-Type: multipart/alternative; boundary="000000000000ec993a057598f53b"
Archived-At: <>
Subject: Re: [lisp] Alvaro Retana's No Objection on draft-ietf-lisp-rfc6833bis-13: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 11 Sep 2018 14:05:09 -0000

On September 11, 2018 at 5:15:38 AM, Luigi Iannone ( wrote:



Some comments below.  Thanks!


Hi Alvaro,

thanks for your feedback.

See my comments inline and let us know what you think.

On 10 Sep 2018, at 23:43, Alvaro Retana <> wrote:

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
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
like to see them resolved before publication.

§5.1 "defines the LISP control message formats and summarizes for IANA the
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.

This can be easily fixed changing the first sentence to:

 This section defines the LISP control message formats and summarizes
           for IANA the LISP Type codes assigned by this document (see
details IANA considerations in Section 11).

What do you think?

The main point is that is you want IANA to look at this text, then the best
way is to put it in the IANA Considerations section.  They may be ok with a
pointer the other way around: from Section 11 to this section (otherwise
they might not notice).

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

Would it be sufficient to add a sentence listing the messages that this
documents re-defines and the original RFC which is obsoleted?

I just want the text to be clear about what is defined here and what
isn’t.  I think that references (like the one in there for rfc8113) would
be enough.

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

Meaning that 6833bis obsoletes both 6830 and 6833?


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

I think that there is some missing  text, and that most proper sentence
would be:

    Note that according to [RFC8113] the LISP Packet Type values 7 and
9 to 14 can be assigned via Standards
           Action [RFC5226 <>].

(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
formats SHOULD use the LISP Shared Extension Message Type".  I think this
statement makes rfc8113 a Normative reference -- which results in a
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.

Or just make a 8113bis standard track. The RFC Editor will hold the
document until an RFC number is assigned to all normative references.

Having said that, I wonder if we really need that “SHOULD”.
If I experiment with new messages and I make sure that nothing goes beyond
my own deployment, why being constrained?
And what if (still isolating my experiment) for any reason I would like to
play with the reserved bits of existing messages? How do I do it?

In general because you want to avoid squatting on code points, leaking,
etc..  We’ve seen cases in other WGs where experiments later became
mainstream and changing code points was then a huge pain.

In any case, I’m fine with the sentence below.



I would change the sentence in:

 The LISP Shared Extension Message is for experimentation purposes as
described in [RFC8113 <>].

(7) Type 7 is missing.

It is not assigned, and yes… should be stated (see above).