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

Luigi Iannone <> Tue, 11 September 2018 09:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E489E13108B for <>; Tue, 11 Sep 2018 02:15:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id X63SSecDzAoV for <>; Tue, 11 Sep 2018 02:15:39 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::42a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A254D130E73 for <>; Tue, 11 Sep 2018 02:15:38 -0700 (PDT)
Received: by with SMTP id n2-v6so24916896wrw.7 for <>; Tue, 11 Sep 2018 02:15:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=xzn0KVFzcJipXxXZ0mcknGYFjlT+oht034oJFBiHOoM=; b=FcyOnI8w4hmsGDXdackdC8h4kXUw2WB3iLfP+OTIuan3akSMxjBqBxFH/g1NU3G/q7 /2Ig/SLx34GGmBk8A4Vc9WCtH5k+5YhCwuIMXOvvNLfFX4Cm08tW0grRU3X2WoKWUr8x 4z7k0Mukh9GFyQy06HjJSptv4+c5b6HQGhFMf6nYqZim9H+73zaogb/01fjQEL8LXHB7 HRfQkkOEvCqiCmukqu7QIyusfYskO8ox+WUp71m9cOyDtQiZaPtKNgh8FtTYv9qJaFon N48SdQuCx5cIdMFjSsW8MxBiuRbxULeICUmKo9bEcW4KqjuJQbPRT6ITeFSjBJb5mAri oZtA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=xzn0KVFzcJipXxXZ0mcknGYFjlT+oht034oJFBiHOoM=; b=USwip7qeWUpquIMcgHYx8jYWro8T2IFz6T7sbbcgdfLi8W+4JqnqlYq9D5l+QOzzbS hp/ZAFM/Yhtaa7jjqAFGHihF33XQVXLrQtbll43wMuJsVrrpWtcPttrqudV/jJ6jr7bT lKvMS+jR72tspVtkuscgV6jidsEuNNZTUSprdqHLFbw7bVKvkSySfT/gLDZmaFLF/sIA elkRXTuvAkUUX/i46SHlfUcnddNoaWXk8XkUMEE9GzUO8iLCavS6YAZ0gWXv0uAjytgL H7bf8HEYguYlaig1Cm11WXAkn5l/dyuQt4tSQ9r82XY762zc8z5eJO+b5DYITElmGcHR DzFQ==
X-Gm-Message-State: APzg51Auom1TFzA9WKSzzCISxsskGXb05sJEQmSlQAXo41c2lX4wap9x RQPZ1PUZ6cSSCFRbKAoQavmEfQ==
X-Google-Smtp-Source: ANB0VdYiQHB6/G1pdwD4tjsQr8uwBRNpTUDExrRBIueJsabB3mkjZTsllJBFGCZ+ykkOJSylKW8vOQ==
X-Received: by 2002:a1c:a507:: with SMTP id o7-v6mr715217wme.45.1536657336904; Tue, 11 Sep 2018 02:15:36 -0700 (PDT)
Received: from ?IPv6:2001:660:330f:a4:b493:b5af:65cf:aebf? ([2001:660:330f:a4:b493:b5af:65cf:aebf]) by with ESMTPSA id i4-v6sm18415462wrs.85.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Sep 2018 02:15:35 -0700 (PDT)
From: Luigi Iannone <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_3F213EDD-ABC3-4227-B9BD-085FDA533DDE"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Tue, 11 Sep 2018 11:15:32 +0200
In-Reply-To: <>
Cc: The IESG <>,,,
To: Alvaro Retana <>
References: <>
X-Mailer: Apple Mail (2.3445.9.1)
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 09:15:42 -0000

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 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.

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?

> (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).

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

> (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.

Meaning that 6833bis obsoletes both 6830 and 6833?

> (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
> rfc8126)

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 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.

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?
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).