From nobody Tue Dec 4 08:17:14 2018 Return-Path: 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 35CC0130DE2; Tue, 4 Dec 2018 08:17:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joel Halpern To: X-Test-IDTracker: no X-IETF-IDTracker: 6.89.1 Auto-Submitted: auto-generated Precedence: bulk Cc: Joel Halpern , lisp-chairs@ietf.org, jmh@joelhalpern.com, iesg-secretary@ietf.org, lisp@ietf.org Message-ID: <154394022921.4806.12960192164307205000.idtracker@ietfa.amsl.com> Date: Tue, 04 Dec 2018 08:17:09 -0800 Archived-At: Subject: [lisp] Publication has been requested for draft-ietf-lisp-rfc8113bis-01 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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, 04 Dec 2018 16:17:09 -0000 Joel Halpern has requested publication of draft-ietf-lisp-rfc8113bis-01 as Proposed Standard on behalf of the LISP working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc8113bis/ From nobody Sun Dec 9 02:10:24 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5B3E127332 for ; Sun, 9 Dec 2018 02:10:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.359 X-Spam-Level: X-Spam-Status: No, score=-3.359 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-net.20150623.gappssmtp.com 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 LT1IhYR23LQG for ; Sun, 9 Dec 2018 02:10:21 -0800 (PST) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45F69126DBF for ; Sun, 9 Dec 2018 02:10:21 -0800 (PST) Received: by mail-wm1-x330.google.com with SMTP id a62so688237wmh.4 for ; Sun, 09 Dec 2018 02:10:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:message-id:date:cc:to; bh=YQBUXF+LFs/YKU5kpDGmNmXKRfRkk1XyBSqxLwLLwnw=; b=kWNqeWnmJq4yjusTWyC58bosg5v+7f/rHSlSncZSL6VSp0RH3zLnQdUjw68jFqZSYd JhLUnFweXTo9NkUP/LRrpFFmUil02nMHqiYAg651GwX5Be9OKtSywHtcL6jhH30NHOx9 tb0yeDu+txuJoh+zMPnxOCorL0hA5F81gsziwqdH9gQ79qEjgnORwMSD2yDxbcisaG7b 8lonB5GOq3HJAHb/u3WJkZ8EXXaiqWTYDCj6GkIV5NU5/lDtiXSDD3z22FlICuSxrNJE K0StTI+C65X12J5OagLJh4m3d8itAPrdGZ3c0jrPvfIf1bQooP1AfZ+or6Jkmt6afDJs FG1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:cc:to; bh=YQBUXF+LFs/YKU5kpDGmNmXKRfRkk1XyBSqxLwLLwnw=; b=PsFUl6kPPhkxIDfEq7DkAbdkd+7hp0KyuKe7ODiI9u9IT6rRFqpT9+xlmczaBbTELt AEk3aX1xKUp2aFRzrzkmCrocbVG3FM8b2uW1dYrwepgNpMUGlPCa8fJ/gOKF7HxByLtI UO6b3TvUW0nsslY6cIEFff1x6r179ukoNZyEaaj7+8LMgRM3h60j3Dh9WT92S8bXLwEz jAhfN4ftzACHaKs+dihpPuoO0zWDEu9mfLr3sFBjwDzSxALoFpeLUJyCTcEmg+qtgaOQ u1f80JIlwVO1dVCEjB5ifXZbgEqw/cId+LNENwVy4YFzDFL0bCs8pGwNRCkbv3J3NjuZ RdSw== X-Gm-Message-State: AA+aEWY8rw+emNpLh9ymXgSyGMZjxCF0ypGcPhc3Qu6/bsJqIGhYxFj5 hQjL85DWJfxK3LT2GVHcUvuWxzWC4XnMeA== X-Google-Smtp-Source: AFSGD/WLjFR1rLsLGLQptdEXYEgdzkdrsertxthy8j2OASx4eMgrMxMKKqqZmyYu1N2Ubf7FVIh++Q== X-Received: by 2002:a1c:4c0c:: with SMTP id z12mr6749961wmf.17.1544350219220; Sun, 09 Dec 2018 02:10:19 -0800 (PST) Received: from fatboy.homenet.telecomitalia.it (host198-116-dynamic.27-79-r.retail.telecomitalia.it. [79.27.116.198]) by smtp.gmail.com with ESMTPSA id e19sm18649466wrc.25.2018.12.09.02.10.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 09 Dec 2018 02:10:17 -0800 (PST) From: Luigi Iannone Content-Type: multipart/alternative; boundary="Apple-Mail=_A07B76A7-1B8A-4750-AB0E-F778B25F65A8" Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) Message-Id: <5AA3ABA5-862D-44D7-805A-91F5AEC882A2@gigix.net> Date: Sun, 9 Dec 2018 11:10:15 +0100 Cc: lisp-chairs@ietf.org To: "lisp@ietf.org list" X-Mailer: Apple Mail (2.3445.101.1) Archived-At: Subject: [lisp] LISP WG Minutes X-BeenThere: lisp@ietf.org 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: Sun, 09 Dec 2018 10:10:23 -0000 --Apple-Mail=_A07B76A7-1B8A-4750-AB0E-F778B25F65A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi All, A revised version of the minutes of our last meeting in Bangkok are now = online at: = https://datatracker.ietf.org/meeting/103/materials/minutes-103-lisp-01 = Please have a look and let us know if there is any mistake or if we = missed something. Ciao L. =20= --Apple-Mail=_A07B76A7-1B8A-4750-AB0E-F778B25F65A8 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Hi All,

A revised version of the minutes of our last meeting in Bangkok are now online at:  https://datatracker.ietf.org/meeting/103/materials/minutes-103-lisp-01

Please have a look and let us know if there is any mistake or if we missed something.

Ciao

L.
 
--Apple-Mail=_A07B76A7-1B8A-4750-AB0E-F778B25F65A8-- From nobody Mon Dec 10 12:47:02 2018 Return-Path: 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 7239B1286E7; Mon, 10 Dec 2018 12:47:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: lisp@ietf.org Message-ID: <154447482041.2905.16269043804590081816@ietfa.amsl.com> Date: Mon, 10 Dec 2018 12:47:00 -0800 Archived-At: Subject: [lisp] I-D Action: draft-ietf-lisp-rfc6833bis-23.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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: Mon, 10 Dec 2018 20:47:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol WG of the IETF. Title : Locator/ID Separation Protocol (LISP) Control-Plane Authors : Vince Fuller Dino Farinacci Albert Cabellos Filename : draft-ietf-lisp-rfc6833bis-23.txt Pages : 61 Date : 2018-12-10 Abstract: This document describes the Control-Plane and Mapping Service for the Locator/ID Separation Protocol (LISP), implemented by two new types of LISP-speaking devices -- the LISP Map-Resolver and LISP Map-Server -- that provides a simplified "front end" for one or more Endpoint ID to Routing Locator mapping databases. By using this Control-Plane service interface and communicating with Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs) are not dependent on the details of mapping database systems, which facilitates modularity with different database designs. Since these devices implement the "edge" of the LISP Control-Plane infrastructure, connecting EID addressable nodes of a LISP site, their implementation and operational complexity reduces the overall cost and effort of deploying LISP. This document obsoletes RFC 6830 and 6833. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lisp-rfc6833bis-23 https://datatracker.ietf.org/doc/html/draft-ietf-lisp-rfc6833bis-23 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-rfc6833bis-23 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Dec 10 12:55:01 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35CB51311ED; Mon, 10 Dec 2018 12:54:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.56 X-Spam-Level: X-Spam-Status: No, score=0.56 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_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.157, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 UGsayQ-PXzfj; Mon, 10 Dec 2018 12:54:49 -0800 (PST) Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com [IPv6:2607:f8b0:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0ACE21311EB; Mon, 10 Dec 2018 12:54:49 -0800 (PST) Received: by mail-oi1-x233.google.com with SMTP id a77so10186639oii.5; Mon, 10 Dec 2018 12:54:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=zhxS9peaS2317fzxIHma048FTaCes3+zCZ604yhTt54=; b=BX2wDhPJMBEVKpSSJh61PfCa4AWvMCVR/shTNpAGjoTwk2qCG8/P6DqbYI0F5ux2JY w7H/pgIxDGSiLpUs5/L3BY57JZvfdxusO3vD9bXHqiAfw+OBQFHSv8E8e+BrG1WOTWwL nYqjOh+vRnhldQQMX7I1WgKQceDAM+NaskcdLVuje/YoFO2k5Cs5k/A6l8FIBu5gO4iN V9Tj+H1BiktoRgnrYp1j+NcvuC11HTr79T0qLJzfy6szNj6vgdWgzEc1Pfdwp0VnIceE yYdl8yxicW000SYMLjJg2CTjZXm1BRP/CD2hR8ZMhSLzLRjvYUPOdUsMmTBtwdFaQjj5 0l/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=zhxS9peaS2317fzxIHma048FTaCes3+zCZ604yhTt54=; b=foKRHyoY5qyewjipoIRRf0q1gwlqwOLtcBE5iR2pCrSFqQwHVg9PtO7P0Hu9vyNOvl 6WIaRkXZU/hloa27iVhbP7WwO3/7IP/TyDlbsEeN4uxyrzbupjcrxJ0WfKv59qNQ0ceA uCbAVaqyIg04DsA4WPNKEuGvF7XmiIfgdczwgBLP0yf3EUQDPiM5wF75ZIelaYzF45Zl UPjcV+t8vMzKVXk25Ip4mzV2xObMhkZSe1/YNiImJZCv6A8h2EKrMB2DJvlIJAvBKsD/ 2JTIQ8ztBJr1mXlasJRHybb01gHNOiXtZazeeAS7eXvpcytxixkkRE72WsszE7DrvCtH ridw== X-Gm-Message-State: AA+aEWY6cyQ7eEKvlLcEkG5Qk5fr/OTAcw7LR3UhuWUGCr5zLmzbr5N1 jcBs1lIkdqM9H6hti2c33MxxoUHL X-Google-Smtp-Source: AFSGD/VESa/4S34B5ZFBy8IbENQZkk74PN4QJKkU921fQPlY/sgZblw1t4+1MBzu7sDw8KMLzNAneA== X-Received: by 2002:aca:d8c1:: with SMTP id p184mr8619551oig.22.1544475288051; Mon, 10 Dec 2018 12:54:48 -0800 (PST) Received: from dino-macbook.attlocal.net (adsl-108-94-1-132.dsl.pltn13.sbcglobal.net. [108.94.1.132]) by smtp.gmail.com with ESMTPSA id u19sm6363919oia.31.2018.12.10.12.54.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Dec 2018 12:54:46 -0800 (PST) From: Dino Farinacci Message-Id: <123E765E-C678-4AB1-BB7D-1C2656C26CD3@gmail.com> Content-Type: multipart/mixed; boundary="Apple-Mail=_0A3B8C53-6760-4889-B9AE-189F7723C2E4" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Mon, 10 Dec 2018 12:54:32 -0800 In-Reply-To: <154447482041.2905.16269043804590081816@ietfa.amsl.com> Cc: i-d-announce@ietf.org To: lisp@ietf.org References: <154447482041.2905.16269043804590081816@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] I-D Action: draft-ietf-lisp-rfc6833bis-23.txt X-BeenThere: lisp@ietf.org 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: Mon, 10 Dec 2018 20:54:59 -0000 --Apple-Mail=_0A3B8C53-6760-4889-B9AE-189F7723C2E4 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii And here are the diffs since the IESG review (draft -16). Dino --Apple-Mail=_0A3B8C53-6760-4889-B9AE-189F7723C2E4 Content-Disposition: attachment; filename=rfcdiff-6833bis-16-23.html Content-Type: text/html; x-unix-mode=0644; name="rfcdiff-6833bis-16-23.html" Content-Transfer-Encoding: quoted-printable =20 =20 =20 Diff: draft-ietf-lisp-rfc6833bis-16.txt - = draft-ietf-lisp-rfc6833bis-23.txt=20 =20 =20 =20 =20 =20 =20 = = = = = =
< draft-ietf-lisp-rfc6833bis-16.txt  =  draft-ietf-lisp-rfc6833bis-23.txt >
=
Network Working = Group V. Fuller = Network Working Group = V. Fuller
Internet-Draft = D. Farinacci Internet-Draft = D. Farinacci
Obsoletes: 6833 = (if approved) Cisco Systems = Obsoletes: 6833 (if approved) = Cisco Systems
Intended status: = Standards Track A. Cabellos (Ed.) = Intended status: Standards Track = A. Cabellos (Ed.)
Expires: March 30, 2019 = UPC/BarcelonaTech Expires: June 13, 2019 = UPC/BarcelonaTech
= September = 26, 2018 = December = 10, 2018
=
= Locator/ID Separation Protocol (LISP) Control-Plane Locator/ID Separation Protocol (LISP) = Control-Plane
= draft-ietf-lisp-rfc6833bis-16 = = draft-ietf-lisp-rfc6833bis-23
=
Abstract = Abstract
=
This document = describes the Control-Plane and Mapping Service for the = This document describes the Control-Plane = and Mapping Service for the
Locator/ID = Separation Protocol (LISP), implemented by two new types = Locator/ID Separation Protocol (LISP), = implemented by two new types
of = LISP-speaking devices -- the LISP Map-Resolver and LISP = Map-Server of LISP-speaking devices = -- the LISP Map-Resolver and LISP Map-Server
-- that = provides a simplified "front end" for one or more Endpoint ID = -- that provides a simplified "front end" = for one or more Endpoint ID
to Routing = Locator mapping databases. to = Routing Locator mapping databases.
=
By using this = Control-Plane service interface and communicating with By using this Control-Plane service interface and = communicating with
Map-Resolvers = and Map-Servers, LISP Ingress Tunnel Routers (ITRs) and = Map-Resolvers and Map-Servers, LISP Ingress = Tunnel Routers (ITRs) and
Egress Tunnel = Routers (ETRs) are not dependent on the details of Egress Tunnel Routers (ETRs) are not dependent on the = details of
mapping = database systems, which facilitates modularity with different = mapping database systems, which facilitates = modularity with different
database = designs. Since these devices implement the "edge" of the = database designs. Since these devices = implement the "edge" of the
LISP = Control-Plane infrastructure, connect directly to = LISP-capable LISP = Control-Plane infrastructure, connecting EID = addressable nodes
Internet end sites, and comprising the bulk = of LISP-speaking devices, = of a LISP = site, their implementation and operational complexity
reducing their implementation and operational = complexity should also reduces the overall = cost and effort of deploying LISP.
reduce the overall cost and effort of = deploying LISP.
=
This document = obsoletes RFC 6830 and 6833. This = document obsoletes RFC 6830 and 6833.
=
Status of This = Memo Status of This Memo
=
This = Internet-Draft is submitted in full conformance with the = This Internet-Draft is submitted in full = conformance with the
provisions of = BCP 78 and BCP 79. provisions of = BCP 78 and BCP 79.
=
= Internet-Drafts are working documents of the Internet = Engineering Internet-Drafts are = working documents of the Internet Engineering
Task Force = (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also = distribute
working = documents as Internet-Drafts. The list of current Internet- = working documents as Internet-Drafts. The = list of current Internet-
Drafts is at = https://datatracker.ietf.org/drafts/current/. Drafts is at = https://datatracker.ietf.org/drafts/current/.
=
= Internet-Drafts are draft documents valid for a maximum of six = months Internet-Drafts are draft = documents valid for a maximum of six months
and may be = updated, replaced, or obsoleted by other documents at any = and may be updated, replaced, or obsoleted = by other documents at any
time. It is = inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as = reference
material or to = cite them other than as "work in progress." material or to cite them other than as "work in = progress."
=
This = Internet-Draft will expire on March 30, = 2019. This Internet-Draft will = expire on June 13, 2019.
=
Copyright = Notice Copyright Notice
=
Copyright (c) = 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons = identified as the
document = authors. All rights reserved. = document authors. All rights reserved.
=
This document = is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF = Trust's Legal
Provisions = Relating to IETF Documents = Provisions Relating to IETF Documents
= (https://trustee.ietf.org/license-info) in effect on the date = of = (https://trustee.ietf.org/license-info) in effect on the date of
publication of = this document. Please review these documents publication of this document. Please review these = documents
carefully, as = they describe your rights and restrictions with respect = carefully, as they describe your rights and = restrictions with respect
to this = document. Code Components extracted from this document must = to this document. Code Components extracted = from this document must
include = Simplified BSD License text as described in Section 4.e of = include Simplified BSD License text as = described in Section 4.e of
the Trust = Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without = warranty as
described in = the Simplified BSD License. = described in the Simplified BSD License.
=
Table of = Contents Table of Contents
=
1. = Introduction . . . . . . . . . . . . . . . . . . . . . . . . = 3 1. Introduction . . . . . . . . = . . . . . . . . . . . . . . . . 3
2. = Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 1.1. Scope of Applicability . . . . . . . . . . . . . = . . . . 4
3. = Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 2. = Requirements Notation . . . . . . . . . . . . . . . . . . . . 5
= 3. Definition of Terms . . . . . . . . . . = . . . . . . . . . . . 5
4. Basic = Overview . . . . . . . . . . . . . . . . . . . . . . . 6 = 4. Basic Overview . . . . . . . . . . . . = . . . . . . . . . . . 6
5. LISP = IPv4 and IPv6 Control-Plane Packet Formats . . . . . . . 7 5. LISP = IPv4 and IPv6 Control-Plane Packet Formats . . . . . . . 8
5.1. LISP = Control Packet Type Allocations . . . . . . . . . . 9 5.1. = LISP Control Packet Type Allocations . . . . . . . . . . 11
5.2. = Map-Request Message Format . . . . . . . . . . . . . . . 10 5.2. = Map-Request Message Format . . . . . . . . . . . . . . . 12
5.3. = EID-to-RLOC UDP Map-Request Message . . . . . . . . . . . 13 5.3. = EID-to-RLOC UDP Map-Request Message . . . . . . . . . . . 15
5.4. = Map-Reply Message Format . . . . . . . . . . . . . . . . 15 5.4. = Map-Reply Message Format . . . . . . . . . . . . . . . . 17
5.5. = EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . . . 19 5.5. = EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . . . 21
5.6. = Map-Register Message Format . . . . . . . . . . . . . . . 22 5.6. = Map-Register Message Format . . . . . . . . . . . . . . . 24
5.7. = Map-Notify/Map-Notify-Ack Message Format . . . . . . . . 25 5.7. = Map-Notify/Map-Notify-Ack Message Format . . . . . . . . 28
5.8. = Encapsulated Control Message Format . . . . . . . . . . . 27 5.8. = Encapsulated Control Message Format . . . . . . . . . . . 30
6. Changing = the Contents of EID-to-RLOC Mappings . . . . . . . . 29 6. = Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 32
6.1. = Solicit-Map-Request (SMR) . . . . . . . . . . . . . . . . 29 6.1. = Solicit-Map-Request (SMR) . . . . . . . . . . . . . . . . 32
7. Routing = Locator Reachability . . . . . . . . . . . . . . . . 30 7. = Routing Locator Reachability . . . . . . . . . . . . . . . . 33
7.1. = RLOC-Probing Algorithm . . . . . . . . . . . . . . . . . 32 7.1. = RLOC-Probing Algorithm . . . . . . . . . . . . . . . . . 35
8. = Interactions with Other LISP Components . . . . . . . . . . . 33 8. = Interactions with Other LISP Components . . . . . . . . . . . 36
8.1. ITR = EID-to-RLOC Mapping Resolution . . . . . . . . . . . 33 8.1. = ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . 36
8.2. = EID-Prefix Configuration and ETR Registration . . . . . . 34 8.2. = EID-Prefix Configuration and ETR Registration . . . . . . 37
8.3. = Map-Server Processing . . . . . . . . . . . . . . . . . . 36 8.3. = Map-Server Processing . . . . . . . . . . . . . . . . . . 39
8.4. = Map-Resolver Processing . . . . . . . . . . . . . . . . . 37 8.4. = Map-Resolver Processing . . . . . . . . . . . . . . . . . 40
8.4.1. = Anycast Operation . . . . . . . . . . . . . . . . . . 37 = 8.4.1. Anycast Operation . . . . . . . . . . . . . . . . . . 40
9. Security = Considerations . . . . . . . . . . . . . . . . . . . 37 9. = Security Considerations . . . . . . . . . . . . . . . . . . . 41
10. Changes = since RFC 6833 . . . . . . . . . . . . . . . . . . . 38 10. = Privacy Considerations . . . . . . . . . . . . . = . . . . . . 42
11. IANA Considerations . . . . . . . . . . . = . . . . . . . . . . 39 11. Changes since RFC = 6833 . . . . . . . . . . . . . . . . . . . 43
11.1. LISP UDP Port Numbers . . . . . . . = . . . . . . . . . . 40 12. IANA = Considerations . . . . . . . . . . . . . . . . . . . . . 44
11.2. LISP Packet Type Codes . . . . . . . = . . . . . . . . . . 40 12.1. LISP UDP Port = Numbers . . . . . . . . . . . . . . . . . 44
11.3. LISP ACT and Flag Fields . . . . . . = . . . . . . . . . . 40 12.2. LISP Packet = Type Codes . . . . . . . . . . . . . . . . . 44
11.4. LISP Address Type Codes . . . . . . = . . . . . . . . . . 41 12.3. LISP ACT and = Flag Fields . . . . . . . . . . . . . . . . 44
11.5. LISP Algorithm ID Numbers . . . . . = . . . . . . . . . . 41 12.4. LISP Address = Type Codes . . . . . . . . . . . . . . . . 45
12.5. LISP Algorithm ID Numbers . . . . . = . . . . . . . . . . 45
12. References . . . . . . . . . . . . . . . = . . . . . . . . . . 41 12.6. LISP Bit Flags . . . = . . . . . . . . . . . . . . . . . . 46
12.1. Normative References . . . . . . . . = . . . . . . . . . . 41 13. References . . . = . . . . . . . . . . . . . . . . . . . . . . 49
12.2. Informative References . . . . . . . = . . . . . . . . . . 42 13.1. Normative = References . . . . . . . . . . . . . . . . . . 49
Appendix A. = Acknowledgments . . . . . . . . . . . . . . . . . . 47 13.2. Informative References . . . . . . . = . . . . . . . . . . 50
Appendix B. = Document Change Log . . . . . . . . . . . . . . . . 47 = Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 55
B.1. = Changes to draft-ietf-lisp-rfc6833bis-16 = . . . . . . . . 47 Appendix B. Document Change Log . . . . . . . . . = . . . . . . . 55
B.2. = Changes to draft-ietf-lisp-rfc6833bis-15 = . . . . . . . . 47 B.1. Changes to draft-ietf-lisp-rfc6833bis-23 . . . . . . . . = 55
B.3. = Changes to draft-ietf-lisp-rfc6833bis-14 = . . . . . . . . 47 B.2. Changes to draft-ietf-lisp-rfc6833bis-22 . . . . . . . . = 55
B.4. = Changes to draft-ietf-lisp-rfc6833bis-13 = . . . . . . . . 47 B.3. Changes to draft-ietf-lisp-rfc6833bis-21 . . . . . . . . = 56
B.5. = Changes to draft-ietf-lisp-rfc6833bis-12 = . . . . . . . . 48 B.4. Changes to draft-ietf-lisp-rfc6833bis-20 . . . . . . . . = 56
B.6. = Changes to draft-ietf-lisp-rfc6833bis-11 = . . . . . . . . 48 B.5. Changes to draft-ietf-lisp-rfc6833bis-19 . . . . . . . . = 56
B.7. = Changes to draft-ietf-lisp-rfc6833bis-10 = . . . . . . . . 48 B.6. Changes to draft-ietf-lisp-rfc6833bis-18 . . . . . . . . = 56
B.8. = Changes to draft-ietf-lisp-rfc6833bis-09 = . . . . . . . . 48 B.7. Changes to draft-ietf-lisp-rfc6833bis-17 . . . . . . . . = 56
B.9. = Changes to draft-ietf-lisp-rfc6833bis-08 = . . . . . . . . 48 B.8. Changes to draft-ietf-lisp-rfc6833bis-16 . . . . . . . . = 57
B.10. = Changes to draft-ietf-lisp-rfc6833bis-07 = . . . . . . . . 48 B.9. Changes to draft-ietf-lisp-rfc6833bis-15 . . . . . . . . = 57
B.11. = Changes to draft-ietf-lisp-rfc6833bis-06 = . . . . . . . . 49 B.10. Changes to draft-ietf-lisp-rfc6833bis-14 . . . . . . . . = 57
B.12. = Changes to draft-ietf-lisp-rfc6833bis-05 = . . . . . . . . 49 B.11. Changes to draft-ietf-lisp-rfc6833bis-13 . . . . . . . . = 57
B.13. = Changes to draft-ietf-lisp-rfc6833bis-04 = . . . . . . . . 49 B.12. Changes to draft-ietf-lisp-rfc6833bis-12 . . . . . . . . = 57
B.14. = Changes to draft-ietf-lisp-rfc6833bis-03 = . . . . . . . . 50 B.13. Changes to draft-ietf-lisp-rfc6833bis-11 . . . . . . . . = 57
B.15. = Changes to draft-ietf-lisp-rfc6833bis-02 = . . . . . . . . 50 B.14. Changes to draft-ietf-lisp-rfc6833bis-10 . . . . . . . . = 58
B.16. = Changes to draft-ietf-lisp-rfc6833bis-01 = . . . . . . . . 50 B.15. Changes to draft-ietf-lisp-rfc6833bis-09 . . . . . . . . = 58
B.17. = Changes to draft-ietf-lisp-rfc6833bis-00 = . . . . . . . . 50 B.16. Changes to draft-ietf-lisp-rfc6833bis-08 . . . . . . . . = 58
B.18. = Changes to draft-farinacci-lisp-rfc6833bis-00 . . . . . . 51 B.17. = Changes to draft-ietf-lisp-rfc6833bis-07 = . . . . . . . . 58
Authors' = Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 B.18. = Changes to draft-ietf-lisp-rfc6833bis-06 . . . . = . . . . 59
= B.19. Changes to = draft-ietf-lisp-rfc6833bis-05 . . . . . . . . 59
= B.20. Changes to = draft-ietf-lisp-rfc6833bis-04 . . . . . . . . 59
= B.21. Changes to = draft-ietf-lisp-rfc6833bis-03 . . . . . . . . 60
= B.22. Changes to = draft-ietf-lisp-rfc6833bis-02 . . . . . . . . 60
= B.23. Changes to = draft-ietf-lisp-rfc6833bis-01 . . . . . . . . 60
= B.24. Changes to = draft-ietf-lisp-rfc6833bis-00 . . . . . . . . 60
= B.25. Changes = to draft-farinacci-lisp-rfc6833bis-00 . . . . . . 60
= Authors' Addresses . . . . . . . . . . . . = . . . . . . . . . . . 61
=
1. = Introduction 1. Introduction
=
The Locator/ID = Separation Protocol [I-D.ietf-lisp-rfc6830bis] (see The Locator/ID Separation Protocol = [I-D.ietf-lisp-rfc6830bis] (see
also = [I-D.ietf-lisp-introduction]) specifies an architecture and = also [I-D.ietf-lisp-introduction]) specifies = an architecture and
mechanism for = dynamic tunneling by logically separating the addresses = mechanism for dynamic tunneling by logically = separating the addresses
currently used = by IP in two separate name spaces: Endpoint IDs currently used by IP in two separate name spaces: = Endpoint IDs
(EIDs), used = within sites; and Routing Locators (RLOCs), used on the = (EIDs), used within sites; and Routing = Locators (RLOCs), used on the
transit = networks that make up the Internet infrastructure. To transit networks that make up the Internet = infrastructure. To
achieve this = separation, LISP defines protocol mechanisms for mapping = achieve this separation, LISP defines = protocol mechanisms for mapping
from EIDs to = RLOCs. In addition, LISP assumes the existence of a from EIDs to RLOCs. In addition, LISP assumes the = existence of a
database to = store and propagate those mappings globally.= Several database to store and = propagate those mappings across mapping = system
such = databases have been proposed; among them are the Content = nodes. = Several such databases have been proposed; among them are the
distribution = Overlay Network Service for LISP-NERD (a Not-so-novel = Content distribution Overlay Network Service for LISP-NERD (a Not-so-
EID-to-RLOC = Database) [RFC6837], LISP Alternative Logical Topology novel EID-to-RLOC = Database) [RFC6837], LISP Alternative Logical
(LISP-ALT) = [RFC6836], and LISP Delegated Database Tree (LISP-DDT) Topology (LISP-ALT) [RFC6836], and LISP Delegated = Database Tree
= [RFC8111]. (LISP-DDT) = [RFC8111].
=
The LISP = Mapping Service defines two new types of LISP-speaking The LISP Mapping Service defines two new types of = LISP-speaking
devices: the = Map-Resolver, which accepts Map-Requests from an Ingress = devices: the Map-Resolver, which accepts = Map-Requests from an Ingress
Tunnel Router = (ITR) and "resolves" the EID-to-RLOC mapping using a Tunnel Router (ITR) and "resolves" the EID-to-RLOC = mapping using a
mapping = database; and the Map-Server, which learns authoritative EID- = mapping database; and the Map-Server, which = learns authoritative EID-
to-RLOC = mappings from an Egress Tunnel Router (ETR) and publishes = to-RLOC mappings from an Egress Tunnel = Router (ETR) and publishes
them in a = database. them in a = database.
=
This LISP = Control-Plane Mapping Service can be used by many different = This LISP Control-Plane Mapping Service can = be used by many different
= encapsulation-based or translation-based Data-Planes which = include encapsulation-based or = translation-based Data-Planes which include
=
skipping to = change at = page 4, line 22 =C2=B6 = skipping to change at page 4, line 32 =C2=B6
=
Conceptually, = LISP Map-Servers share some of the same basic Conceptually, LISP Map-Servers share some of the same = basic
configuration = and maintenance properties as Domain Name System (DNS) configuration and maintenance properties as Domain = Name System (DNS)
[RFC1035] = servers; likewise, Map-Resolvers are conceptually similar = [RFC1035] servers; likewise, Map-Resolvers = are conceptually similar
to DNS caching = resolvers. With this in mind, this specification to DNS caching resolvers. With this in mind, this = specification
borrows = familiar terminology (resolver and server) from the DNS = borrows familiar terminology (resolver and = server) from the DNS
= specifications. = specifications.
=
Note this = document doesn't assume any particular database mapping = Note this document doesn't assume any = particular database mapping
infrastructure = to illustrate certain aspects of Map-Server and Map- infrastructure to illustrate certain aspects of = Map-Server and Map-
Resolver = operation, the Mapping Service interface = can (and likely Resolver = operation. The Mapping Service interface = can (and likely
will) be used = by ITRs and ETRs to access other mapping database will) be used by ITRs and ETRs to access other = mapping database
systems as the = LISP infrastructure evolves. = systems as the LISP infrastructure evolves.
=
The LISP Mapping = Service is an important component = of the LISP LISP is not intended to = address problems of connectivity = and scaling
toolset. Issues and concerns about the deployment of LISP for on behalf of arbitrary = communicating parties. Relevant situations
Internet traffic are discussed in [I-D.ietf-lisp-rfc6830bis], are described in the scoping section of the introduction = to
[RFC7215], and = [I-D.rodrigueznatal-lisp-oam]. = [I-D.ietf-lisp-rfc6830bis].
=
This document = obsoletes RFC 6830 and 6833. This = document obsoletes RFC 6830 and 6833.
=
= 1.1. Scope of = Applicability
=
= LISP was originally = developed to address the Internet-wide route
= scaling problem = [RFC4984].. While there are a number of approaches
= of interest for that = problem, as LISP as been developed and refined,
= a large number of = other LISP uses have been found and are being used.
= As such, the design = and development of LISP has changed so as to
= focus on these use = cases. The common property of these uses is a
= large set of = cooperating entities seeking to communicate over the
= public Internet or = other large underlay IP infrastructures, while
= keeping the = addressing and topology of the cooperating entities
= separate from the = underlay and Internet topology, routing, and
= = addressing.
= =
2. Requirements = Notation 2. Requirements = Notation
=
The key words = "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", = "SHALL", "SHALL NOT",
"SHOULD", = "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this = "SHOULD", "SHOULD NOT", "RECOMMENDED", = "NOT RECOMMENDED", "MAY", and
document are = to be interpreted as described in [RFC2119] and "OPTIONAL" in this document are to be interpreted as = described in BCP
[RFC8174]. 14 [RFC2119] [RFC8174] when, and only = when, they appear in all
= capitals, as shown = here.
=
3. Definition of = Terms 3. Definition of Terms
=
Map-Server: = A network infrastructure component that learns of EID- Map-Server: A network infrastructure component that = learns of EID-
Prefix = mapping entries from an ETR, via the registration mechanism = Prefix mapping entries from an ETR, via = the registration mechanism
described = below, or some other authoritative source if one exists. = described below, or some other = authoritative source if one exists.
A = Map-Server publishes these EID-Prefixes in a mapping database. = A Map-Server publishes these EID-Prefixes = in a mapping database.
=
Map-Request: = A LISP Map-Request is a Control-Plane message to query Map-Request: A LISP Map-Request is a Control-Plane = message to query
the mapping = system to resolve an EID. A LISP Map-Request can also the mapping system to resolve an EID. A LISP = Map-Request can also
=
skipping to = change at = page 7, line 31 =C2=B6 = skipping to change at page 8, line 31 =C2=B6
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | = Source Port | Dest Port | / | Source Port | Dest = Port |
UDP = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= UDP = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | = UDP Length | UDP Checksum | \ | UDP Length | UDP = Checksum |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = | | = |
| = LISP Message | | LISP Message = |
| = | | = |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
= IPv4 UDP LISP Control Message
= =
0 = 1 2 3 0 1 2 = 3
0 1 2 3 4 = 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 = 4 5 6 7 8 9 0 1
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| = Traffic Class | Flow Label | = |Version| Traffic Class | Flow = Label |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = Payload Length | Next Header=3D17| Hop Limit | = | Payload Length | Next = Header=3D17| Hop Limit |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = | | = |
+ = + + = +
| = | | = |
=
skipping to = change at = page 8, line 15 =C2=B6 = skipping to change at page 9, line 37 =C2=B6
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | = Source Port | Dest Port | / | Source Port | Dest = Port |
UDP = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= UDP = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | = UDP Length | UDP Checksum | \ | UDP Length | UDP = Checksum |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = | | = |
| = LISP Message | | LISP Message = |
| = | | = |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
= IPv6 UDP LISP Control Message
= =
When a UDP = Map-Request, Map-Register, or Map-Notify (when used as a = When a UDP Map-Request, Map-Register, or = Map-Notify (when used as a
notification = message) are sent, the UDP source port is chosen by the = notification message) are sent, the UDP = source port is chosen by the
sender and the = destination UDP port number is set to 4342. When a sender and the destination UDP port number is set to = 4342. When a
UDP Map-Reply, = Map-Notify (when used as an acknowledgement to a Map- UDP Map-Reply, Map-Notify (when used as an = acknowledgement to a Map-
Register), or = Map-Notify-Ack are sent, the source UDP port number is Register), or Map-Notify-Ack are sent, the source UDP = port number is
set to 4342 = and the destination UDP port number is copied from the set to 4342 and the destination UDP port number is = copied from the
source port of = either the Map-Request or the invoking data packet. source port of either the Map-Request or the invoking = data packet.
= Implementations MUST be prepared to accept packets when either = the Implementations MUST be = prepared to accept packets when either the
source port or = destination UDP port is set to 4342 due to NATs source port or destination UDP port is set to 4342 = due to NATs
changing port = number values. changing port number = values.
=
skipping to = change at = page 9, line 38 =C2=B6 = skipping to change at page 11, line = 38 =C2=B6
recommended to = use the LISP Shared Extension Message Type described recommended to use the LISP Shared Extension Message = Type described
in = [RFC8113]. in [RFC8113].
=
All LISP = Control-Plane messages use Address Family Identifiers (AFI) = All LISP Control-Plane messages use Address = Family Identifiers (AFI)
[AFI] or LISP = Canonical Address Format (LCAF) [RFC8060] formats to [AFI] or LISP Canonical Address Format (LCAF) = [RFC8060] formats to
encode either = fixed or variable length addresses. This includes encode either fixed or variable length addresses. = This includes
explicit = fields in each control message or part of EID-records or = explicit fields in each control message or = part of EID-records or
RLOC-records = in commonly formatted messages. = RLOC-records in commonly formatted messages.
=
The LISP = control-plane describes how other data-planes can encode = The LISP control-plane describes how other = data-planes can encode
messages to = support the SMR and RLOC-probing = procedures. messages to support = the Soliciting of Map-Requests as well as = RLOC-
= probing = procedures.
=
5.2. Map-Request = Message Format 5.2. Map-Request = Message Format
=
0 = 1 2 3 0 1 2 = 3
0 1 2 3 4 = 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 = 4 5 6 7 8 9 0 1
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=3D1 = |A|M|P|S|p|s|m|I| Rsvd |L|D| IRC | = Record Count | |Type=3D1 = |A|M|P|S|p|s|R|R| Rsvd |L|D| IRC | = Record Count |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = Nonce . . . | | Nonce . . . = |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = . . . Nonce | | . . . Nonce = |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = Source-EID-AFI | Source EID Address ... | = | Source-EID-AFI | = Source EID Address ... |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = ITR-RLOC-AFI 1 | ITR-RLOC Address 1 ... | = | ITR-RLOC-AFI 1 | = ITR-RLOC Address 1 ... |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = ... | | ... = |
=
skipping to = change at = page 10, line 38 =C2=B6 = skipping to change at page 12, line = 38 =C2=B6
| = Map-Reply Record ... | | Map-Reply Record ... = |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
Packet field = descriptions: Packet field = descriptions:
=
Type: 1 = (Map-Request) Type: 1 = (Map-Request)
=
A: This is an = authoritative bit, which is set to 0 for UDP-based Map- = A: This is an authoritative bit, which is = set to 0 for UDP-based Map-
Requests = sent by an ITR. It is set to 1 when an ITR wants the Requests sent by an ITR. It is set to 1 when an = ITR wants the
destination = site to return the Map-Reply rather than the mapping destination site to return the Map-Reply rather = than the mapping
database = system. database system returning a Map-Reply.
=
M: This is the = map-data-present bit. When set, it indicates that a M: This is the map-data-present bit. When set, it = indicates that a
Map-Reply = Record segment is included in the Map-Request. Map-Reply Record segment is included in the = Map-Request.
=
P: This is the = probe-bit, which indicates that a Map-Request SHOULD P: This is the probe-bit, which indicates that a = Map-Request SHOULD
be treated = as a Locator reachability probe. The receiver SHOULD be treated as a Locator reachability probe. The = receiver SHOULD
respond = with a Map-Reply with the probe-bit set, indicating that = respond with a Map-Reply with the = probe-bit set, indicating that
the = Map-Reply is a Locator reachability probe reply, with the = the Map-Reply is a Locator reachability = probe reply, with the
nonce = copied from the Map-Request. See RLOC-Probing Section 7.1 = nonce copied from the Map-Request. See = RLOC-Probing Section 7.1
for more = details. for more details. = This RLOC-probe Map-Request MUST not be sent = to
= the mapping = system. If a Map-Resolver or Map-Server receives a
= Map-Request with = the probe-bit set, it MUST drop the message.
=
S: This is the = Solicit-Map-Request (SMR) bit. See Solicit-Map- S: This is the Solicit-Map-Request (SMR) bit. See = Solicit-Map-
Request = (SMRs) Section 6.1 for details. = Request (SMRs) Section 6.1 for details.
=
p: This is the = PITR bit. This bit is set to 1 when a PITR sends a p: This is the PITR bit. This bit is set to 1 when a = PITR sends a
= Map-Request. = Map-Request.
=
s: This is the = SMR-invoked bit. This bit is set to 1 when an xTR is s: This is the SMR-invoked bit. This bit is set to 1 = when an xTR is
sending a = Map-Request in response to a received SMR-based Map- sending a Map-Request in response to a received = SMR-based Map-
= Request. Request.
=
m: This is the LISP mobile-node m-bit. This bit = is set by xTRs that R: This reserved and unassigned bit MUST be set to = 0 on transmit and
operate as a mobile node as defined in = [I-D.ietf-lisp-mn]. This MUST be ignored on = receipt.
bit can be ignored = if an implementation does not support
[I-D.ietf-lisp-mn].
I: This is the xTR-ID bit. When this bit is set, = what is appended to
the Map-Request is a 128-bit xTR router-ID. See LISP = PubSub usage
procedures in [I-D.ietf-lisp-pubsub] for details. = This bit can be
ignored = if an implementation does not = support
[I-D.ietf-lisp-pubsub].
=
Rsvd: This = field MUST be set to 0 on transmit and MUST be ignored on = Rsvd: This field MUST be set to 0 on = transmit and MUST be ignored on
= receipt. receipt.
=
L: This is the = local-xtr bit. It is used by an xTR in a LISP site to L: This is the local-xtr bit. It is used by an xTR = in a LISP site to
tell other = xTRs in the same site that it is part of the RLOC-set tell other xTRs in the same site that it is part = of the RLOC-set
for the = LISP site. The L-bit is set to 1 when the RLOC is the for the LISP site. The L-bit is set to 1 when the = RLOC is the
sender's IP = address. sender's IP = address.
=
D: This is the = dont-map-reply bit. It is used in the SMR procedure D: This is the dont-map-reply bit. It is used in the = SMR procedure
=
skipping to = change at = page 12, line 4 =C2=B6 = skipping to change at page 13, line = 47 =C2=B6
value of 0, = there is 1 ITR-RLOC address encoded; for a value of 1, value of 0, there is 1 ITR-RLOC address encoded; = for a value of 1,
there are 2 = ITR-RLOC addresses encoded, and so on up to 31, which there are 2 ITR-RLOC addresses encoded, and so on = up to 31, which
encodes a = total of 32 ITR-RLOC addresses. = encodes a total of 32 ITR-RLOC addresses.
=
Record Count: = This is the number of records in this Map-Request Record Count: This is the number of records in this = Map-Request
message. A = record is comprised of the portion of the packet that message. A record is comprised of the portion of = the packet that
is labeled = 'Rec' above and occurs the number of times equal to is labeled 'Rec' above and occurs the number of = times equal to
Record = Count. For this version of the protocol, a receiver MUST = Record Count. For this version of the = protocol, a receiver MUST
accept and = process Map-Requests that contain one or more records, accept and process Map-Requests that contain one = or more records,
but a = sender MUST only send Map-Requests containing one record. = but a sender MUST only send Map-Requests = containing one record.
=
Support for = processing multiple EIDs in a single Map-Request Support for processing multiple EIDs in a single = Map-Request
message = will be specified in a future version of the protocol. message will be specified in a future version of = the protocol.
=
Nonce: This = is an 8-octet random value created by the sender of the = Nonce: This is an 8-octet random value = created by the sender of the
= Map-Request. This nonce will be returned in the Map-Reply. = The Map-Request. This nonce = will be returned in the Map-Reply. The
security of = the LISP mapping protocol critically depends on the security of the LISP mapping protocol critically = depends on the
strength = of the nonce in the Map-Request message. The nonce strength of the nonce in the Map-Request message. = The nonce MUST
SHOULD be generated by a properly seeded = pseudo-random (or strong be = generated by a properly seeded pseudo-random (or strong random)
random) = source. See [RFC4086] for advice on generating security- = source. See [RFC4086] for advice on generating security-sensitive
sensitive random data. random data.
=
= Source-EID-AFI: This is the address family of the 'Source EID = Source-EID-AFI: This is the address family = of the 'Source EID
Address' = field. Address' field.
=
Source EID = Address: This is the EID of the source host that Source EID Address: This is the EID of the source = host that
originated = the packet that caused the Map-Request. When Map- originated the packet that caused the Map-Request. = When Map-
Requests = are used for refreshing a Map-Cache entry or for RLOC- Requests are used for refreshing a Map-Cache entry = or for RLOC-
Probing, an = AFI value 0 is used and this field is of zero length. Probing, an AFI value 0 is used and this field is = of zero length.
=
ITR-RLOC-AFI: = This is the address family of the 'ITR-RLOC Address' ITR-RLOC-AFI: This is the address family of the = 'ITR-RLOC Address'
=
skipping to = change at = page 12, line 37 =C2=B6 = skipping to change at page 14, line = 30 =C2=B6
ITR-RLOC = Address: This is used to give the ETR the option of ITR-RLOC Address: This is used to give the ETR the = option of
selecting = the destination address from any address family for the = selecting the destination address from = any address family for the
Map-Reply = message. This address MUST be a routable RLOC address Map-Reply message. This address MUST be a = routable RLOC address
of the = sender of the Map-Request message. = of the sender of the Map-Request message.
=
EID mask-len: = This is the mask length for the EID-Prefix. EID mask-len: This is the mask length for the = EID-Prefix.
=
= EID-Prefix-AFI: This is the address family of the EID-Prefix = EID-Prefix-AFI: This is the address family = of the EID-Prefix
according = to [AFI] and [RFC8060]. = according to [AFI] and [RFC8060].
=
EID-Prefix: = This prefix is 4 octets for an IPv4 address family and EID-Prefix: This prefix address length is 4 octets for an IPv4
16 octets = for an IPv6 address family when the EID-Prefix-AFI is 1 = address family and 16 octets for an IPv6 = address family when the
or 2, = respectively. For other AFIs [AFI], the length varies and = EID-Prefix-AFI is 1 or 2, respectively. = For other AFIs [AFI], the
for the = LCAF AFI the format is defined in [RFC8060]. When a Map- = address length varies and for the LCAF AFI = the format is defined
Request is sent by an ITR because a data = packet is received for a in = [RFC8060]. When a Map-Request is sent by = an ITR because a data
= destination where there is no mapping entry, the EID-Prefix is = set packet is received for a = destination where there is no mapping
to the = destination IP address of the data packet, and the 'EID = entry, the EID-Prefix is set to the = destination IP address of the
mask-len' = is set to 32 or 128 for IPv4 or IPv6, respectively. data packet, and the 'EID mask-len' is set to 32 = or 128 for IPv4
When an = xTR wants to query a site about the status of a mapping it = or IPv6, respectively. When an xTR = wants to query a site about
already = has cached, the EID-Prefix used in the Map-Request has the = the status of a mapping it already has = cached, the EID-Prefix used
same = mask length as the EID-Prefix returned = from the site when it in the = Map-Request has the same mask-length as = the EID-Prefix
sent a = Map-Reply message. returned = from the site when it sent a Map-Reply message.
=
Map-Reply = Record: When the M-bit is set, this field is the size of a = Map-Reply Record: When the M-bit is set, = this field is the size of a
single = "Record" in the Map-Reply format. This Map-Reply record = single "Record" in the Map-Reply format. = This Map-Reply record
contains = the EID-to-RLOC mapping entry associated with the Source = contains the EID-to-RLOC mapping entry = associated with the Source
EID. This = allows the ETR that will receive this Map-Request to EID. This allows the ETR that will receive this = Map-Request to
cache the = data if it chooses to do so. = cache the data if it chooses to do so.
=
5.3. EID-to-RLOC = UDP Map-Request Message 5.3. = EID-to-RLOC UDP Map-Request Message
=
A Map-Request = is sent from an ITR when it needs a mapping for an EID, = A Map-Request is sent from an ITR when it = needs a mapping for an EID,
=
skipping to = change at = page 13, line 51 =C2=B6 = skipping to change at page 15, line = 49 =C2=B6
Map-Requests = MUST be rate-limited. It is RECOMMENDED that a Map- Map-Requests MUST be rate-limited. It is RECOMMENDED = that a Map-
Request for = the same EID-Prefix be sent no more than once per second. = Request for the same EID-Prefix be sent no = more than once per second.
However, = recommendations from [RFC8085] SHOULD be considered. However, recommendations from [RFC8085] SHOULD be = considered.
=
An ITR that is = configured with mapping database information (i.e., it An ITR that is configured with mapping database = information (i.e., it
is also an = ETR) MAY optionally include those mappings in a Map- is also an ETR) MAY optionally include those mappings = in a Map-
Request. When = an ETR configured to accept and verify such Request. When an ETR configured to accept and verify = such
"piggybacked" = mapping data receives such a Map-Request and it does "piggybacked" mapping data receives such a = Map-Request and it does
not have this = mapping in the Map-Cache, it MAY originate a "verifying = not have this mapping in the Map-Cache, it = MAY originate a "verifying
Map-Request", = addressed to the map-requesting ITR and the ETR MAY add = Map-Request", addressed to the = map-requesting ITR and the ETR MAY add
a Map-Cache = entry. If the ETR has a Map-Cache entry that matches the = a Map-Cache entry. If the ETR (when it is an xTR co-located as an
= "piggybacked" EID and the RLOC is in the Locator-Set for the = entry, = ITR) has a Map-Cache entry that matches the "piggybacked" EID and = the
then it MAY = send the "verifying Map-Request" directly to the RLOC is in the Locator-Set for the entry, then it = MAY send the
originating = Map-Request source. If the RLOC is not in the Locator- = "verifying Map-Request" directly to the originating Map-Request
Set, then the ETR MUST send the "verifying = Map-Request" to the source. If = the RLOC is not in the Locator-Set, then = the ETR MUST
= "piggybacked" EID. Doing this forces the "verifying Map-Request" = to send the "verifying = Map-Request" to the "piggybacked" EID. Doing
go through = the mapping database system to reach the authoritative this forces the "verifying Map-Request" to go = through the mapping
source of = information about that EID, guarding against RLOC-spoofing = database system to reach the authoritative = source of information
in the = "piggybacked" mapping data. about = that EID, guarding against RLOC-spoofing in the "piggybacked"
= mapping data.
=
5.4. Map-Reply = Message Format 5.4. Map-Reply Message = Format
=
0 = 1 2 3 0 1 2 = 3
0 1 2 3 4 = 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 = 4 5 6 7 8 9 0 1
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=3D2 = |P|E|S| Reserved | Record Count | = |Type=3D2 |P|E|S| Reserved = | Record Count |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = Nonce . . . | | Nonce . . . = |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
skipping = to change at page 16, line = 11 =C2=B6 = skipping to change at page 18, line = 11 =C2=B6
= authentication information will be appended to the end of the = Map- authentication information = will be appended to the end of the Map-
Reply. The = details of signing a Map-Reply message can be found in Reply. The details of signing a Map-Reply message = can be found in
= [I-D.ietf-lisp-sec]. = [I-D.ietf-lisp-sec].
=
0 = 1 2 3 0 1 2 = 3
0 1 2 3 4 5 = 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 = 6 7 8 9 0 1
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AD Type = | Authentication Data Content . . . | | AD Type | Authentication Data Content = . . . |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
Reserved: = This field MUST be set to 0 on transmit and MUST be Reserved: This unassigned field MUST be set to 0 on transmit = and
ignored = on receipt. MUST be ignored on = receipt.
=
Record Count: = This is the number of records in this reply message. Record Count: This is the number of records in this = reply message.
A record is = comprised of that portion of the packet labeled A record is comprised of that portion of the = packet labeled
'Record' = above and occurs the number of times equal to Record 'Record' above and occurs the number of times = equal to Record
= Count. Count.
=
Nonce: This = is a 24-bit value set in a = Data-Probe Nonce: This = 64-bit value from the Map-Request is echoed in this
[I-D.ietf-lisp-rfc6830bis] or a 64-bit = value from the Map-Request = 'Nonce' field of the Map-Reply.
is echoed = in this 'Nonce' field of the Map-Reply. When a = 24-bit
value is supplied, it resides in the low-order 64 = bits of the
'Nonce' field.
=
Record TTL: = This is the time in minutes the recipient of the Map- Record TTL: This is the time in minutes the = recipient of the Map-
Reply will = store the mapping. If the TTL is 0, the entry MUST be Reply will store the mapping. If the TTL is 0, = the entry MUST be
removed = from the cache immediately. If the value is 0xffffffff, = removed from the cache immediately. If = the value is 0xffffffff,
the = recipient can decide locally how long to store the mapping. = the recipient can decide locally how long = to store the mapping.
=
Locator Count: = This is the number of Locator entries. A Locator Locator Count: This is the number of Locator = entries. A Locator
entry = comprises what is labeled above as 'Loc'. The Locator count = entry comprises what is labeled above as = 'Loc'. The Locator count
can be 0, = indicating that there are no Locators for the EID- can be 0, indicating that there are no Locators = for the EID-
= Prefix. Prefix.
=
skipping = to change at page 17, line = 23 =C2=B6 = skipping to change at page 19, line = 19 =C2=B6
(4) = Drop/Policy-Denied: A packet that matches this Map-Cache = (4) Drop/Policy-Denied: A packet that = matches this Map-Cache
entry = is dropped. The reason for the Drop action is that a entry is dropped. The reason for the Drop = action is that a
= Map-Request for the target-EID is being policy denied by = Map-Request for the target-EID is = being policy denied by
either = an xTR or the mapping system. = either an xTR or the mapping system.
=
(5) = Drop/Authentication-Failure: A packet that matches this Map- = (5) Drop/Authentication-Failure: A = packet that matches this Map-
Cache = entry is dropped. The reason for the Drop action is Cache entry is dropped. The reason for the = Drop action is
that a = Map-Request for the target-EID fails an authentication that a Map-Request for the target-EID fails an = authentication
= verification-check by either an xTR or the mapping system. = verification-check by either an xTR = or the mapping system.
=
A: The = Authoritative bit, when sent, is always = set to 1 by an ETR. A: The = Authoritative bit, when set to 1, is = always set to 1 by an
When a = Map-Server is proxy Map-Replying for a LISP site, the ETR. When a Map-Server is proxy Map-Replying for = a LISP site, the
= Authoritative bit is set to 0. This indicates to requesting = ITRs Authoritative bit is set to = 0. This indicates to requesting ITRs
that the = Map-Reply was not originated by a LISP node managed at that the Map-Reply was not originated by a LISP = node managed at
the site = that owns the EID-Prefix. the = site that owns the EID-Prefix.
=
Map-Version = Number: When this 12-bit value is non-zero, the Map- Map-Version Number: When this 12-bit value is = non-zero, the Map-
Reply = sender is informing the ITR what the version number is for = Reply sender is informing the ITR what = the version number is for
the EID = record contained in the Map-Reply. The ETR can allocate = the EID record contained in the = Map-Reply. The ETR can allocate
this number = internally but MUST coordinate this value with other this number internally but MUST coordinate this = value with other
ETRs for = the site. When this value is 0, there is no versioning = ETRs for the site. When this value is 0, = there is no versioning
information = conveyed. The Map-Version Number can be included in information conveyed. The Map-Version Number can = be included in
=
skipping = to change at page 18, line = 44 =C2=B6 = skipping to change at page 20, line = 40 =C2=B6
Locators in = this Locator-Set. Locators in = this Locator-Set.
=
p: When this = bit is set, an ETR informs the RLOC-Probing ITR that the = p: When this bit is set, an ETR informs the = RLOC-Probing ITR that the
locator = address for which this bit is set is the one being RLOC- = locator address for which this bit is set = is the one being RLOC-
probed and = may be different from the source address of the Map- probed and may be different from the source = address of the Map-
Reply. An = ITR that RLOC-probes a particular Locator MUST use this = Reply. An ITR that RLOC-probes a = particular Locator MUST use this
Locator for = retrieving the data structure used to store the fact Locator for retrieving the data structure used to = store the fact
that the = Locator is reachable. The p-bit is set for a single that the Locator is reachable. The p-bit is set = for a single
Locator in = the same Locator-Set. If an implementation sets more Locator in the same Locator-Set. If an = implementation sets more
than one = p-bit erroneously, the receiver of the Map-Reply MUST than one p-bit erroneously, the receiver of the = Map-Reply MUST
select = the first Locator. The p-bit MUST NOT be set for Locator- = select the first set p-bit Locator. The = p-bit MUST NOT be set for
Set records sent in Map-Request and = Map-Register messages. Locator-Set records sent in Map-Request and = Map-Register messages.
=
R: This is set = when the sender of a Map-Reply has a route to the R: This is set when the sender of a Map-Reply has a = route to the
Locator in = the Locator data record. This receiver may find this Locator in the Locator data record. This receiver = may find this
useful to = know if the Locator is up but not necessarily reachable = useful to know if the Locator is up but = not necessarily reachable
from the = receiver's point of view. See also EID-Reachability from the receiver's point of view. See also = EID-Reachability
Section 7.1 = for another way the R-bit may be used. = Section 7.1 for another way the R-bit may be used.
=
Locator: This = is an IPv4 or IPv6 address (as encoded by the 'Loc- Locator: This is an IPv4 or IPv6 address (as encoded = by the 'Loc-
AFI' = field) assigned to an ETR. Note that the = destination RLOC AFI' field) = assigned to an ETR and used by an ITR as a = destination
address = MAY be an anycast address. A source RLOC can be an RLOC address in the outer = header of a LISP encapsualted packet.
anycast = address as well. The source or destination RLOC MUST NOT = =
be the = broadcast address (255.255.255.255 or any subnet broadcast = Note that the destination RLOC address = of a LISP encapsulated
address = known to the router) and MUST NOT be a link-local packet MAY be an = anycast address. A source RLOC of a = LISP
multicast = address. The source RLOC MUST NOT be a multicast encapsulated packet = can be an anycast address as well. The source
address. = The destination RLOC SHOULD be a multicast address if it = or destination RLOC MUST NOT be the = broadcast address
is being = mapped from a multicast destination EID. (255.255.255.255 or any subnet broadcast address = known to the
= router) and MUST NOT be a link-local = multicast address. The
= source RLOC MUST NOT be a multicast = address. The destination RLOC
= SHOULD be a multicast address if it is = being mapped from a
= multicast destination EID.
=
5.5. EID-to-RLOC = UDP Map-Reply Message 5.5. = EID-to-RLOC UDP Map-Reply Message
=
A Map-Reply = returns an EID-Prefix with a prefix length = that is less A Map-Reply returns = an EID-Prefix with a mask-length that is = less
than or equal = to the EID being requested. The EID being requested is = than or equal to the EID being requested. = The EID being requested is
either from = the destination field of an IP header of a Data-Probe or = either from the destination field of an IP = header of a Data-Probe or
the EID record = of a Map-Request. The RLOCs in the Map-Reply are the EID record of a Map-Request. The RLOCs in the = Map-Reply are
routable IP = addresses of all ETRs for the LISP site. Each RLOC routable IP addresses of all ETRs for the LISP site. = Each RLOC
conveys status = reachability but does not convey path reachability conveys status reachability but does not convey path = reachability
from a = requester's perspective. Separate testing of path from a requester's perspective. Separate testing of = path
reachability = is required. See RLOC-reachability Section 7.1 for reachability is required. See RLOC-reachability = Section 7.1 for
= details. details.
=
Note that a = Map-Reply MAY contain different EID-Prefix granularity Note that a Map-Reply MAY contain different = EID-Prefix granularity
(prefix + = length) than the Map-Request that triggers = it. This might (prefix + mask-length) than the Map-Request that triggers = it. This
occur if a = Map-Request were for a prefix that had been returned by an = might occur if a Map-Request were for a = prefix that had been returned
earlier = Map-Reply. In such a case, the requester updates its cache = by an earlier Map-Reply. In such a case, = the requester updates its
with the new = prefix information and granularity. For example, a cache with the new prefix information and = granularity. For example,
requester = with two cached EID-Prefixes that are covered by a Map- = a requester with two cached EID-Prefixes = that are covered by a Map-
Reply = containing one less-specific prefix replaces the entry with the = Reply containing one less-specific prefix = replaces the entry with the
less-specific = EID-Prefix. Note that the reverse, replacement of one less-specific EID-Prefix. Note that the reverse, = replacement of one
less-specific = prefix with multiple more-specific prefixes, can also less-specific prefix with multiple more-specific = prefixes, can also
occur, not by = removing the less-specific prefix but rather by adding occur, not by removing the less-specific prefix but = rather by adding
the = more-specific prefixes that, during a lookup, will override the = the more-specific prefixes that, during a = lookup, will override the
less-specific = prefix. less-specific = prefix.
=
When an EID = moves out of a LISP site [I-D.ietf-lisp-eid-mobility], When an EID moves out of a LISP site = [I-D.ietf-lisp-eid-mobility],
the database = mapping system may have overlapping EID-prefixes. Or the database mapping system may have overlapping = EID-prefixes. Or
when a LISP = site is configured with multiple sets of ETRs that when a LISP site is configured with multiple sets of = ETRs that
support = different EID-prefix lengths, the database = mapping system may support = different EID-prefix mask-lengths, the = database mapping
have = overlapping EID-prefixes. When overlapping EID-prefixes exist, system may have overlapping EID-prefixes. When = overlapping EID-
a = Map-Request with an EID that best matches any EID-Prefix MUST be prefixes exist, a = Map-Request with an EID that best matches any EID-
returned in = a single Map-Reply message. For instance, if an ETR had = Prefix MUST = be returned in a single Map-Reply message. For instance,
database = mapping entries for EID-Prefixes: = if an ETR had database mapping entries for EID-Prefixes:
=
= 2001:db8::/16 = 2001:db8::/16
= 2001:db8:1::/24 = 2001:db8:1::/24
= 2001:db8:1:1::/32 = 2001:db8:1:1::/32
= 2001:db8:1:2::/32 = 2001:db8:1:2::/32
=
A Map-Request = for EID 2001:db8:1:1::1 would cause a Map-Reply with a A Map-Request for EID 2001:db8:1:1::1 would cause a = Map-Reply with a
record count = of 1 to be returned with a mapping record EID-Prefix of = record count of 1 to be returned with a = mapping record EID-Prefix of
= 2001:db8:1:1::/32. = 2001:db8:1:1::/32.
=
A Map-Request = for EID 2001:db8:1:5::5 would cause a Map-Reply with a A Map-Request for EID 2001:db8:1:5::5 would cause a = Map-Reply with a
record count = of 3 to be returned with mapping records for EID- record count of 3 to be returned with mapping records = for EID-
Prefixes = 2001:db8:1::/24, 2001:db8:1:1::/32, 2001:db8:1:2::/32. Note = Prefixes 2001:db8:1::/24, 2001:db8:1:1::/32, 2001:db8:1:2::/32,
filling out = the /24 with more-specifics that exist in the mapping filling out the /24 with more-specifics that exist in = the mapping
= system. system.
=
Note that not = all overlapping EID-Prefixes need to be returned but Note that not all overlapping EID-Prefixes need to be = returned but
only the = more-specific entries (note that in the second example above = only the more-specific entries (note that in = the second example above
2001:db8::/16 = was not returned for requesting EID 2001:db8:1:5::5) 2001:db8::/16 was not returned for requesting EID = 2001:db8:1:5::5)
for the = matching EID-Prefix of the requesting EID. When more than = for the matching EID-Prefix of the = requesting EID. When more than
one EID-Prefix = is returned, all SHOULD use the same Time to Live one EID-Prefix is returned, all SHOULD use the same = Time to Live
value so they = can all time out at the same time. When a more- value so they can all time out at the same time. = When a more-
specific = EID-Prefix is received later, its Time to Live value in the = specific EID-Prefix is received later, its = Time to Live value in the
=
skipping = to change at page 21, line = 8 =C2=B6 = skipping to change at page 23, line = 8 =C2=B6
message. The = Locator-Set MUST be sorted in order of ascending IP message. The Locator-Set MUST be sorted in order of = ascending IP
address where = an IPv4 locator address is considered numerically 'less = address where an IPv4 locator address is = considered numerically 'less
than' an IPv6 = locator address. than' an IPv6 = locator address.
=
When sending a = Map-Reply message, the destination address is copied When sending a Map-Reply message, the destination = address is copied
from one of = the 'ITR-RLOC' fields from the Map-Request. The ETR can = from one of the 'ITR-RLOC' fields from the = Map-Request. The ETR can
choose a = locator address from one of the address families it choose a locator address from one of the address = families it
supports. For = Data-Probes, the destination address of the Map-Reply supports. For Data-Probes, the destination address = of the Map-Reply
is copied from = the source address of the Data-Probe message that is is copied from the source address of the Data-Probe = message that is
invoking the = reply. The source address of the Map-Reply is one of invoking the reply. The source address of the = Map-Reply is one of
the local IP = addresses chosen to allow Unicast Reverse Path the local IP addresses chosen, to allow Unicast Reverse Path
Forwarding = (uRPF) checks to succeed in the upstream service provider. = Forwarding (uRPF) checks to succeed in the = upstream service provider.
The = destination port of a Map-Reply message is copied from the = source The destination port of a = Map-Reply message is copied from the source
port of the = Map-Request or Data-Probe, and the source port of the port of the Map-Request or Data-Probe, and the source = port of the
Map-Reply = message is set to the well-known UDP port 4342. Map-Reply message is set to the well-known UDP port = 4342.
=
5.6. = Map-Register Message Format 5.6. = Map-Register Message Format
=
This section = specifies the encoding format for the Map-Register This section specifies the encoding format for the = Map-Register
message. The = message is sent in UDP with a destination UDP port of message. The message is sent in UDP with a = destination UDP port of
4342 and a = randomly selected UDP source port number. 4342 and a randomly selected UDP source port = number.
=
= The fields below are = used in multiple control messages. They are
= defined for = Map-Register, Map-Notify and Map-Notify-Ack message
= = types.
= =
The = Map-Register message format is: The = Map-Register message format is:
=
0 = 1 2 3 0 1 2 = 3
0 1 2 3 4 = 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 = 4 5 6 7 8 9 0 1
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=3D3 = |P|S|I| Reserved |E|T|a|m|M| = Record Count | |Type=3D3 = |P|S|I| Reserved |E|T|a|R|M| = Record Count |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = Nonce . . . | | Nonce . . . = |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = . . . Nonce | | . . . Nonce = |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key = ID | Algorithm ID | Authentication Data Length | = | Key ID | Algorithm ID | = Authentication Data Length |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ = Authentication Data ~ ~ Authentication Data = ~
+-> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= +-> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | = Record TTL | | | Record TTL = |
=
skipping = to change at page 23, line = 5 =C2=B6 = skipping to change at page 25, line = 8 =C2=B6
Type: 3 = (Map-Register) Type: 3 = (Map-Register)
=
P: This is the = proxy Map-Reply bit. When set to 1, an ETR sends a P: This is the proxy Map-Reply bit. When set to 1, = an ETR sends a
= Map-Register message requesting the Map-Server to proxy a Map- = Map-Register message requesting the = Map-Server to proxy a Map-
Reply. The = Map-Server will send non-authoritative Map-Replies on Reply. The Map-Server will send non-authoritative = Map-Replies on
behalf of = the ETR. behalf of the = ETR.
=
S: This is the = security-capable bit. When set, the procedures from S: This is the security-capable bit. When set, the = procedures from
= [I-D.ietf-lisp-sec] are supported. = [I-D.ietf-lisp-sec] are supported.
=
I: This is = the xTR-ID bit. = When this bit is set, what is = appended to I: This bit is set to 1 to = indicate that a 128 bit xTR-ID and a = 64
the = Map-Register is a 128-bit xTR router-ID and then a 64-bit = bit Site-ID fields are present at the end of the = Map-Register
site-ID. See LISP NAT-Traversal procedures in message. If an xTR = is configured with an xTR-ID and Site-ID, = it
[I-D.ermagan-lisp-nat-traversal] for = details. = MUST set the I bit to 1 and include = its xTR-ID and Site-ID in the
= Map-Register messages it generates. The combination of = Site-ID
= plus xTR-ID = uniquely identifies an xTR in a = LISP domain and serves
= to track its last = seen nonce.
=
Reserved: = This field MUST be set to 0 on transmit and MUST be Reserved: This unassigned field MUST be set to 0 on transmit = and
ignored = on receipt. MUST be ignored on = receipt.
=
E: This is the = Map-Register EID-notify bit. This is used by a First- E: This is the Map-Register EID-notify bit. This is = used by a First-
Hop-Router = (FHR) which discovers a dynamic-EID. This EID-notify Hop-Router (FHR) which discovers a dynamic-EID. = This EID-notify
based = Map-Register is sent by the FHR to the same site xTR that = based Map-Register is sent by the FHR to = the same site xTR that
propogates = the Map-Register to the mapping system. The site xTR propogates the Map-Register to the mapping system. = The site xTR
keeps state = to later Map-Notify the FHR after the EID has moves keeps state to later Map-Notify the FHR after the = EID has moves
away. See = [I-D.ietf-lisp-eid-mobility] for a detailed use-case. away. See [I-D.ietf-lisp-eid-mobility] for a = detailed use-case.
=
T: This is the = use-TTL for timeout bit. When set to 1, the xTR wants T: This is the use-TTL for timeout bit. When set to = 1, the xTR wants
the = Map-Server to time out registrations based on the value in the = the Map-Server to time out registrations = based on the value in the
"Record = TTL" field of this message. = "Record TTL" field of this message. Otherwise, = the default
= timeout described = in Section 8.2 is used.
=
a: This is the = merge-request bit. When set to 1, the xTR requests to a: This is the merge-request bit. When set to 1, the = xTR requests to
merge = RLOC-records from different xTRs registering the same EID- = merge RLOC-records from different xTRs = registering the same EID-
record. = See signal-free multicast [RFC8378] for one use case record. See signal-free multicast [RFC8378] for = one use case
= example. example.
=
m: This is the = mobile-node bit. When set to 1, the = registering xTR R: This reserved and = unassigned bit MUST be set to 0 on = transmit and
supports the procedures in [I-D.ietf-lisp-mn]. = This bit can be MUST be ignored on = receipt.
ignored = if an implementation does not support = [I-D.ietf-lisp-mn]
=
M: This is the = want-map-notify bit. When set to 1, an ETR is M: This is the want-map-notify bit. When set to 1, = an ETR is
requesting = a Map-Notify message to be returned in response to requesting a Map-Notify message to be returned in = response to
sending a = Map-Register message. The Map-Notify message sent by a = sending a Map-Register message. The = Map-Notify message sent by a
Map-Server = is used to acknowledge receipt of a Map-Register Map-Server is used to acknowledge receipt of a = Map-Register
= message. message.
=
Record Count: = This is the number of records in this Map-Register Record Count: This is the number of records in this = Map-Register
message. A = record is comprised of that portion of the packet message. A record is comprised of that portion of = the packet
labeled = 'Record' above and occurs the number of times equal to labeled 'Record' above and occurs the number of = times equal to
Record = Count. Record Count.
=
Nonce: This = 8-octet 'Nonce' field is set to 0 in = Map-Register Nonce: This = 8-octet 'Nonce' field is incremented each time a = Map-
messages if no Map-Notify message is expected to acknowledge it. Register message is = sent. When a Map-Register acknowledgement = is
Since the = Map-Register message is authenticated, the 'Nonce' field = requested, the = nonce is returned by Map-Servers in Map-Notify
is not = currently used for any security function but may = be in the messages. Since the entire Map-Register message is = authenticated,
future as part of an anti-replay = solution. the 'Nonce' = field serves to protect against Map-Register = replay
= attacks. An ETR = that registers to the mapping system SHOULD store
= the last nonce = sent in persistent storage so when it restarts it
= can continue = using an incrementing nonce. If the the ETR cannot
= support saving = the nonce, then when it restarts it MUST use a new
= authentication = key to register to the mapping system. A Map-
= Server MUST track = and save in persistent storage the last nonce
= received for each = ETR xTR-ID that registers to it. If a Map-
= Register is = received with a nonce value that is not greater than
= the saved nonce, = it drops the Map-Register message and logs the
= fact a replay = attack could have occurred.
=
Key ID: This = is a configured key-id value that corresponds to a Key ID: This is a configured key-id value that = corresponds to a
= shared-secret password that is used to authenticate the sender. = shared-secret password that is used to = authenticate the sender.
=
Multiple = shared-secrets can be used to roll over keys in a non- Multiple shared-secrets can be used to roll over = keys in a non-
disruptive = way. disruptive way.
=
Algorithm ID: = This is the configured Message Authentication Code Algorithm ID: This is the configured Message = Authentication Code
(MAC) = algorithm value used for the authentication function. See = (MAC) algorithm value used for the = authentication function. See
Algorithm = ID Numbers in the Section 11.5 for = codepoint Algorithm ID Numbers = in the Section 12.5 for codepoint
= assignments. = assignments.
=
Authentication = Data Length: This is the length in octets of the Authentication Data Length: This is the length in = octets of the
= 'Authentication Data' field that follows this field. The = length 'Authentication Data' = field that follows this field. The length
of the = 'Authentication Data' field is dependent on the MAC of the 'Authentication Data' field is dependent on = the MAC
algorithm = used. The length field allows a device that doesn't algorithm used. The length field allows a device = that doesn't
know the = MAC algorithm to correctly parse the packet. know the MAC algorithm to correctly parse the = packet.
=
= Authentication Data: This is the message digest = used from the output = Authentication Data: This is the output of the MAC algorithm. = The
of the = MAC algorithm. The entire Map-Register payload is entire Map-Register payload (from and including the LISP message
= type field = through the end of the last RLOC record) is
= authenticated with this field preset to 0. After the MAC is = authenticated with this field preset to = 0. After the MAC is
computed, = it is placed in this field. Implementations of this computed, it is placed in this field. = Implementations of this
= specification MUST include support for HMAC-SHA-1-96 [RFC2404], = specification MUST include support for either HMAC-SHA-1-96
and support for HMAC-SHA-256-128 [RFC4868] is = RECOMMENDED. [RFC2404] and HMAC-SHA-256-128 [RFC4868] where the latter is
= RECOMMENDED.
=
The definition = of the rest of the Map-Register can be found in EID- The definition of the rest of the Map-Register can be = found in EID-
record = description in Section 5.4. record = description in Section 5.4. When the I-bit is = set, the
= following fields are = added to the end of thd Map-Register message:
=
= xTR-ID: xTR-ID is a = 128 bit field at the end of the Map-Register
= message, starting = after the final Record in the message. The xTR-
= ID is used to = uniquely identify a xTR. The same xTR-ID value MUST
= NOT be used in = two different xTRs.
=
= Site-ID: Site-ID is = a 64 bit field at the end of the Map- Register
= message, = following the xTR-ID. Site-ID is used to uniquely
= identify to which = site the xTR that sent the message belongs.
=
5.7. = Map-Notify/Map-Notify-Ack Message Format 5.7. Map-Notify/Map-Notify-Ack Message Format
=
This section = specifies the encoding format for the Map-Notify and This section specifies the encoding format for the = Map-Notify and
Map-Notify-Ack = messages. The messages are sent inside a UDP packet Map-Notify-Ack messages. The messages are sent = inside a UDP packet
with source = and destination UDP ports equal to 4342. with source and destination UDP ports equal to = 4342.
=
The Map-Notify = and Map-Notify-Ack message formats are: = The Map-Notify and Map-Notify-Ack message formats are:
=
0 = 1 2 3 0 1 2 = 3
=
skipping = to change at page 25, line = 46 =C2=B6 = skipping to change at page 28, line = 46 =C2=B6
| o | = Unused Flags |L|p|R| Loc-AFI | = | o | Unused Flags |L|p|R| = Loc-AFI |
| c = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= | c = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| \| = Locator | | \| Locator = |
+-> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= +-> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
Packet field = descriptions: Packet field = descriptions:
=
Type: 4/5 = (Map-Notify/Map-Notify-Ack) Type: = 4/5 (Map-Notify/Map-Notify-Ack)
=
The Map-Notify = message has the same contents as a Map-Register The Map-Notify message has the same contents as a = Map-Register
message. = See the Map-Register section for field descriptions. message. See the Map-Register section for field = descriptions and the
= Map-Reply section = for EID-record and RLOC-record descriptions.
=
The = Map-Notify-Ack message has the same contents as a Map-Notify = The Map-Notify-Ack message has the same = contents as a Map-Notify
message. It = is used to acknowledge the receipt of a Map-Notify and message. It is used to acknowledge the receipt of a = Map-Notify
for the = sender to stop retransmitting a Map-Notify with the same = (solicited or = unsolicited) and for the sender to stop retransmitting
= nonce. a Map-Notify with the same = nonce.
=
A Map-Server = sends an unsolicited Map-Notify message (one that is not = A Map-Server sends an unsolicited Map-Notify = message (one that is not
used as an = acknowledgment to a Map-Register message) that follows the = used as an acknowledgment to a Map-Register = message) that follows the
Congestion = Control And Relability Guideline sections of [RFC8085]. A = Congestion Control And Relability Guideline = sections of [RFC8085]. A
Map-Notify is = retransmitted until a Map-Notify-Ack is received by the = Map-Notify is retransmitted until a = Map-Notify-Ack is received by the
Map-Server = with the same nonce used in the Map-Notify message. If a = Map-Server with the same nonce used in the = Map-Notify message. If a
Map-Notify-Ack = is never received by the Map-Server, it issues a log Map-Notify-Ack is never received by the Map-Server, = it issues a log
message. An = implementation SHOULD retransmit up to 3 times at 3 message. An implementation SHOULD retransmit up to 3 = times at 3
second = retransmission intervals, after which time the retransmission = second retransmission intervals, after which = time the retransmission
interval is = exponentially backed-off for another 3 retransmission interval is exponentially backed-off for another 3 = retransmission
=
skipping = to change at page 28, line = 38 =C2=B6 = skipping to change at page 31, line = 38 =C2=B6
UDP: The = inner UDP header, where the port assignments depend on the = UDP: The inner UDP header, where the port = assignments depend on the
control = packet being encapsulated. When the control packet is control packet being encapsulated. When the = control packet is
a = Map-Request or Map-Register, the source port is selected by = a Map-Request or Map-Register, the = source port is selected by
the = ITR/PITR and the destination port is 4342. When the the ITR/PITR and the destination port is 4342. = When the
control = packet is a Map-Reply, the source port is 4342 and the control packet is a Map-Reply, the source port = is 4342 and the
= destination port is assigned from the source port of the = destination port is assigned from the = source port of the
invoking = Map-Request. Port number 4341 MUST NOT be assigned to invoking Map-Request. Port number 4341 MUST = NOT be assigned to
either = port. The checksum field MUST be non-zero. either port. The checksum field MUST be = non-zero.
=
LCM: The = format is one of the control message formats described in = LCM: The format is one of the control = message formats described in
this = section. At this time, only Map-Request = messages are this section. = Map-Request messages are allowed to be Control-
= allowed to be Control-Plane (ECM) = encapsulated. In the future, = Plane = (ECM) encapsulated. When Map-Requests are sent for RLOC-
PIM Join/Prune messages [RFC6831] might be = allowed. = Probing purposes (i.e. the = probe-bit is set), they MUST NOT be
Encapsulating other types of LISP control = messages is for sent = inside Encapsulated Control Messages. PIM = Join/Prune
further study. When Map-Requests are = sent for RLOC-Probing messages [RFC6831] are = also allowed to be Control-Plane (ECM)
= purposes (i.e., the probe-bit is set), = they MUST NOT be sent encapsulated.
inside = Encapsulated Control Messages.
=
6. Changing the = Contents of EID-to-RLOC Mappings 6. = Changing the Contents of EID-to-RLOC Mappings
=
In the LISP = architecture ITRs/PITRs use a local Map-Cache to store In the LISP architecture ITRs/PITRs use a local = Map-Cache to store
EID-to-RLOC = mappings for forwarding. When an ETR updates a mapping a = EID-to-RLOC mappings for forwarding. When = an ETR updates a mapping a
mechanism is = required to inform ITRs/PITRs that are using such mechanism is required to inform ITRs/PITRs that are = using such
= mappings. mappings.
=
The LISP = Data-Plane defines several mechanism to update mappings = The LISP Data-Plane defines several = mechanism to update mappings
= [I-D.ietf-lisp-rfc6830bis]. This document specifies the = Solicit-Map = [I-D.ietf-lisp-rfc6830bis]. This document specifies the = Solicit-Map
=
skipping = to change at page 29, line = 25 =C2=B6 = skipping to change at page 32, line = 25 =C2=B6
Control-Plane = mechanism based on the Publish/subscribe paradigm is Control-Plane mechanism based on the = Publish/subscribe paradigm is
specified in = [I-D.ietf-lisp-pubsub]. specified = in [I-D.ietf-lisp-pubsub].
=
6.1. = Solicit-Map-Request (SMR) 6.1. = Solicit-Map-Request (SMR)
=
Soliciting a = Map-Request is a selective way for ETRs, at the site Soliciting a Map-Request is a selective way for ETRs, = at the site
where mappings = change, to control the rate they receive requests for where mappings change, to control the rate they = receive requests for
Map-Reply = messages. SMRs are also used to tell remote ITRs to update = Map-Reply messages. SMRs are also used to = tell remote ITRs to update
the mappings = they have cached. the mappings they = have cached.
=
Since the ETRs don't = keep track of remote ITRs that have cached their Since ETRs are not required = to keep track of remote ITRs that have
mappings, = they do not know which ITRs need to have their mappings = cached their mappings, they do not know = which ITRs need to have their
updated. As = a result, an ETR will solicit Map-Requests (called an mappings updated. As a result, an ETR will solicit = Map-Requests
SMR message) = to those sites to which it has been sending encapsulated = (called an SMR message) to those sites to = which it has been sending
data for the = last minute. In particular, an ETR will send an SMR to = LISP = encapsulated data packets for the last = minute. In particular,
an ITR to = which it has recently sent encapsulated data. This can = an ETR will send an SMR to an ITR to which = it has recently sent
only occur = when both ITR and ETR functionality reside in the same encapsulated data. This can only occur when both = ITR and ETR
= router. functionality reside in = the same router.
=
An SMR message = is simply a bit set in a Map-Request message. An ITR An SMR message is simply a bit set in a Map-Request = message. An ITR
or PITR will = send a Map-Request when they receive an SMR message. or PITR will send a Map-Request when they receive an = SMR message.
Both the SMR = sender and the Map-Request responder MUST rate-limit Both the SMR sender and the Map-Request responder = MUST rate-limit
these = messages. Rate-limiting can be implemented as a global rate- = these messages. Rate-limiting can be = implemented as a global rate-
limiter or one = rate-limiter per SMR destination. = limiter or one rate-limiter per SMR destination.
=
The following = procedure shows how an SMR exchange occurs when a site The following procedure shows how an SMR exchange = occurs when a site
is doing = Locator-Set compaction for an EID-to-RLOC mapping: is doing Locator-Set compaction for an EID-to-RLOC = mapping:
=
1. When the = database mappings in an ETR change, the ETRs at the site = 1. When the database mappings in an ETR = change, the ETRs at the site
begin to = send Map-Requests with the SMR bit set for each Locator = begin to send Map-Requests with the SMR = bit set for each Locator
in each = Map-Cache entry the ETR caches. = in each Map-Cache entry the ETR (when it is an = xTR co-located as
= an ITR) = caches.
=
2. A remote = ITR that receives the SMR message will schedule sending = 2. A remote ITR that receives the SMR = message will schedule sending
a = Map-Request message to the source locator address of the SMR = a Map-Request message to the source = locator address of the SMR
message or = to the mapping database system. A newly allocated message or to the mapping database system. A = newly allocated
random = nonce is selected, and the EID-Prefix used is the one random nonce is selected, and the EID-Prefix used = is the one
copied = from the SMR message. If the source Locator is the only = copied from the SMR message. If the = source Locator is the only
Locator in = the cached Locator-Set, the remote ITR SHOULD send a Locator in the cached Locator-Set, the remote ITR = SHOULD send a
= Map-Request to the database mapping system just in case the = Map-Request to the database mapping = system just in case the
single = Locator has changed and may no longer be reachable to single Locator has changed and may no longer be = reachable to
accept the = Map-Request. accept the = Map-Request.
=
3. The remote = ITR MUST rate-limit the Map-Request until it gets a 3. The remote ITR MUST rate-limit the Map-Request = until it gets a
Map-Reply = while continuing to use the cached mapping. When Map-Reply while continuing to use the cached = mapping. When
= Map-Versioning as described in [I-D.ietf-lisp-6834bis] is used, = Map-Versioning as described in = [I-D.ietf-lisp-6834bis] is used,
an SMR = sender can detect if an ITR is using the most up-to-date = an SMR sender can detect if an ITR is = using the most up-to-date
database = mapping. database = mapping.
=
4. The = ETRs at the site with= the changed mapping will reply to the 4. The site sending SMR = messages will reply to the Map-Request with
= Map-Request with a Map-Reply message that has a nonce from the = a Map-Reply message that has a nonce = from the SMR-invoked Map-
= SMR-invoked Map-Request. The Map-Reply = messages MUST be rate- Request. The = Map-Reply messages MUST be rate-limited = according
limited according to procedures in = [RFC8085]. This is important = to procedures in [RFC8085]. This is important to avoid = Map-Reply
to avoid = Map-Reply implosion. = implosion.
=
5. The ETRs = at the site with the changed mapping record the fact 5. The ETRs at the site with the changed mapping = record the fact
that the = site that sent the Map-Request has received the new that the site that sent the Map-Request has = received the new
mapping = data in the Map-Cache entry for the remote site so the mapping data in the Map-Cache entry for the = remote site so the
= Locator-Status-Bits are reflective of the new mapping for = packets Locator-Status-Bits are = reflective of the new mapping for packets
going to = the remote site. The ETR then stops sending SMR going to the remote site. The ETR then stops = sending SMR
= messages. messages.
=
For security = reasons, an ITR MUST NOT process unsolicited Map- For security reasons, an ITR MUST NOT process = unsolicited Map-
Replies. To = avoid Map-Cache entry corruption by a third party, a Replies. To avoid Map-Cache entry corruption by a = third party, a
=
skipping = to change at page 32, line = 39 =C2=B6 = skipping to change at page 35, line = 43 =C2=B6
an RLOC-probe = is NOT encapsulated and NOT sent to a Map-Server or to an RLOC-probe is NOT encapsulated and NOT sent to a = Map-Server or to
the mapping = database system as one would when soliciting mapping the mapping database system as one would when = soliciting mapping
data. The EID = record encoded in the Map-Request is the EID-Prefix of data. The EID record encoded in the Map-Request is = the EID-Prefix of
the Map-Cache = entry cached by the ITR or PITR. The ITR MAY include a = the Map-Cache entry cached by the ITR or = PITR. The ITR MAY include a
mapping data = record for its own database mapping information that mapping data record for its own database mapping = information that
contains the = local EID-Prefixes and RLOCs for its site. RLOC-probes = contains the local EID-Prefixes and RLOCs = for its site. RLOC-probes
are sent = periodically using a jittered timer interval. are sent periodically using a jittered timer = interval.
=
When an ETR = receives a Map-Request message with the probe-bit set, it = When an ETR receives a Map-Request message = with the probe-bit set, it
returns a = Map-Reply with the probe-bit set. The source address of = returns a Map-Reply with the probe-bit set. = The source address of
the = Map-Reply is set according to the procedure described in the Map-Reply is set to the IP = address of the outgoing interface the
[I-D.ietf-lisp-rfc6830bis]. The Map-Reply = SHOULD contain mapping Map-Reply destination address routes to. The = Map-Reply SHOULD
data for the = EID-Prefix contained in the Map-Request. This provides = contain mapping data for the EID-Prefix = contained in the Map-Request.
the = opportunity for the ITR or PITR that sent the RLOC-probe to get This provides the opportunity for the ITR or PITR = that sent the RLOC-
mapping = updates if there were changes to the ETR's database mapping = probe to get = mapping updates if there were changes to the ETR's
= entries. database mapping = entries.
=
There are = advantages and disadvantages of RLOC-Probing. The greatest = There are advantages and disadvantages of RLOC-Probing. The main
benefit of = RLOC-Probing is that it can handle many failure scenarios = benefit of RLOC-Probing is that it can = handle many failure scenarios
allowing the = ITR to determine when the path to a specific Locator is = allowing the ITR to determine when the path = to a specific Locator is
reachable or = has become unreachable, thus providing a robust reachable or has become unreachable, thus providing a = robust
mechanism for = switching to using another Locator from the cached mechanism for switching to using another Locator from = the cached
Locator. = RLOC-Probing can also provide rough Round-Trip Time (RTT) = Locator. RLOC-Probing can also provide = rough Round-Trip Time (RTT)
estimates = between a pair of Locators, which can be useful for network = estimates between a pair of Locators, which = can be useful for network
management = purposes as well as for selecting low delay paths. The = management purposes as well as for selecting = low delay paths. The
major = disadvantage of RLOC-Probing is in the number of control = major disadvantage of RLOC-Probing is in the = number of control
messages = required and the amount of bandwidth used to obtain those = messages required and the amount of = bandwidth used to obtain those
benefits, = especially if the requirement for failure detection times = benefits, especially if the requirement for = failure detection times
=
skipping = to change at page 37, line = 45 =C2=B6 = skipping to change at page 40, line = 47 =C2=B6
=
8.4.1. Anycast = Operation 8.4.1. Anycast = Operation
=
A Map-Resolver = can be set up to use "anycast", where the same address A Map-Resolver can be set up to use "anycast", where = the same address
is assigned to = multiple Map-Resolvers and is propagated through IGP is assigned to multiple Map-Resolvers and is = propagated through IGP
routing, to = facilitate the use of a topologically close Map-Resolver = routing, to facilitate the use of a = topologically close Map-Resolver
by each = ITR. by each ITR.
=
ETRs MAY have = anycast RLOC addresses which are registered as part of ETRs MAY have anycast RLOC addresses which are = registered as part of
their RLOC-set = to the mapping system. However, registrations MUST their RLOC-set to the mapping system. However, = registrations MUST
use their = unique RLOC addresses, xTR-IDs, or = distinct authentication use their = unique RLOC addresses or distinct = authentication keys to
keys to = identify security associations with the Map-Servers. identify security associations with the = Map-Servers.
=
9. Security = Considerations 9. Security = Considerations
=
= A complete LISP = threat analysis can be found in [RFC7835]. In what
= follows we highlight = security considerations that apply when LISP is
= deployed in = environments such as those specified in Section 1.1,
= where the following = assumptions hold:
=
= 1. The Mapping = System is secure and trusted, and for the purpose of
= this security = considerations the Mapping System is considered as
= one trusted = element.
=
= 2. The ETRs have a = pre-configured trust relationship with the
= Mapping System, = which includes some form of shared keys, and the
= Mapping System = is aware of which EIDs an ETR can advertise. How
= those keys and = mappings gets established is out of the scope of
= this = document.
=
= 3. LISP-SEC = [I-D.ietf-lisp-sec] MUST be implemented. Network
= operartors = should carefully weight how the LISP-SEC threat model
= applies to their = particular use case or deployment. If they
= decide to ignore = a particular recommendation, they should make
= sure the risk = associated with the corresponding threats is well
= = understood.
= =
The = Map-Request/Map-Reply message exchange can be exploited by an = The Map-Request/Map-Reply message exchange = can be exploited by an
attacker to = mount DoS and/or amplification attacks. Attackers can attacker to mount DoS and/or amplification attacks. = Attackers can
send = Map-Requests at high rates to overload LISP nodes and increase = send Map-Requests at high rates to overload = LISP nodes and increase
the state = maintained by such nodes or consume CPU cycles. Such the state maintained by such nodes or consume CPU = cycles. Such
threats can be = mitigated by systematically applying filters and rate threats can be mitigated by systematically applying = filters and rate
= limiters. limiters.
=
The 2-way LISP = control-plane header nonce exchange can be used to The 2-way LISP control-plane header nonce exchange = can be used to
avoid ITR = spoofing attacks, but active on-path attackers (e.g 'man- = avoid ITR spoofing attacks, but active = on-path attackers (e.g 'man-
= in-the-middle') capable of intercepting the nonce can exploit = the in-the-middle') capable of = intercepting the nonce can exploit the
=
skipping = to change at page 38, line = 29 =C2=B6 = skipping to change at page 42, line = 9 =C2=B6
overclaiming' = attacks on the Map-Request/Map-Reply exchange. In overclaiming' attacks on the Map-Request/Map-Reply = exchange. In
addition and = while beyond the scope of securing an individual Map- addition and while beyond the scope of securing an = individual Map-
Server or = Map-Resolver, it should be noted that LISP-SEC can be Server or Map-Resolver, it should be noted that = LISP-SEC can be
complemented = by additional security mechanisms defined by the Mapping = complemented by additional security = mechanisms defined by the Mapping
System = Infrastructure. For instance, BGP-based LISP-ALT [RFC6836] = System Infrastructure. For instance, = BGP-based LISP-ALT [RFC6836]
can take = advantage of standards work on adding security to BGP while = can take advantage of standards work on = adding security to BGP while
LISP-DDT = [RFC8111] defines its own additional security mechanisms. = LISP-DDT [RFC8111] defines its own = additional security mechanisms.
=
To publish an = authoritative EID-to-RLOC mapping with a Map-Server To publish an authoritative EID-to-RLOC mapping with = a Map-Server
using the = Map-Register message, an ETR includes authentication data = using the Map-Register message, an ETR = includes authentication data
that is a = hash of the entire message using a = pair-wise shared key. that is a = MAC of the entire message using a = pair-wise shared key. An
An = implementation MUST support use of HMAC-SHA-1-96 [RFC2104] and = implementation MUST support use of = HMAC-SHA-1-96 [RFC2104] and SHOULD
SHOULD = support use of HMAC-SHA-256-128 [RFC6234] (SHA-256 truncated = support use of HMAC-SHA-256-128 [RFC6234] = (SHA-256 truncated to 128
to 128 = bits). The Map-Register message is vulnerable to replay = bits). The Map-Register message is = vulnerable to replay attacks by a
attacks by a = man-in-the-middle. Deployments that are = concerned with = man-in-the-middle. A compromised ETR can = overclaim the prefix it
active man-in-the-middle attacks to the Map-Register = message SHOULD owns and = successfully register it on its corresponding Map-Server.
use a transport-level integrity and anti-reply = protection mechanism To = mitigate this and as noted in Section 8.2, a Map-Server SHOULD
such as IPSEC [RFC6071]. In addition, a = compromised ETR can verify that = all EID-Prefixes registered by an ETR match the
overclaim = the prefix it owns and successfully register it on its configuration stored on the Map-Server.
= corresponding Map-Server. To mitigate this and as noted in =
Section 8.2, = a Map-Server SHOULD verify that all EID-Prefixes Deployments concerned about = manipulations of Map-Request and Map-
registered = by an ETR match the configuration stored on the Map- Reply messages, and malicious = ETR EID prefix overclaiming MUST drop
Server. LISP Control Plane messages that do not contain = LISP-SEC material
= (S-bit, EID-AD, = OTK-AD, PKT-AD).
=
= Encrypting control = messages via DTLS [RFC6347] or LISP-crypto
= [RFC8061] SHOULD be = used to support privacy to prevent eavesdroping
= and packet tampering = for messages exchanged between xTRs, xTRs and
= the mapping system, = and nodes that make up the mapping system.
=
A complete = LISP threat analysis has been published in [RFC7835]. A complete LISP threat analysis has been published in = [RFC7835].
Please refer = to it for more detailed security related details. Please refer to it for more detailed security related = details.
=
10. Changes = since RFC 6833 10. Privacy Considerations
=
= As noted by = [RFC6973] privacy is a complex issue that greatly depends
= on the specific = protocol use-case and deployment. As noted in
= section 1.1 of = [I-D.ietf-lisp-rfc6830bis] LISP focuses on use-cases
= where entities = communicate over the public Internet while keeping
= separate addressing = and topology. In what follows we detail the
= privacy threats = introduced by the LISP Control Plane, the analysis is
= based on the = guidelines detailed in [RFC6973].
=
= LISP can use = long-lived identifiers (EIDs) that survive mobility
= events. Such = identifiers bind to the RLOCs of the nodes, which
= represents the = topological location with respect to the specific LISP
= deployments. In = addition, EID-to-RLOC mappings are typically
= considered public = information within the LISP deployment when
= control-plane = messages are not encrypted, and can be eavesdropped
= while Map-Request = messages are sent to the corresponding Map-
= Resolvers or = Map-Register messages to Map-Servers.
=
= In this context, = attackers can correlate the EID with the RLOC and
= track the = corresponding user topological location and/or mobility.
= This can be achieved = by off-path attackers, if they are
= authenticated, by = querying the mapping system. Deployments concerned
= about this threat = can use access control-lists or stronger
= authentication = mechanisms [I-D.ietf-lisp-ecdsa-auth] in the mapping
= system to make sure = that only authorized users can access this
= information (data = minimization). Use of ephemeral EIDs
= = [I-D.ietf-lisp-eid-anonymity] to achieve anonymity is = another
= mechanism to lessen = persistency and identity tracking.
=
= 11. Changes = since RFC 6833
=
For = implementation considerations, the following changes have been = For implementation considerations, the = following changes have been
made to this = document since RFC 6833 was published: = made to this document since RFC 6833 was published:
=
o A = Map-Notify-Ack message is added in this document to provide = o A Map-Notify-Ack message is added in this = document to provide
reliability = for Map-Notify messages. Any receiver of a Map-Notify reliability for Map-Notify messages. Any receiver = of a Map-Notify
message = must respond with a Map-Notify-Ack message. Map-Servers = message must respond with a = Map-Notify-Ack message. Map-Servers
who are = senders of Map-Notify messages, must queue the Map-Notify = who are senders of Map-Notify messages, = must queue the Map-Notify
contents = until they receive a Map-Notify-Ack with the nonce used = contents until they receive a = Map-Notify-Ack with the nonce used
in the = Map-Notify message. Note that implementations for Map- = in the Map-Notify message. Note that = implementations for Map-
=
skipping = to change at page 39, line = 33 =C2=B6 = skipping to change at page 44, line = 5 =C2=B6
=
o The 16-bit = Key-ID field of the Map-Register message has been split = o The 16-bit Key-ID field of the = Map-Register message has been split
into a = 8-bit Key-ID field and a 8-bit Algorithm-ID field. into a 8-bit Key-ID field and a 8-bit Algorithm-ID = field.
=
o This = document adds two new Action values that are in an EID-record = o This document adds two new Action values = that are in an EID-record
that appear = in Map-Reply, Map-Register, Map-Notify, and Map- that appear in Map-Reply, Map-Register, = Map-Notify, and Map-
Notify-Ack = messages. The Drop/Policy-Denied and Drop/Auth-Failure = Notify-Ack messages. The = Drop/Policy-Denied and Drop/Auth-Failure
are the = descriptions for the two new action values. See are the descriptions for the two new action = values. See
Section 5.4 = for details. Section 5.4 for = details.
=
11. IANA Considerations 12. IANA = Considerations
=
This section = provides guidance to the Internet Assigned Numbers This section provides guidance to the Internet = Assigned Numbers
Authority = (IANA) regarding registration of values related to this = Authority (IANA) regarding registration of = values related to this
LISP = Control-Plane specification, in accordance with BCP 26 LISP Control-Plane specification, in accordance with = BCP 26
= [RFC8126]. [RFC8126].
=
There are = three namespaces (listed in the sub-sections below) in LISP = There are three namespaces (listed in the = sub-sections below) in LISP
that have been = registered. that have been = registered.
=
o LISP IANA = registry allocations should not be made for purposes o LISP IANA registry allocations should not be made = for purposes
unrelated = to LISP routing or transport protocols. = unrelated to LISP routing or transport protocols.
=
o The = following policies are used here with the meanings defined in = o The following policies are used here with = the meanings defined in
BCP 26: = "Specification Required", "IETF Review", "Experimental BCP 26: "Specification Required", "IETF Review", = "Experimental
Use", and = "First Come First Served". Use", = and "First Come First Served".
=
11.1. LISP UDP Port Numbers 12.1. LISP UDP Port = Numbers
=
The IANA = registry has allocated UDP port number 4342 for the LISP = The IANA registry has allocated UDP port = number 4342 for the LISP
Control-Plane. = IANA has updated the description for UDP port 4342 as Control-Plane. IANA has updated the description for = UDP port 4342 as
= follows: follows:
=
Keyword = Port Transport Layer Description Keyword Port Transport Layer = Description
------- = ---- --------------- ----------- ------- ---- --------------- = -----------
= lisp-control 4342 udp LISP Control = Packets lisp-control 4342 = udp LISP Control Packets
=
11.2. LISP Packet Type Codes 12.2. LISP Packet Type = Codes
=
It is being = requested that the IANA be authoritative for LISP Packet = It is being requested that the IANA be = authoritative for LISP Packet
Type = definitions and it is requested to replace the [RFC6830] = Type definitions and it is requested to = replace the [RFC6830]
registry = message references with the RFC number assigned to this = registry message references with the RFC = number assigned to this
= document. document.
=
Based on = deployment experience of [RFC6830], the Map-Notify-Ack Based on deployment experience of [RFC6830], the = Map-Notify-Ack
message, = message type 5, was added by this document. This document = message, message type 5, was added by this = document. This document
requests IANA = to add it to the LISP Packet Type Registry. requests IANA to add it to the LISP Packet Type = Registry.
=
Name = Number Defined in = Name Number Defined in
---- = ------ ----------- = ---- ------ -----------
LISP = Map-Notify-Ack 5 RFC6833bis LISP Map-Notify-Ack 5 = RFC6833bis
=
11.3. LISP ACT and Flag Fields 12.3. LISP ACT and Flag = Fields
=
New ACT values = can be allocated through IETF review or IESG approval. New ACT values can be allocated through IETF review = or IESG approval.
Four values = have already been allocated by [RFC6830], IANA is Four values have already been allocated by [RFC6830], = IANA is
requested to = replace the [RFC6830] reference for this registry with requested to replace the [RFC6830] reference for this = registry with
the RFC number = assigned to this document and the [RFC6830]. Action the RFC number assigned to this document and the = [RFC6830]. Action
values = references with the RFC number assigned to this document. = values references with the RFC number = assigned to this document.
This = specification changes the name of ACT type 3 value from "Drop" = This specification changes the name of ACT = type 3 value from "Drop"
to = "Drop/No-Reason" as well as adding two new ACT values, the = "Drop/ to "Drop/No-Reason" as well = as adding two new ACT values, the "Drop/
Policy-Denied" = (type 4) and "Drop/Authentication-Failure" (type 5). Policy-Denied" (type 4) and = "Drop/Authentication-Failure" (type 5).
=
=
skipping = to change at page 41, line = 10 =C2=B6 = skipping to change at page 45, line = 27 =C2=B6
= Auth-Failure entry is dropped because the Auth-Failure entry is dropped because = the
= Map-Request for target EID fails an Map-Request for target EID = fails an
= authentication check by the xTR or authentication check by the xTR = or
= the mapping system. = the mapping system.
=
In addition, = LISP has a number of flag fields and reserved fields, In addition, LISP has a number of flag fields and = reserved fields,
such as the = LISP header flags field [I-D.ietf-lisp-rfc6830bis]. New = such as the LISP header flags field = [I-D.ietf-lisp-rfc6830bis]. New
bits for flags = in these fields can be implemented after IETF review bits for flags in these fields can be implemented = after IETF review
or IESG = approval, but these need not be managed by IANA. or IESG approval, but these need not be managed by = IANA.
=
11.4. LISP Address Type Codes 12.4. LISP Address Type = Codes
=
LISP Canonical = Address Format (LCAF) [RFC8060] is an 8-bit field that LISP Canonical Address Format (LCAF) [RFC8060] is an = 8-bit field that
defines = LISP-specific encodings for AFI value 16387. LCAF encodings = defines LISP-specific encodings for AFI = value 16387. LCAF encodings
are used for = specific use-cases where different address types for are used for specific use-cases where different = address types for
EID-records = and RLOC-records are required. = EID-records and RLOC-records are required.
=
The IANA = registry "LISP Canonical Address Format (LCAF) Types" is = The IANA registry "LISP Canonical Address = Format (LCAF) Types" is
used for = LCAF types, the registry for LCAF types = use the used for LCAF types. The registry for LCAF types use the
Specification = Required policy [RFC8126]. Initial values for the Specification Required policy [RFC8126]. Initial = values for the
registry as = well as further information can be found in [RFC8060]. registry as well as further information can be found = in [RFC8060].
=
Therefore, = there is no longer a need for the "LISP Address Type Therefore, there is no longer a need for the "LISP = Address Type
Codes" = registry requested by [RFC6830]. This document requests to = Codes" registry requested by [RFC6830]. = This document requests to
remove = it. remove it.
=
11.5. LISP Algorithm ID Numbers = 12.5. LISP = Algorithm ID Numbers
=
In [RFC6830], = a request for a "LISP Key ID Numbers" registry was In [RFC6830], a request for a "LISP Key ID Numbers" = registry was
submitted. = This document renames the registry to "LISP Algorithm ID = submitted. This document renames the = registry to "LISP Algorithm ID
Numbers" and = requests the IANA to make the name change. Numbers" and requests the IANA to make the name = change.
=
The following = Algorithm ID values are defined by this specification The following Algorithm ID values are defined by this = specification
as used in any = packet type that references a 'Algorithm ID' field: as used in any packet type that references a = 'Algorithm ID' field:
=
Name = Number Defined in = Name Number Defined in
= ----------------------------------------------- = -----------------------------------------------
None = 0 RFC6833bis = None 0 RFC6833bis
= HMAC-SHA-1-96 1 [RFC2404] HMAC-SHA-1-96 1 = [RFC2404]
= HMAC-SHA-256-128 2 [RFC4868] HMAC-SHA-256-128 2 = [RFC4868]
=
Number values = are in the range of 0 to 255. The allocation of values = Number values are in the range of 0 to 255. = The allocation of values
is on a first = come first served basis. is on a = first come first served basis.
=
12. References 12.6. LISP Bit = Flags
=
12.1. Normative References This document asks IANA to = create a registry for allocation of bits
= in several headers = of the LISP control plane, namely in the Map-
= Request, Map-Reply, = Map-Register, Encapsulated Control Message (ECM)
= messages. Bit = allocations are also requested for EID-records and
= RLOC-records. The = registry created should be named "LISP Control
= Plane Header Bits". = A sub-registry needs to be created per each
= message and record. = The name of each sub-registry is indicated
= below, along with = its format and allocation of bits defined in this
= document. Any = additional bits allocation, requires a specification,
= according with = [RFC5226] policies.
=
= Sub-Registry: = Map-Request Header Bits [Section 5.2]:
=
= 0 = 1 2 3
= 0 1 2 3 4 5 6 7 8 9 = 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= |Type=3D1 = |A|M|P|S|p|s|R|R| Rsvd |L|D| IRC | Record Count |
= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
= = +----------+---------------+------------+---------------------------+
= | Spec | IANA = Name | Bit | Description |
= | Name | = | Position | |
= = +----------+---------------+------------+---------------------------+
= | A | = map-request-A | 4 | Authoritative Bit |
= | M | = map-request-M | 5 | Map Data Present Bit |
= | P | = map-request-P | 6 | RLOC-Probe Request Bit |
= | S | = map-request-S | 7 | Solicit Map-Request (SMR) |
= | | = | | Bit |
= | p | = map-request-p | 8 | Proxy-ITR Bit |
= | s | = map-request-s | 9 | Solicit Map-Request |
= | | = | | Invoked Bit |
= | L | = map-request-L | 17 | Local xTR Bit |
= | D | = map-request-D | 18 | Don't Map-Reply Bit |
= = +----------+---------------+------------+---------------------------+
=
= = LISP Map-Request Header Bits
=
= Sub-Registry: = Map-Reply Header Bits [Section 5.4]:
=
= 0 = 1 2 3
= 0 1 2 3 4 5 6 7 8 = 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= |Type=3D2 |P|E|S| = Reserved | Record Count |
= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
= = +-----------+-------------+--------------+------------------------+=
= | Spec Name | IANA = Name | Bit Position | Description |
= = +-----------+-------------+--------------+------------------------+=
= | P | = map-reply-P | 4 | RLOC-Probe Bit |
= | E | = map-reply-E | 5 | Echo Nonce Capable Bit |
= | S | = map-reply-S | 6 | Security Bit |
= = +-----------+-------------+--------------+------------------------+=
=
= = LISP Map-Reply Header Bits
=
= Sub-Registry: = Map-Register Header Bits [Section 5.6]:
=
= 0 = 1 2 3
= 0 1 2 3 4 5 6 7 8 9 = 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= |Type=3D3 |P|S|I| = Reserved |E|T|a|R|M| Record Count |
= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
= = +-----------+----------------+--------------+----------------------+
= | Spec Name | IANA = Name | Bit Position | Description |
= = +-----------+----------------+--------------+----------------------+
= | P | = map-register-P | 4 | Proxy Map-Reply Bit |
= | S | = map-register-S | 5 | LISP-SEC Capable Bit |
= | I | = map-register-I | 6 | xTR-ID present flag |
= = +-----------+----------------+--------------+----------------------+
=
= = LISP Map-Register Header Bits
=
= Sub-Registry: = Encapsulated Control Message (ECM) Header Bits
= [Section = 5.8]:
=
= 0 = 1 2 3
= 0 1 2 3 4 5 6 7 8 9 = 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= |Type=3D8 |S|D|E|M| = Reserved |
= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= = +-----------+-----------+--------------+----------------------------+
= | Spec Name | IANA = Name | Bit Position | Description |
= = +-----------+-----------+--------------+----------------------------+
= | S | ecm-S = | 4 | Security Bit |
= | D | ecm-D = | 5 | LISP-DDT Bit |
= | E | ecm-E = | 6 | Forward to ETR Bit |
= | M | ecm-M = | 7 | Destined to Map-Server Bit |
= = +-----------+-----------+--------------+----------------------------+
=
= LISP = Encapsulated Control Message (ECM) Header Bits
=
= Sub-Registry: = EID-Record Header Bits [Section 5.4]:
=
= 0 = 1 2 3
= 0 1 2 3 4 5 6 7 = 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= | Locator Count | = EID mask-len | ACT |A| Reserved |
= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
= = +-----------+--------------+--------------+-------------------+
= | Spec Name | = IANA Name | Bit Position | Description |
= = +-----------+--------------+--------------+-------------------+
= | A | = eid-record-A | 19 | Authoritative Bit |
= = +-----------+--------------+--------------+-------------------+
=
= = LISP EID-Record Header Bits
=
= Sub-Registry: = RLOC-Record Header Bits [Section 5.4]:
=
= 0 = 1 2 3
= 0 1 2 3 4 5 6 7 8 = 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= | Unused = Flags |L|p|R| Loc-AFI |
= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
= = +-----------+---------------+--------------+----------------------+=
= | Spec Name | IANA = Name | Bit Position | Description |
= = +-----------+---------------+--------------+----------------------+=
= | L | = rloc-record-L | 13 | Local RLOC Bit |
= | p | = rloc-record-p | 19 | RLOC-Probe Reply Bit |
= | R | = rloc-record-R | 19 | RLOC Reachable Bit |
= = +-----------+---------------+--------------+----------------------+=
=
= = LISP RLOC-Record Header Bits
=
= 13. = References
=
= 13.1. Normative = References
=
= [I-D.ietf-lisp-6834bis] = [I-D.ietf-lisp-6834bis]
= Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID = Iannone, L., Saucez, D., and O. = Bonaventure, "Locator/ID
= Separation Protocol (LISP) Map-Versioning", draft-ietf- = Separation Protocol (LISP) = Map-Versioning", draft-ietf-
= lisp-6834bis-02 (work in progress), September 2018. lisp-6834bis-02 (work in progress), = September 2018.
=
= [I-D.ietf-lisp-rfc6830bis] = [I-D.ietf-lisp-rfc6830bis]
= Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. = Farinacci, D., Fuller, V., Meyer, = D., Lewis, D., and A.
= Cabellos-Aparicio, "The Locator/ID Separation Protocol Cabellos-Aparicio, "The Locator/ID = Separation Protocol
= (LISP)", draft-ietf-lisp-rfc6830bis-19 = (work in progress), = (LISP)", draft-ietf-lisp-rfc6830bis-26 = (work in progress),
= September 2018. November = 2018.
=
= = [I-D.ietf-lisp-sec]
= Maino, = F., Ermagan, V., Cabellos-Aparicio, A., and D.
= Saucez, = "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-17
= (work in = progress), November 2018.
=
[RFC2404] = Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within = [RFC2404] Madson, C. and R. Glenn, "The Use = of HMAC-SHA-1-96 within
ESP = and AH", RFC 2404, DOI 10.17487/RFC2404, November ESP and AH", RFC 2404, DOI = 10.17487/RFC2404, November
= 1998, <https://www.rfc-editor.org/info/rfc2404>. 1998, = <https://www.rfc-editor.org/info/rfc2404>.
=
[RFC4086] = Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. = Crocker,
= "Randomness Requirements for Security", BCP 106, RFC 4086, = "Randomness Requirements for = Security", BCP 106, RFC 4086,
DOI = 10.17487/RFC4086, June 2005, = DOI 10.17487/RFC4086, June 2005,
= <https://www.rfc-editor.org/info/rfc4086>. = <https://www.rfc-editor.org/info/rfc4086>.
=
[RFC4868] = Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- = [RFC4868] Kelly, S. and S. Frankel, "Using = HMAC-SHA-256, HMAC-SHA-
= 384, and HMAC-SHA-512 with IPsec", RFC 4868, 384, and HMAC-SHA-512 with IPsec", RFC = 4868,
DOI = 10.17487/RFC4868, May 2007, = DOI 10.17487/RFC4868, May 2007,
= <https://www.rfc-editor.org/info/rfc4868>. = <https://www.rfc-editor.org/info/rfc4868>.
=
= [RFC4984] Meyer, = D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report
= from the = IAB Workshop on Routing and Addressing",
= RFC 4984, = DOI 10.17487/RFC4984, September 2007,
= = <https://www.rfc-editor.org/info/rfc4984>.
=
= [RFC5226] Narten, = T. and H. Alvestrand, "Guidelines for Writing an
= IANA = Considerations Section in RFCs", RFC 5226,
= DOI = 10.17487/RFC5226, May 2008,
= = <https://www.rfc-editor.org/info/rfc5226>.
= =
[RFC6071] = Frankel, S. and S. Krishnan, "IP Security (IPsec) and [RFC6071] Frankel, S. and S. Krishnan, "IP Security = (IPsec) and
= Internet Key Exchange (IKE) Document Roadmap", RFC 6071, = Internet Key Exchange (IKE) = Document Roadmap", RFC 6071,
DOI = 10.17487/RFC6071, February 2011, = DOI 10.17487/RFC6071, February 2011,
= <https://www.rfc-editor.org/info/rfc6071>. = <https://www.rfc-editor.org/info/rfc6071>.
=
= [RFC6347] Rescorla, = E. and N. Modadugu, "Datagram Transport Layer
= Security = Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
= January = 2012, <https://www.rfc-editor.org/info/rfc6347>.
= =
[RFC8085] = Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage [RFC8085] Eggert, L., Fairhurst, G., and G. = Shepherd, "UDP Usage
= Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, Guidelines", BCP 145, RFC 8085, DOI = 10.17487/RFC8085,
= March 2017, <https://www.rfc-editor.org/info/rfc8085>. = March 2017, = <https://www.rfc-editor.org/info/rfc8085>.
=
12.2. Informative References 13.2. Informative = References
=
[AFI] = IANA, "Address Family Identifier (AFIs)", ADDRESS FAMILY = [AFI] IANA, "Address Family Identifier = (AFIs)", ADDRESS FAMILY
= NUMBERS http://www.iana.org/assignments/address-family- = NUMBERS = http://www.iana.org/assignments/address-family-
= numbers/address-family-numbers.xhtml?, Febuary 2007. numbers/address-family-numbers.xhtml?, = Febuary 2007.
=
= [GTP-3GPP] [GTP-3GPP]
= 3GPP, "General Packet Radio System (GPRS) Tunnelling 3GPP, "General Packet Radio System (GPRS) = Tunnelling
= Protocol User Plane (GTPv1-U)", TS.29.281 Protocol User Plane (GTPv1-U)", = TS.29.281
= https://portal.3gpp.org/desktopmodules/Specifications/ = https://portal.3gpp.org/desktopmodules/Specifications/
= SpecificationDetails.aspx?specificationId=3D1699, January = = SpecificationDetails.aspx?specificationId=3D1699, January
= 2015. 2015.
=
[I-D.ermagan-lisp-nat-traversal] =
Ermagan, V., Farinacci, D., Lewis, D., = Skriver, J., Maino,
F., and C. White, "NAT traversal for = LISP", draft-ermagan-
lisp-nat-traversal-14 (work in progress), = April 2018.
= =
= [I-D.herbert-intarea-ila] = [I-D.herbert-intarea-ila]
= Herbert, T. and P. Lapukhov, "Identifier-locator Herbert, T. and P. Lapukhov, = "Identifier-locator
= addressing for IPv6", draft-herbert-intarea-ila-01 (work = addressing for IPv6", = draft-herbert-intarea-ila-01 (work
in = progress), March 2018. = in progress), March 2018.
=
= [I-D.ietf-lisp-ecdsa-auth]
= = Farinacci, D. and E. Nordmark, "LISP Control-Plane ECDSA
= = Authentication and Authorization", draft-ietf-lisp-ecdsa-
= auth-00 = (work in progress), September 2018.
=
= = [I-D.ietf-lisp-eid-anonymity]
= = Farinacci, D., Pillay-Esnault, P., and W. Haddad, "LISP
= EID = Anonymity", draft-ietf-lisp-eid-anonymity-04 (work in
= = progress), October 2018.
= =
= [I-D.ietf-lisp-eid-mobility] = [I-D.ietf-lisp-eid-mobility]
= Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, = Portoles-Comeras, M., Ashtaputre, = V., Moreno, V., Maino,
F., = and D. Farinacci, "LISP L2/L3 EID Mobility Using a F., and D. Farinacci, "LISP L2/L3 EID = Mobility Using a
= Unified Control Plane", draft-ietf-lisp-eid-mobility-02 = Unified Control Plane", draft-ietf-lisp-eid-mobility-03
= (work in progress), May 2018. = (work in progress), November 2018.
=
= [I-D.ietf-lisp-gpe] = [I-D.ietf-lisp-gpe]
= Maino, F., Lemon, J., Agarwal, P., Lewis, D., and M. Maino, F., Lemon, J., Agarwal, P., Lewis, = D., and M.
= Smith, "LISP Generic Protocol Extension", draft-ietf-lisp- = Smith, "LISP Generic Protocol = Extension", draft-ietf-lisp-
= gpe-06 (work in progress), September 2018. gpe-06 (work in progress), September = 2018.
=
= [I-D.ietf-lisp-introduction] = [I-D.ietf-lisp-introduction]
= Cabellos-Aparicio, A. and D. Saucez, "An Architectural Cabellos-Aparicio, A. and D. Saucez, "An = Architectural
= Introduction to the Locator/ID Separation Protocol Introduction to the Locator/ID Separation = Protocol
= (LISP)", draft-ietf-lisp-introduction-13 (work in (LISP)", draft-ietf-lisp-introduction-13 = (work in
= progress), April 2015. = progress), April 2015.
=
= [I-D.ietf-lisp-mn] = [I-D.ietf-lisp-mn]
= Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP = Farinacci, D., Lewis, D., Meyer, = D., and C. White, "LISP
= Mobile Node", draft-ietf-lisp-mn-02 (work = in progress), Mobile = Node", draft-ietf-lisp-mn-04 (work in = progress),
= April 2018. October = 2018.
=
= [I-D.ietf-lisp-pubsub] = [I-D.ietf-lisp-pubsub]
= Rodriguez-Natal, A., Ermagan, V., Leong, J., Maino, F., = Rodriguez-Natal, A., Ermagan, V., = Leong, J., Maino, F.,
= Cabellos-Aparicio, A., Barkai, S., Farinacci, D., Cabellos-Aparicio, A., Barkai, S., = Farinacci, D.,
= Boucadair, M., Jacquenet, C., and S. Secci, "Publish/ Boucadair, M., Jacquenet, C., and S. = Secci, "Publish/
= Subscribe Functionality for LISP", draft-ietf-lisp- Subscribe Functionality for LISP", = draft-ietf-lisp-
= pubsub-00 (work in progress), April 2018. = pubsub-02 (work in progress), = November 2018.
[I-D.ietf-lisp-sec]
Maino, F., Ermagan, V., = Cabellos-Aparicio, A., and D.
Saucez, "LISP-Security (LISP-SEC)", = draft-ietf-lisp-sec-15
(work in progress), April = 2018.
=
= [I-D.ietf-nvo3-vxlan-gpe] = [I-D.ietf-nvo3-vxlan-gpe]
= Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol = Maino, F., Kreeger, L., and U. = Elzur, "Generic Protocol
= Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-06 (work = Extension for VXLAN", = draft-ietf-nvo3-vxlan-gpe-06 (work
in = progress), April 2018. = in progress), April 2018.
=
= [I-D.ietf-opsec-icmp-filtering] = [I-D.ietf-opsec-icmp-filtering]
= Gont, F., Gont, G., and C. Pignataro, "Recommendations for = Gont, F., Gont, G., and C. = Pignataro, "Recommendations for
= filtering ICMP messages", draft-ietf-opsec-icmp- filtering ICMP messages", = draft-ietf-opsec-icmp-
= filtering-04 (work in progress), July 2013. filtering-04 (work in progress), July = 2013.
=
= [I-D.meyer-loc-id-implications] = [I-D.meyer-loc-id-implications]
= Meyer, D. and D. Lewis, "Architectural Implications of Meyer, D. and D. Lewis, "Architectural = Implications of
= Locator/ID Separation", draft-meyer-loc-id-implications-01 = Locator/ID Separation", = draft-meyer-loc-id-implications-01
= (work in progress), January 2009. = (work in progress), January 2009.
=
[I-D.rodrigueznatal-lisp-oam]
Rodriguez-Natal, A., Cabellos-Aparicio, = A., Portoles-
Comeras, M., Kowal, M., Lewis, D., and F. = Maino, "LISP-OAM
(Operations, Administration and = Management): Use cases and
requirements", = draft-rodrigueznatal-lisp-oam-08 (work in
progress), June 2018. =
= =
[RFC1035] = Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - = implementation and
= specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, = specification", STD 13, RFC 1035, = DOI 10.17487/RFC1035,
= November 1987, <https://www.rfc-editor.org/info/rfc1035>. = November 1987, = <https://www.rfc-editor.org/info/rfc1035>.
=
[RFC1071] = Braden, R., Borman, D., and C. Partridge, "Computing the = [RFC1071] Braden, R., Borman, D., and C. = Partridge, "Computing the
= Internet checksum", RFC 1071, DOI 10.17487/RFC1071, Internet checksum", RFC 1071, DOI = 10.17487/RFC1071,
= September 1988, = <https://www.rfc-editor.org/info/rfc1071>. September 1988, = <https://www.rfc-editor.org/info/rfc1071>.
=
[RFC2104] = Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- = [RFC2104] Krawczyk, H., Bellare, M., and R. = Canetti, "HMAC: Keyed-
= Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC = 2104,
=
skipping = to change at page 45, line = 21 =C2=B6 = skipping to change at page 52, line = 45 =C2=B6
[RFC6836] = Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and = D. Lewis,
= "Locator/ID Separation Protocol Alternative Logical "Locator/ID Separation Protocol = Alternative Logical
= Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, Topology (LISP+ALT)", RFC 6836, DOI = 10.17487/RFC6836,
= January 2013, <https://www.rfc-editor.org/info/rfc6836>. = January 2013, = <https://www.rfc-editor.org/info/rfc6836>.
=
[RFC6837] = Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to [RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint = ID (EID) to
= Routing Locator (RLOC) Database", RFC 6837, Routing Locator (RLOC) Database", RFC = 6837,
DOI = 10.17487/RFC6837, January 2013, = DOI 10.17487/RFC6837, January 2013,
= <https://www.rfc-editor.org/info/rfc6837>. = <https://www.rfc-editor.org/info/rfc6837>.
=
[RFC7215] Jakab, L., Cabellos-Aparicio, A., = Coras, F., Domingo- [RFC6973] Cooper, A., = Tschofenig, H., Aboba, B., Peterson, = J.,
Pascual, J., and D. Lewis, "Locator/Identifier = Separation Morris, J., Hansen, M., and R. Smith, "Privacy
Protocol (LISP) Network Element = Deployment Considerations for Internet = Protocols", RFC 6973,
Considerations", RFC 7215, DOI 10.17487/RFC7215,= April DOI 10.17487/RFC6973, July 2013,
2014, = <https://www.rfc-editor.org/info/rfc7215>. = = <https://www.rfc-editor.org/info/rfc6973>.
=
[RFC7348] = Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, = [RFC7348] Mahalingam, M., Dutt, D., Duda, = K., Agarwal, P., Kreeger,
L., = Sridhar, T., Bursell, M., and C. Wright, "Virtual L., Sridhar, T., Bursell, M., and C. = Wright, "Virtual
= eXtensible Local Area Network (VXLAN): A Framework for eXtensible Local Area Network (VXLAN): A = Framework for
= Overlaying Virtualized Layer 2 Networks over Layer 3 Overlaying Virtualized Layer 2 Networks = over Layer 3
= Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, = Networks", RFC 7348, DOI = 10.17487/RFC7348, August 2014,
= <https://www.rfc-editor.org/info/rfc7348>. = <https://www.rfc-editor.org/info/rfc7348>.
=
[RFC7835] = Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID = [RFC7835] Saucez, D., Iannone, L., and O. = Bonaventure, "Locator/ID
= Separation Protocol (LISP) Threat Analysis", RFC 7835, Separation Protocol (LISP) Threat = Analysis", RFC 7835,
DOI = 10.17487/RFC7835, April 2016, = DOI 10.17487/RFC7835, April 2016,
= <https://www.rfc-editor.org/info/rfc7835>. = <https://www.rfc-editor.org/info/rfc7835>.
=
[RFC8060] = Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical = [RFC8060] Farinacci, D., Meyer, D., and J. = Snijders, "LISP Canonical
= Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, = Address Format (LCAF)", RFC 8060, = DOI 10.17487/RFC8060,
= February 2017, <https://www.rfc-editor.org/info/rfc8060>. = February 2017, = <https://www.rfc-editor.org/info/rfc8060>.
=
= [RFC8061] = Farinacci, D. and B. Weis, "Locator/ID Separation = Protocol
= (LISP) = Data-Plane Confidentiality", RFC 8061,
= DOI = 10.17487/RFC8061, February 2017,
= = <https://www.rfc-editor.org/info/rfc8061>.
= =
[RFC8111] = Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. [RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, = A., and A.
= Smirnov, "Locator/ID Separation Protocol Delegated Smirnov, "Locator/ID Separation Protocol = Delegated
= Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, = Database Tree (LISP-DDT)", RFC = 8111, DOI 10.17487/RFC8111,
May = 2017, <https://www.rfc-editor.org/info/rfc8111>. May 2017, = <https://www.rfc-editor.org/info/rfc8111>.
=
[RFC8113] = Boucadair, M. and C. Jacquenet, "Locator/ID Separation [RFC8113] Boucadair, M. and C. Jacquenet, = "Locator/ID Separation
= Protocol (LISP): Shared Extension Message & IANA Registry = Protocol (LISP): Shared Extension = Message & IANA Registry
for = Packet Type Allocations", RFC 8113, = for Packet Type Allocations", RFC 8113,
DOI = 10.17487/RFC8113, March 2017, = DOI 10.17487/RFC8113, March 2017,
= <https://www.rfc-editor.org/info/rfc8113>. = <https://www.rfc-editor.org/info/rfc8113>.
=
skipping = to change at page 47, line = 7 =C2=B6 = skipping to change at page 55, line = 7 =C2=B6
DOI = 10.17487/RFC8378, May 2018, = DOI 10.17487/RFC8378, May 2018,
= <https://www.rfc-editor.org/info/rfc8378>. = <https://www.rfc-editor.org/info/rfc8378>.
=
[RFC8402] = Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., = Ginsberg, L.,
= Decraene, B., Litkowski, S., and R. Shakir, "Segment Decraene, B., Litkowski, S., and R. = Shakir, "Segment
= Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, Routing Architecture", RFC 8402, DOI = 10.17487/RFC8402,
= July 2018, <https://www.rfc-editor.org/info/rfc8402>. = July 2018, = <https://www.rfc-editor.org/info/rfc8402>.
=
Appendix A. = Acknowledgments Appendix A. = Acknowledgments
=
The authors = would like to thank Greg Schudel, Darrel Lewis, John The original authors = would like to thank Greg Schudel, Darrel Lewis,
Zwiebel, = Andrew Partan, Dave Meyer, Isidor Kouvelas, Jesper Skriver, = John Zwiebel, Andrew Partan, Dave Meyer, = Isidor Kouvelas, Jesper
Fabio Maino, = and members of the lisp@ietf.org mailing list for their = Skriver, Fabio Maino, and members of the = lisp@ietf.org mailing list
feedback and = helpful suggestions. for their = feedback and helpful suggestions.
=
Special thanks = are due to Noel Chiappa for his extensive work and Special thanks are due to Noel Chiappa for his = extensive work and
thought about = caching in Map-Resolvers. thought = about caching in Map-Resolvers.
=
= The current authors = would like to give a sincere thank you to the
= people who help put = LISP on standards track in the IETF. They
= include Joel = Halpern, Luigi Iannone, Deborah Brungard, Fabio Maino,
= Scott Bradner, Kyle = Rose, Takeshi Takahashi, Sarah Banks, Pete
= Resnick, Colin = Perkins, Mirja Kuhlewind, Francis Dupont, Benjamin
= Kaduk, Eric = Rescorla, Alvaro Retana, Alexey Melnikov, Alissa Cooper,
= Suresh Krishnan, = Alberto Rodriguez-Natal, Vina Ermagen, Mohamed
= Boucadair, Brian = Trammell, Sabrina Tanamal, and John Drake. The
= contributions they = offered greatly added to the security, scale, and
= robustness of the = LISP architecture and protocols.
= =
Appendix B. = Document Change Log Appendix B. = Document Change Log
=
[RFC Editor: = Please delete this section on publication as RFC.] [RFC Editor: Please delete this section on = publication as RFC.]
=
B.1. Changes = to draft-ietf-lisp-rfc6833bis-16 B.1. = Changes to draft-ietf-lisp-rfc6833bis-23
=
= o Posted December = 2018.
=
= o Added to Security = Considerations section that deployments that
= care about prefix = over claiming should use LISP-SEC.
=
= o Added to Security = Considerations section that DTLS or LISP-crypto
= be used for = control-plane privacy.
=
= o Make LISP-SEC a = normative reference.
=
= o Make it more = clear where field descriptions are spec'ed when
= referencing to = the same fields in other packet types.
=
= B.2. Changes to = draft-ietf-lisp-rfc6833bis-22
=
= o Posted week after = IETF November 2018.
=
= o No longer need to = use IPSEC for replay attacks.
=
= B.3. Changes to = draft-ietf-lisp-rfc6833bis-21
=
= o Posted early = November 2018.
=
= o Added I-bit back = in because its necessary to use for Map-Register
= replay attack = scenarios. The Map-Server tracks the nonce per xTR-
= ID to detect = duplicate or replayed Map-Register messages.
=
= B.4. Changes to = draft-ietf-lisp-rfc6833bis-20
=
= o Posted late = October 2018.
=
= o Changed = description about "reserved" bits to state "reserved and
= = unassigned".
=
= o Make it more = clear how Map-Register nonce processing is performed
= in an ETR and = Map-Server.
=
= B.5. Changes to = draft-ietf-lisp-rfc6833bis-19
=
= o Posted mid = October 2018.
=
= o Added Fabio text = to the Security Considerations section.
=
= B.6. Changes to = draft-ietf-lisp-rfc6833bis-18
=
= o Posted mid = October 2018.
=
= o Fixed comments = from Eric after more email clarity.
=
= B.7. Changes to = draft-ietf-lisp-rfc6833bis-17
=
= o Posted early = October 2018.
=
= o Changes to = reflect comments from Sep 27th Telechat.
=
= o Added all flag = bit definitions as request for allocation in IANA
= Considersations = section.
=
= o Added an = applicability statement in section 1 to address security
= concerns from = Telechat.
=
= o Moved m-bit = description and IANA request to draft-ietf-lisp-mn.
=
= o Moved I-bit = description and IANA request to draft-ietf-lisp-
= = pubsub.
=
= B.8. Changes to = draft-ietf-lisp-rfc6833bis-16
=
o Posted = Late-September 2018. o Posted = Late-September 2018.
=
o Re-wrote = Security Considerations section. Thanks Albert. o Re-wrote Security Considerations section. Thanks = Albert.
=
o Added = Alvaro text to be more clear about IANA actions. o Added Alvaro text to be more clear about IANA = actions.
=
B.2. Changes to = draft-ietf-lisp-rfc6833bis-15 B.9. Changes to = draft-ietf-lisp-rfc6833bis-15
=
o Posted = mid-September 2018. o Posted = mid-September 2018.
=
o Changes to = reflect comments from Colin and Mirja. = o Changes to reflect comments from Colin and Mirja.
=
B.3. Changes to = draft-ietf-lisp-rfc6833bis-14 B.10. Changes to = draft-ietf-lisp-rfc6833bis-14
=
o Posted = September 2018. o Posted September = 2018.
=
o Changes to = reflect comments from Genart, RTGarea, and Secdir o Changes to reflect comments from Genart, RTGarea, = and Secdir
= reviews. reviews.
=
B.4. Changes to = draft-ietf-lisp-rfc6833bis-13 B.11. Changes to = draft-ietf-lisp-rfc6833bis-13
=
o Posted = August 2018. o Posted August = 2018.
=
o Final = editorial changes before RFC submission for Proposed o Final editorial changes before RFC submission for = Proposed
= Standard. Standard.
=
o Added = section "Changes since RFC 6833" so implementators are o Added section "Changes since RFC 6833" so = implementators are
informed of = any changes since the last RFC publication. informed of any changes since the last RFC = publication.
=
B.5. Changes to = draft-ietf-lisp-rfc6833bis-12 B.12. Changes to = draft-ietf-lisp-rfc6833bis-12
=
o Posted late = July 2018. o Posted late July = 2018.
=
o Moved = RFC6830bis and RFC6834bis to Normative References. o Moved RFC6830bis and RFC6834bis to Normative = References.
=
B.6. Changes to = draft-ietf-lisp-rfc6833bis-11 B.13. Changes to = draft-ietf-lisp-rfc6833bis-11
=
o Posted July = 2018. o Posted July 2018.
=
o Fixed Luigi = editorial comments to ready draft for RFC status and o Fixed Luigi editorial comments to ready draft for = RFC status and
ran through = IDNITs again. ran through IDNITs = again.
=
B.7. Changes to = draft-ietf-lisp-rfc6833bis-10 B.14. Changes to = draft-ietf-lisp-rfc6833bis-10
=
o Posted = after LISP WG at IETF week March. o = Posted after LISP WG at IETF week March.
=
o Move AD = field encoding after S-bit in the ECM packet format o Move AD field encoding after S-bit in the ECM = packet format
description = section. description = section.
=
o Say more = about when the new Drop actions should be sent. o Say more about when the new Drop actions should be = sent.
=
B.8. Changes to = draft-ietf-lisp-rfc6833bis-09 B.15. Changes to = draft-ietf-lisp-rfc6833bis-09
=
o Posted = March IETF week 2018. o Posted = March IETF week 2018.
=
o Fixed = editorial comments submitted by document shepherd Luigi = o Fixed editorial comments submitted by = document shepherd Luigi
= Iannone. Iannone.
=
B.9. Changes to = draft-ietf-lisp-rfc6833bis-08 B.16. Changes to = draft-ietf-lisp-rfc6833bis-08
=
o Posted = March 2018. o Posted March = 2018.
=
o Added = RLOC-probing algorithm. o Added = RLOC-probing algorithm.
=
o Added = Solicit-Map Request algorithm. o = Added Solicit-Map Request algorithm.
=
o Added = several mechanisms (from 6830bis) regarding Routing Locator = o Added several mechanisms (from 6830bis) = regarding Routing Locator
= Reachability. = Reachability.
=
o Added port = 4342 to IANA Considerations section. = o Added port 4342 to IANA Considerations section.
=
B.10. Changes to = draft-ietf-lisp-rfc6833bis-07 B.17. Changes to = draft-ietf-lisp-rfc6833bis-07
=
o Posted = December 2017. o Posted December = 2017.
=
o Make it = more clear in a couple of places that RLOCs are used to = o Make it more clear in a couple of places = that RLOCs are used to
locate ETRs = more so than for Map-Server Map-Request forwarding. locate ETRs more so than for Map-Server = Map-Request forwarding.
=
o Make it = clear that "encapsualted" for a control message is an ECM = o Make it clear that "encapsualted" for a = control message is an ECM
based = message. based message.
=
o Make it = more clear what messages use source-port 4342 and which = o Make it more clear what messages use = source-port 4342 and which
=
skipping = to change at page 49, line = 25 =C2=B6 = skipping to change at page 59, line = 13 =C2=B6
Can use = othe AFIs then IPv4 and IPv6. = Can use othe AFIs then IPv4 and IPv6.
=
o Many = editorial changes to clarify text. = o Many editorial changes to clarify text.
=
o Changed = some "must", "should", and "may" to capitalized. o Changed some "must", "should", and "may" to = capitalized.
=
o Added = definitions for Map-Request and Map-Reply messages. o Added definitions for Map-Request and Map-Reply = messages.
=
o Ran = document through IDNITs. o Ran = document through IDNITs.
=
B.11. Changes to = draft-ietf-lisp-rfc6833bis-06 B.18. Changes to = draft-ietf-lisp-rfc6833bis-06
=
o Posted = October 2017. o Posted October = 2017.
=
o Spec the = I-bit to include the xTR-ID in a Map-Request message to = o Spec the I-bit to include the xTR-ID in a = Map-Request message to
be = consistent with the Map-Register message and to anticipate the = be consistent with the Map-Register = message and to anticipate the
= introduction of pubsub functionality to allow Map-Requests to = introduction of pubsub functionality to = allow Map-Requests to
subscribe = to RLOC-set changes. subscribe = to RLOC-set changes.
=
o Updated = references for individual submissions that became working = o Updated references for individual = submissions that became working
group = documents. group = documents.
=
o Updated = references for working group documents that became RFCs. = o Updated references for working group = documents that became RFCs.
=
B.12. Changes to = draft-ietf-lisp-rfc6833bis-05 B.19. Changes to = draft-ietf-lisp-rfc6833bis-05
=
o Posted May = 2017. o Posted May 2017.
=
o Update IANA = Considerations section based on new requests from this o Update IANA Considerations section based on new = requests from this
document = and changes from what was requested in [RFC6830]. document and changes from what was requested in = [RFC6830].
=
B.13. Changes to = draft-ietf-lisp-rfc6833bis-04 B.20. Changes to = draft-ietf-lisp-rfc6833bis-04
=
o Posted May = 2017. o Posted May 2017.
=
o Clarify how = the Key-ID field is used in Map-Register and Map- o Clarify how the Key-ID field is used in = Map-Register and Map-
Notify = messages. Break the 16-bit field into a 8-bit Key-ID field = Notify messages. Break the 16-bit field = into a 8-bit Key-ID field
and a 8-bit = Algorithm-ID field. and a 8-bit = Algorithm-ID field.
=
o Move the = Control-Plane codepoints from the IANA Considerations o Move the Control-Plane codepoints from the IANA = Considerations
section of = RFC6830bis to the IANA Considerations section of this section of RFC6830bis to the IANA Considerations = section of this
= document. document.
=
o In the = "LISP Control Packet Type Allocations" section, indicate = o In the "LISP Control Packet Type = Allocations" section, indicate
how message = Types are IANA allocated and how experimental RFC8113 how message Types are IANA allocated and how = experimental RFC8113
sub-types = should be requested. sub-types = should be requested.
=
B.14. Changes to = draft-ietf-lisp-rfc6833bis-03 B.21. Changes to = draft-ietf-lisp-rfc6833bis-03
=
o Posted = April 2017. o Posted April = 2017.
=
o Add types = 9-14 and specify they are not assigned. = o Add types 9-14 and specify they are not assigned.
=
o Add the = "LISP Shared Extension Message" type and point to RFC8113. = o Add the "LISP Shared Extension Message" = type and point to RFC8113.
=
B.15. Changes to = draft-ietf-lisp-rfc6833bis-02 B.22. Changes to = draft-ietf-lisp-rfc6833bis-02
=
o Posted = April 2017. o Posted April = 2017.
=
o Clarify = that the LISP Control-Plane document defines how the LISP = o Clarify that the LISP Control-Plane = document defines how the LISP
Data-Plane = uses Map-Requests with either the SMR-bit set or the Data-Plane uses Map-Requests with either the = SMR-bit set or the
P-bit set = supporting mapping updates and RLOC-probing. Indicating = P-bit set supporting mapping updates and = RLOC-probing. Indicating
that other = Data-Planes can use the same mechanisms or their own that other Data-Planes can use the same mechanisms = or their own
defined = mechanisms to achieve the same functionality. defined mechanisms to achieve the same = functionality.
=
B.16. Changes to = draft-ietf-lisp-rfc6833bis-01 B.23. Changes to = draft-ietf-lisp-rfc6833bis-01
=
o Posted = March 2017. o Posted March = 2017.
=
o Include = references to new RFCs published. o = Include references to new RFCs published.
=
o Remove = references to self. o Remove = references to self.
=
o Change = references from RFC6830 to RFC6830bis. = o Change references from RFC6830 to RFC6830bis.
=
o Add two new = action/reasons to a Map-Reply has posted to the LISP o Add two new action/reasons to a Map-Reply has = posted to the LISP
WG mailing = list. WG mailing list.
=
o In intro = section, add refernece to I-D.ietf-lisp-introduction. o In intro section, add refernece to = I-D.ietf-lisp-introduction.
=
o Removed = Open Issues section and references to "experimental". o Removed Open Issues section and references to = "experimental".
=
B.17. Changes to = draft-ietf-lisp-rfc6833bis-00 B.24. Changes to = draft-ietf-lisp-rfc6833bis-00
=
o Posted = December 2016. o Posted December = 2016.
=
o Created = working group document from draft-farinacci-lisp o Created working group document from = draft-farinacci-lisp
-rfc6833-00 = individual submission. No other changes made. -rfc6833-00 individual submission. No other = changes made.
=
B.18. Changes to = draft-farinacci-lisp-rfc6833bis-00 B.25. Changes to = draft-farinacci-lisp-rfc6833bis-00
=
o Posted = November 2016. o Posted November = 2016.
=
o This is the = initial draft to turn RFC 6833 into RFC 6833bis. o This is the initial draft to turn RFC 6833 into = RFC 6833bis.
=
o The = document name has changed from the "Locator/ID Separation = o The document name has changed from the = "Locator/ID Separation
Protocol = (LISP) Map-Server Interface" to the "Locator/ID Protocol (LISP) Map-Server Interface" to the = "Locator/ID
Separation = Protocol (LISP) Control-Plane". = Separation Protocol (LISP) Control-Plane".
=
o The = fundamental change was to move the Control-Plane messages from = o The fundamental change was to move the = Control-Plane messages from
 End of changes. 97 change blocks. 
280 lines changed or = deleted 614 lines changed or = added

This = html diff was produced by rfcdiff 1.47. The latest version is available = from http://tools.ietf.org/to= ols/rfcdiff/
=20 =20 = --Apple-Mail=_0A3B8C53-6760-4889-B9AE-189F7723C2E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Dec 10, 2018, at 12:47 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Locator/ID Separation Protocol WG of = the IETF. >=20 > Title : Locator/ID Separation Protocol (LISP) = Control-Plane > Authors : Vince Fuller > Dino Farinacci > Albert Cabellos > Filename : draft-ietf-lisp-rfc6833bis-23.txt > Pages : 61 > Date : 2018-12-10 >=20 > Abstract: > This document describes the Control-Plane and Mapping Service for = the > Locator/ID Separation Protocol (LISP), implemented by two new types > of LISP-speaking devices -- the LISP Map-Resolver and LISP = Map-Server > -- that provides a simplified "front end" for one or more Endpoint = ID > to Routing Locator mapping databases. >=20 > By using this Control-Plane service interface and communicating with > Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers (ITRs) = and > Egress Tunnel Routers (ETRs) are not dependent on the details of > mapping database systems, which facilitates modularity with = different > database designs. Since these devices implement the "edge" of the > LISP Control-Plane infrastructure, connecting EID addressable nodes > of a LISP site, their implementation and operational complexity > reduces the overall cost and effort of deploying LISP. >=20 > This document obsoletes RFC 6830 and 6833. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-lisp-rfc6833bis-23 > https://datatracker.ietf.org/doc/html/draft-ietf-lisp-rfc6833bis-23 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lisp-rfc6833bis-23 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp --Apple-Mail=_0A3B8C53-6760-4889-B9AE-189F7723C2E4-- From nobody Thu Dec 13 07:44:30 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8AC5126C7E; Thu, 13 Dec 2018 07:44:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.161 X-Spam-Level: X-Spam-Status: No, score=-4.161 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net 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 68Pou8_N2EYn; Thu, 13 Dec 2018 07:44:20 -0800 (PST) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D85F2124408; Thu, 13 Dec 2018 07:44:16 -0800 (PST) Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id wBDFTGFr026494; Thu, 13 Dec 2018 07:44:15 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=IlFzTqO60x2Iop3CpNO82O8Kk8g4UaaYDLChzc5w0W4=; b=gtTK/qwxnKIcONWmqxfHhsIpJk8LSpKt32W7z27gptQf6aJ/QhStGhkp9GOevrljIuC5 UzUx/9zuGMpsFdJe09MO6W0+ihmgDrCaKDO31ay6tY9hMQo0Rtll5KIMwO6kn5nRKOFj GkFq3tYkBf90VyjSrO7GvMB3bDTCyTUb0Xa31WgBS96fV0KET5pnoHWmdqrS1MdjIUxF Ms9gp4HSepjRbVp+oUS1Kqi8xSUgGoRkabn220oHCbaMjRCHp6I/ZE61P1OlS3j900PK Qq6P2nwkBlee53cz1/z2wXDKtYyGPkz9z7rteGdLRWsuuPr9m2HppgxnkaPjA+KtWryv WQ== Received: from nam04-sn1-obe.outbound.protection.outlook.com (mail-sn1nam04lp2050.outbound.protection.outlook.com [104.47.44.50]) by mx0b-00273201.pphosted.com with ESMTP id 2pbrmx07ju-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 13 Dec 2018 07:44:15 -0800 Received: from BYAPR05MB5029.namprd05.prod.outlook.com (20.177.230.211) by BYAPR05MB4870.namprd05.prod.outlook.com (52.135.235.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1446.8; Thu, 13 Dec 2018 15:44:13 +0000 Received: from BYAPR05MB5029.namprd05.prod.outlook.com ([fe80::79a9:fae7:8d61:ff3e]) by BYAPR05MB5029.namprd05.prod.outlook.com ([fe80::79a9:fae7:8d61:ff3e%3]) with mapi id 15.20.1425.016; Thu, 13 Dec 2018 15:44:13 +0000 From: John E Drake To: "rtg-ads@ietf.org" CC: "rtg-dir@ietf.org" , "draft-ietf-lisp-rfc8113bis.all@ietf.org" , "lisp@ietf.org" Thread-Topic: rtgdir Last Call Review requested: draft-ietf-lisp-rfc8113bis-01.txt Thread-Index: AdSS+eqT4Gsyp+qDQB6wnP1fWN+JHw== Date: Thu, 13 Dec 2018 15:44:13 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.1.0.61 dlp-reaction: no-action x-originating-ip: [66.129.241.13] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR05MB4870; 6:hxa5qWS8XoUlbhdq46AvIPAZ0qezAEsMbcgblNcA/YE50AUQakql2Au4CF3vjMnmLo8qAhfoyxsBEoI9PNhReRYWxtGLmeIJ6wRbF8VcOStvrlgVbOWNeod+UkIQiEyPuzMgO5xSJZYxcmYWJesdB4PRzs2kG5KJwx3PoPS7c5TQ66204eY6FYA1mCZ5IFAv/FQzwS9mkxI9jw0BOjd2MjnPE7QThLTJ8Z2rAd+Is9wBGjzTI5nK/MeS4KN69Mg96IOcbMIpKAE2S9dKJg0L6YLFiMHlTgDrlNf36MbZaLkvTVrtcC1syozcWnYovG15J1S14qS1KQJvrb9Ex+nioPIdjTeTEEAptwb38dP4EJQjRvbp0DKlMI1U7oKEVgWi/MC486vY2GasuPIKHSS02A4oBg1QNNJZr6T1VHwOeVXewquz7xhk+B7ZCRIPm6EYDxURAdUJi8PawTnkbhr/eg==; 5:8dZ8e7+xh8TaBFW5pafYlWB8TvKlj1Z2vdsIgstYD5WOstQNtCBeYFIzmDXgTu05He6icz+rNMEiwi8VcgmUzWYS2SzmYpM6SdOxE9/Vyl/2XINdpx9LnMDL/aEuFH13TKvVxyWtmTMXDSoIHDbugHN/nJdAWbYMAVSVo9PvPAQ=; 7:wiyFLkLZ2blEh+E4wu7ON3DEzFz9IKAgAV8YZwW6E91/zNs8/7hHN8+kbeo3KkNli7xLeDFi0ZH92ryGYw0zQrgFh7xwghosSa9sMWuIXAoYHl8yLrhZfVQH4rWmolgNiNcqHFktblocyC9g9oBkmw== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: db0f94ef-c447-4285-183e-08d66111d52b x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:BYAPR05MB4870; x-ms-traffictypediagnostic: BYAPR05MB4870: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(999002)(6040522)(2401047)(5005006)(8121501046)(3231475)(944501520)(52105112)(93006095)(93001095)(3002001)(10201501046)(6055026)(148016)(149066)(150057)(6041310)(20161123560045)(20161123564045)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:BYAPR05MB4870; BCL:0; PCL:0; RULEID:; SRVR:BYAPR05MB4870; x-forefront-prvs: 088552DE73 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39860400002)(136003)(396003)(346002)(376002)(199004)(189003)(3846002)(81166006)(81156014)(450100002)(6116002)(4326008)(186003)(25786009)(6436002)(26005)(5660300001)(6916009)(8676002)(33656002)(7736002)(9686003)(74316002)(305945005)(8936002)(97736004)(53936002)(2501003)(14454004)(55016002)(5640700003)(102836004)(66066001)(486006)(14444005)(256004)(478600001)(105586002)(54906003)(106356001)(7696005)(6506007)(86362001)(2906002)(2351001)(99286004)(68736007)(71190400001)(476003)(71200400001)(316002); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB4870; H:BYAPR05MB5029.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: qUoAfoIDkn0Qhc7bQjh4dGns5sNdr5SSDt7+Z19Rx3q1Vqnz2RgEWruYtJJL3x+gzbRGI3HvNaWXI/TLrta4RSFfmuRMPuu2dHQqu29YnAloAnxMn9H5ALnJRvZMbZ4plnwKfIxlRjph0KmVH7tz2QyDD32GpCFk38OqayUzNX8YvUCqBXrG+aJY0gTHhcj06me9TRntq+1iJ0biOq1b8mgIbY3T3F02ubqxocSVXXZeXigPtkKGxb+jYya93NSYnY+awBLDM/ee5IftB78P4EzR7yOVMl/RcTLGKwMFONdGxGmsCT2eNoSyJpEjeKnq spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: db0f94ef-c447-4285-183e-08d66111d52b X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Dec 2018 15:44:13.7102 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB4870 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-12-13_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1812130134 Archived-At: Subject: [lisp] rtgdir Last Call Review requested: draft-ietf-lisp-rfc8113bis-01.txt X-BeenThere: lisp@ietf.org 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: Thu, 13 Dec 2018 15:44:23 -0000 SGVsbG8sDQoNCkkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRl IHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUgUm91dGluZyBEaXJlY3RvcmF0ZSBzZWVrcyB0 byByZXZpZXcgYWxsIHJvdXRpbmcgb3Igcm91dGluZy1yZWxhdGVkIGRyYWZ0cyBhcyB0aGV5IHBh c3MgdGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVTRyByZXZpZXcsIGFuZCBzb21ldGltZXMg b24gc3BlY2lhbCByZXF1ZXN0LiBUaGUgcHVycG9zZSBvZiB0aGUgcmV2aWV3IGlzIHRvIHByb3Zp ZGUgYXNzaXN0YW5jZSB0byB0aGUgUm91dGluZyBBRHMuIEZvciBtb3JlIGluZm9ybWF0aW9uIGFi b3V0IHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlLCBwbGVhc2Ugc2VlIOKAi2h0dHA6Ly90cmFjLnRv b2xzLmlldGYub3JnL2FyZWEvcnRnL3RyYWMvd2lraS9SdGdEaXINCg0KQWx0aG91Z2ggdGhlc2Ug Y29tbWVudHMgYXJlIHByaW1hcmlseSBmb3IgdGhlIHVzZSBvZiB0aGUgUm91dGluZyBBRHMsIGl0 IHdvdWxkIGJlIGhlbHBmdWwgaWYgeW91IGNvdWxkIGNvbnNpZGVyIHRoZW0gYWxvbmcgd2l0aCBh bnkgb3RoZXIgSUVURiBMYXN0IENhbGwgY29tbWVudHMgdGhhdCB5b3UgcmVjZWl2ZSwgYW5kIHN0 cml2ZSB0byByZXNvbHZlIHRoZW0gdGhyb3VnaCBkaXNjdXNzaW9uIG9yIGJ5IHVwZGF0aW5nIHRo ZSBkcmFmdC4NCg0KRG9jdW1lbnQ6IGRyYWZ0LWlldGYtbGlzcC1yZmM4MTEzYmlzLTAxLnR4dA0K UmV2aWV3ZXI6IEpvaG4gRHJha2UNClJldmlldyBEYXRlOiAxMy1EZWMtMjAxOA0KSUVURiBMQyBF bmQgRGF0ZTogMjEtRGVjLTIwMTgNCkludGVuZGVkIFN0YXR1czogU3RhbmRhcmRzIFRyYWNrDQoN ClN1bW1hcnk6DQoNCiAgICBObyBpc3N1ZXMgZm91bmQuIFRoaXMgZG9jdW1lbnQgaXMgcmVhZHkg Zm9yIHB1YmxpY2F0aW9uLg0KDQpDb21tZW50czoNCg0KICAgIENvbmNpc2UgYW5kIHRvIHRoZSBw b2ludC4NCg0KTWFqb3IgSXNzdWVzOg0KDQogICAgTm8gbWFqb3IgaXNzdWVzIGZvdW5kLg0KDQpN aW5vciBJc3N1ZXM6DQoNCiAgICBObyBtaW5vciBpc3N1ZXMgZm91bmQuIA0KDQpZb3VycyBJcnJl c3BlY3RpdmVseSwNCg0KSm9obg0KDQo= From nobody Thu Dec 13 09:29:59 2018 Return-Path: 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 214C4130E03; Thu, 13 Dec 2018 09:29:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.89.1 Auto-Submitted: auto-generated Precedence: bulk CC: lisp-chairs@ietf.org, lisp@ietf.org, db3546@att.com, Joel Halpern , draft-ietf-lisp-rfc8113bis@ietf.org, jmh@joelhalpern.com Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Message-ID: <154472219707.32137.4370649725518621697.idtracker@ietfa.amsl.com> Date: Thu, 13 Dec 2018 09:29:57 -0800 Archived-At: Subject: [lisp] Last Call: (Locator/ID Separation Protocol (LISP): Shared Extension Message & IANA Registry for Packet Type Allocations) to Proposed Standard X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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: Thu, 13 Dec 2018 17:29:57 -0000 The IESG has received a request from the Locator/ID Separation Protocol WG (lisp) to consider the following document: - 'Locator/ID Separation Protocol (LISP): Shared Extension Message & IANA Registry for Packet Type Allocations' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-12-27. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies a Locator/ID Separation Protocol (LISP) shared message type for defining future extensions and conducting experiments without consuming a LISP packet type codepoint for each extension. This document obsoletes RFC 8113. This document updates I-D.ietf-lisp-rfc6833bis. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc8113bis/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc8113bis/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Tue Dec 18 18:25:15 2018 Return-Path: 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 B34DE130DF5; Tue, 18 Dec 2018 18:25:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Brian Carpenter To: Cc: draft-ietf-lisp-rfc8113bis.all@ietf.org, lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154518630870.5131.10104452678736081639@ietfa.amsl.com> Date: Tue, 18 Dec 2018 18:25:08 -0800 Archived-At: Subject: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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: Wed, 19 Dec 2018 02:25:09 -0000 Reviewer: Brian Carpenter Review result: Ready with Issues Gen-ART Last Call review of draft-ietf-lisp-rfc8113bis-01 I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-lisp-rfc8113bis-01.txt Reviewer: Brian Carpenter Review Date: 2018-12-19 IETF LC End Date: 2018-12-27 IESG Telechat date: Summary: Ready with issues -------- Comments: --------- I note that this is being raised from Experimental to the standards track. Presumably that depends on the base LISP spec becoming PS. Minor issues: ------------- "This document updates I-D.ietf-lisp-rfc6833bis." The text doesn't explain which text is updated. This is in contrast to RFC8113, which explains clearly how it updates RFC6830 (*not* RFC6833). Why doesn't this draft claim to update rfc6830bis? I'm going to assume that is an error. In fact, why wasn't the definition of the LISP Packet Types registry moved into the base spec (rfc6830bis)? That is where it belongs. Since rfc6830bis (and rfc6833bis) are still under IESG review, anything in them that needs updating should be updated! The fact is that rfc8113bis extends rfc6830bis, which is not the same thing as "updates". If the WG thinks that implementers of 6830bis need to read 8113bis, there should be a normative reference in 6830bis to 8113bis. From nobody Tue Dec 18 18:46:27 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B4B9130DEF; Tue, 18 Dec 2018 18:46:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 pBXSAXV1NNT7; Tue, 18 Dec 2018 18:46:18 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E92B130DC8; Tue, 18 Dec 2018 18:46:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 43KK5j5g4lz1JPcr; Tue, 18 Dec 2018 18:46:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1545187577; bh=zzZW8rtlXJiK0+iOJ2U4dqHlNVLLjUDdQfUeDZPv46g=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=XvX9b4MAg5VmTI7sEJniXx5ahdh8TYtoKSvK2aWdN+OKS90poyEjAzG98BZE1JRDC wXbMymqsu9zBioePE1Uf5DrfrX+By7VFwa60xRaVNyDsw3vlyNwU30bQN+wFLCMRhV 4/A/rwMIK59Wi8rcAIVLtNH/6hB1YewEIfBEBG/8= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 43KK5j0k5lzFqXP; Tue, 18 Dec 2018 18:46:16 -0800 (PST) To: Brian Carpenter , gen-art@ietf.org Cc: draft-ietf-lisp-rfc8113bis.all@ietf.org, lisp@ietf.org References: <154518630870.5131.10104452678736081639@ietfa.amsl.com> From: "Joel M. Halpern" Message-ID: Date: Tue, 18 Dec 2018 21:46:15 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 MIME-Version: 1.0 In-Reply-To: <154518630870.5131.10104452678736081639@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01 X-BeenThere: lisp@ietf.org 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: Wed, 19 Dec 2018 02:46:20 -0000 This is part of the package to move the coherent set of base LISP specs to PS. The reason we did this rather than folding it into 6830bis / 6833bis is that we had originally simply cited 8113, and then realized that needed to move to PS along with everything else. It seemed (and is) simpler to do it separately rather than to further modify 6830bis / 6933bis. As for why it updates 6833bis, that is because one of the cahnges in moving the set to PS was to improve the split as to which information belonged in which document. Yours, Joel On 12/18/18 9:25 PM, Brian Carpenter wrote: > Reviewer: Brian Carpenter > Review result: Ready with Issues > > Gen-ART Last Call review of draft-ietf-lisp-rfc8113bis-01 > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > . > > Document: draft-ietf-lisp-rfc8113bis-01.txt > Reviewer: Brian Carpenter > Review Date: 2018-12-19 > IETF LC End Date: 2018-12-27 > IESG Telechat date: > > Summary: Ready with issues > -------- > > Comments: > --------- > > I note that this is being raised from Experimental to the standards track. > Presumably that depends on the base LISP spec becoming PS. > > Minor issues: > ------------- > > "This document updates I-D.ietf-lisp-rfc6833bis." The text doesn't > explain which text is updated. This is in contrast to RFC8113, which > explains clearly how it updates RFC6830 (*not* RFC6833). Why doesn't > this draft claim to update rfc6830bis? I'm going to assume that > is an error. > > In fact, why wasn't the definition of the LISP Packet Types registry > moved into the base spec (rfc6830bis)? That is where it belongs. > > Since rfc6830bis (and rfc6833bis) are still under IESG review, anything > in them that needs updating should be updated! The fact is that rfc8113bis > extends rfc6830bis, which is not the same thing as "updates". > If the WG thinks that implementers of 6830bis need to read 8113bis, > there should be a normative reference in 6830bis to 8113bis. > > From nobody Tue Dec 18 19:48:19 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D69912F1A5; Tue, 18 Dec 2018 19:48:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 iwQeajdNX-rh; Tue, 18 Dec 2018 19:48:10 -0800 (PST) Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 427171276D0; Tue, 18 Dec 2018 19:48:10 -0800 (PST) Received: by mail-pl1-x62b.google.com with SMTP id e11so8169059plt.11; Tue, 18 Dec 2018 19:48:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=1ixcLii9gE4L3kDWy4zUqQBjXQX9+ytxUPe0nXvYvJQ=; b=GxBWlvSW0JPKIdZPDIOhzzAJYh8yk08uNcSjZsUbNWxBeg5E50IQUwIhCUMx7snPc6 YkY+H4l4HdKxfBjLAb3UyC0NW67KMkpjbWVlV7DWPpGrbDmssmMrP3zUo8A8rNaCZ/FD uGr9pu2iAEcsnSQXHOSAFPlyyyD7R46BYj9Fu4GE9/+1nnUX1nm7ImcbRyrnyhanpWjZ uyuXcyvbfcXbNWIZ50iIrG+S+5sCKu899xuqcl+CDbqoXD03DpYHIsJe6Nwt6JFYQgmC b2cSq2sXo2gBENrO+FbEt5Sud36fcGC5UxdysmBPWbXI2CPk0qEBOxT8dS7L0WehOZj3 O1xQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=1ixcLii9gE4L3kDWy4zUqQBjXQX9+ytxUPe0nXvYvJQ=; b=U7N2I8sP26u8CF665rOZjTmFRgzM2v+LdjAnUHJHJHmBTqJuG7og5LGMiTp7/wpP7a 5VxKmoc5mBe1OsqcyHlFQJQQYAWlvbaBDx2SJAlkTTmYQH5DyKX3B8kK6xsCG5PuB/bX fXFI16j0+0OkDBglBGXNh9Y/XG+ouvs9KiskQpQWx6ZVaU0PZmKYH1c59t1AiopKy6AB obqjfdDFKdGlZgJgbZeG6+1MM/tzjIFAnYAThCJWAv0YBgaS7iDNC7LTf1ioOf9RjIOa XkR0jnju5fehI22QDa3AV8l+nlGwv6daeAez0tpM6+Ww1G4zF1HfZa/nKvsPfgl+Td8s 89ig== X-Gm-Message-State: AA+aEWZ4alWqoF+nwM+zILuY6xfytkahaSC5A9QCUy1lXaJfvTKytdCR V+n2cgeefjrLYZ/oP6Fxp7FMI4CQXhg= X-Google-Smtp-Source: AFSGD/UP28MQ4IF3srMb7nQIa2E24+kV72M4aAu9lFuGrwOeGxzAuDD4enGh3ALDIe9aZDWAUImhAQ== X-Received: by 2002:a17:902:8d8e:: with SMTP id v14mr18722496plo.133.1545191289266; Tue, 18 Dec 2018 19:48:09 -0800 (PST) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id b27sm23614810pfh.113.2018.12.18.19.48.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Dec 2018 19:48:08 -0800 (PST) To: "Joel M. Halpern" , gen-art@ietf.org Cc: draft-ietf-lisp-rfc8113bis.all@ietf.org, lisp@ietf.org References: <154518630870.5131.10104452678736081639@ietfa.amsl.com> From: Brian E Carpenter Message-ID: Date: Wed, 19 Dec 2018 16:48:02 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01 X-BeenThere: lisp@ietf.org 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: Wed, 19 Dec 2018 03:48:13 -0000 On 2018-12-19 15:46, Joel M. Halpern wrote: > This is part of the package to move the coherent set of base LISP specs > to PS. > > The reason we did this rather than folding it into 6830bis / 6833bis is > that we had originally simply cited 8113, and then realized that needed > to move to PS along with everything else. It seemed (and is) simpler to > do it separately rather than to further modify 6830bis / 6933bis. > > As for why it updates 6833bis, that is because one of the cahnges in > moving the set to PS was to improve the split as to which information > belonged in which document. OK, but I still don't find it logical The text doesn't explain which part of 6833bis is impacted, and normally these days we require such an explanation. And if there is an impact, you're missing the opportunity of fixing the error or gap in 6833bis, so the reader of 6833bis will be none the wiser unless you insert a reference to 8113bis. On the other hand, if there is no error or gap, you don't need "Updates:" at all. (Unfortunately, we don't have an "Extends:" header.) Brian > > Yours, > Joel > > On 12/18/18 9:25 PM, Brian Carpenter wrote: >> Reviewer: Brian Carpenter >> Review result: Ready with Issues >> >> Gen-ART Last Call review of draft-ietf-lisp-rfc8113bis-01 >> >> I am the assigned Gen-ART reviewer for this draft. The General Area >> Review Team (Gen-ART) reviews all IETF documents being processed >> by the IESG for the IETF Chair. Please treat these comments just >> like any other last call comments. >> >> For more information, please see the FAQ at >> . >> >> Document: draft-ietf-lisp-rfc8113bis-01.txt >> Reviewer: Brian Carpenter >> Review Date: 2018-12-19 >> IETF LC End Date: 2018-12-27 >> IESG Telechat date: >> >> Summary: Ready with issues >> -------- >> >> Comments: >> --------- >> >> I note that this is being raised from Experimental to the standards track. >> Presumably that depends on the base LISP spec becoming PS. >> >> Minor issues: >> ------------- >> >> "This document updates I-D.ietf-lisp-rfc6833bis." The text doesn't >> explain which text is updated. This is in contrast to RFC8113, which >> explains clearly how it updates RFC6830 (*not* RFC6833). Why doesn't >> this draft claim to update rfc6830bis? I'm going to assume that >> is an error. >> >> In fact, why wasn't the definition of the LISP Packet Types registry >> moved into the base spec (rfc6830bis)? That is where it belongs. >> >> Since rfc6830bis (and rfc6833bis) are still under IESG review, anything >> in them that needs updating should be updated! The fact is that rfc8113bis >> extends rfc6830bis, which is not the same thing as "updates". >> If the WG thinks that implementers of 6830bis need to read 8113bis, >> there should be a normative reference in 6830bis to 8113bis. >> >> > From nobody Tue Dec 18 20:24:43 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8B551276D0; Tue, 18 Dec 2018 20:24:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 8ITdoqpTL6Qv; Tue, 18 Dec 2018 20:24:34 -0800 (PST) Received: from maila1.tigertech.net (maila1.tigertech.net [208.80.4.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD3B1123FFD; Tue, 18 Dec 2018 20:24:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila1.tigertech.net (Postfix) with ESMTP id 43KMH62YxtzVhQc; Tue, 18 Dec 2018 20:24:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1545193474; bh=rDdINl5v3HErPISGff0+0hJQiXLxXB7Pjb/FUpipPdc=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=n1RyTv9+ftsUDRtZBS1oyAAehrjka/JFRqNT45shnO+4JzJr/DXNFh+A2oM8yA5eH jxBvI+GOQ7mlxNwDBlWQXpayJEUpWFZmXLKHcYL/l1ynU7F1kcvKb8xw/w85P+1Swb vV6xF2YcbfreXhOrfhwlXQ6tLPXdNSFqoKmQmQd4= X-Virus-Scanned: Debian amavisd-new at maila1.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila1.tigertech.net (Postfix) with ESMTPSA id 43KMH52TVszVhKq; Tue, 18 Dec 2018 20:24:33 -0800 (PST) To: Brian E Carpenter , gen-art@ietf.org Cc: draft-ietf-lisp-rfc8113bis.all@ietf.org, lisp@ietf.org References: <154518630870.5131.10104452678736081639@ietfa.amsl.com> From: "Joel M. Halpern" Message-ID: Date: Tue, 18 Dec 2018 23:24:31 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01 X-BeenThere: lisp@ietf.org 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: Wed, 19 Dec 2018 04:24:37 -0000 Authors: that sounds like a reasonable addition to me? Yours, Joel On 12/18/18 10:48 PM, Brian E Carpenter wrote: > On 2018-12-19 15:46, Joel M. Halpern wrote: >> This is part of the package to move the coherent set of base LISP specs >> to PS. >> >> The reason we did this rather than folding it into 6830bis / 6833bis is >> that we had originally simply cited 8113, and then realized that needed >> to move to PS along with everything else. It seemed (and is) simpler to >> do it separately rather than to further modify 6830bis / 6933bis. >> >> As for why it updates 6833bis, that is because one of the cahnges in >> moving the set to PS was to improve the split as to which information >> belonged in which document. > > OK, but I still don't find it logical The text doesn't explain which part of > 6833bis is impacted, and normally these days we require such an explanation. > And if there is an impact, you're missing the opportunity of fixing the error > or gap in 6833bis, so the reader of 6833bis will be none the wiser unless > you insert a reference to 8113bis. > > On the other hand, if there is no error or gap, you don't need "Updates:" > at all. (Unfortunately, we don't have an "Extends:" header.) > > Brian > >> >> Yours, >> Joel >> >> On 12/18/18 9:25 PM, Brian Carpenter wrote: >>> Reviewer: Brian Carpenter >>> Review result: Ready with Issues >>> >>> Gen-ART Last Call review of draft-ietf-lisp-rfc8113bis-01 >>> >>> I am the assigned Gen-ART reviewer for this draft. The General Area >>> Review Team (Gen-ART) reviews all IETF documents being processed >>> by the IESG for the IETF Chair. Please treat these comments just >>> like any other last call comments. >>> >>> For more information, please see the FAQ at >>> . >>> >>> Document: draft-ietf-lisp-rfc8113bis-01.txt >>> Reviewer: Brian Carpenter >>> Review Date: 2018-12-19 >>> IETF LC End Date: 2018-12-27 >>> IESG Telechat date: >>> >>> Summary: Ready with issues >>> -------- >>> >>> Comments: >>> --------- >>> >>> I note that this is being raised from Experimental to the standards track. >>> Presumably that depends on the base LISP spec becoming PS. >>> >>> Minor issues: >>> ------------- >>> >>> "This document updates I-D.ietf-lisp-rfc6833bis." The text doesn't >>> explain which text is updated. This is in contrast to RFC8113, which >>> explains clearly how it updates RFC6830 (*not* RFC6833). Why doesn't >>> this draft claim to update rfc6830bis? I'm going to assume that >>> is an error. >>> >>> In fact, why wasn't the definition of the LISP Packet Types registry >>> moved into the base spec (rfc6830bis)? That is where it belongs. >>> >>> Since rfc6830bis (and rfc6833bis) are still under IESG review, anything >>> in them that needs updating should be updated! The fact is that rfc8113bis >>> extends rfc6830bis, which is not the same thing as "updates". >>> If the WG thinks that implementers of 6830bis need to read 8113bis, >>> there should be a normative reference in 6830bis to 8113bis. >>> >>> >> > From nobody Tue Dec 18 20:43:31 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F9F812F1A5; Tue, 18 Dec 2018 20:43:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 4hU4WR-6HTkD; Tue, 18 Dec 2018 20:43:27 -0800 (PST) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD69F1276D0; Tue, 18 Dec 2018 20:43:26 -0800 (PST) Received: by mail-qt1-x835.google.com with SMTP id k12so20862369qtf.7; Tue, 18 Dec 2018 20:43:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NQLhvRJyp1TobF8RDzTIYBv+g8FY01js8wYmwS7Xu7w=; b=GEz6h8Ee5B13J2L5swuPf7Y5JO920uG90IEmwqxAgmLJ4+gVPiB55I2ri406JtsKdg 4/pcuy78w7f4KKG8+mb4GdmiCwIWINgLbGvv9AblBs5fjxFFOUkuvHGJ3XHaP8OkL4Ac YdpHu3MicEuyL41ykz+OycZ1E8J4S2iNzXKi0ePDxbnjWAPNIjf5/YoQTYv2uwmxEQOH uYSkOm/OY4k5a6JfdFprwlcGWcSKIsIv+sxegEtRZXoEPGP+qkIWEmkYNAUFCC0ElX23 gx8eJEzNemqoOmOQS8f0NsW5KgjHNxu1b3jfya4mXEKTD6UiUHgA/hpa7ZZLMWR4F2i8 ffqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NQLhvRJyp1TobF8RDzTIYBv+g8FY01js8wYmwS7Xu7w=; b=AkCEs8f63FapTnG8SD/qnlOwMUrrU6y8wvopwqowSjds98ZsuhRbUttcIAbDkINi+Q BKwaN8rSCZl76wMJpoDVZHy9fnPqa413V4el8u27HBiDPqHTX7leNKvztSCHyv+Fb/Xy s6FLP88Pvlpl/n74q8zbBc6ZqMLxFp6r58On0YD46LF4amATeuAoc+8uiFmeDSPFF5lL wV00B43wiBTsSDbH8mozXJg+ZPrla5twGGKF7tEpvg4TQnUw5mpaQ2Du9MF0N8XghfWu SwtYARcYoLxO/0QY+rRDItzqJ7zoWrIF1b5NP1pqDPrQbKCRuBCoGkGV0ktp9H9t91Qq W3ZA== X-Gm-Message-State: AA+aEWa9FEQyEC0MSLC1qyl14FkLAgkpQuZT56Y7q2dZkbG2OHaxz1hi r8f5XGdnGYthvw/ZbGZiMyQ= X-Google-Smtp-Source: AFSGD/Xn9wndRExVTyx4uSS95465Qe6g+W07wyjXBQCLx8XOA5fQjyaI6HUSYkyDFqD2j3hkbq71Pw== X-Received: by 2002:aed:3746:: with SMTP id i64mr19871583qtb.307.1545194606031; Tue, 18 Dec 2018 20:43:26 -0800 (PST) Received: from [10.206.31.55] ([184.169.45.4]) by smtp.gmail.com with ESMTPSA id 46sm1422019qtv.22.2018.12.18.20.43.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Dec 2018 20:43:25 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: Date: Tue, 18 Dec 2018 21:43:07 -0700 Cc: Brian E Carpenter , gen-art@ietf.org, lisp@ietf.org, draft-ietf-lisp-rfc8113bis.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <407BD77D-F364-4989-A6D2-C75DF9914402@gmail.com> References: <154518630870.5131.10104452678736081639@ietfa.amsl.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01 X-BeenThere: lisp@ietf.org 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: Wed, 19 Dec 2018 04:43:29 -0000 8113bis should say that is it *extending* the type field so we can have = more types. The word =E2=80=9Cupdate=E2=80=9D I always had a problem = with because it can be interpreted as =E2=80=9Creplacing". Replacing = something to fix a problem.=20 8113 is simply asking for one of the type value codepoint, so there can = be another format to have more types. Dino > On Dec 18, 2018, at 9:24 PM, Joel M. Halpern = wrote: >=20 > Authors: that sounds like a reasonable addition to me? >=20 > Yours, > Joel >=20 > On 12/18/18 10:48 PM, Brian E Carpenter wrote: >> On 2018-12-19 15:46, Joel M. Halpern wrote: >>> This is part of the package to move the coherent set of base LISP = specs >>> to PS. >>>=20 >>> The reason we did this rather than folding it into 6830bis / 6833bis = is >>> that we had originally simply cited 8113, and then realized that = needed >>> to move to PS along with everything else. It seemed (and is) = simpler to >>> do it separately rather than to further modify 6830bis / 6933bis. >>>=20 >>> As for why it updates 6833bis, that is because one of the cahnges in >>> moving the set to PS was to improve the split as to which = information >>> belonged in which document. >> OK, but I still don't find it logical The text doesn't explain which = part of >> 6833bis is impacted, and normally these days we require such an = explanation. >> And if there is an impact, you're missing the opportunity of fixing = the error >> or gap in 6833bis, so the reader of 6833bis will be none the wiser = unless >> you insert a reference to 8113bis. >> On the other hand, if there is no error or gap, you don't need = "Updates:" >> at all. (Unfortunately, we don't have an "Extends:" header.) >> Brian >>>=20 >>> Yours, >>> Joel >>>=20 >>> On 12/18/18 9:25 PM, Brian Carpenter wrote: >>>> Reviewer: Brian Carpenter >>>> Review result: Ready with Issues >>>>=20 >>>> Gen-ART Last Call review of draft-ietf-lisp-rfc8113bis-01 >>>>=20 >>>> I am the assigned Gen-ART reviewer for this draft. The General Area >>>> Review Team (Gen-ART) reviews all IETF documents being processed >>>> by the IESG for the IETF Chair. Please treat these comments just >>>> like any other last call comments. >>>>=20 >>>> For more information, please see the FAQ at >>>> . >>>>=20 >>>> Document: draft-ietf-lisp-rfc8113bis-01.txt >>>> Reviewer: Brian Carpenter >>>> Review Date: 2018-12-19 >>>> IETF LC End Date: 2018-12-27 >>>> IESG Telechat date: >>>>=20 >>>> Summary: Ready with issues >>>> -------- >>>>=20 >>>> Comments: >>>> --------- >>>>=20 >>>> I note that this is being raised from Experimental to the standards = track. >>>> Presumably that depends on the base LISP spec becoming PS. >>>>=20 >>>> Minor issues: >>>> ------------- >>>>=20 >>>> "This document updates I-D.ietf-lisp-rfc6833bis." The text doesn't >>>> explain which text is updated. This is in contrast to RFC8113, = which >>>> explains clearly how it updates RFC6830 (*not* RFC6833). Why = doesn't >>>> this draft claim to update rfc6830bis? I'm going to assume that >>>> is an error. >>>>=20 >>>> In fact, why wasn't the definition of the LISP Packet Types = registry >>>> moved into the base spec (rfc6830bis)? That is where it belongs. >>>>=20 >>>> Since rfc6830bis (and rfc6833bis) are still under IESG review, = anything >>>> in them that needs updating should be updated! The fact is that = rfc8113bis >>>> extends rfc6830bis, which is not the same thing as "updates". >>>> If the WG thinks that implementers of 6830bis need to read 8113bis, >>>> there should be a normative reference in 6830bis to 8113bis. >>>>=20 >>>>=20 >>>=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Tue Dec 18 20:49:59 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1434012D84D; Tue, 18 Dec 2018 20:49:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 Z5YsBP7EK1KA; Tue, 18 Dec 2018 20:49:49 -0800 (PST) Received: from maila1.tigertech.net (maila1.tigertech.net [208.80.4.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2926F1276D0; Tue, 18 Dec 2018 20:49:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila1.tigertech.net (Postfix) with ESMTP id 43KMrD6Lz3zVhKq; Tue, 18 Dec 2018 20:49:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1545194988; bh=TOXXh/sRNXpGK9Vu+eUlWJeB6+pLRWKYsDo3s0AztGc=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=A6H3iyb4n9I4sSuuKGz/9gGssnqYGA7P1J0zWVM0SmFuBr/iMwlyA/LQqw6K+ULSX 6bcEKE8osORHAOfdXQXpvlzUz0B43JVqFWElM/daBkwZLe7n3LxqpDsEnstNONH/f7 NV1WI/ykRK3ZWHWleSwg3nu+bT0qCud3VFQE5qcU= X-Virus-Scanned: Debian amavisd-new at maila1.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila1.tigertech.net (Postfix) with ESMTPSA id 43KMrD1Gf1zVhDk; Tue, 18 Dec 2018 20:49:48 -0800 (PST) To: Dino Farinacci Cc: Brian E Carpenter , gen-art@ietf.org, lisp@ietf.org, draft-ietf-lisp-rfc8113bis.all@ietf.org References: <154518630870.5131.10104452678736081639@ietfa.amsl.com> <407BD77D-F364-4989-A6D2-C75DF9914402@gmail.com> From: "Joel M. Halpern" Message-ID: <9cc58af9-2bcf-89d7-a2ae-3fc80e723d78@joelhalpern.com> Date: Tue, 18 Dec 2018 23:49:47 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 MIME-Version: 1.0 In-Reply-To: <407BD77D-F364-4989-A6D2-C75DF9914402@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01 X-BeenThere: lisp@ietf.org 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: Wed, 19 Dec 2018 04:49:51 -0000 That is the other fix he offered. Just remove the updates tag. I will leav eit to you and the the authors to determine which is correct. Yours, Joel On 12/18/18 11:43 PM, Dino Farinacci wrote: > 8113bis should say that is it *extending* the type field so we can have more types. The word “update” I always had a problem with because it can be interpreted as “replacing". Replacing something to fix a problem. > > 8113 is simply asking for one of the type value codepoint, so there can be another format to have more types. > > Dino > >> On Dec 18, 2018, at 9:24 PM, Joel M. Halpern wrote: >> >> Authors: that sounds like a reasonable addition to me? >> >> Yours, >> Joel >> >> On 12/18/18 10:48 PM, Brian E Carpenter wrote: >>> On 2018-12-19 15:46, Joel M. Halpern wrote: >>>> This is part of the package to move the coherent set of base LISP specs >>>> to PS. >>>> >>>> The reason we did this rather than folding it into 6830bis / 6833bis is >>>> that we had originally simply cited 8113, and then realized that needed >>>> to move to PS along with everything else. It seemed (and is) simpler to >>>> do it separately rather than to further modify 6830bis / 6933bis. >>>> >>>> As for why it updates 6833bis, that is because one of the cahnges in >>>> moving the set to PS was to improve the split as to which information >>>> belonged in which document. >>> OK, but I still don't find it logical The text doesn't explain which part of >>> 6833bis is impacted, and normally these days we require such an explanation. >>> And if there is an impact, you're missing the opportunity of fixing the error >>> or gap in 6833bis, so the reader of 6833bis will be none the wiser unless >>> you insert a reference to 8113bis. >>> On the other hand, if there is no error or gap, you don't need "Updates:" >>> at all. (Unfortunately, we don't have an "Extends:" header.) >>> Brian >>>> >>>> Yours, >>>> Joel >>>> >>>> On 12/18/18 9:25 PM, Brian Carpenter wrote: >>>>> Reviewer: Brian Carpenter >>>>> Review result: Ready with Issues >>>>> >>>>> Gen-ART Last Call review of draft-ietf-lisp-rfc8113bis-01 >>>>> >>>>> I am the assigned Gen-ART reviewer for this draft. The General Area >>>>> Review Team (Gen-ART) reviews all IETF documents being processed >>>>> by the IESG for the IETF Chair. Please treat these comments just >>>>> like any other last call comments. >>>>> >>>>> For more information, please see the FAQ at >>>>> . >>>>> >>>>> Document: draft-ietf-lisp-rfc8113bis-01.txt >>>>> Reviewer: Brian Carpenter >>>>> Review Date: 2018-12-19 >>>>> IETF LC End Date: 2018-12-27 >>>>> IESG Telechat date: >>>>> >>>>> Summary: Ready with issues >>>>> -------- >>>>> >>>>> Comments: >>>>> --------- >>>>> >>>>> I note that this is being raised from Experimental to the standards track. >>>>> Presumably that depends on the base LISP spec becoming PS. >>>>> >>>>> Minor issues: >>>>> ------------- >>>>> >>>>> "This document updates I-D.ietf-lisp-rfc6833bis." The text doesn't >>>>> explain which text is updated. This is in contrast to RFC8113, which >>>>> explains clearly how it updates RFC6830 (*not* RFC6833). Why doesn't >>>>> this draft claim to update rfc6830bis? I'm going to assume that >>>>> is an error. >>>>> >>>>> In fact, why wasn't the definition of the LISP Packet Types registry >>>>> moved into the base spec (rfc6830bis)? That is where it belongs. >>>>> >>>>> Since rfc6830bis (and rfc6833bis) are still under IESG review, anything >>>>> in them that needs updating should be updated! The fact is that rfc8113bis >>>>> extends rfc6830bis, which is not the same thing as "updates". >>>>> If the WG thinks that implementers of 6830bis need to read 8113bis, >>>>> there should be a normative reference in 6830bis to 8113bis. >>>>> >>>>> >>>> >> >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp > From nobody Tue Dec 18 21:37:40 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C59BA12D84D; Tue, 18 Dec 2018 21:37:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Bk17NzXwIgNK; Tue, 18 Dec 2018 21:37:30 -0800 (PST) Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C37512426A; Tue, 18 Dec 2018 21:37:30 -0800 (PST) Received: by mail-pl1-x62a.google.com with SMTP id gn14so8946628plb.10; Tue, 18 Dec 2018 21:37:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZwQjqAo7ixmW7Fi7tPNu5gYcdpCSKLvecHhwEs/osDc=; b=JPIvY5ximYvvr7UJY6ULbKdC5RXS0GY4rWTHmI405NgLI9pKMtM9PU+/bPs+Pnl/GE 7x6B5NGnlRhP8BGSG0ei8Pa78Dzh3esByelvCaPXCp1E/838z7z7WoU5dFF2x1QB3J/D fE3zyO2r/GsGN83he9Qq1UDx2cfROjmM1NtV6NwRHs28vbnGyQ3qRfrSkRpWZ5ecpEBT puASCmanebIwq6ThuF0Wz41acwSrO0zN6ozQFGqR1gNEHc0n3Y1ehhMKU93NvZahplxQ BUfcAt9gvbKvEEI3nj4+/IbTRHjREZC/a66PNEh1/bFudIwQMIr3KSXq/qtKdlToh8KA 1GJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZwQjqAo7ixmW7Fi7tPNu5gYcdpCSKLvecHhwEs/osDc=; b=kcKNccNd5o2r8C97D9IKVxQ7DjeH2nYv/0Kq+h3Wt48omwsC4bnfozLD67VhQIBX+A cJkgTO1FRQIBdXk5pLsmAVe8hXM4gEzpu3xCaSStlMtBtBqViS6dASjJpHG/Ge76Tjx5 7RjXkdmw7x41BGL45kWLaWpzXIUokblDpOocnGvzCWm29K58h4OF0TaR08N7yOJZr0IU TGoeffMg+fIfBwFYFfpkKAfjbBGxHhe4XHpO8TMCNh3qNGdqJxGYvR1sQfOf9GShSpjf pQPGgaFbieY0LCurLVzr1ONI25NftU0/m+AWQXGXmVlWAMI6AVNjtXJxA77b/SKapQL7 LNjA== X-Gm-Message-State: AA+aEWZG9uj6xD60qJVsEGYOiSm4nJ44eh6noq0SdQ4FxLIiYWZ6kD3O +vDZSKvqX2F1+Sqq2U34SB4= X-Google-Smtp-Source: AFSGD/Uzn1sq7sAwU2JsaTxwA7WmOXmuAtD7K4od+UNZiIKGoeECWTLCJAyfUvIFCj2sVYLKbnO+9Q== X-Received: by 2002:a17:902:7c85:: with SMTP id y5mr18968500pll.63.1545197849973; Tue, 18 Dec 2018 21:37:29 -0800 (PST) Received: from ?IPv6:2603:3024:151c:55f0:104f:3347:f01d:b2d2? ([2603:3024:151c:55f0:104f:3347:f01d:b2d2]) by smtp.gmail.com with ESMTPSA id h74sm25072205pfd.35.2018.12.18.21.37.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Dec 2018 21:37:29 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: <9cc58af9-2bcf-89d7-a2ae-3fc80e723d78@joelhalpern.com> Date: Tue, 18 Dec 2018 21:37:27 -0800 Cc: Brian E Carpenter , gen-art@ietf.org, lisp@ietf.org, draft-ietf-lisp-rfc8113bis.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <154518630870.5131.10104452678736081639@ietfa.amsl.com> <407BD77D-F364-4989-A6D2-C75DF9914402@gmail.com> <9cc58af9-2bcf-89d7-a2ae-3fc80e723d78@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01 X-BeenThere: lisp@ietf.org 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: Wed, 19 Dec 2018 05:37:33 -0000 Mohmad to comment. Dino > On Dec 18, 2018, at 8:49 PM, Joel M. Halpern = wrote: >=20 > That is the other fix he offered. Just remove the updates tag. > I will leav eit to you and the the authors to determine which is = correct. > Yours, > Joel >=20 > On 12/18/18 11:43 PM, Dino Farinacci wrote: >> 8113bis should say that is it *extending* the type field so we can = have more types. The word =E2=80=9Cupdate=E2=80=9D I always had a = problem with because it can be interpreted as =E2=80=9Creplacing". = Replacing something to fix a problem. >> 8113 is simply asking for one of the type value codepoint, so there = can be another format to have more types. >> Dino >>> On Dec 18, 2018, at 9:24 PM, Joel M. Halpern = wrote: >>>=20 >>> Authors: that sounds like a reasonable addition to me? >>>=20 >>> Yours, >>> Joel >>>=20 >>> On 12/18/18 10:48 PM, Brian E Carpenter wrote: >>>> On 2018-12-19 15:46, Joel M. Halpern wrote: >>>>> This is part of the package to move the coherent set of base LISP = specs >>>>> to PS. >>>>>=20 >>>>> The reason we did this rather than folding it into 6830bis / = 6833bis is >>>>> that we had originally simply cited 8113, and then realized that = needed >>>>> to move to PS along with everything else. It seemed (and is) = simpler to >>>>> do it separately rather than to further modify 6830bis / 6933bis. >>>>>=20 >>>>> As for why it updates 6833bis, that is because one of the cahnges = in >>>>> moving the set to PS was to improve the split as to which = information >>>>> belonged in which document. >>>> OK, but I still don't find it logical The text doesn't explain = which part of >>>> 6833bis is impacted, and normally these days we require such an = explanation. >>>> And if there is an impact, you're missing the opportunity of fixing = the error >>>> or gap in 6833bis, so the reader of 6833bis will be none the wiser = unless >>>> you insert a reference to 8113bis. >>>> On the other hand, if there is no error or gap, you don't need = "Updates:" >>>> at all. (Unfortunately, we don't have an "Extends:" header.) >>>> Brian >>>>>=20 >>>>> Yours, >>>>> Joel >>>>>=20 >>>>> On 12/18/18 9:25 PM, Brian Carpenter wrote: >>>>>> Reviewer: Brian Carpenter >>>>>> Review result: Ready with Issues >>>>>>=20 >>>>>> Gen-ART Last Call review of draft-ietf-lisp-rfc8113bis-01 >>>>>>=20 >>>>>> I am the assigned Gen-ART reviewer for this draft. The General = Area >>>>>> Review Team (Gen-ART) reviews all IETF documents being processed >>>>>> by the IESG for the IETF Chair. Please treat these comments just >>>>>> like any other last call comments. >>>>>>=20 >>>>>> For more information, please see the FAQ at >>>>>> . >>>>>>=20 >>>>>> Document: draft-ietf-lisp-rfc8113bis-01.txt >>>>>> Reviewer: Brian Carpenter >>>>>> Review Date: 2018-12-19 >>>>>> IETF LC End Date: 2018-12-27 >>>>>> IESG Telechat date: >>>>>>=20 >>>>>> Summary: Ready with issues >>>>>> -------- >>>>>>=20 >>>>>> Comments: >>>>>> --------- >>>>>>=20 >>>>>> I note that this is being raised from Experimental to the = standards track. >>>>>> Presumably that depends on the base LISP spec becoming PS. >>>>>>=20 >>>>>> Minor issues: >>>>>> ------------- >>>>>>=20 >>>>>> "This document updates I-D.ietf-lisp-rfc6833bis." The text = doesn't >>>>>> explain which text is updated. This is in contrast to RFC8113, = which >>>>>> explains clearly how it updates RFC6830 (*not* RFC6833). Why = doesn't >>>>>> this draft claim to update rfc6830bis? I'm going to assume that >>>>>> is an error. >>>>>>=20 >>>>>> In fact, why wasn't the definition of the LISP Packet Types = registry >>>>>> moved into the base spec (rfc6830bis)? That is where it belongs. >>>>>>=20 >>>>>> Since rfc6830bis (and rfc6833bis) are still under IESG review, = anything >>>>>> in them that needs updating should be updated! The fact is that = rfc8113bis >>>>>> extends rfc6830bis, which is not the same thing as "updates". >>>>>> If the WG thinks that implementers of 6830bis need to read = 8113bis, >>>>>> there should be a normative reference in 6830bis to 8113bis. >>>>>>=20 >>>>>>=20 >>>>>=20 >>>=20 >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp From nobody Wed Dec 19 00:43:02 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF9A0130DEF for ; Wed, 19 Dec 2018 00:42:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-net.20150623.gappssmtp.com 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 2C8RYfkeGi6P for ; Wed, 19 Dec 2018 00:42:55 -0800 (PST) Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com [IPv6:2a00:1450:4864:20::443]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 295FB130DEC for ; Wed, 19 Dec 2018 00:42:52 -0800 (PST) Received: by mail-wr1-x443.google.com with SMTP id t6so18392566wrr.12 for ; Wed, 19 Dec 2018 00:42:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=asS3FqYkYU4GJelbDZkStj6RE44HHrEmsnIJCyZCLpg=; b=VQgZoTE+gFZr8vcEmgiRrqqVYuSZp4OFcCFg5f0Ncv+HiaWqlGponvyAVbyqsAnVfG dtIkJq1uxGeaKxSUTxrYrloagB1wCLbcGW6EdZ9QyINGiBbRJbrvW+y7mR/8esHTnGV/ YjRzNmcUhS8JIQMGiyGIrReVgZFwA9tLNJiPeBveprYebCsaCpuYpuoKS/kyzaSN2XhW oOinyTrKQnAzKjOqZii8yiOYaIs9/+GHCUnNtEDX55x9ESdx3ECLBwDmWoxt2YqqqjCM LqdiPxTuUVFEdwc/rnf2e4ln/c9yWm2gHKrkXpE+UvYBTbRXO/J+NSr/hWxz5HJ3q6Zq aQSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=asS3FqYkYU4GJelbDZkStj6RE44HHrEmsnIJCyZCLpg=; b=oRgSAJRokPjceyQcCF0eetqj5j+U6R1Jq2ZN4FxGi6g0QW6SXfFQRZNXD1xkcFkgrk Ps9GElibdg7FsKcvpBzNIvRZlj2wOhXo+8vevClSjISRP4mYfJankBeXuuNjrJ5qZK8Y jbjcmI1+eHKfeuTCbl1IW+PQVHmOdVOcQTecgvDFfILVad9SJPxeBEVxHAo4DaxU7MYs asuz3TqudvTdUu+Nk/d7dKIVsIEbcg7ORGKvjmJ+6FeQEgzFVJuInNNfKursb6pggQuJ MpOsUh/V+RYZZa0AXtC+c1HNbVBTbIch/ToE4oBqZUNxGDfZFsCgD4FxSjpBNS2uImgC +Xag== X-Gm-Message-State: AA+aEWboliMvVXadg89/4HcZwjJDF89acJ8NhcpCLOWrPDlVahkg5ReZ hPhqxkD2g537hTvxqlnuOZAUAQ== X-Google-Smtp-Source: AFSGD/X3dBr0L/POGfdjwSVlcOmaHpgos8VQ51ouqhGCU/Tz6UkJbSBzUbSe18IXNQ0MwC6+iatCAg== X-Received: by 2002:adf:fb0d:: with SMTP id c13mr19227250wrr.285.1545208967869; Wed, 19 Dec 2018 00:42:47 -0800 (PST) Received: from ?IPv6:2001:660:330f:a4:844b:645b:a365:677c? ([2001:660:330f:a4:844b:645b:a365:677c]) by smtp.gmail.com with ESMTPSA id l78sm8577041wma.0.2018.12.19.00.42.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Dec 2018 00:42:46 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) From: Luigi Iannone In-Reply-To: Date: Wed, 19 Dec 2018 09:42:44 +0100 Cc: "Joel M. Halpern" , Brian E Carpenter , gen-art@ietf.org, lisp@ietf.org, draft-ietf-lisp-rfc8113bis.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <2032D0A3-7BC0-4D22-B5A8-DCD021EB0E88@gigix.net> References: <154518630870.5131.10104452678736081639@ietfa.amsl.com> <407BD77D-F364-4989-A6D2-C75DF9914402@gmail.com> <9cc58af9-2bcf-89d7-a2ae-3fc80e723d78@joelhalpern.com> To: Dino Farinacci X-Mailer: Apple Mail (2.3445.101.1) Archived-At: Subject: Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01 X-BeenThere: lisp@ietf.org 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: Wed, 19 Dec 2018 08:42:57 -0000 Hi, may be we do not need a state anything with respect of 6833bis. Looking at the IANA considerations section of both 8113bis and 6833bis, = they just request IANA to rename/allocate something in an existing = registry. In particular, 8113bis does not extend/update nothing in 6833bis. IMHO we just drop the =E2=80=9Cupdate 6833bis=E2=80=9D and we are fine. Ciao L. > On 19 Dec 2018, at 06:37, Dino Farinacci wrote: >=20 > Mohmad to comment. >=20 > Dino >=20 >> On Dec 18, 2018, at 8:49 PM, Joel M. Halpern = wrote: >>=20 >> That is the other fix he offered. Just remove the updates tag. >> I will leav eit to you and the the authors to determine which is = correct. >> Yours, >> Joel >>=20 >> On 12/18/18 11:43 PM, Dino Farinacci wrote: >>> 8113bis should say that is it *extending* the type field so we can = have more types. The word =E2=80=9Cupdate=E2=80=9D I always had a = problem with because it can be interpreted as =E2=80=9Creplacing". = Replacing something to fix a problem. >>> 8113 is simply asking for one of the type value codepoint, so there = can be another format to have more types. >>> Dino >>>> On Dec 18, 2018, at 9:24 PM, Joel M. Halpern = wrote: >>>>=20 >>>> Authors: that sounds like a reasonable addition to me? >>>>=20 >>>> Yours, >>>> Joel >>>>=20 >>>> On 12/18/18 10:48 PM, Brian E Carpenter wrote: >>>>> On 2018-12-19 15:46, Joel M. Halpern wrote: >>>>>> This is part of the package to move the coherent set of base LISP = specs >>>>>> to PS. >>>>>>=20 >>>>>> The reason we did this rather than folding it into 6830bis / = 6833bis is >>>>>> that we had originally simply cited 8113, and then realized that = needed >>>>>> to move to PS along with everything else. It seemed (and is) = simpler to >>>>>> do it separately rather than to further modify 6830bis / 6933bis. >>>>>>=20 >>>>>> As for why it updates 6833bis, that is because one of the cahnges = in >>>>>> moving the set to PS was to improve the split as to which = information >>>>>> belonged in which document. >>>>> OK, but I still don't find it logical The text doesn't explain = which part of >>>>> 6833bis is impacted, and normally these days we require such an = explanation. >>>>> And if there is an impact, you're missing the opportunity of = fixing the error >>>>> or gap in 6833bis, so the reader of 6833bis will be none the wiser = unless >>>>> you insert a reference to 8113bis. >>>>> On the other hand, if there is no error or gap, you don't need = "Updates:" >>>>> at all. (Unfortunately, we don't have an "Extends:" header.) >>>>> Brian >>>>>>=20 >>>>>> Yours, >>>>>> Joel >>>>>>=20 >>>>>> On 12/18/18 9:25 PM, Brian Carpenter wrote: >>>>>>> Reviewer: Brian Carpenter >>>>>>> Review result: Ready with Issues >>>>>>>=20 >>>>>>> Gen-ART Last Call review of draft-ietf-lisp-rfc8113bis-01 >>>>>>>=20 >>>>>>> I am the assigned Gen-ART reviewer for this draft. The General = Area >>>>>>> Review Team (Gen-ART) reviews all IETF documents being processed >>>>>>> by the IESG for the IETF Chair. Please treat these comments = just >>>>>>> like any other last call comments. >>>>>>>=20 >>>>>>> For more information, please see the FAQ at >>>>>>> . >>>>>>>=20 >>>>>>> Document: draft-ietf-lisp-rfc8113bis-01.txt >>>>>>> Reviewer: Brian Carpenter >>>>>>> Review Date: 2018-12-19 >>>>>>> IETF LC End Date: 2018-12-27 >>>>>>> IESG Telechat date: >>>>>>>=20 >>>>>>> Summary: Ready with issues >>>>>>> -------- >>>>>>>=20 >>>>>>> Comments: >>>>>>> --------- >>>>>>>=20 >>>>>>> I note that this is being raised from Experimental to the = standards track. >>>>>>> Presumably that depends on the base LISP spec becoming PS. >>>>>>>=20 >>>>>>> Minor issues: >>>>>>> ------------- >>>>>>>=20 >>>>>>> "This document updates I-D.ietf-lisp-rfc6833bis." The text = doesn't >>>>>>> explain which text is updated. This is in contrast to RFC8113, = which >>>>>>> explains clearly how it updates RFC6830 (*not* RFC6833). Why = doesn't >>>>>>> this draft claim to update rfc6830bis? I'm going to assume that >>>>>>> is an error. >>>>>>>=20 >>>>>>> In fact, why wasn't the definition of the LISP Packet Types = registry >>>>>>> moved into the base spec (rfc6830bis)? That is where it belongs. >>>>>>>=20 >>>>>>> Since rfc6830bis (and rfc6833bis) are still under IESG review, = anything >>>>>>> in them that needs updating should be updated! The fact is that = rfc8113bis >>>>>>> extends rfc6830bis, which is not the same thing as "updates". >>>>>>> If the WG thinks that implementers of 6830bis need to read = 8113bis, >>>>>>> there should be a normative reference in 6830bis to 8113bis. >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> lisp mailing list >>>> lisp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lisp >=20 From nobody Wed Dec 19 03:51:35 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C66B4130DF5; Wed, 19 Dec 2018 03:51:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no 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 lGL3EfH0_l1d; Wed, 19 Dec 2018 03:51:24 -0800 (PST) Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D4FB128CF2; Wed, 19 Dec 2018 03:51:24 -0800 (PST) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 43KYBf573sz10tW; Wed, 19 Dec 2018 12:51:22 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.27]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 43KYBf3cxzz1xq6; Wed, 19 Dec 2018 12:51:22 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7C.corporate.adroot.infra.ftgroup ([fe80::8007:17b:c3b4:d68b%19]) with mapi id 14.03.0415.000; Wed, 19 Dec 2018 12:51:22 +0100 From: To: Dino Farinacci , "Joel M. Halpern" , Brian E Carpenter CC: "gen-art@ietf.org" , "lisp@ietf.org" , "draft-ietf-lisp-rfc8113bis.all@ietf.org" Thread-Topic: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01 Thread-Index: AQHUl1zyY+Dwq6ZnWEOLuP+YMO3vRqWF1sgw Date: Wed, 19 Dec 2018 11:51:21 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302E05D7D4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <154518630870.5131.10104452678736081639@ietfa.amsl.com> <407BD77D-F364-4989-A6D2-C75DF9914402@gmail.com> <9cc58af9-2bcf-89d7-a2ae-3fc80e723d78@joelhalpern.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01 X-BeenThere: lisp@ietf.org 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: Wed, 19 Dec 2018 11:51:27 -0000 SGkgYWxsLCANCg0KQnJpYW4sIHdoZXRoZXIgdG8gbWFpbnRhaW4gdGhlIGRvY3VtZW50IHN0YW5k YWxvbmUgd2FzIGRpc2N1c3NlZCBieSB0aGUgV0cuIFlvdSBtYXkgcmVmZXIsIGZvciBleGFtcGxl LCB0byB0aGUgbWVzc2FnZSBmcm9tIERlYm9yYWggd2hpY2ggY2xhcmlmaWVzIHRoaXMgcG9pbnQ6 IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbGlzcC9jdXJyZW50L21zZzA3 ODg2Lmh0bWwuIE9uZSBvZiB0aGUgb3V0Y29tZXMgb2YgdGhhdCBkaXNjdXNzaW9uIGlzIHRvIGFk ZCBhbiAidXBkYXRlcyIgaGVhZGVyIHRvIDgxMTNiaXMuDQoNCkZXSVcsIG9uZSBvZiB0aGUgaXNz dWVzIHRoYXQgbGVkIHRvIHRoYXQgY29uY2x1c2lvbiB3YXMgd2hldGhlciB0byBjaXRlIHJmYzgx MTNiaXMgYXMgbm9ybWF0aXZlIGluIDY4MzNiaXMgKHRoZSBhcHByb2FjaCBJIGluaXRpYWxseSBz dXBwb3J0ZWQpIGFuZCBhZ3JlZWQgYnkgRGlubyAoaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1h cmNoaXZlL3dlYi9saXNwL2N1cnJlbnQvbXNnMDc4ODIuaHRtbCkuIERlYm9yYWggY29udmluY2Vk IG1lIHRoYXQgY2l0aW5nIDgxMTNiaXMgd2lsbCBsZWFkIHRvIGNpcmN1bGFyIGRlcGVuZGVuY3ku IFdoaWNoIGlzIGEgZmFpciBhcmd1bWVudC4gDQoNClRoZSAidXBkYXRlcyIgdGFnIHdhcyBqdXN0 aWZpZWQgYXMgZm9sbG93czoNCg0KKDEpDQoNClJGQzY4MzNiaXMgaW5jbHVkZXMgdGhlIGZvbGxv d2luZzoNCiANCiAgIFZhbHVlcyBpbiB0aGUgIk5vdCBBc3NpZ25lZCIgcmFuZ2UgY2FuIGJlIGFz c2lnbmVkIGFjY29yZGluZyB0bw0KICAgcHJvY2VkdXJlcyBpbiBbUkZDODEyNl0uDQoNClRoYXQg dGV4dCBpcyB1cGRhdGVkIGJ5IFJGQzgxMTNiaXMgdG8gYmUgYWxpZ25lZCB3aXRoIDgxMTM6IA0K DQogICBWYWx1ZXMgY2FuIGJlIGFzc2lnbmVkIHZpYSBTdGFuZGFyZHMgQWN0aW9uDQoNCigyKSAN Cg0KUkZDODExM2JpcyBleHRlbmRzIHRoZSB0eXBlIGZpZWxkIHRvIGdyYWIgbW9yZSBiaXRzL3Zh bHVlcyB3aGVuIHRoZSBhdmFpbGFibGUgdHlwZXMgYXJlIGV4aGF1c3RlZC4gVGhpcyBpcyBjYXB0 dXJlZCBpbiA4MTEzYmlzOg0KDQogICBUaGUgdmFsdWVzIGluIHRoZSByYW5nZSAwLTEwMjMgYXJl IGFzc2lnbmVkIHZpYSBTdGFuZGFyZHMgQWN0aW9uLg0KICAgVGhpcyByYW5nZSBpcyBwcm92aXNp b25lZCB0byBhbnRpY2lwYXRlLCBpbiBwYXJ0aWN1bGFyLCB0aGUNCiAgIGV4aGF1c3Rpb24gb2Yg dGhlIExJU1AgUGFja2V0IHR5cGVzLg0KDQpEaW5vOiBJZiAoMSkgaXMgZml4ZWQgZGlyZWN0bHkg aW4gUkZDNjgzM2JpcywgdGhlbiBJJ20gZmluZSB0byByZW1vdmUgdGhlICJ1cGRhdGVzIiBoZWFk ZXIgYmVjYXVzZSAoMikgY2FuIGJlIGFsc28gc2VlbiBhcyBhbiBleHRlbnNpb24uIA0KDQpDaGVl cnMsDQpNZWQNCg0KPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gRGXCoDogRGlubyBG YXJpbmFjY2kgW21haWx0bzpmYXJpbmFjY2lAZ21haWwuY29tXQ0KPiBFbnZvecOpwqA6IG1lcmNy ZWRpIDE5IGTDqWNlbWJyZSAyMDE4IDA2OjM3DQo+IMOAwqA6IEpvZWwgTS4gSGFscGVybg0KPiBD Y8KgOiBCcmlhbiBFIENhcnBlbnRlcjsgZ2VuLWFydEBpZXRmLm9yZzsgbGlzcEBpZXRmLm9yZzsg ZHJhZnQtaWV0Zi1saXNwLQ0KPiByZmM4MTEzYmlzLmFsbEBpZXRmLm9yZw0KPiBPYmpldMKgOiBS ZTogW2xpc3BdIEdlbmFydCBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtbGlzcC1yZmM4 MTEzYmlzLTAxDQo+IA0KPiBNb2htYWQgdG8gY29tbWVudC4NCj4gDQo+IERpbm8NCj4gDQo+ID4g T24gRGVjIDE4LCAyMDE4LCBhdCA4OjQ5IFBNLCBKb2VsIE0uIEhhbHBlcm4gPGptaEBqb2VsaGFs cGVybi5jb20+IHdyb3RlOg0KPiA+DQo+ID4gVGhhdCBpcyB0aGUgb3RoZXIgZml4IGhlIG9mZmVy ZWQuICBKdXN0IHJlbW92ZSB0aGUgdXBkYXRlcyB0YWcuDQo+ID4gSSB3aWxsIGxlYXYgZWl0IHRv IHlvdSBhbmQgdGhlIHRoZSBhdXRob3JzIHRvIGRldGVybWluZSB3aGljaCBpcyBjb3JyZWN0Lg0K PiA+IFlvdXJzLA0KPiA+IEpvZWwNCj4gPg0KPiA+IE9uIDEyLzE4LzE4IDExOjQzIFBNLCBEaW5v IEZhcmluYWNjaSB3cm90ZToNCj4gPj4gODExM2JpcyBzaG91bGQgc2F5IHRoYXQgaXMgaXQgKmV4 dGVuZGluZyogdGhlIHR5cGUgZmllbGQgc28gd2UgY2FuIGhhdmUNCj4gbW9yZSB0eXBlcy4gVGhl IHdvcmQg4oCcdXBkYXRl4oCdIEkgYWx3YXlzIGhhZCBhIHByb2JsZW0gd2l0aCBiZWNhdXNlIGl0 IGNhbiBiZQ0KPiBpbnRlcnByZXRlZCBhcyDigJxyZXBsYWNpbmciLiBSZXBsYWNpbmcgc29tZXRo aW5nIHRvIGZpeCBhIHByb2JsZW0uDQo+ID4+IDgxMTMgaXMgc2ltcGx5IGFza2luZyBmb3Igb25l IG9mIHRoZSB0eXBlIHZhbHVlIGNvZGVwb2ludCwgc28gdGhlcmUgY2FuIGJlDQo+IGFub3RoZXIg Zm9ybWF0IHRvIGhhdmUgbW9yZSB0eXBlcy4NCj4gPj4gRGlubw0KPiA+Pj4gT24gRGVjIDE4LCAy MDE4LCBhdCA5OjI0IFBNLCBKb2VsIE0uIEhhbHBlcm4gPGptaEBqb2VsaGFscGVybi5jb20+IHdy b3RlOg0KPiA+Pj4NCj4gPj4+IEF1dGhvcnM6IHRoYXQgc291bmRzIGxpa2UgYSByZWFzb25hYmxl IGFkZGl0aW9uIHRvIG1lPw0KPiA+Pj4NCj4gPj4+IFlvdXJzLA0KPiA+Pj4gSm9lbA0KPiA+Pj4N Cj4gPj4+IE9uIDEyLzE4LzE4IDEwOjQ4IFBNLCBCcmlhbiBFIENhcnBlbnRlciB3cm90ZToNCj4g Pj4+PiBPbiAyMDE4LTEyLTE5IDE1OjQ2LCBKb2VsIE0uIEhhbHBlcm4gd3JvdGU6DQo+ID4+Pj4+ IFRoaXMgaXMgcGFydCBvZiB0aGUgcGFja2FnZSB0byBtb3ZlIHRoZSBjb2hlcmVudCBzZXQgb2Yg YmFzZSBMSVNQIHNwZWNzDQo+ID4+Pj4+IHRvIFBTLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBUaGUgcmVh c29uIHdlIGRpZCB0aGlzIHJhdGhlciB0aGFuIGZvbGRpbmcgaXQgaW50byA2ODMwYmlzIC8gNjgz M2JpcyBpcw0KPiA+Pj4+PiB0aGF0IHdlIGhhZCBvcmlnaW5hbGx5IHNpbXBseSBjaXRlZCA4MTEz LCBhbmQgdGhlbiByZWFsaXplZCB0aGF0IG5lZWRlZA0KPiA+Pj4+PiB0byBtb3ZlIHRvIFBTIGFs b25nIHdpdGggZXZlcnl0aGluZyBlbHNlLiAgSXQgc2VlbWVkIChhbmQgaXMpIHNpbXBsZXINCj4g dG8NCj4gPj4+Pj4gZG8gaXQgc2VwYXJhdGVseSByYXRoZXIgdGhhbiB0byBmdXJ0aGVyIG1vZGlm eSA2ODMwYmlzIC8gNjkzM2Jpcy4NCj4gPj4+Pj4NCj4gPj4+Pj4gQXMgZm9yIHdoeSBpdCB1cGRh dGVzIDY4MzNiaXMsIHRoYXQgaXMgYmVjYXVzZSBvbmUgb2YgdGhlIGNhaG5nZXMgaW4NCj4gPj4+ Pj4gbW92aW5nIHRoZSBzZXQgdG8gUFMgd2FzIHRvIGltcHJvdmUgdGhlIHNwbGl0IGFzIHRvIHdo aWNoIGluZm9ybWF0aW9uDQo+ID4+Pj4+IGJlbG9uZ2VkIGluIHdoaWNoIGRvY3VtZW50Lg0KPiA+ Pj4+IE9LLCBidXQgSSBzdGlsbCBkb24ndCBmaW5kIGl0IGxvZ2ljYWwgVGhlIHRleHQgZG9lc24n dCBleHBsYWluIHdoaWNoDQo+IHBhcnQgb2YNCj4gPj4+PiA2ODMzYmlzIGlzIGltcGFjdGVkLCBh bmQgbm9ybWFsbHkgdGhlc2UgZGF5cyB3ZSByZXF1aXJlIHN1Y2ggYW4NCj4gZXhwbGFuYXRpb24u DQo+ID4+Pj4gQW5kIGlmIHRoZXJlIGlzIGFuIGltcGFjdCwgeW91J3JlIG1pc3NpbmcgdGhlIG9w cG9ydHVuaXR5IG9mIGZpeGluZyB0aGUNCj4gZXJyb3INCj4gPj4+PiBvciBnYXAgaW4gNjgzM2Jp cywgc28gdGhlIHJlYWRlciBvZiA2ODMzYmlzIHdpbGwgYmUgbm9uZSB0aGUgd2lzZXINCj4gdW5s ZXNzDQo+ID4+Pj4geW91IGluc2VydCBhIHJlZmVyZW5jZSB0byA4MTEzYmlzLg0KPiA+Pj4+IE9u IHRoZSBvdGhlciBoYW5kLCBpZiB0aGVyZSBpcyBubyBlcnJvciBvciBnYXAsIHlvdSBkb24ndCBu ZWVkDQo+ICJVcGRhdGVzOiINCj4gPj4+PiBhdCBhbGwuIChVbmZvcnR1bmF0ZWx5LCB3ZSBkb24n dCBoYXZlIGFuICJFeHRlbmRzOiIgaGVhZGVyLikNCj4gPj4+PiAgICBCcmlhbg0KPiA+Pj4+Pg0K PiA+Pj4+PiBZb3VycywNCj4gPj4+Pj4gSm9lbA0KPiA+Pj4+Pg0KPiA+Pj4+PiBPbiAxMi8xOC8x OCA5OjI1IFBNLCBCcmlhbiBDYXJwZW50ZXIgd3JvdGU6DQo+ID4+Pj4+PiBSZXZpZXdlcjogQnJp YW4gQ2FycGVudGVyDQo+ID4+Pj4+PiBSZXZpZXcgcmVzdWx0OiBSZWFkeSB3aXRoIElzc3Vlcw0K PiA+Pj4+Pj4NCj4gPj4+Pj4+IEdlbi1BUlQgTGFzdCBDYWxsIHJldmlldyBvZiBkcmFmdC1pZXRm LWxpc3AtcmZjODExM2Jpcy0wMQ0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IEkgYW0gdGhlIGFzc2lnbmVk IEdlbi1BUlQgcmV2aWV3ZXIgZm9yIHRoaXMgZHJhZnQuIFRoZSBHZW5lcmFsIEFyZWENCj4gPj4+ Pj4+IFJldmlldyBUZWFtIChHZW4tQVJUKSByZXZpZXdzIGFsbCBJRVRGIGRvY3VtZW50cyBiZWlu ZyBwcm9jZXNzZWQNCj4gPj4+Pj4+IGJ5IHRoZSBJRVNHIGZvciB0aGUgSUVURiBDaGFpci4gIFBs ZWFzZSB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0DQo+ID4+Pj4+PiBsaWtlIGFueSBvdGhlciBs YXN0IGNhbGwgY29tbWVudHMuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gRm9yIG1vcmUgaW5mb3JtYXRp b24sIHBsZWFzZSBzZWUgdGhlIEZBUSBhdA0KPiA+Pj4+Pj4gPGh0dHA6Ly93aWtpLnRvb2xzLmll dGYub3JnL2FyZWEvZ2VuL3RyYWMvd2lraS9HZW5BcnRmYXE+Lg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+ IERvY3VtZW50OiBkcmFmdC1pZXRmLWxpc3AtcmZjODExM2Jpcy0wMS50eHQNCj4gPj4+Pj4+IFJl dmlld2VyOiBCcmlhbiBDYXJwZW50ZXINCj4gPj4+Pj4+IFJldmlldyBEYXRlOiAyMDE4LTEyLTE5 DQo+ID4+Pj4+PiBJRVRGIExDIEVuZCBEYXRlOiAyMDE4LTEyLTI3DQo+ID4+Pj4+PiBJRVNHIFRl bGVjaGF0IGRhdGU6DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gU3VtbWFyeTogUmVhZHkgd2l0aCBpc3N1 ZXMNCj4gPj4+Pj4+IC0tLS0tLS0tDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gQ29tbWVudHM6DQo+ID4+ Pj4+PiAtLS0tLS0tLS0NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBJIG5vdGUgdGhhdCB0aGlzIGlzIGJl aW5nIHJhaXNlZCBmcm9tIEV4cGVyaW1lbnRhbCB0byB0aGUgc3RhbmRhcmRzDQo+IHRyYWNrLg0K PiA+Pj4+Pj4gUHJlc3VtYWJseSB0aGF0IGRlcGVuZHMgb24gdGhlIGJhc2UgTElTUCBzcGVjIGJl Y29taW5nIFBTLg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IE1pbm9yIGlzc3VlczoNCj4gPj4+Pj4+IC0t LS0tLS0tLS0tLS0NCj4gPj4+Pj4+DQo+ID4+Pj4+PiAiVGhpcyBkb2N1bWVudCB1cGRhdGVzIEkt RC5pZXRmLWxpc3AtcmZjNjgzM2Jpcy4iIFRoZSB0ZXh0IGRvZXNuJ3QNCj4gPj4+Pj4+IGV4cGxh aW4gd2hpY2ggdGV4dCBpcyB1cGRhdGVkLiBUaGlzIGlzIGluIGNvbnRyYXN0IHRvIFJGQzgxMTMs IHdoaWNoDQo+ID4+Pj4+PiBleHBsYWlucyBjbGVhcmx5IGhvdyBpdCB1cGRhdGVzIFJGQzY4MzAg KCpub3QqIFJGQzY4MzMpLiBXaHkgZG9lc24ndA0KPiA+Pj4+Pj4gdGhpcyBkcmFmdCBjbGFpbSB0 byB1cGRhdGUgcmZjNjgzMGJpcz8gSSdtIGdvaW5nIHRvIGFzc3VtZSB0aGF0DQo+ID4+Pj4+PiBp cyBhbiBlcnJvci4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBJbiBmYWN0LCB3aHkgd2Fzbid0IHRoZSBk ZWZpbml0aW9uIG9mIHRoZSBMSVNQIFBhY2tldCBUeXBlcyByZWdpc3RyeQ0KPiA+Pj4+Pj4gbW92 ZWQgaW50byB0aGUgYmFzZSBzcGVjIChyZmM2ODMwYmlzKT8gVGhhdCBpcyB3aGVyZSBpdCBiZWxv bmdzLg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IFNpbmNlIHJmYzY4MzBiaXMgKGFuZCByZmM2ODMzYmlz KSBhcmUgc3RpbGwgdW5kZXIgSUVTRyByZXZpZXcsDQo+IGFueXRoaW5nDQo+ID4+Pj4+PiBpbiB0 aGVtIHRoYXQgbmVlZHMgdXBkYXRpbmcgc2hvdWxkIGJlIHVwZGF0ZWQhIFRoZSBmYWN0IGlzIHRo YXQNCj4gcmZjODExM2Jpcw0KPiA+Pj4+Pj4gZXh0ZW5kcyByZmM2ODMwYmlzLCB3aGljaCBpcyBu b3QgdGhlIHNhbWUgdGhpbmcgYXMgInVwZGF0ZXMiLg0KPiA+Pj4+Pj4gSWYgdGhlIFdHIHRoaW5r cyB0aGF0IGltcGxlbWVudGVycyBvZiA2ODMwYmlzIG5lZWQgdG8gcmVhZCA4MTEzYmlzLA0KPiA+ Pj4+Pj4gdGhlcmUgc2hvdWxkIGJlIGEgbm9ybWF0aXZlIHJlZmVyZW5jZSBpbiA2ODMwYmlzIHRv IDgxMTNiaXMuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4NCj4gPj4+Pj4NCj4gPj4+DQo+ID4+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4gbGlzcCBt YWlsaW5nIGxpc3QNCj4gPj4+IGxpc3BAaWV0Zi5vcmcNCj4gPj4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbGlzcA0KDQo= From nobody Wed Dec 19 09:58:22 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE371130EC9; Wed, 19 Dec 2018 09:58:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 3v06sUWu6VsK; Wed, 19 Dec 2018 09:57:59 -0800 (PST) Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CAB9130EB3; Wed, 19 Dec 2018 09:57:59 -0800 (PST) Received: by mail-pg1-x52a.google.com with SMTP id m1so8135910pgq.8; Wed, 19 Dec 2018 09:57:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9AcUAZsDUjH9Xl1LX07WZ14N3mLVXzqN1h4fMUZCrkk=; b=llx+SGX0lctGNNKvBZcBDZuhHkOV7wnS+xwKIHVQL3rxwb4Gb3glthEHY4x06rWubU RVdBNIVhqBCiKyIKqiKICJVWaOTkiV+CQZ2Bixp14HL3pBbU5dGHGVsuV9C6KRFko48g 2m9ouYYdzuU1ILhVhVLi5TV9496zb2jjt5DN6dLEuVkNqltK5F0NPD6Qm+KnzYHtRg5T 9a+a37P/5lJTvagG8OZUnNThqLLa3ED1W6MqiIPWx3BaCOJy8JfdYGa2KovWN0WHGFKQ xvTpX/HWJU9hJlsI0cUZXqSBNlyXVPyXRgDdjbfd/yhVHJewig7Ba2KpQc5idg4vTlb4 Ktsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9AcUAZsDUjH9Xl1LX07WZ14N3mLVXzqN1h4fMUZCrkk=; b=jbfUkyw+evAqQJHkK7nkUfVJAhWCV6tPt/dxHVaAK9raAUpZod/WL9zXZMel5fIoRV qhdhUKfdhuE/qqUgvlDLuv/8JXOakNt2es1sTSNtSbCBafu9a8Wfij1UVTJU22yr8+UF /APMMqjs7oXOpni8iy1VHPK5NELboJjvv52f0WGvQAn8wUahLqiJ+paOufEFUn0lSsAq nQHLFvsXVa0mezHMiMPuA5iMt7EddSlPOi+75r4THdSpLQ5s8xmb5hMttxpluJ0l3YB5 0b+K3y/jltl2uEgi/fBnRktSzWv+3Lj3ltw/kalb6JxJOO0MhCLCELBSfze8jP0TpRXb FqDA== X-Gm-Message-State: AA+aEWbaMPwy3k7WnN9r9Q2ifcuzU2js/CPyIGPqxipo3ZYid0aoGlZX YN/oSOyAlSAktI359yI9vYg= X-Google-Smtp-Source: AFSGD/U+j6Xt9Si3Cv05u1OTxw54Hg4DrqnnDNYaDO4Vkt3X+RRamJC8zk11IU6N2aNIniVoNWFOHw== X-Received: by 2002:a63:5723:: with SMTP id l35mr11374152pgb.228.1545242278837; Wed, 19 Dec 2018 09:57:58 -0800 (PST) Received: from [10.31.79.215] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id v62sm32539011pfd.163.2018.12.19.09.57.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Dec 2018 09:57:57 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: <2032D0A3-7BC0-4D22-B5A8-DCD021EB0E88@gigix.net> Date: Wed, 19 Dec 2018 09:57:56 -0800 Cc: "Joel M. Halpern" , Brian E Carpenter , gen-art@ietf.org, lisp@ietf.org, draft-ietf-lisp-rfc8113bis.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <154518630870.5131.10104452678736081639@ietfa.amsl.com> <407BD77D-F364-4989-A6D2-C75DF9914402@gmail.com> <9cc58af9-2bcf-89d7-a2ae-3fc80e723d78@joelhalpern.com> <2032D0A3-7BC0-4D22-B5A8-DCD021EB0E88@gigix.net> To: Luigi Iannone X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01 X-BeenThere: lisp@ietf.org 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: Wed, 19 Dec 2018 17:58:13 -0000 > IMHO we just drop the =E2=80=9Cupdate 6833bis=E2=80=9D and we are = fine. I agree. Dino From nobody Wed Dec 19 10:00:18 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D5CC130E86; Wed, 19 Dec 2018 10:00:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 PhWLkhZmw3lu; Wed, 19 Dec 2018 10:00:08 -0800 (PST) Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCFE5130E95; Wed, 19 Dec 2018 10:00:07 -0800 (PST) Received: by mail-pf1-x42c.google.com with SMTP id r136so3116465pfc.6; Wed, 19 Dec 2018 10:00:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=frrJncUTF5SqXktto9o+VAuiFlrM6b9BO6/GadLvYWk=; b=vNbg9g5n2leH9Nvzmia/FeScahK46snKb/PrmKQBlj/MQv4NsZ2Ey2+gichrVW63jh otAGov/5B9ULziSGitJvZIVpKYs5+UITklrxYqtGge8mrLPQgqW2ne/yaKknAifN8ySM yPQbc+AysKAO7PYLeaFnsQKleua3UfVpcZCKa9vZ9DtH86mXuLij6zRkCJwhxxtYU8fQ DyjEgWu1EhMXBg6neF0QHZLfFnonL+MYKhztQuZvgg+r5Sxc/p5thJVcIXkHf3wuRXGs 40G8RmJuDMfAW1sUh1bjpT52RTbLgC2Gt9iHyLMQ+X88Ti3808ZMLzzvHh8fSmWXfVTI ao6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=frrJncUTF5SqXktto9o+VAuiFlrM6b9BO6/GadLvYWk=; b=YArzTEu3smWZg33PLEJpqi2oYeooTVfuRtcoL+ddktGq6C0qOdY957Ud16vH+yT/ab F5rbKhpQkbJiACX6/EyeLvcHabQBufhwE1/PaM9igxcQ0KVoUeiuHNpmKEocLE/0eiNL v0LTFC6WrMdbvgM89P/1reqWYk8pQWmLVxBCkauXX3HA+mVW9kmhZJwpUToApyEk5ZR4 67JHlGmggDle2xYRFAGiBG5t06ojwUvhoGoXKFSUTJulTDo3OlkWJXva6vEAZw37G4hw CwjbKSNwv8xiG6UCb1kOyRyPbreZgCfAmRrb/AGnhfRnjS4lDniUBMc/J1PqP3LeXdIE WJjg== X-Gm-Message-State: AA+aEWZEA0VK0Frw3HRPVdKkD1NVIkyZBd5zeFxcfVat1a0vELJZHEBz Bv+ycJQHWgTGbyqqsGguptM= X-Google-Smtp-Source: AFSGD/WdLO39YYknd+RYM50glQHgY2JdenC1Ul1qQ9Xi70j3LhnNa7j6QTmlDioiK7M4ZwtoT5TDEA== X-Received: by 2002:a63:6cc:: with SMTP id 195mr20351697pgg.401.1545242407379; Wed, 19 Dec 2018 10:00:07 -0800 (PST) Received: from [10.31.79.215] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id m3sm32343463pff.173.2018.12.19.10.00.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Dec 2018 10:00:06 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: <787AE7BB302AE849A7480A190F8B93302E05D7D4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Wed, 19 Dec 2018 10:00:05 -0800 Cc: "Joel M. Halpern" , Brian E Carpenter , "gen-art@ietf.org" , "lisp@ietf.org" , "draft-ietf-lisp-rfc8113bis.all@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <154518630870.5131.10104452678736081639@ietfa.amsl.com> <407BD77D-F364-4989-A6D2-C75DF9914402@gmail.com> <9cc58af9-2bcf-89d7-a2ae-3fc80e723d78@joelhalpern.com> <787AE7BB302AE849A7480A190F8B93302E05D7D4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> To: mohamed.boucadair@orange.com X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01 X-BeenThere: lisp@ietf.org 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: Wed, 19 Dec 2018 18:00:11 -0000 What does fixing in (1) mean? Dino > On Dec 19, 2018, at 3:51 AM, = wrote: >=20 > Hi all,=20 >=20 > Brian, whether to maintain the document standalone was discussed by = the WG. You may refer, for example, to the message from Deborah which = clarifies this point: = https://www.ietf.org/mail-archive/web/lisp/current/msg07886.html. One of = the outcomes of that discussion is to add an "updates" header to = 8113bis. >=20 > FWIW, one of the issues that led to that conclusion was whether to = cite rfc8113bis as normative in 6833bis (the approach I initially = supported) and agreed by Dino = (https://www.ietf.org/mail-archive/web/lisp/current/msg07882.html). = Deborah convinced me that citing 8113bis will lead to circular = dependency. Which is a fair argument.=20 >=20 > The "updates" tag was justified as follows: >=20 > (1) >=20 > RFC6833bis includes the following: >=20 > Values in the "Not Assigned" range can be assigned according to > procedures in [RFC8126]. >=20 > That text is updated by RFC8113bis to be aligned with 8113:=20 >=20 > Values can be assigned via Standards Action >=20 > (2)=20 >=20 > RFC8113bis extends the type field to grab more bits/values when the = available types are exhausted. This is captured in 8113bis: >=20 > The values in the range 0-1023 are assigned via Standards Action. > This range is provisioned to anticipate, in particular, the > exhaustion of the LISP Packet types. >=20 > Dino: If (1) is fixed directly in RFC6833bis, then I'm fine to remove = the "updates" header because (2) can be also seen as an extension.=20 >=20 > Cheers, > Med >=20 >> -----Message d'origine----- >> De : Dino Farinacci [mailto:farinacci@gmail.com] >> Envoy=C3=A9 : mercredi 19 d=C3=A9cembre 2018 06:37 >> =C3=80 : Joel M. Halpern >> Cc : Brian E Carpenter; gen-art@ietf.org; lisp@ietf.org; = draft-ietf-lisp- >> rfc8113bis.all@ietf.org >> Objet : Re: [lisp] Genart last call review of = draft-ietf-lisp-rfc8113bis-01 >>=20 >> Mohmad to comment. >>=20 >> Dino >>=20 >>> On Dec 18, 2018, at 8:49 PM, Joel M. Halpern = wrote: >>>=20 >>> That is the other fix he offered. Just remove the updates tag. >>> I will leav eit to you and the the authors to determine which is = correct. >>> Yours, >>> Joel >>>=20 >>> On 12/18/18 11:43 PM, Dino Farinacci wrote: >>>> 8113bis should say that is it *extending* the type field so we can = have >> more types. The word =E2=80=9Cupdate=E2=80=9D I always had a problem = with because it can be >> interpreted as =E2=80=9Creplacing". Replacing something to fix a = problem. >>>> 8113 is simply asking for one of the type value codepoint, so there = can be >> another format to have more types. >>>> Dino >>>>> On Dec 18, 2018, at 9:24 PM, Joel M. Halpern = wrote: >>>>>=20 >>>>> Authors: that sounds like a reasonable addition to me? >>>>>=20 >>>>> Yours, >>>>> Joel >>>>>=20 >>>>> On 12/18/18 10:48 PM, Brian E Carpenter wrote: >>>>>> On 2018-12-19 15:46, Joel M. Halpern wrote: >>>>>>> This is part of the package to move the coherent set of base = LISP specs >>>>>>> to PS. >>>>>>>=20 >>>>>>> The reason we did this rather than folding it into 6830bis / = 6833bis is >>>>>>> that we had originally simply cited 8113, and then realized that = needed >>>>>>> to move to PS along with everything else. It seemed (and is) = simpler >> to >>>>>>> do it separately rather than to further modify 6830bis / = 6933bis. >>>>>>>=20 >>>>>>> As for why it updates 6833bis, that is because one of the = cahnges in >>>>>>> moving the set to PS was to improve the split as to which = information >>>>>>> belonged in which document. >>>>>> OK, but I still don't find it logical The text doesn't explain = which >> part of >>>>>> 6833bis is impacted, and normally these days we require such an >> explanation. >>>>>> And if there is an impact, you're missing the opportunity of = fixing the >> error >>>>>> or gap in 6833bis, so the reader of 6833bis will be none the = wiser >> unless >>>>>> you insert a reference to 8113bis. >>>>>> On the other hand, if there is no error or gap, you don't need >> "Updates:" >>>>>> at all. (Unfortunately, we don't have an "Extends:" header.) >>>>>> Brian >>>>>>>=20 >>>>>>> Yours, >>>>>>> Joel >>>>>>>=20 >>>>>>> On 12/18/18 9:25 PM, Brian Carpenter wrote: >>>>>>>> Reviewer: Brian Carpenter >>>>>>>> Review result: Ready with Issues >>>>>>>>=20 >>>>>>>> Gen-ART Last Call review of draft-ietf-lisp-rfc8113bis-01 >>>>>>>>=20 >>>>>>>> I am the assigned Gen-ART reviewer for this draft. The General = Area >>>>>>>> Review Team (Gen-ART) reviews all IETF documents being = processed >>>>>>>> by the IESG for the IETF Chair. Please treat these comments = just >>>>>>>> like any other last call comments. >>>>>>>>=20 >>>>>>>> For more information, please see the FAQ at >>>>>>>> . >>>>>>>>=20 >>>>>>>> Document: draft-ietf-lisp-rfc8113bis-01.txt >>>>>>>> Reviewer: Brian Carpenter >>>>>>>> Review Date: 2018-12-19 >>>>>>>> IETF LC End Date: 2018-12-27 >>>>>>>> IESG Telechat date: >>>>>>>>=20 >>>>>>>> Summary: Ready with issues >>>>>>>> -------- >>>>>>>>=20 >>>>>>>> Comments: >>>>>>>> --------- >>>>>>>>=20 >>>>>>>> I note that this is being raised from Experimental to the = standards >> track. >>>>>>>> Presumably that depends on the base LISP spec becoming PS. >>>>>>>>=20 >>>>>>>> Minor issues: >>>>>>>> ------------- >>>>>>>>=20 >>>>>>>> "This document updates I-D.ietf-lisp-rfc6833bis." The text = doesn't >>>>>>>> explain which text is updated. This is in contrast to RFC8113, = which >>>>>>>> explains clearly how it updates RFC6830 (*not* RFC6833). Why = doesn't >>>>>>>> this draft claim to update rfc6830bis? I'm going to assume that >>>>>>>> is an error. >>>>>>>>=20 >>>>>>>> In fact, why wasn't the definition of the LISP Packet Types = registry >>>>>>>> moved into the base spec (rfc6830bis)? That is where it = belongs. >>>>>>>>=20 >>>>>>>> Since rfc6830bis (and rfc6833bis) are still under IESG review, >> anything >>>>>>>> in them that needs updating should be updated! The fact is that >> rfc8113bis >>>>>>>> extends rfc6830bis, which is not the same thing as "updates". >>>>>>>> If the WG thinks that implementers of 6830bis need to read = 8113bis, >>>>>>>> there should be a normative reference in 6830bis to 8113bis. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> lisp mailing list >>>>> lisp@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/lisp >=20 From nobody Wed Dec 19 23:35:50 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BBA21310A2; Wed, 19 Dec 2018 23:35:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 az1oFK9gh6K2; Wed, 19 Dec 2018 23:35:46 -0800 (PST) Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8139213109F; Wed, 19 Dec 2018 23:35:46 -0800 (PST) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 43L3TF01rJz20fQ; Thu, 20 Dec 2018 08:35:45 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.24]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 43L3TD6CXgzFpXT; Thu, 20 Dec 2018 08:35:44 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7D.corporate.adroot.infra.ftgroup ([fe80::9044:c5ee:4dd2:4f16%19]) with mapi id 14.03.0415.000; Thu, 20 Dec 2018 08:35:44 +0100 From: To: Dino Farinacci CC: "Joel M. Halpern" , Brian E Carpenter , "gen-art@ietf.org" , "lisp@ietf.org" , "draft-ietf-lisp-rfc8113bis.all@ietf.org" Thread-Topic: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01 Thread-Index: AQHUl8SrGurFpIpzE0eaxl1ntjJuYKWHPS/w Date: Thu, 20 Dec 2018 07:35:43 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302E05E137@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <154518630870.5131.10104452678736081639@ietfa.amsl.com> <407BD77D-F364-4989-A6D2-C75DF9914402@gmail.com> <9cc58af9-2bcf-89d7-a2ae-3fc80e723d78@joelhalpern.com> <787AE7BB302AE849A7480A190F8B93302E05D7D4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01 X-BeenThere: lisp@ietf.org 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: Thu, 20 Dec 2018 07:35:50 -0000 SGkgRGlubywgDQoNCk9MRDogDQoNCiAgIFZhbHVlcyBpbiB0aGUgIk5vdCBBc3NpZ25lZCIgcmFu Z2UgY2FuIGJlIGFzc2lnbmVkIGFjY29yZGluZyB0bw0KICAgcHJvY2VkdXJlcyBpbiBbUkZDODEy Nl0uDQoNCk5FVzoNCg0KICAgVmFsdWVzIGluIHRoZSAiTm90IEFzc2lnbmVkIiByYW5nZSBjYW4g YmUgYXNzaWduZWQgdmlhIFN0YW5kYXJkcw0KICAgQWN0aW9uIFtSRkM4MTEzXS4NCg0KQ2hlZXJz LA0KTWVkDQoNCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IERpbm8gRmFy aW5hY2NpIFttYWlsdG86ZmFyaW5hY2NpQGdtYWlsLmNvbV0NCj4gRW52b3nDqcKgOiBtZXJjcmVk aSAxOSBkw6ljZW1icmUgMjAxOCAxOTowMA0KPiDDgMKgOiBCT1VDQURBSVIgTW9oYW1lZCBUR0kv T0xODQo+IENjwqA6IEpvZWwgTS4gSGFscGVybjsgQnJpYW4gRSBDYXJwZW50ZXI7IGdlbi1hcnRA aWV0Zi5vcmc7IGxpc3BAaWV0Zi5vcmc7DQo+IGRyYWZ0LWlldGYtbGlzcC1yZmM4MTEzYmlzLmFs bEBpZXRmLm9yZw0KPiBPYmpldMKgOiBSZTogW2xpc3BdIEdlbmFydCBsYXN0IGNhbGwgcmV2aWV3 IG9mIGRyYWZ0LWlldGYtbGlzcC1yZmM4MTEzYmlzLTAxDQo+IA0KPiBXaGF0IGRvZXMgZml4aW5n IGluICgxKSBtZWFuPw0KPiANCj4gRGlubw0KPiANCj4gPiBPbiBEZWMgMTksIDIwMTgsIGF0IDM6 NTEgQU0sIDxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPg0KPiA8bW9oYW1lZC5ib3VjYWRh aXJAb3JhbmdlLmNvbT4gd3JvdGU6DQo+ID4NCj4gPiBIaSBhbGwsDQo+ID4NCj4gPiBCcmlhbiwg d2hldGhlciB0byBtYWludGFpbiB0aGUgZG9jdW1lbnQgc3RhbmRhbG9uZSB3YXMgZGlzY3Vzc2Vk IGJ5IHRoZSBXRy4NCj4gWW91IG1heSByZWZlciwgZm9yIGV4YW1wbGUsIHRvIHRoZSBtZXNzYWdl IGZyb20gRGVib3JhaCB3aGljaCBjbGFyaWZpZXMgdGhpcw0KPiBwb2ludDogaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9saXNwL2N1cnJlbnQvbXNnMDc4ODYuaHRtbC4gT25l DQo+IG9mIHRoZSBvdXRjb21lcyBvZiB0aGF0IGRpc2N1c3Npb24gaXMgdG8gYWRkIGFuICJ1cGRh dGVzIiBoZWFkZXIgdG8gODExM2Jpcy4NCj4gPg0KPiA+IEZXSVcsIG9uZSBvZiB0aGUgaXNzdWVz IHRoYXQgbGVkIHRvIHRoYXQgY29uY2x1c2lvbiB3YXMgd2hldGhlciB0byBjaXRlDQo+IHJmYzgx MTNiaXMgYXMgbm9ybWF0aXZlIGluIDY4MzNiaXMgKHRoZSBhcHByb2FjaCBJIGluaXRpYWxseSBz dXBwb3J0ZWQpIGFuZA0KPiBhZ3JlZWQgYnkgRGlubyAoaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bC0NCj4gYXJjaGl2ZS93ZWIvbGlzcC9jdXJyZW50L21zZzA3ODgyLmh0bWwpLiBEZWJvcmFoIGNv bnZpbmNlZCBtZSB0aGF0IGNpdGluZw0KPiA4MTEzYmlzIHdpbGwgbGVhZCB0byBjaXJjdWxhciBk ZXBlbmRlbmN5LiBXaGljaCBpcyBhIGZhaXIgYXJndW1lbnQuDQo+ID4NCj4gPiBUaGUgInVwZGF0 ZXMiIHRhZyB3YXMganVzdGlmaWVkIGFzIGZvbGxvd3M6DQo+ID4NCj4gPiAoMSkNCj4gPg0KPiA+ IFJGQzY4MzNiaXMgaW5jbHVkZXMgdGhlIGZvbGxvd2luZzoNCj4gPg0KPiA+ICAgVmFsdWVzIGlu IHRoZSAiTm90IEFzc2lnbmVkIiByYW5nZSBjYW4gYmUgYXNzaWduZWQgYWNjb3JkaW5nIHRvDQo+ ID4gICBwcm9jZWR1cmVzIGluIFtSRkM4MTI2XS4NCj4gPg0KPiA+IFRoYXQgdGV4dCBpcyB1cGRh dGVkIGJ5IFJGQzgxMTNiaXMgdG8gYmUgYWxpZ25lZCB3aXRoIDgxMTM6DQo+ID4NCj4gPiAgIFZh bHVlcyBjYW4gYmUgYXNzaWduZWQgdmlhIFN0YW5kYXJkcyBBY3Rpb24NCj4gPg0KPiA+ICgyKQ0K PiA+DQo+ID4gUkZDODExM2JpcyBleHRlbmRzIHRoZSB0eXBlIGZpZWxkIHRvIGdyYWIgbW9yZSBi aXRzL3ZhbHVlcyB3aGVuIHRoZQ0KPiBhdmFpbGFibGUgdHlwZXMgYXJlIGV4aGF1c3RlZC4gVGhp cyBpcyBjYXB0dXJlZCBpbiA4MTEzYmlzOg0KPiA+DQo+ID4gICBUaGUgdmFsdWVzIGluIHRoZSBy YW5nZSAwLTEwMjMgYXJlIGFzc2lnbmVkIHZpYSBTdGFuZGFyZHMgQWN0aW9uLg0KPiA+ICAgVGhp cyByYW5nZSBpcyBwcm92aXNpb25lZCB0byBhbnRpY2lwYXRlLCBpbiBwYXJ0aWN1bGFyLCB0aGUN Cj4gPiAgIGV4aGF1c3Rpb24gb2YgdGhlIExJU1AgUGFja2V0IHR5cGVzLg0KPiA+DQo+ID4gRGlu bzogSWYgKDEpIGlzIGZpeGVkIGRpcmVjdGx5IGluIFJGQzY4MzNiaXMsIHRoZW4gSSdtIGZpbmUg dG8gcmVtb3ZlIHRoZQ0KPiAidXBkYXRlcyIgaGVhZGVyIGJlY2F1c2UgKDIpIGNhbiBiZSBhbHNv IHNlZW4gYXMgYW4gZXh0ZW5zaW9uLg0KPiA+DQo+ID4gQ2hlZXJzLA0KPiA+IE1lZA0KPiA+DQo+ ID4+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiA+PiBEZSA6IERpbm8gRmFyaW5hY2Np IFttYWlsdG86ZmFyaW5hY2NpQGdtYWlsLmNvbV0NCj4gPj4gRW52b3nDqSA6IG1lcmNyZWRpIDE5 IGTDqWNlbWJyZSAyMDE4IDA2OjM3DQo+ID4+IMOAIDogSm9lbCBNLiBIYWxwZXJuDQo+ID4+IENj IDogQnJpYW4gRSBDYXJwZW50ZXI7IGdlbi1hcnRAaWV0Zi5vcmc7IGxpc3BAaWV0Zi5vcmc7IGRy YWZ0LWlldGYtbGlzcC0NCj4gPj4gcmZjODExM2Jpcy5hbGxAaWV0Zi5vcmcNCj4gPj4gT2JqZXQg OiBSZTogW2xpc3BdIEdlbmFydCBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtbGlzcC1y ZmM4MTEzYmlzLQ0KPiAwMQ0KPiA+Pg0KPiA+PiBNb2htYWQgdG8gY29tbWVudC4NCj4gPj4NCj4g Pj4gRGlubw0KPiA+Pg0KPiA+Pj4gT24gRGVjIDE4LCAyMDE4LCBhdCA4OjQ5IFBNLCBKb2VsIE0u IEhhbHBlcm4gPGptaEBqb2VsaGFscGVybi5jb20+IHdyb3RlOg0KPiA+Pj4NCj4gPj4+IFRoYXQg aXMgdGhlIG90aGVyIGZpeCBoZSBvZmZlcmVkLiAgSnVzdCByZW1vdmUgdGhlIHVwZGF0ZXMgdGFn Lg0KPiA+Pj4gSSB3aWxsIGxlYXYgZWl0IHRvIHlvdSBhbmQgdGhlIHRoZSBhdXRob3JzIHRvIGRl dGVybWluZSB3aGljaCBpcyBjb3JyZWN0Lg0KPiA+Pj4gWW91cnMsDQo+ID4+PiBKb2VsDQo+ID4+ Pg0KPiA+Pj4gT24gMTIvMTgvMTggMTE6NDMgUE0sIERpbm8gRmFyaW5hY2NpIHdyb3RlOg0KPiA+ Pj4+IDgxMTNiaXMgc2hvdWxkIHNheSB0aGF0IGlzIGl0ICpleHRlbmRpbmcqIHRoZSB0eXBlIGZp ZWxkIHNvIHdlIGNhbiBoYXZlDQo+ID4+IG1vcmUgdHlwZXMuIFRoZSB3b3JkIOKAnHVwZGF0ZeKA nSBJIGFsd2F5cyBoYWQgYSBwcm9ibGVtIHdpdGggYmVjYXVzZSBpdCBjYW4NCj4gYmUNCj4gPj4g aW50ZXJwcmV0ZWQgYXMg4oCccmVwbGFjaW5nIi4gUmVwbGFjaW5nIHNvbWV0aGluZyB0byBmaXgg YSBwcm9ibGVtLg0KPiA+Pj4+IDgxMTMgaXMgc2ltcGx5IGFza2luZyBmb3Igb25lIG9mIHRoZSB0 eXBlIHZhbHVlIGNvZGVwb2ludCwgc28gdGhlcmUgY2FuDQo+IGJlDQo+ID4+IGFub3RoZXIgZm9y bWF0IHRvIGhhdmUgbW9yZSB0eXBlcy4NCj4gPj4+PiBEaW5vDQo+ID4+Pj4+IE9uIERlYyAxOCwg MjAxOCwgYXQgOToyNCBQTSwgSm9lbCBNLiBIYWxwZXJuIDxqbWhAam9lbGhhbHBlcm4uY29tPg0K PiB3cm90ZToNCj4gPj4+Pj4NCj4gPj4+Pj4gQXV0aG9yczogdGhhdCBzb3VuZHMgbGlrZSBhIHJl YXNvbmFibGUgYWRkaXRpb24gdG8gbWU/DQo+ID4+Pj4+DQo+ID4+Pj4+IFlvdXJzLA0KPiA+Pj4+ PiBKb2VsDQo+ID4+Pj4+DQo+ID4+Pj4+IE9uIDEyLzE4LzE4IDEwOjQ4IFBNLCBCcmlhbiBFIENh cnBlbnRlciB3cm90ZToNCj4gPj4+Pj4+IE9uIDIwMTgtMTItMTkgMTU6NDYsIEpvZWwgTS4gSGFs cGVybiB3cm90ZToNCj4gPj4+Pj4+PiBUaGlzIGlzIHBhcnQgb2YgdGhlIHBhY2thZ2UgdG8gbW92 ZSB0aGUgY29oZXJlbnQgc2V0IG9mIGJhc2UgTElTUA0KPiBzcGVjcw0KPiA+Pj4+Pj4+IHRvIFBT Lg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gVGhlIHJlYXNvbiB3ZSBkaWQgdGhpcyByYXRoZXIgdGhh biBmb2xkaW5nIGl0IGludG8gNjgzMGJpcyAvIDY4MzNiaXMNCj4gaXMNCj4gPj4+Pj4+PiB0aGF0 IHdlIGhhZCBvcmlnaW5hbGx5IHNpbXBseSBjaXRlZCA4MTEzLCBhbmQgdGhlbiByZWFsaXplZCB0 aGF0DQo+IG5lZWRlZA0KPiA+Pj4+Pj4+IHRvIG1vdmUgdG8gUFMgYWxvbmcgd2l0aCBldmVyeXRo aW5nIGVsc2UuICBJdCBzZWVtZWQgKGFuZCBpcykgc2ltcGxlcg0KPiA+PiB0bw0KPiA+Pj4+Pj4+ IGRvIGl0IHNlcGFyYXRlbHkgcmF0aGVyIHRoYW4gdG8gZnVydGhlciBtb2RpZnkgNjgzMGJpcyAv IDY5MzNiaXMuDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiBBcyBmb3Igd2h5IGl0IHVwZGF0ZXMgNjgz M2JpcywgdGhhdCBpcyBiZWNhdXNlIG9uZSBvZiB0aGUgY2FobmdlcyBpbg0KPiA+Pj4+Pj4+IG1v dmluZyB0aGUgc2V0IHRvIFBTIHdhcyB0byBpbXByb3ZlIHRoZSBzcGxpdCBhcyB0byB3aGljaCBp bmZvcm1hdGlvbg0KPiA+Pj4+Pj4+IGJlbG9uZ2VkIGluIHdoaWNoIGRvY3VtZW50Lg0KPiA+Pj4+ Pj4gT0ssIGJ1dCBJIHN0aWxsIGRvbid0IGZpbmQgaXQgbG9naWNhbCBUaGUgdGV4dCBkb2Vzbid0 IGV4cGxhaW4gd2hpY2gNCj4gPj4gcGFydCBvZg0KPiA+Pj4+Pj4gNjgzM2JpcyBpcyBpbXBhY3Rl ZCwgYW5kIG5vcm1hbGx5IHRoZXNlIGRheXMgd2UgcmVxdWlyZSBzdWNoIGFuDQo+ID4+IGV4cGxh bmF0aW9uLg0KPiA+Pj4+Pj4gQW5kIGlmIHRoZXJlIGlzIGFuIGltcGFjdCwgeW91J3JlIG1pc3Np bmcgdGhlIG9wcG9ydHVuaXR5IG9mIGZpeGluZw0KPiB0aGUNCj4gPj4gZXJyb3INCj4gPj4+Pj4+ IG9yIGdhcCBpbiA2ODMzYmlzLCBzbyB0aGUgcmVhZGVyIG9mIDY4MzNiaXMgd2lsbCBiZSBub25l IHRoZSB3aXNlcg0KPiA+PiB1bmxlc3MNCj4gPj4+Pj4+IHlvdSBpbnNlcnQgYSByZWZlcmVuY2Ug dG8gODExM2Jpcy4NCj4gPj4+Pj4+IE9uIHRoZSBvdGhlciBoYW5kLCBpZiB0aGVyZSBpcyBubyBl cnJvciBvciBnYXAsIHlvdSBkb24ndCBuZWVkDQo+ID4+ICJVcGRhdGVzOiINCj4gPj4+Pj4+IGF0 IGFsbC4gKFVuZm9ydHVuYXRlbHksIHdlIGRvbid0IGhhdmUgYW4gIkV4dGVuZHM6IiBoZWFkZXIu KQ0KPiA+Pj4+Pj4gICBCcmlhbg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gWW91cnMsDQo+ID4+Pj4+ Pj4gSm9lbA0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gT24gMTIvMTgvMTggOToyNSBQTSwgQnJpYW4g Q2FycGVudGVyIHdyb3RlOg0KPiA+Pj4+Pj4+PiBSZXZpZXdlcjogQnJpYW4gQ2FycGVudGVyDQo+ ID4+Pj4+Pj4+IFJldmlldyByZXN1bHQ6IFJlYWR5IHdpdGggSXNzdWVzDQo+ID4+Pj4+Pj4+DQo+ ID4+Pj4+Pj4+IEdlbi1BUlQgTGFzdCBDYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLWxpc3AtcmZj ODExM2Jpcy0wMQ0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+PiBJIGFtIHRoZSBhc3NpZ25lZCBHZW4t QVJUIHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUgR2VuZXJhbCBBcmVhDQo+ID4+Pj4+Pj4+ IFJldmlldyBUZWFtIChHZW4tQVJUKSByZXZpZXdzIGFsbCBJRVRGIGRvY3VtZW50cyBiZWluZyBw cm9jZXNzZWQNCj4gPj4+Pj4+Pj4gYnkgdGhlIElFU0cgZm9yIHRoZSBJRVRGIENoYWlyLiAgUGxl YXNlIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3QNCj4gPj4+Pj4+Pj4gbGlrZSBhbnkgb3RoZXIg bGFzdCBjYWxsIGNvbW1lbnRzLg0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+PiBGb3IgbW9yZSBpbmZv cm1hdGlvbiwgcGxlYXNlIHNlZSB0aGUgRkFRIGF0DQo+ID4+Pj4+Pj4+IDxodHRwOi8vd2lraS50 b29scy5pZXRmLm9yZy9hcmVhL2dlbi90cmFjL3dpa2kvR2VuQXJ0ZmFxPi4NCj4gPj4+Pj4+Pj4N Cj4gPj4+Pj4+Pj4gRG9jdW1lbnQ6IGRyYWZ0LWlldGYtbGlzcC1yZmM4MTEzYmlzLTAxLnR4dA0K PiA+Pj4+Pj4+PiBSZXZpZXdlcjogQnJpYW4gQ2FycGVudGVyDQo+ID4+Pj4+Pj4+IFJldmlldyBE YXRlOiAyMDE4LTEyLTE5DQo+ID4+Pj4+Pj4+IElFVEYgTEMgRW5kIERhdGU6IDIwMTgtMTItMjcN Cj4gPj4+Pj4+Pj4gSUVTRyBUZWxlY2hhdCBkYXRlOg0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+PiBT dW1tYXJ5OiBSZWFkeSB3aXRoIGlzc3Vlcw0KPiA+Pj4+Pj4+PiAtLS0tLS0tLQ0KPiA+Pj4+Pj4+ Pg0KPiA+Pj4+Pj4+PiBDb21tZW50czoNCj4gPj4+Pj4+Pj4gLS0tLS0tLS0tDQo+ID4+Pj4+Pj4+ DQo+ID4+Pj4+Pj4+IEkgbm90ZSB0aGF0IHRoaXMgaXMgYmVpbmcgcmFpc2VkIGZyb20gRXhwZXJp bWVudGFsIHRvIHRoZSBzdGFuZGFyZHMNCj4gPj4gdHJhY2suDQo+ID4+Pj4+Pj4+IFByZXN1bWFi bHkgdGhhdCBkZXBlbmRzIG9uIHRoZSBiYXNlIExJU1Agc3BlYyBiZWNvbWluZyBQUy4NCj4gPj4+ Pj4+Pj4NCj4gPj4+Pj4+Pj4gTWlub3IgaXNzdWVzOg0KPiA+Pj4+Pj4+PiAtLS0tLS0tLS0tLS0t DQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+ICJUaGlzIGRvY3VtZW50IHVwZGF0ZXMgSS1ELmlldGYt bGlzcC1yZmM2ODMzYmlzLiIgVGhlIHRleHQgZG9lc24ndA0KPiA+Pj4+Pj4+PiBleHBsYWluIHdo aWNoIHRleHQgaXMgdXBkYXRlZC4gVGhpcyBpcyBpbiBjb250cmFzdCB0byBSRkM4MTEzLCB3aGlj aA0KPiA+Pj4+Pj4+PiBleHBsYWlucyBjbGVhcmx5IGhvdyBpdCB1cGRhdGVzIFJGQzY4MzAgKCpu b3QqIFJGQzY4MzMpLiBXaHkgZG9lc24ndA0KPiA+Pj4+Pj4+PiB0aGlzIGRyYWZ0IGNsYWltIHRv IHVwZGF0ZSByZmM2ODMwYmlzPyBJJ20gZ29pbmcgdG8gYXNzdW1lIHRoYXQNCj4gPj4+Pj4+Pj4g aXMgYW4gZXJyb3IuDQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+IEluIGZhY3QsIHdoeSB3YXNuJ3Qg dGhlIGRlZmluaXRpb24gb2YgdGhlIExJU1AgUGFja2V0IFR5cGVzIHJlZ2lzdHJ5DQo+ID4+Pj4+ Pj4+IG1vdmVkIGludG8gdGhlIGJhc2Ugc3BlYyAocmZjNjgzMGJpcyk/IFRoYXQgaXMgd2hlcmUg aXQgYmVsb25ncy4NCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4gU2luY2UgcmZjNjgzMGJpcyAoYW5k IHJmYzY4MzNiaXMpIGFyZSBzdGlsbCB1bmRlciBJRVNHIHJldmlldywNCj4gPj4gYW55dGhpbmcN Cj4gPj4+Pj4+Pj4gaW4gdGhlbSB0aGF0IG5lZWRzIHVwZGF0aW5nIHNob3VsZCBiZSB1cGRhdGVk ISBUaGUgZmFjdCBpcyB0aGF0DQo+ID4+IHJmYzgxMTNiaXMNCj4gPj4+Pj4+Pj4gZXh0ZW5kcyBy ZmM2ODMwYmlzLCB3aGljaCBpcyBub3QgdGhlIHNhbWUgdGhpbmcgYXMgInVwZGF0ZXMiLg0KPiA+ Pj4+Pj4+PiBJZiB0aGUgV0cgdGhpbmtzIHRoYXQgaW1wbGVtZW50ZXJzIG9mIDY4MzBiaXMgbmVl ZCB0byByZWFkIDgxMTNiaXMsDQo+ID4+Pj4+Pj4+IHRoZXJlIHNob3VsZCBiZSBhIG5vcm1hdGl2 ZSByZWZlcmVuY2UgaW4gNjgzMGJpcyB0byA4MTEzYmlzLg0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+ Pg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+DQo+ID4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+ID4+Pj4+IGxpc3AgbWFpbGluZyBsaXN0DQo+ID4+Pj4+ IGxpc3BAaWV0Zi5vcmcNCj4gPj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9saXNwDQo+ID4NCg0K From nobody Thu Dec 20 09:32:37 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BD74131187; Thu, 20 Dec 2018 09:32:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 GMvj3SX3QB8F; Thu, 20 Dec 2018 09:32:09 -0800 (PST) Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65445131154; Thu, 20 Dec 2018 09:32:09 -0800 (PST) Received: by mail-pl1-x62a.google.com with SMTP id gn14so1185236plb.10; Thu, 20 Dec 2018 09:32:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KpmAt2Bde+wyvr4+ofu5/lCmR2+SdrkZMtJUNRA2H+w=; b=kyA9BXJklqHAhahKDwqZgC0++di+SYDkkFq6Z5wMva1/HchSlgqp2t+Zzb4An3FUED N4RR1uvAPyzRBxXzfeU96fHu5l18E7/otERJwYZbp6qccwRsHqXrYuNPAADiQd6/IrtF +DhhXzJKozJrkf1rYxiRoojASjdLEqQPK1gqg0dK64hwNkkXC5QDx52iH7zJ7/PHRLjg f+V96EgKhYt+MbS1ir+sFNfLtksM8nK7SvabqGv0poQXt6AQE9mMXnup5VtrLhdamCS2 /xMrzPc8VuWqA+UhdWv5bc1FBr6f3AlZxJHaRkLmUz/2Neisp8lv1e2QSqNPiHkhq3nX 3sIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KpmAt2Bde+wyvr4+ofu5/lCmR2+SdrkZMtJUNRA2H+w=; b=r3PgipAbbYDv5FKjUABUMBQLVst/rSn4lM3lXX4QsIMN1s7ZwDr6LkSDJRsXD5OiCR i7pTlILtr47llkdT7LvUA1Rzbfu5GD2m6eZENTC2LEWuIZ28WJE1+CKMq2CTm1nwX+KX qqFcADFZYmpxCEaa19xwSVBLaJmEYDpDxWjVcsBcxtHmX9KUOIVe8lWB1YkollSe4SG2 r6/jzjHpWhMQdA8NyGVB95CWVy4mC9aXUzmXlMvq3atY7Yq0lXndi/lyE8DDfxan47sa /KfpPsNJiDOpC6UK/8nJO+g/NLmO596FiKR1LCMDPFufwzFjLMx2n8fDjUx6nYqOE7F0 fMrQ== X-Gm-Message-State: AA+aEWb3NlHCx0NrIShSvXq7ZyTJgLCpzlq2eQYflaHzaXzOO3VnMqoX v8A5ltP4+3nJlKRNNiFMLBEVwlNl X-Google-Smtp-Source: AFSGD/XaguhcUwSzL7b610ualC685qWkRJDVaVo9IyhYyKr9PMryalBdymOMWD78DIkxLneu5gPDgg== X-Received: by 2002:a17:902:6bc9:: with SMTP id m9mr24531608plt.173.1545327128831; Thu, 20 Dec 2018 09:32:08 -0800 (PST) Received: from ?IPv6:2603:3024:151c:55f0:8c9:a91c:edf9:19ec? ([2603:3024:151c:55f0:8c9:a91c:edf9:19ec]) by smtp.gmail.com with ESMTPSA id z10sm22324792pfg.120.2018.12.20.09.32.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Dec 2018 09:32:07 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: <787AE7BB302AE849A7480A190F8B93302E05E137@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Thu, 20 Dec 2018 09:32:05 -0800 Cc: "Joel M. Halpern" , Brian E Carpenter , "gen-art@ietf.org" , "lisp@ietf.org" , "draft-ietf-lisp-rfc8113bis.all@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <154518630870.5131.10104452678736081639@ietfa.amsl.com> <407BD77D-F364-4989-A6D2-C75DF9914402@gmail.com> <9cc58af9-2bcf-89d7-a2ae-3fc80e723d78@joelhalpern.com> <787AE7BB302AE849A7480A190F8B93302E05D7D4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302E05E137@OPEXCLILMA3.corporate.adroot.infra.ftgroup> To: mohamed.boucadair@orange.com X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01 X-BeenThere: lisp@ietf.org 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: Thu, 20 Dec 2018 17:32:21 -0000 I=E2=80=99ll make that change if Brian thinks it fixes the issues he = raised. Dino > On Dec 19, 2018, at 11:35 PM, = wrote: >=20 > Hi Dino,=20 >=20 > OLD:=20 >=20 > Values in the "Not Assigned" range can be assigned according to > procedures in [RFC8126]. >=20 > NEW: >=20 > Values in the "Not Assigned" range can be assigned via Standards > Action [RFC8113]. >=20 > Cheers, > Med >=20 >> -----Message d'origine----- >> De : Dino Farinacci [mailto:farinacci@gmail.com] >> Envoy=C3=A9 : mercredi 19 d=C3=A9cembre 2018 19:00 >> =C3=80 : BOUCADAIR Mohamed TGI/OLN >> Cc : Joel M. Halpern; Brian E Carpenter; gen-art@ietf.org; = lisp@ietf.org; >> draft-ietf-lisp-rfc8113bis.all@ietf.org >> Objet : Re: [lisp] Genart last call review of = draft-ietf-lisp-rfc8113bis-01 >>=20 >> What does fixing in (1) mean? >>=20 >> Dino >>=20 >>> On Dec 19, 2018, at 3:51 AM, >> wrote: >>>=20 >>> Hi all, >>>=20 >>> Brian, whether to maintain the document standalone was discussed by = the WG. >> You may refer, for example, to the message from Deborah which = clarifies this >> point: = https://www.ietf.org/mail-archive/web/lisp/current/msg07886.html. One >> of the outcomes of that discussion is to add an "updates" header to = 8113bis. >>>=20 >>> FWIW, one of the issues that led to that conclusion was whether to = cite >> rfc8113bis as normative in 6833bis (the approach I initially = supported) and >> agreed by Dino (https://www.ietf.org/mail- >> archive/web/lisp/current/msg07882.html). Deborah convinced me that = citing >> 8113bis will lead to circular dependency. Which is a fair argument. >>>=20 >>> The "updates" tag was justified as follows: >>>=20 >>> (1) >>>=20 >>> RFC6833bis includes the following: >>>=20 >>> Values in the "Not Assigned" range can be assigned according to >>> procedures in [RFC8126]. >>>=20 >>> That text is updated by RFC8113bis to be aligned with 8113: >>>=20 >>> Values can be assigned via Standards Action >>>=20 >>> (2) >>>=20 >>> RFC8113bis extends the type field to grab more bits/values when the >> available types are exhausted. This is captured in 8113bis: >>>=20 >>> The values in the range 0-1023 are assigned via Standards Action. >>> This range is provisioned to anticipate, in particular, the >>> exhaustion of the LISP Packet types. >>>=20 >>> Dino: If (1) is fixed directly in RFC6833bis, then I'm fine to = remove the >> "updates" header because (2) can be also seen as an extension. >>>=20 >>> Cheers, >>> Med >>>=20 >>>> -----Message d'origine----- >>>> De : Dino Farinacci [mailto:farinacci@gmail.com] >>>> Envoy=C3=A9 : mercredi 19 d=C3=A9cembre 2018 06:37 >>>> =C3=80 : Joel M. Halpern >>>> Cc : Brian E Carpenter; gen-art@ietf.org; lisp@ietf.org; = draft-ietf-lisp- >>>> rfc8113bis.all@ietf.org >>>> Objet : Re: [lisp] Genart last call review of = draft-ietf-lisp-rfc8113bis- >> 01 >>>>=20 >>>> Mohmad to comment. >>>>=20 >>>> Dino >>>>=20 >>>>> On Dec 18, 2018, at 8:49 PM, Joel M. Halpern = wrote: >>>>>=20 >>>>> That is the other fix he offered. Just remove the updates tag. >>>>> I will leav eit to you and the the authors to determine which is = correct. >>>>> Yours, >>>>> Joel >>>>>=20 >>>>> On 12/18/18 11:43 PM, Dino Farinacci wrote: >>>>>> 8113bis should say that is it *extending* the type field so we = can have >>>> more types. The word =E2=80=9Cupdate=E2=80=9D I always had a = problem with because it can >> be >>>> interpreted as =E2=80=9Creplacing". Replacing something to fix a = problem. >>>>>> 8113 is simply asking for one of the type value codepoint, so = there can >> be >>>> another format to have more types. >>>>>> Dino >>>>>>> On Dec 18, 2018, at 9:24 PM, Joel M. Halpern = >> wrote: >>>>>>>=20 >>>>>>> Authors: that sounds like a reasonable addition to me? >>>>>>>=20 >>>>>>> Yours, >>>>>>> Joel >>>>>>>=20 >>>>>>> On 12/18/18 10:48 PM, Brian E Carpenter wrote: >>>>>>>> On 2018-12-19 15:46, Joel M. Halpern wrote: >>>>>>>>> This is part of the package to move the coherent set of base = LISP >> specs >>>>>>>>> to PS. >>>>>>>>>=20 >>>>>>>>> The reason we did this rather than folding it into 6830bis / = 6833bis >> is >>>>>>>>> that we had originally simply cited 8113, and then realized = that >> needed >>>>>>>>> to move to PS along with everything else. It seemed (and is) = simpler >>>> to >>>>>>>>> do it separately rather than to further modify 6830bis / = 6933bis. >>>>>>>>>=20 >>>>>>>>> As for why it updates 6833bis, that is because one of the = cahnges in >>>>>>>>> moving the set to PS was to improve the split as to which = information >>>>>>>>> belonged in which document. >>>>>>>> OK, but I still don't find it logical The text doesn't explain = which >>>> part of >>>>>>>> 6833bis is impacted, and normally these days we require such an >>>> explanation. >>>>>>>> And if there is an impact, you're missing the opportunity of = fixing >> the >>>> error >>>>>>>> or gap in 6833bis, so the reader of 6833bis will be none the = wiser >>>> unless >>>>>>>> you insert a reference to 8113bis. >>>>>>>> On the other hand, if there is no error or gap, you don't need >>>> "Updates:" >>>>>>>> at all. (Unfortunately, we don't have an "Extends:" header.) >>>>>>>> Brian >>>>>>>>>=20 >>>>>>>>> Yours, >>>>>>>>> Joel >>>>>>>>>=20 >>>>>>>>> On 12/18/18 9:25 PM, Brian Carpenter wrote: >>>>>>>>>> Reviewer: Brian Carpenter >>>>>>>>>> Review result: Ready with Issues >>>>>>>>>>=20 >>>>>>>>>> Gen-ART Last Call review of draft-ietf-lisp-rfc8113bis-01 >>>>>>>>>>=20 >>>>>>>>>> I am the assigned Gen-ART reviewer for this draft. The = General Area >>>>>>>>>> Review Team (Gen-ART) reviews all IETF documents being = processed >>>>>>>>>> by the IESG for the IETF Chair. Please treat these comments = just >>>>>>>>>> like any other last call comments. >>>>>>>>>>=20 >>>>>>>>>> For more information, please see the FAQ at >>>>>>>>>> . >>>>>>>>>>=20 >>>>>>>>>> Document: draft-ietf-lisp-rfc8113bis-01.txt >>>>>>>>>> Reviewer: Brian Carpenter >>>>>>>>>> Review Date: 2018-12-19 >>>>>>>>>> IETF LC End Date: 2018-12-27 >>>>>>>>>> IESG Telechat date: >>>>>>>>>>=20 >>>>>>>>>> Summary: Ready with issues >>>>>>>>>> -------- >>>>>>>>>>=20 >>>>>>>>>> Comments: >>>>>>>>>> --------- >>>>>>>>>>=20 >>>>>>>>>> I note that this is being raised from Experimental to the = standards >>>> track. >>>>>>>>>> Presumably that depends on the base LISP spec becoming PS. >>>>>>>>>>=20 >>>>>>>>>> Minor issues: >>>>>>>>>> ------------- >>>>>>>>>>=20 >>>>>>>>>> "This document updates I-D.ietf-lisp-rfc6833bis." The text = doesn't >>>>>>>>>> explain which text is updated. This is in contrast to = RFC8113, which >>>>>>>>>> explains clearly how it updates RFC6830 (*not* RFC6833). Why = doesn't >>>>>>>>>> this draft claim to update rfc6830bis? I'm going to assume = that >>>>>>>>>> is an error. >>>>>>>>>>=20 >>>>>>>>>> In fact, why wasn't the definition of the LISP Packet Types = registry >>>>>>>>>> moved into the base spec (rfc6830bis)? That is where it = belongs. >>>>>>>>>>=20 >>>>>>>>>> Since rfc6830bis (and rfc6833bis) are still under IESG = review, >>>> anything >>>>>>>>>> in them that needs updating should be updated! The fact is = that >>>> rfc8113bis >>>>>>>>>> extends rfc6830bis, which is not the same thing as "updates". >>>>>>>>>> If the WG thinks that implementers of 6830bis need to read = 8113bis, >>>>>>>>>> there should be a normative reference in 6830bis to 8113bis. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> lisp mailing list >>>>>>> lisp@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/lisp >>>=20 >=20 From nobody Thu Dec 20 11:12:53 2018 Return-Path: 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 9B3EC130F05; Thu, 20 Dec 2018 11:12:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Barry Leiba To: Cc: ietf@ietf.org, draft-ietf-lisp-rfc8113bis.all@ietf.org, lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154533317061.19019.3538327801383303400@ietfa.amsl.com> Date: Thu, 20 Dec 2018 11:12:50 -0800 Archived-At: Subject: [lisp] Secdir last call review of draft-ietf-lisp-rfc8113bis-01 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.29 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: Thu, 20 Dec 2018 19:12:51 -0000 Reviewer: Barry Leiba Review result: Ready Nothing to see here: this document is straightforward and well done, and is ready to publish. It's a simple change from Experimental to Standards Track with some minor updates along the way. From nobody Thu Dec 20 11:55:53 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 792A51311E7; Thu, 20 Dec 2018 11:55:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 mpmjmsP-sVqe; Thu, 20 Dec 2018 11:55:49 -0800 (PST) Received: from mail-pg1-x543.google.com (mail-pg1-x543.google.com [IPv6:2607:f8b0:4864:20::543]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 294D01311E8; Thu, 20 Dec 2018 11:55:49 -0800 (PST) Received: by mail-pg1-x543.google.com with SMTP id g189so1362108pgc.5; Thu, 20 Dec 2018 11:55:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=lSnuhbWhUR1BXP7gB1Ljny54HcZ8drPLhoTdASOpFiA=; b=ianYe07fy0VxKLC8YlH4wobYd+ipCNHhgD8QmOut0eyTXgWlOrqG4EH+zMzOWrJbF/ bWDjWP8ZlxO/nNdJZqxNOrLBF9LHOQwnBQVai0/oWrnywTZgAKjEVrc/pP2S9oSR7IBc aVBfwo3l3gnz7Sf24Un8Atx3rJb1iGF1EISJcWiTPpuPvc7mts17zwcsT7eckE/Amduf TX/JCYORbC2LIsMo2kM3wtdzSAEnfT/ZOyLe83o8bkaN2P2kp0W/PBiirrxXV3Fx1vxB TxNFCx5H+/v+YFlRfSXOKgAw5oOE28D36n9OKhehLfNBXimmHQGBzYpkRgC9W9uk8YoM ULCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=lSnuhbWhUR1BXP7gB1Ljny54HcZ8drPLhoTdASOpFiA=; b=T8BR8AnJZeQQSO5JJR2S52IR/k9soGGXHBeZ8bLDJhGTXOJnvMRoi3mMNYfszdNZsd cBqR9+2kU2mf/IoeeRtWXIeeMd5HLcVfBIOn3aNHTzDNhE/l5Clq8bLOv8v3H1HZaxY/ 24AamgzwMsbfnJN14zcw55bOi/HpjXkoSgPqngyRZry0He8OfIUQxois2Hp+ZJ2HZBi3 uy+0dUeYUL/eBQQXB10zr7Hh0Wl0C9fQQkMJsERUrZJ1evxQeAdR+ho6kAfBi1e1hnkL F5SdnXFJHL8VFgzKKGGrGvL9pyrzPVyvqYcJORaf/Q4nS+nahe6MlDYJuiowXGtEG5wY IOLw== X-Gm-Message-State: AA+aEWaW1n+b0PvZKGA+NRHoAfYbKkuBzAJfiiVWzscSiGjY4pJ/Z2KV 63jtlW6jzoFqHleablzD0LwzyMSK+JY= X-Google-Smtp-Source: AFSGD/UvGvoPp02TucigO9kdCLySAukbD1xQITJc1ZPMx/qrkxq5n8uaUhU6NTCuuYbFQH9Z+TyTDQ== X-Received: by 2002:a62:cf84:: with SMTP id b126mr25285339pfg.98.1545335747194; Thu, 20 Dec 2018 11:55:47 -0800 (PST) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id i73sm32749758pfi.66.2018.12.20.11.55.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Dec 2018 11:55:46 -0800 (PST) To: Dino Farinacci , mohamed.boucadair@orange.com Cc: "Joel M. Halpern" , "gen-art@ietf.org" , "lisp@ietf.org" , "draft-ietf-lisp-rfc8113bis.all@ietf.org" References: <154518630870.5131.10104452678736081639@ietfa.amsl.com> <407BD77D-F364-4989-A6D2-C75DF9914402@gmail.com> <9cc58af9-2bcf-89d7-a2ae-3fc80e723d78@joelhalpern.com> <787AE7BB302AE849A7480A190F8B93302E05D7D4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302E05E137@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Brian E Carpenter Message-ID: Date: Fri, 21 Dec 2018 08:55:39 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01 X-BeenThere: lisp@ietf.org 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: Thu, 20 Dec 2018 19:55:52 -0000 I may be missing something but I don't see how 8113bis can logically cite 8113, which it replaces. Frankly I think you've collectively created a plate of citation spaghetti by not moving the IANA considerations for the type field registry into 6830bis, which is where they naturally belong. If you don't want to do that, I think you have to leave them in 8113bis and simply lose the citation of 6833bis, which serves no purpose that I can see. Regards Brian On 2018-12-21 06:32, Dino Farinacci wrote: > I=E2=80=99ll make that change if Brian thinks it fixes the issues he ra= ised. >=20 > Dino >=20 >> On Dec 19, 2018, at 11:35 PM, wrote: >> >> Hi Dino,=20 >> >> OLD:=20 >> >> Values in the "Not Assigned" range can be assigned according to >> procedures in [RFC8126]. >> >> NEW: >> >> Values in the "Not Assigned" range can be assigned via Standards >> Action [RFC8113]. >> >> Cheers, >> Med >> >>> -----Message d'origine----- >>> De : Dino Farinacci [mailto:farinacci@gmail.com] >>> Envoy=C3=A9 : mercredi 19 d=C3=A9cembre 2018 19:00 >>> =C3=80 : BOUCADAIR Mohamed TGI/OLN >>> Cc : Joel M. Halpern; Brian E Carpenter; gen-art@ietf.org; lisp@ietf.= org; >>> draft-ietf-lisp-rfc8113bis.all@ietf.org >>> Objet : Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113= bis-01 >>> >>> What does fixing in (1) mean? >>> >>> Dino >>> >>>> On Dec 19, 2018, at 3:51 AM, >>> wrote: >>>> >>>> Hi all, >>>> >>>> Brian, whether to maintain the document standalone was discussed by = the WG. >>> You may refer, for example, to the message from Deborah which clarifi= es this >>> point: https://www.ietf.org/mail-archive/web/lisp/current/msg07886.ht= ml. One >>> of the outcomes of that discussion is to add an "updates" header to 8= 113bis. >>>> >>>> FWIW, one of the issues that led to that conclusion was whether to c= ite >>> rfc8113bis as normative in 6833bis (the approach I initially supporte= d) and >>> agreed by Dino (https://www.ietf.org/mail- >>> archive/web/lisp/current/msg07882.html). Deborah convinced me that ci= ting >>> 8113bis will lead to circular dependency. Which is a fair argument. >>>> >>>> The "updates" tag was justified as follows: >>>> >>>> (1) >>>> >>>> RFC6833bis includes the following: >>>> >>>> Values in the "Not Assigned" range can be assigned according to >>>> procedures in [RFC8126]. >>>> >>>> That text is updated by RFC8113bis to be aligned with 8113: >>>> >>>> Values can be assigned via Standards Action >>>> >>>> (2) >>>> >>>> RFC8113bis extends the type field to grab more bits/values when the >>> available types are exhausted. This is captured in 8113bis: >>>> >>>> The values in the range 0-1023 are assigned via Standards Action. >>>> This range is provisioned to anticipate, in particular, the >>>> exhaustion of the LISP Packet types. >>>> >>>> Dino: If (1) is fixed directly in RFC6833bis, then I'm fine to remov= e the >>> "updates" header because (2) can be also seen as an extension. >>>> >>>> Cheers, >>>> Med >>>> >>>>> -----Message d'origine----- >>>>> De : Dino Farinacci [mailto:farinacci@gmail.com] >>>>> Envoy=C3=A9 : mercredi 19 d=C3=A9cembre 2018 06:37 >>>>> =C3=80 : Joel M. Halpern >>>>> Cc : Brian E Carpenter; gen-art@ietf.org; lisp@ietf.org; draft-ietf= -lisp- >>>>> rfc8113bis.all@ietf.org >>>>> Objet : Re: [lisp] Genart last call review of draft-ietf-lisp-rfc81= 13bis- >>> 01 >>>>> >>>>> Mohmad to comment. >>>>> >>>>> Dino >>>>> >>>>>> On Dec 18, 2018, at 8:49 PM, Joel M. Halpern = wrote: >>>>>> >>>>>> That is the other fix he offered. Just remove the updates tag. >>>>>> I will leav eit to you and the the authors to determine which is c= orrect. >>>>>> Yours, >>>>>> Joel >>>>>> >>>>>> On 12/18/18 11:43 PM, Dino Farinacci wrote: >>>>>>> 8113bis should say that is it *extending* the type field so we ca= n have >>>>> more types. The word =E2=80=9Cupdate=E2=80=9D I always had a proble= m with because it can >>> be >>>>> interpreted as =E2=80=9Creplacing". Replacing something to fix a pr= oblem. >>>>>>> 8113 is simply asking for one of the type value codepoint, so the= re can >>> be >>>>> another format to have more types. >>>>>>> Dino >>>>>>>> On Dec 18, 2018, at 9:24 PM, Joel M. Halpern >>> wrote: >>>>>>>> >>>>>>>> Authors: that sounds like a reasonable addition to me? >>>>>>>> >>>>>>>> Yours, >>>>>>>> Joel >>>>>>>> >>>>>>>> On 12/18/18 10:48 PM, Brian E Carpenter wrote: >>>>>>>>> On 2018-12-19 15:46, Joel M. Halpern wrote: >>>>>>>>>> This is part of the package to move the coherent set of base L= ISP >>> specs >>>>>>>>>> to PS. >>>>>>>>>> >>>>>>>>>> The reason we did this rather than folding it into 6830bis / 6= 833bis >>> is >>>>>>>>>> that we had originally simply cited 8113, and then realized th= at >>> needed >>>>>>>>>> to move to PS along with everything else. It seemed (and is) = simpler >>>>> to >>>>>>>>>> do it separately rather than to further modify 6830bis / 6933b= is. >>>>>>>>>> >>>>>>>>>> As for why it updates 6833bis, that is because one of the cahn= ges in >>>>>>>>>> moving the set to PS was to improve the split as to which info= rmation >>>>>>>>>> belonged in which document. >>>>>>>>> OK, but I still don't find it logical The text doesn't explain = which >>>>> part of >>>>>>>>> 6833bis is impacted, and normally these days we require such an= >>>>> explanation. >>>>>>>>> And if there is an impact, you're missing the opportunity of fi= xing >>> the >>>>> error >>>>>>>>> or gap in 6833bis, so the reader of 6833bis will be none the wi= ser >>>>> unless >>>>>>>>> you insert a reference to 8113bis. >>>>>>>>> On the other hand, if there is no error or gap, you don't need >>>>> "Updates:" >>>>>>>>> at all. (Unfortunately, we don't have an "Extends:" header.) >>>>>>>>> Brian >>>>>>>>>> >>>>>>>>>> Yours, >>>>>>>>>> Joel >>>>>>>>>> >>>>>>>>>> On 12/18/18 9:25 PM, Brian Carpenter wrote: >>>>>>>>>>> Reviewer: Brian Carpenter >>>>>>>>>>> Review result: Ready with Issues >>>>>>>>>>> >>>>>>>>>>> Gen-ART Last Call review of draft-ietf-lisp-rfc8113bis-01 >>>>>>>>>>> >>>>>>>>>>> I am the assigned Gen-ART reviewer for this draft. The Genera= l Area >>>>>>>>>>> Review Team (Gen-ART) reviews all IETF documents being proces= sed >>>>>>>>>>> by the IESG for the IETF Chair. Please treat these comments = just >>>>>>>>>>> like any other last call comments. >>>>>>>>>>> >>>>>>>>>>> For more information, please see the FAQ at >>>>>>>>>>> . >>>>>>>>>>> >>>>>>>>>>> Document: draft-ietf-lisp-rfc8113bis-01.txt >>>>>>>>>>> Reviewer: Brian Carpenter >>>>>>>>>>> Review Date: 2018-12-19 >>>>>>>>>>> IETF LC End Date: 2018-12-27 >>>>>>>>>>> IESG Telechat date: >>>>>>>>>>> >>>>>>>>>>> Summary: Ready with issues >>>>>>>>>>> -------- >>>>>>>>>>> >>>>>>>>>>> Comments: >>>>>>>>>>> --------- >>>>>>>>>>> >>>>>>>>>>> I note that this is being raised from Experimental to the sta= ndards >>>>> track. >>>>>>>>>>> Presumably that depends on the base LISP spec becoming PS. >>>>>>>>>>> >>>>>>>>>>> Minor issues: >>>>>>>>>>> ------------- >>>>>>>>>>> >>>>>>>>>>> "This document updates I-D.ietf-lisp-rfc6833bis." The text do= esn't >>>>>>>>>>> explain which text is updated. This is in contrast to RFC8113= , which >>>>>>>>>>> explains clearly how it updates RFC6830 (*not* RFC6833). Why = doesn't >>>>>>>>>>> this draft claim to update rfc6830bis? I'm going to assume th= at >>>>>>>>>>> is an error. >>>>>>>>>>> >>>>>>>>>>> In fact, why wasn't the definition of the LISP Packet Types r= egistry >>>>>>>>>>> moved into the base spec (rfc6830bis)? That is where it belon= gs. >>>>>>>>>>> >>>>>>>>>>> Since rfc6830bis (and rfc6833bis) are still under IESG review= , >>>>> anything >>>>>>>>>>> in them that needs updating should be updated! The fact is th= at >>>>> rfc8113bis >>>>>>>>>>> extends rfc6830bis, which is not the same thing as "updates".= >>>>>>>>>>> If the WG thinks that implementers of 6830bis need to read 81= 13bis, >>>>>>>>>>> there should be a normative reference in 6830bis to 8113bis. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> lisp mailing list >>>>>>>> lisp@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/lisp >>>> >> >=20 >=20 From nobody Thu Dec 20 11:58:40 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6C7A13116F; Thu, 20 Dec 2018 11:58:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 SNa4ya4K-Rrv; Thu, 20 Dec 2018 11:58:28 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15ECB131163; Thu, 20 Dec 2018 11:58:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 43LMyC5l1Zz1KHwM; Thu, 20 Dec 2018 11:58:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1545335907; bh=wr688jp0V0ZwJAZRcFyVZx92ZxG9lZMXA8a6D+dJuE4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=d8Q7kH+ivuEmkd4Gfa+7rlD14qNqGa/cfgpqFvFQiU1VFE9lT7lWo3zW7m8HXuDuY LZ7JcYtGNfHHrmpHnGNRXt3oqDT/x52DT7goWXbI6eFqwUCOW8X2xzHFTE7u/tHf7u 9jcz1N5Mcm7Y6NUwvtbugGM7ZRIV9UWqO0vFumQw= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 43LMyB5LxJz1KHw9; Thu, 20 Dec 2018 11:58:26 -0800 (PST) To: Brian E Carpenter , Dino Farinacci , mohamed.boucadair@orange.com Cc: "Joel M. Halpern" , "gen-art@ietf.org" , "lisp@ietf.org" , "draft-ietf-lisp-rfc8113bis.all@ietf.org" References: <154518630870.5131.10104452678736081639@ietfa.amsl.com> <407BD77D-F364-4989-A6D2-C75DF9914402@gmail.com> <9cc58af9-2bcf-89d7-a2ae-3fc80e723d78@joelhalpern.com> <787AE7BB302AE849A7480A190F8B93302E05D7D4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302E05E137@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: "Joel M. Halpern" Message-ID: <583bf0d5-3de8-adba-7445-54ec4779a345@joelhalpern.com> Date: Thu, 20 Dec 2018 14:58:25 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01 X-BeenThere: lisp@ietf.org 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: Thu, 20 Dec 2018 19:58:31 -0000 Dino, Med, please confirm if I am reading the thread properly: I believe that the proposal is to make the small change below to 6833bis and to drop the "updates" reference from 8113bis to 6833bis. I believe Dino's question was whether Brian agreed that the combination suggested would address his concern. Yours, Joel On 12/20/18 2:55 PM, Brian E Carpenter wrote: > I may be missing something but I don't see how 8113bis can > logically cite 8113, which it replaces. > > Frankly I think you've collectively created a plate of citation > spaghetti by not moving the IANA considerations for the type field > registry into 6830bis, which is where they naturally belong. If you > don't want to do that, I think you have to leave them in 8113bis and > simply lose the citation of 6833bis, which serves no purpose that > I can see. > > Regards > Brian > > On 2018-12-21 06:32, Dino Farinacci wrote: >> I’ll make that change if Brian thinks it fixes the issues he raised. >> >> Dino >> >>> On Dec 19, 2018, at 11:35 PM, wrote: >>> >>> Hi Dino, >>> >>> OLD: >>> >>> Values in the "Not Assigned" range can be assigned according to >>> procedures in [RFC8126]. >>> >>> NEW: >>> >>> Values in the "Not Assigned" range can be assigned via Standards >>> Action [RFC8113]. >>> >>> Cheers, >>> Med >>> >>>> -----Message d'origine----- >>>> De : Dino Farinacci [mailto:farinacci@gmail.com] >>>> Envoyé : mercredi 19 décembre 2018 19:00 >>>> À : BOUCADAIR Mohamed TGI/OLN >>>> Cc : Joel M. Halpern; Brian E Carpenter; gen-art@ietf.org; lisp@ietf.org; >>>> draft-ietf-lisp-rfc8113bis.all@ietf.org >>>> Objet : Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01 >>>> >>>> What does fixing in (1) mean? >>>> >>>> Dino >>>> >>>>> On Dec 19, 2018, at 3:51 AM, >>>> wrote: >>>>> >>>>> Hi all, >>>>> >>>>> Brian, whether to maintain the document standalone was discussed by the WG. >>>> You may refer, for example, to the message from Deborah which clarifies this >>>> point: https://www.ietf.org/mail-archive/web/lisp/current/msg07886.html. One >>>> of the outcomes of that discussion is to add an "updates" header to 8113bis. >>>>> >>>>> FWIW, one of the issues that led to that conclusion was whether to cite >>>> rfc8113bis as normative in 6833bis (the approach I initially supported) and >>>> agreed by Dino (https://www.ietf.org/mail- >>>> archive/web/lisp/current/msg07882.html). Deborah convinced me that citing >>>> 8113bis will lead to circular dependency. Which is a fair argument. >>>>> >>>>> The "updates" tag was justified as follows: >>>>> >>>>> (1) >>>>> >>>>> RFC6833bis includes the following: >>>>> >>>>> Values in the "Not Assigned" range can be assigned according to >>>>> procedures in [RFC8126]. >>>>> >>>>> That text is updated by RFC8113bis to be aligned with 8113: >>>>> >>>>> Values can be assigned via Standards Action >>>>> >>>>> (2) >>>>> >>>>> RFC8113bis extends the type field to grab more bits/values when the >>>> available types are exhausted. This is captured in 8113bis: >>>>> >>>>> The values in the range 0-1023 are assigned via Standards Action. >>>>> This range is provisioned to anticipate, in particular, the >>>>> exhaustion of the LISP Packet types. >>>>> >>>>> Dino: If (1) is fixed directly in RFC6833bis, then I'm fine to remove the >>>> "updates" header because (2) can be also seen as an extension. >>>>> >>>>> Cheers, >>>>> Med >>>>> >>>>>> -----Message d'origine----- >>>>>> De : Dino Farinacci [mailto:farinacci@gmail.com] >>>>>> Envoyé : mercredi 19 décembre 2018 06:37 >>>>>> À : Joel M. Halpern >>>>>> Cc : Brian E Carpenter; gen-art@ietf.org; lisp@ietf.org; draft-ietf-lisp- >>>>>> rfc8113bis.all@ietf.org >>>>>> Objet : Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis- >>>> 01 >>>>>> >>>>>> Mohmad to comment. >>>>>> >>>>>> Dino >>>>>> >>>>>>> On Dec 18, 2018, at 8:49 PM, Joel M. Halpern wrote: >>>>>>> >>>>>>> That is the other fix he offered. Just remove the updates tag. >>>>>>> I will leav eit to you and the the authors to determine which is correct. >>>>>>> Yours, >>>>>>> Joel >>>>>>> >>>>>>> On 12/18/18 11:43 PM, Dino Farinacci wrote: >>>>>>>> 8113bis should say that is it *extending* the type field so we can have >>>>>> more types. The word “update” I always had a problem with because it can >>>> be >>>>>> interpreted as “replacing". Replacing something to fix a problem. >>>>>>>> 8113 is simply asking for one of the type value codepoint, so there can >>>> be >>>>>> another format to have more types. >>>>>>>> Dino >>>>>>>>> On Dec 18, 2018, at 9:24 PM, Joel M. Halpern >>>> wrote: >>>>>>>>> >>>>>>>>> Authors: that sounds like a reasonable addition to me? >>>>>>>>> >>>>>>>>> Yours, >>>>>>>>> Joel >>>>>>>>> >>>>>>>>> On 12/18/18 10:48 PM, Brian E Carpenter wrote: >>>>>>>>>> On 2018-12-19 15:46, Joel M. Halpern wrote: >>>>>>>>>>> This is part of the package to move the coherent set of base LISP >>>> specs >>>>>>>>>>> to PS. >>>>>>>>>>> >>>>>>>>>>> The reason we did this rather than folding it into 6830bis / 6833bis >>>> is >>>>>>>>>>> that we had originally simply cited 8113, and then realized that >>>> needed >>>>>>>>>>> to move to PS along with everything else. It seemed (and is) simpler >>>>>> to >>>>>>>>>>> do it separately rather than to further modify 6830bis / 6933bis. >>>>>>>>>>> >>>>>>>>>>> As for why it updates 6833bis, that is because one of the cahnges in >>>>>>>>>>> moving the set to PS was to improve the split as to which information >>>>>>>>>>> belonged in which document. >>>>>>>>>> OK, but I still don't find it logical The text doesn't explain which >>>>>> part of >>>>>>>>>> 6833bis is impacted, and normally these days we require such an >>>>>> explanation. >>>>>>>>>> And if there is an impact, you're missing the opportunity of fixing >>>> the >>>>>> error >>>>>>>>>> or gap in 6833bis, so the reader of 6833bis will be none the wiser >>>>>> unless >>>>>>>>>> you insert a reference to 8113bis. >>>>>>>>>> On the other hand, if there is no error or gap, you don't need >>>>>> "Updates:" >>>>>>>>>> at all. (Unfortunately, we don't have an "Extends:" header.) >>>>>>>>>> Brian >>>>>>>>>>> >>>>>>>>>>> Yours, >>>>>>>>>>> Joel >>>>>>>>>>> >>>>>>>>>>> On 12/18/18 9:25 PM, Brian Carpenter wrote: >>>>>>>>>>>> Reviewer: Brian Carpenter >>>>>>>>>>>> Review result: Ready with Issues >>>>>>>>>>>> >>>>>>>>>>>> Gen-ART Last Call review of draft-ietf-lisp-rfc8113bis-01 >>>>>>>>>>>> >>>>>>>>>>>> I am the assigned Gen-ART reviewer for this draft. The General Area >>>>>>>>>>>> Review Team (Gen-ART) reviews all IETF documents being processed >>>>>>>>>>>> by the IESG for the IETF Chair. Please treat these comments just >>>>>>>>>>>> like any other last call comments. >>>>>>>>>>>> >>>>>>>>>>>> For more information, please see the FAQ at >>>>>>>>>>>> . >>>>>>>>>>>> >>>>>>>>>>>> Document: draft-ietf-lisp-rfc8113bis-01.txt >>>>>>>>>>>> Reviewer: Brian Carpenter >>>>>>>>>>>> Review Date: 2018-12-19 >>>>>>>>>>>> IETF LC End Date: 2018-12-27 >>>>>>>>>>>> IESG Telechat date: >>>>>>>>>>>> >>>>>>>>>>>> Summary: Ready with issues >>>>>>>>>>>> -------- >>>>>>>>>>>> >>>>>>>>>>>> Comments: >>>>>>>>>>>> --------- >>>>>>>>>>>> >>>>>>>>>>>> I note that this is being raised from Experimental to the standards >>>>>> track. >>>>>>>>>>>> Presumably that depends on the base LISP spec becoming PS. >>>>>>>>>>>> >>>>>>>>>>>> Minor issues: >>>>>>>>>>>> ------------- >>>>>>>>>>>> >>>>>>>>>>>> "This document updates I-D.ietf-lisp-rfc6833bis." The text doesn't >>>>>>>>>>>> explain which text is updated. This is in contrast to RFC8113, which >>>>>>>>>>>> explains clearly how it updates RFC6830 (*not* RFC6833). Why doesn't >>>>>>>>>>>> this draft claim to update rfc6830bis? I'm going to assume that >>>>>>>>>>>> is an error. >>>>>>>>>>>> >>>>>>>>>>>> In fact, why wasn't the definition of the LISP Packet Types registry >>>>>>>>>>>> moved into the base spec (rfc6830bis)? That is where it belongs. >>>>>>>>>>>> >>>>>>>>>>>> Since rfc6830bis (and rfc6833bis) are still under IESG review, >>>>>> anything >>>>>>>>>>>> in them that needs updating should be updated! The fact is that >>>>>> rfc8113bis >>>>>>>>>>>> extends rfc6830bis, which is not the same thing as "updates". >>>>>>>>>>>> If the WG thinks that implementers of 6830bis need to read 8113bis, >>>>>>>>>>>> there should be a normative reference in 6830bis to 8113bis. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> lisp mailing list >>>>>>>>> lisp@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/lisp >>>>> >>> >> >> > From nobody Thu Dec 20 12:19:12 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38772130EFE; Thu, 20 Dec 2018 12:19:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 1qsxW8S4C-mH; Thu, 20 Dec 2018 12:19:02 -0800 (PST) Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE58E130E95; Thu, 20 Dec 2018 12:19:01 -0800 (PST) Received: by mail-pg1-x531.google.com with SMTP id c25so1393756pgb.4; Thu, 20 Dec 2018 12:19:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/atzJpqwvLxiXGV9qoRcEK2hZjfDm1h13OZ4aO5VA8o=; b=YBfmAznEZtVyMPdzodzkbuxo+dNNj2F48+HuQCNxtLjXmMZwBEvfOIILjWeAHjdKiL 1gP2CqKgk2dzr4HGHWDdWo5O1koBPTkHW14ZJBH2rr7NWDzkFYLMCkEA1kt4tWI5tjKX DD46KOtHYFBaPuKOTXwQsEFhomD5rOBqHsORQOhNQCmrV8g/L0iqZ8XGArDAPVR2SIG+ 9pPaRdeb1Pl1sUXSqnVy+fluEBUerKJVeZWudN8ycoCmadehjj4Vnx794dZwqCrNCuSv pd2sB4E9J/VBOahImj0mPC3y/8VFLVCfoaRt+MZaqKZSX1aSA4wQfqox7Kq9F0PUBviX 9uvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/atzJpqwvLxiXGV9qoRcEK2hZjfDm1h13OZ4aO5VA8o=; b=KOWrKv3sBwH4003iN0SHJAQ6F2GM2pLho9PZasb7iaY7ntXOvOlg1VWpjF/Hr0UYVM /6r+MiggPH8QqddvAHhhCTJjNLf/avrAdCNm27w/ZxI1YwfwVvhrYgApTNOSbV0NtZKd 2hjgO9hN0JRaH7DBufAsMOOYnBTvOv8CcRfJ8ExxbcXxb7z+u/VPeYJx8q0MmZk5/Iq0 eeYMmJcy4bHyNagW56uf7EMjm/5sQpLAW3HOnfnSzjfOuwGhXXZnRNJLYSWkpn4YDlsY lcNKlOzjJ2OVYCrsdPZq9PM1n9v2X367izSdDyR9vwtQlsfrKyGI8R+wjpHDMyCDUVRw C11Q== X-Gm-Message-State: AA+aEWZHWuSH99g8bvB+19QrACC/9rmYYPyTTrtQv1CJlQIotot1fPzL JL1hvE5lFwUmeHcxwHXAcKo= X-Google-Smtp-Source: AFSGD/Uemqt9CgMcnfygFBvjDk8rLYcoODxGeyaFr7EsmX69C+PjS3Rw2NxlK4B57HYxYJzhcC75Ag== X-Received: by 2002:a62:546:: with SMTP id 67mr24995104pff.99.1545337141136; Thu, 20 Dec 2018 12:19:01 -0800 (PST) Received: from [10.31.79.215] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id n66sm32362763pfk.19.2018.12.20.12.18.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Dec 2018 12:19:00 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: <583bf0d5-3de8-adba-7445-54ec4779a345@joelhalpern.com> Date: Thu, 20 Dec 2018 12:18:59 -0800 Cc: Brian E Carpenter , mohamed.boucadair@orange.com, "gen-art@ietf.org" , "lisp@ietf.org" , "draft-ietf-lisp-rfc8113bis.all@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <48ED1BED-7055-4DF4-AF69-E764E5ADABDB@gmail.com> References: <154518630870.5131.10104452678736081639@ietfa.amsl.com> <407BD77D-F364-4989-A6D2-C75DF9914402@gmail.com> <9cc58af9-2bcf-89d7-a2ae-3fc80e723d78@joelhalpern.com> <787AE7BB302AE849A7480A190F8B93302E05D7D4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302E05E137@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <583bf0d5-3de8-adba-7445-54ec4779a345@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01 X-BeenThere: lisp@ietf.org 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: Thu, 20 Dec 2018 20:19:05 -0000 Brian wants to drop the reference to 6833bis from 8113bis. I am fine = with that. That reference being at the top of the draft saying = =E2=80=9CUpdates 6833bis=E2=80=9D. If we remove that, he may concur. = Please confirm Brian (again). Like I have mentioned to you before, the IETF =E2=80=9CUpdates=E2=80=9D = lingo is confusing and really not useful unless a draft replaces a = previous draft. And this is not the case here. Dino > On Dec 20, 2018, at 11:58 AM, Joel M. Halpern = wrote: >=20 > Dino, Med, please confirm if I am reading the thread properly: >=20 > I believe that the proposal is to make the small change below to = 6833bis and to drop the "updates" reference from 8113bis to 6833bis. >=20 > I believe Dino's question was whether Brian agreed that the = combination suggested would address his concern. >=20 > Yours, > Joel >=20 > On 12/20/18 2:55 PM, Brian E Carpenter wrote: >> I may be missing something but I don't see how 8113bis can >> logically cite 8113, which it replaces. >> Frankly I think you've collectively created a plate of citation >> spaghetti by not moving the IANA considerations for the type field >> registry into 6830bis, which is where they naturally belong. If you >> don't want to do that, I think you have to leave them in 8113bis and >> simply lose the citation of 6833bis, which serves no purpose that >> I can see. >> Regards >> Brian >> On 2018-12-21 06:32, Dino Farinacci wrote: >>> I=E2=80=99ll make that change if Brian thinks it fixes the issues he = raised. >>>=20 >>> Dino >>> ngo=20 >>>> On Dec 19, 2018, at 11:35 PM, = wrote: >>>>=20 >>>> Hi Dino, >>>>=20 >>>> OLD: >>>>=20 >>>> Values in the "Not Assigned" range can be assigned according to >>>> procedures in [RFC8126]. >>>>=20 >>>> NEW: >>>>=20 >>>> Values in the "Not Assigned" range can be assigned via Standards >>>> Action [RFC8113]. >>>>=20 >>>> Cheers, >>>> Med >>>>=20 >>>>> -----Message d'origine----- >>>>> De : Dino Farinacci [mailto:farinacci@gmail.com] >>>>> Envoy=C3=A9 : mercredi 19 d=C3=A9cembre 2018 19:00 >>>>> =C3=80 : BOUCADAIR Mohamed TGI/OLN >>>>> Cc : Joel M. Halpern; Brian E Carpenter; gen-art@ietf.org; = lisp@ietf.org; >>>>> draft-ietf-lisp-rfc8113bis.all@ietf.org >>>>> Objet : Re: [lisp] Genart last call review of = draft-ietf-lisp-rfc8113bis-01 >>>>>=20 >>>>> What does fixing in (1) mean? >>>>>=20 >>>>> Dino >>>>>=20 >>>>>> On Dec 19, 2018, at 3:51 AM, >>>>> wrote: >>>>>>=20 >>>>>> Hi all, >>>>>>=20 >>>>>> Brian, whether to maintain the document standalone was discussed = by the WG. >>>>> You may refer, for example, to the message from Deborah which = clarifies this >>>>> point: = https://www.ietf.org/mail-archive/web/lisp/current/msg07886.html. One >>>>> of the outcomes of that discussion is to add an "updates" header = to 8113bis. >>>>>>=20 >>>>>> FWIW, one of the issues that led to that conclusion was whether = to cite >>>>> rfc8113bis as normative in 6833bis (the approach I initially = supported) and >>>>> agreed by Dino (https://www.ietf.org/mail- >>>>> archive/web/lisp/current/msg07882.html). Deborah convinced me that = citing >>>>> 8113bis will lead to circular dependency. Which is a fair = argument. >>>>>>=20 >>>>>> The "updates" tag was justified as follows: >>>>>>=20 >>>>>> (1) >>>>>>=20 >>>>>> RFC6833bis includes the following: >>>>>>=20 >>>>>> Values in the "Not Assigned" range can be assigned according to >>>>>> procedures in [RFC8126]. >>>>>>=20 >>>>>> That text is updated by RFC8113bis to be aligned with 8113: >>>>>>=20 >>>>>> Values can be assigned via Standards Action >>>>>>=20 >>>>>> (2) >>>>>>=20 >>>>>> RFC8113bis extends the type field to grab more bits/values when = the >>>>> available types are exhausted. This is captured in 8113bis: >>>>>>=20 >>>>>> The values in the range 0-1023 are assigned via Standards = Action. >>>>>> This range is provisioned to anticipate, in particular, the >>>>>> exhaustion of the LISP Packet types. >>>>>>=20 >>>>>> Dino: If (1) is fixed directly in RFC6833bis, then I'm fine to = remove the >>>>> "updates" header because (2) can be also seen as an extension. >>>>>>=20 >>>>>> Cheers, >>>>>> Med >>>>>>=20 >>>>>>> -----Message d'origine----- >>>>>>> De : Dino Farinacci [mailto:farinacci@gmail.com] >>>>>>> Envoy=C3=A9 : mercredi 19 d=C3=A9cembre 2018 06:37 >>>>>>> =C3=80 : Joel M. Halpern >>>>>>> Cc : Brian E Carpenter; gen-art@ietf.org; lisp@ietf.org; = draft-ietf-lisp- >>>>>>> rfc8113bis.all@ietf.org >>>>>>> Objet : Re: [lisp] Genart last call review of = draft-ietf-lisp-rfc8113bis- >>>>> 01 >>>>>>>=20 >>>>>>> Mohmad to comment. >>>>>>>=20 >>>>>>> Dino >>>>>>>=20 >>>>>>>> On Dec 18, 2018, at 8:49 PM, Joel M. Halpern = wrote: >>>>>>>>=20 >>>>>>>> That is the other fix he offered. Just remove the updates tag. >>>>>>>> I will leav eit to you and the the authors to determine which = is correct. >>>>>>>> Yours, >>>>>>>> Joel >>>>>>>>=20 >>>>>>>> On 12/18/18 11:43 PM, Dino Farinacci wrote: >>>>>>>>> 8113bis should say that is it *extending* the type field so we = can have >>>>>>> more types. The word =E2=80=9Cupdate=E2=80=9D I always had a = problem with because it can >>>>> be >>>>>>> interpreted as =E2=80=9Creplacing". Replacing something to fix a = problem. >>>>>>>>> 8113 is simply asking for one of the type value codepoint, so = there can >>>>> be >>>>>>> another format to have more types. >>>>>>>>> Dino >>>>>>>>>> On Dec 18, 2018, at 9:24 PM, Joel M. Halpern = >>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>> Authors: that sounds like a reasonable addition to me? >>>>>>>>>>=20 >>>>>>>>>> Yours, >>>>>>>>>> Joel >>>>>>>>>>=20 >>>>>>>>>> On 12/18/18 10:48 PM, Brian E Carpenter wrote: >>>>>>>>>>> On 2018-12-19 15:46, Joel M. Halpern wrote: >>>>>>>>>>>> This is part of the package to move the coherent set of = base LISP >>>>> specs >>>>>>>>>>>> to PS. >>>>>>>>>>>>=20 >>>>>>>>>>>> The reason we did this rather than folding it into 6830bis = / 6833bis >>>>> is >>>>>>>>>>>> that we had originally simply cited 8113, and then realized = that >>>>> needed >>>>>>>>>>>> to move to PS along with everything else. It seemed (and = is) simpler >>>>>>> to >>>>>>>>>>>> do it separately rather than to further modify 6830bis / = 6933bis. >>>>>>>>>>>>=20 >>>>>>>>>>>> As for why it updates 6833bis, that is because one of the = cahnges in >>>>>>>>>>>> moving the set to PS was to improve the split as to which = information >>>>>>>>>>>> belonged in which document. >>>>>>>>>>> OK, but I still don't find it logical The text doesn't = explain which >>>>>>> part of >>>>>>>>>>> 6833bis is impacted, and normally these days we require such = an >>>>>>> explanation. >>>>>>>>>>> And if there is an impact, you're missing the opportunity of = fixing >>>>> the >>>>>>> error >>>>>>>>>>> or gap in 6833bis, so the reader of 6833bis will be none the = wiser >>>>>>> unless >>>>>>>>>>> you insert a reference to 8113bis. >>>>>>>>>>> On the other hand, if there is no error or gap, you don't = need >>>>>>> "Updates:" >>>>>>>>>>> at all. (Unfortunately, we don't have an "Extends:" header.) >>>>>>>>>>> Brian >>>>>>>>>>>>=20 >>>>>>>>>>>> Yours, >>>>>>>>>>>> Joel >>>>>>>>>>>>=20 >>>>>>>>>>>> On 12/18/18 9:25 PM, Brian Carpenter wrote: >>>>>>>>>>>>> Reviewer: Brian Carpenter >>>>>>>>>>>>> Review result: Ready with Issues >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Gen-ART Last Call review of draft-ietf-lisp-rfc8113bis-01 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> I am the assigned Gen-ART reviewer for this draft. The = General Area >>>>>>>>>>>>> Review Team (Gen-ART) reviews all IETF documents being = processed >>>>>>>>>>>>> by the IESG for the IETF Chair. Please treat these = comments just >>>>>>>>>>>>> like any other last call comments. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> For more information, please see the FAQ at >>>>>>>>>>>>> . >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Document: draft-ietf-lisp-rfc8113bis-01.txt >>>>>>>>>>>>> Reviewer: Brian Carpenter >>>>>>>>>>>>> Review Date: 2018-12-19 >>>>>>>>>>>>> IETF LC End Date: 2018-12-27 >>>>>>>>>>>>> IESG Telechat date: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Summary: Ready with issues >>>>>>>>>>>>> -------- >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Comments: >>>>>>>>>>>>> --------- >>>>>>>>>>>>>=20 >>>>>>>>>>>>> I note that this is being raised from Experimental to the = standards >>>>>>> track. >>>>>>>>>>>>> Presumably that depends on the base LISP spec becoming PS. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Minor issues: >>>>>>>>>>>>> ------------- >>>>>>>>>>>>>=20 >>>>>>>>>>>>> "This document updates I-D.ietf-lisp-rfc6833bis." The text = doesn't >>>>>>>>>>>>> explain which text is updated. This is in contrast to = RFC8113, which >>>>>>>>>>>>> explains clearly how it updates RFC6830 (*not* RFC6833). = Why doesn't >>>>>>>>>>>>> this draft claim to update rfc6830bis? I'm going to assume = that >>>>>>>>>>>>> is an error. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> In fact, why wasn't the definition of the LISP Packet = Types registry >>>>>>>>>>>>> moved into the base spec (rfc6830bis)? That is where it = belongs. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Since rfc6830bis (and rfc6833bis) are still under IESG = review, >>>>>>> anything >>>>>>>>>>>>> in them that needs updating should be updated! The fact is = that >>>>>>> rfc8113bis >>>>>>>>>>>>> extends rfc6830bis, which is not the same thing as = "updates". >>>>>>>>>>>>> If the WG thinks that implementers of 6830bis need to read = 8113bis, >>>>>>>>>>>>> there should be a normative reference in 6830bis to = 8113bis. >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> lisp mailing list >>>>>>>>>> lisp@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/lisp >>>>>>=20 >>>>=20 >>>=20 >>>=20 From nobody Thu Dec 20 15:24:58 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45917131054; Thu, 20 Dec 2018 15:24:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 7izs5FWtqR_N; Thu, 20 Dec 2018 15:24:53 -0800 (PST) Received: from mail-pg1-x541.google.com (mail-pg1-x541.google.com [IPv6:2607:f8b0:4864:20::541]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD53C130DF4; Thu, 20 Dec 2018 15:24:53 -0800 (PST) Received: by mail-pg1-x541.google.com with SMTP id n2so1587668pgm.3; Thu, 20 Dec 2018 15:24:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=SzjumBL+VhDSVmd8Cyjv2Sj50zNRbrDxTvSeTkjXuIU=; b=ju5cKKIcRivMvRhqH5lzs+zKodFbhiD6tQyvBdSbqcT7ktUpVl2+8A1/snwKHKku6Q Ttz5Rzj8fXLODjpQQsZsFfVRddjNCncOkY+4EwPCxfdG7Vmx2POGtzoHtm5QolR1nXWQ blVnzm2kBHwBV2TPXZOyqk10C/7qYxMrVT0NRrGFsuq3HCrMJ1mTLrfIkm3hTuXloY5g MPae3EC/FBVgF9sXTsW03Gj4PZaUe5zj95JxKmcnZ+rJ1KO0tYnrJoTh+/zVriqNiXLU Uz3GwVfnoXFBITtNTHDzWvmhtbiZoruJ6pC5YbJkRhmGqn13AmGrETO+SGrzSwEUf612 Pixw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=SzjumBL+VhDSVmd8Cyjv2Sj50zNRbrDxTvSeTkjXuIU=; b=OrPXpu5+lXwsTzu0qXAvt9I0T/fh7ZZgcENmWFnq+COO4PriEQJvbeRJf8tvmYQkmu YOFPfCU5lgbeMJB5uAbA+V8NY2oRAP5fwlBhgKaibC+lVxn9A4rghlvL94m34jLcd1c9 p33qcM9yYv/Kxskg/V5agtFta/5HFDhmCVhy9lPlIabB3Y7vRWwmO4zKZ5PY1bDHXhn5 uhPTSQvgMWMrlQ9a36pC0xQLUlAm3YgLLgDL6kSebX5N//3CY2e5RduMoA8/yEBxUBkU ++DP9ZxXfVcwMRheKtgc/sFk5glT38Gb2/uamHi1q6YMIxr8bgSmHi3NtgiU8sVc2SPg eJzQ== X-Gm-Message-State: AJcUukc7nmCGXuUcpPh9mNWFbhKn57gl7w30++eakI3xQP7FAcVziWxz zB/JK1FKBiGeXoV3hBAvktHKRcl6X64= X-Google-Smtp-Source: ALg8bN4st3iSMqx6n1u/vEApSAQvc4c6tQ0N2l04Eo5aeaia9VSYcOvoXFQ/EdtmF4y97M5eLYumXA== X-Received: by 2002:a63:5907:: with SMTP id n7mr145050pgb.435.1545348292928; Thu, 20 Dec 2018 15:24:52 -0800 (PST) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id x7sm23951258pga.68.2018.12.20.15.24.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Dec 2018 15:24:52 -0800 (PST) To: Dino Farinacci , "Joel M. Halpern" Cc: mohamed.boucadair@orange.com, "gen-art@ietf.org" , "lisp@ietf.org" , "draft-ietf-lisp-rfc8113bis.all@ietf.org" References: <154518630870.5131.10104452678736081639@ietfa.amsl.com> <407BD77D-F364-4989-A6D2-C75DF9914402@gmail.com> <9cc58af9-2bcf-89d7-a2ae-3fc80e723d78@joelhalpern.com> <787AE7BB302AE849A7480A190F8B93302E05D7D4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302E05E137@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <583bf0d5-3de8-adba-7445-54ec4779a345@joelhalpern.com> <48ED1BED-7055-4DF4-AF69-E764E5ADABDB@gmail.com> From: Brian E Carpenter Message-ID: Date: Fri, 21 Dec 2018 12:24:45 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 MIME-Version: 1.0 In-Reply-To: <48ED1BED-7055-4DF4-AF69-E764E5ADABDB@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01 X-BeenThere: lisp@ietf.org 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: Thu, 20 Dec 2018 23:24:57 -0000 On 2018-12-21 09:18, Dino Farinacci wrote: > Brian wants to drop the reference to 6833bis from 8113bis. I am fine wi= th that. That reference being at the top of the draft saying =E2=80=9CUpd= ates 6833bis=E2=80=9D. If we remove that, he may concur. Please confirm B= rian (again). Yes, that would resolve my concern. > Like I have mentioned to you before, the IETF =E2=80=9CUpdates=E2=80=9D= lingo is confusing and really not useful unless a draft replaces a previ= ous draft. And this is not the case here. That's a debate for the RFC-interest list perhaps. IMHO the issue is that= "Updates" sometimes means "Extends" and sometimes means "Modifies". "Obs= oletes" sometimes also implies "Replaces", but that doesn't seem to creat= e confusion. Thanks Brian >=20 > Dino >=20 >> On Dec 20, 2018, at 11:58 AM, Joel M. Halpern wr= ote: >> >> Dino, Med, please confirm if I am reading the thread properly: >> >> I believe that the proposal is to make the small change below to 6833b= is and to drop the "updates" reference from 8113bis to 6833bis. >> >> I believe Dino's question was whether Brian agreed that the combinatio= n suggested would address his concern. >> >> Yours, >> Joel >> >> On 12/20/18 2:55 PM, Brian E Carpenter wrote: >>> I may be missing something but I don't see how 8113bis can >>> logically cite 8113, which it replaces. >>> Frankly I think you've collectively created a plate of citation >>> spaghetti by not moving the IANA considerations for the type field >>> registry into 6830bis, which is where they naturally belong. If you >>> don't want to do that, I think you have to leave them in 8113bis and >>> simply lose the citation of 6833bis, which serves no purpose that >>> I can see. >>> Regards >>> Brian >>> On 2018-12-21 06:32, Dino Farinacci wrote: >>>> I=E2=80=99ll make that change if Brian thinks it fixes the issues he= raised. >>>> >>>> Dino >>>> ngo=20 >>>>> On Dec 19, 2018, at 11:35 PM, wrote: >>>>> >>>>> Hi Dino, >>>>> >>>>> OLD: >>>>> >>>>> Values in the "Not Assigned" range can be assigned according to >>>>> procedures in [RFC8126]. >>>>> >>>>> NEW: >>>>> >>>>> Values in the "Not Assigned" range can be assigned via Standards >>>>> Action [RFC8113]. >>>>> >>>>> Cheers, >>>>> Med >>>>> >>>>>> -----Message d'origine----- >>>>>> De : Dino Farinacci [mailto:farinacci@gmail.com] >>>>>> Envoy=C3=A9 : mercredi 19 d=C3=A9cembre 2018 19:00 >>>>>> =C3=80 : BOUCADAIR Mohamed TGI/OLN >>>>>> Cc : Joel M. Halpern; Brian E Carpenter; gen-art@ietf.org; lisp@ie= tf.org; >>>>>> draft-ietf-lisp-rfc8113bis.all@ietf.org >>>>>> Objet : Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8= 113bis-01 >>>>>> >>>>>> What does fixing in (1) mean? >>>>>> >>>>>> Dino >>>>>> >>>>>>> On Dec 19, 2018, at 3:51 AM, >>>>>> wrote: >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> Brian, whether to maintain the document standalone was discussed = by the WG. >>>>>> You may refer, for example, to the message from Deborah which clar= ifies this >>>>>> point: https://www.ietf.org/mail-archive/web/lisp/current/msg07886= =2Ehtml. One >>>>>> of the outcomes of that discussion is to add an "updates" header t= o 8113bis. >>>>>>> >>>>>>> FWIW, one of the issues that led to that conclusion was whether t= o cite >>>>>> rfc8113bis as normative in 6833bis (the approach I initially suppo= rted) and >>>>>> agreed by Dino (https://www.ietf.org/mail- >>>>>> archive/web/lisp/current/msg07882.html). Deborah convinced me that= citing >>>>>> 8113bis will lead to circular dependency. Which is a fair argument= =2E >>>>>>> >>>>>>> The "updates" tag was justified as follows: >>>>>>> >>>>>>> (1) >>>>>>> >>>>>>> RFC6833bis includes the following: >>>>>>> >>>>>>> Values in the "Not Assigned" range can be assigned according to >>>>>>> procedures in [RFC8126]. >>>>>>> >>>>>>> That text is updated by RFC8113bis to be aligned with 8113: >>>>>>> >>>>>>> Values can be assigned via Standards Action >>>>>>> >>>>>>> (2) >>>>>>> >>>>>>> RFC8113bis extends the type field to grab more bits/values when t= he >>>>>> available types are exhausted. This is captured in 8113bis: >>>>>>> >>>>>>> The values in the range 0-1023 are assigned via Standards Action= =2E >>>>>>> This range is provisioned to anticipate, in particular, the >>>>>>> exhaustion of the LISP Packet types. >>>>>>> >>>>>>> Dino: If (1) is fixed directly in RFC6833bis, then I'm fine to re= move the >>>>>> "updates" header because (2) can be also seen as an extension. >>>>>>> >>>>>>> Cheers, >>>>>>> Med >>>>>>> >>>>>>>> -----Message d'origine----- >>>>>>>> De : Dino Farinacci [mailto:farinacci@gmail.com] >>>>>>>> Envoy=C3=A9 : mercredi 19 d=C3=A9cembre 2018 06:37 >>>>>>>> =C3=80 : Joel M. Halpern >>>>>>>> Cc : Brian E Carpenter; gen-art@ietf.org; lisp@ietf.org; draft-i= etf-lisp- >>>>>>>> rfc8113bis.all@ietf.org >>>>>>>> Objet : Re: [lisp] Genart last call review of draft-ietf-lisp-rf= c8113bis- >>>>>> 01 >>>>>>>> >>>>>>>> Mohmad to comment. >>>>>>>> >>>>>>>> Dino >>>>>>>> >>>>>>>>> On Dec 18, 2018, at 8:49 PM, Joel M. Halpern wrote: >>>>>>>>> >>>>>>>>> That is the other fix he offered. Just remove the updates tag.= >>>>>>>>> I will leav eit to you and the the authors to determine which i= s correct. >>>>>>>>> Yours, >>>>>>>>> Joel >>>>>>>>> >>>>>>>>> On 12/18/18 11:43 PM, Dino Farinacci wrote: >>>>>>>>>> 8113bis should say that is it *extending* the type field so we= can have >>>>>>>> more types. The word =E2=80=9Cupdate=E2=80=9D I always had a pro= blem with because it can >>>>>> be >>>>>>>> interpreted as =E2=80=9Creplacing". Replacing something to fix a= problem. >>>>>>>>>> 8113 is simply asking for one of the type value codepoint, so = there can >>>>>> be >>>>>>>> another format to have more types. >>>>>>>>>> Dino >>>>>>>>>>> On Dec 18, 2018, at 9:24 PM, Joel M. Halpern >>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Authors: that sounds like a reasonable addition to me? >>>>>>>>>>> >>>>>>>>>>> Yours, >>>>>>>>>>> Joel >>>>>>>>>>> >>>>>>>>>>> On 12/18/18 10:48 PM, Brian E Carpenter wrote: >>>>>>>>>>>> On 2018-12-19 15:46, Joel M. Halpern wrote: >>>>>>>>>>>>> This is part of the package to move the coherent set of bas= e LISP >>>>>> specs >>>>>>>>>>>>> to PS. >>>>>>>>>>>>> >>>>>>>>>>>>> The reason we did this rather than folding it into 6830bis = / 6833bis >>>>>> is >>>>>>>>>>>>> that we had originally simply cited 8113, and then realized= that >>>>>> needed >>>>>>>>>>>>> to move to PS along with everything else. It seemed (and i= s) simpler >>>>>>>> to >>>>>>>>>>>>> do it separately rather than to further modify 6830bis / 69= 33bis. >>>>>>>>>>>>> >>>>>>>>>>>>> As for why it updates 6833bis, that is because one of the c= ahnges in >>>>>>>>>>>>> moving the set to PS was to improve the split as to which i= nformation >>>>>>>>>>>>> belonged in which document. >>>>>>>>>>>> OK, but I still don't find it logical The text doesn't expla= in which >>>>>>>> part of >>>>>>>>>>>> 6833bis is impacted, and normally these days we require such= an >>>>>>>> explanation. >>>>>>>>>>>> And if there is an impact, you're missing the opportunity of= fixing >>>>>> the >>>>>>>> error >>>>>>>>>>>> or gap in 6833bis, so the reader of 6833bis will be none the= wiser >>>>>>>> unless >>>>>>>>>>>> you insert a reference to 8113bis. >>>>>>>>>>>> On the other hand, if there is no error or gap, you don't ne= ed >>>>>>>> "Updates:" >>>>>>>>>>>> at all. (Unfortunately, we don't have an "Extends:" header.)= >>>>>>>>>>>> Brian >>>>>>>>>>>>> >>>>>>>>>>>>> Yours, >>>>>>>>>>>>> Joel >>>>>>>>>>>>> >>>>>>>>>>>>> On 12/18/18 9:25 PM, Brian Carpenter wrote: >>>>>>>>>>>>>> Reviewer: Brian Carpenter >>>>>>>>>>>>>> Review result: Ready with Issues >>>>>>>>>>>>>> >>>>>>>>>>>>>> Gen-ART Last Call review of draft-ietf-lisp-rfc8113bis-01 >>>>>>>>>>>>>> >>>>>>>>>>>>>> I am the assigned Gen-ART reviewer for this draft. The Gen= eral Area >>>>>>>>>>>>>> Review Team (Gen-ART) reviews all IETF documents being pro= cessed >>>>>>>>>>>>>> by the IESG for the IETF Chair. Please treat these commen= ts just >>>>>>>>>>>>>> like any other last call comments. >>>>>>>>>>>>>> >>>>>>>>>>>>>> For more information, please see the FAQ at >>>>>>>>>>>>>> .= >>>>>>>>>>>>>> >>>>>>>>>>>>>> Document: draft-ietf-lisp-rfc8113bis-01.txt >>>>>>>>>>>>>> Reviewer: Brian Carpenter >>>>>>>>>>>>>> Review Date: 2018-12-19 >>>>>>>>>>>>>> IETF LC End Date: 2018-12-27 >>>>>>>>>>>>>> IESG Telechat date: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Summary: Ready with issues >>>>>>>>>>>>>> -------- >>>>>>>>>>>>>> >>>>>>>>>>>>>> Comments: >>>>>>>>>>>>>> --------- >>>>>>>>>>>>>> >>>>>>>>>>>>>> I note that this is being raised from Experimental to the = standards >>>>>>>> track. >>>>>>>>>>>>>> Presumably that depends on the base LISP spec becoming PS.= >>>>>>>>>>>>>> >>>>>>>>>>>>>> Minor issues: >>>>>>>>>>>>>> ------------- >>>>>>>>>>>>>> >>>>>>>>>>>>>> "This document updates I-D.ietf-lisp-rfc6833bis." The text= doesn't >>>>>>>>>>>>>> explain which text is updated. This is in contrast to RFC8= 113, which >>>>>>>>>>>>>> explains clearly how it updates RFC6830 (*not* RFC6833). W= hy doesn't >>>>>>>>>>>>>> this draft claim to update rfc6830bis? I'm going to assume= that >>>>>>>>>>>>>> is an error. >>>>>>>>>>>>>> >>>>>>>>>>>>>> In fact, why wasn't the definition of the LISP Packet Type= s registry >>>>>>>>>>>>>> moved into the base spec (rfc6830bis)? That is where it be= longs. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Since rfc6830bis (and rfc6833bis) are still under IESG rev= iew, >>>>>>>> anything >>>>>>>>>>>>>> in them that needs updating should be updated! The fact is= that >>>>>>>> rfc8113bis >>>>>>>>>>>>>> extends rfc6830bis, which is not the same thing as "update= s". >>>>>>>>>>>>>> If the WG thinks that implementers of 6830bis need to read= 8113bis, >>>>>>>>>>>>>> there should be a normative reference in 6830bis to 8113bi= s. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> lisp mailing list >>>>>>>>>>> lisp@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/lisp >>>>>>> >>>>> >>>> >>>> >=20 >=20 From nobody Thu Dec 20 15:29:39 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACFEE131054; Thu, 20 Dec 2018 15:29:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 YBJH1NBBOZCW; Thu, 20 Dec 2018 15:29:28 -0800 (PST) Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05DB0130EE1; Thu, 20 Dec 2018 15:29:28 -0800 (PST) Received: by mail-pl1-x629.google.com with SMTP id u6so1573373plm.8; Thu, 20 Dec 2018 15:29:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=OPi73smYSR5znOA5TVSSyuIM9sFvfeKBE7HxzrgPYDE=; b=NHPXTdvgNWJzJhAKfXWae5Yhj0edeMFgFcdrIeYNLybCZuQJKyKMowhOFaaho4hW+7 AQyuKi3JzUuyAY9uV1qjjPWnmd6xD+kqzt8pliN5+9ZGsswD7UL8W1rU5zc+kbLaERWP boqCft8VLEwYL1b1Tq7/uszpJRAd6YwpmhKBvlDtXRDBZl/yCbghelbg8r1BRtaQ1uaC ELoGFYBkzpduCJ0cHRZVyf/XsgwpwgFkquY3f06hVLd9N9F2OERXr5JqKqRXeNZ8S/pG 0rkmRJqrckJQD09Ol7Q6ZAcWwzrmeOBbtgBJMENsZrSFNSllnGI061OIT2WiQNcbOP8d cztw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=OPi73smYSR5znOA5TVSSyuIM9sFvfeKBE7HxzrgPYDE=; b=l+iWqagVOsV65JDqg4McVoYoa5Cr3IwJbG4P166RaV+IJvoVqFMkja6IGjMcynv6a/ 6JbsVIBL6Wh6GdQer31QiUX1uzgYkk3V15t0ygR+0s9OsrUfque45qn/aCpyPZf8GK6l AbZI24Z/JVZKRl321Z7FOvnJDkiG5UTZUWn+kCFMmZs02Dy/eQ+zdK1PWL8GHI/NuRK9 YXsLDIyO13di5DJx44metiEeDgcJT00bZ8Zgq2WJDHJnw1H9XnNjsiuRyTmqb/MpW99K demFyH07FdHrKsjUo6jSj+oZE3BRsmXXFtsTinYICqjuEm48GAr4FTCAIeiYEov1l2Hj z+Yw== X-Gm-Message-State: AJcUukfG2BPDq3ic2q8Pw7vZU3nYeu7Hihdaqx2eiYfNiMTufcSW1Di5 jhS3rKZUmO/dWOENW5p4FUA= X-Google-Smtp-Source: ALg8bN5gaJDdz+KE0jO1Ok0Tg0FxRF97p06/O4iXtPnlJLmbj0LwHpExTCQ4/Lqg7gEHBOmdTh8Y5Q== X-Received: by 2002:a17:902:8641:: with SMTP id y1mr178789plt.159.1545348567303; Thu, 20 Dec 2018 15:29:27 -0800 (PST) Received: from [10.31.79.215] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id y6sm43105111pfd.104.2018.12.20.15.29.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Dec 2018 15:29:26 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: Date: Thu, 20 Dec 2018 15:29:25 -0800 Cc: "Joel M. Halpern" , mohamed.boucadair@orange.com, "gen-art@ietf.org" , "lisp@ietf.org" , "draft-ietf-lisp-rfc8113bis.all@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <41802D01-0195-464C-9044-9AB0B58F8B72@gmail.com> References: <154518630870.5131.10104452678736081639@ietfa.amsl.com> <407BD77D-F364-4989-A6D2-C75DF9914402@gmail.com> <9cc58af9-2bcf-89d7-a2ae-3fc80e723d78@joelhalpern.com> <787AE7BB302AE849A7480A190F8B93302E05D7D4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302E05E137@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <583bf0d5-3de8-adba-7445-54ec4779a345@joelhalpern.com> <48ED1BED-7055-4DF4-AF69-E764E5ADABDB@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01 X-BeenThere: lisp@ietf.org 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: Thu, 20 Dec 2018 23:29:31 -0000 > On 2018-12-21 09:18, Dino Farinacci wrote: >> Brian wants to drop the reference to 6833bis from 8113bis. I am fine = with that. That reference being at the top of the draft saying = =E2=80=9CUpdates 6833bis=E2=80=9D. If we remove that, he may concur. = Please confirm Brian (again). >=20 > Yes, that would resolve my concern. Thanks. >> Like I have mentioned to you before, the IETF =E2=80=9CUpdates=E2=80=9D= lingo is confusing and really not useful unless a draft replaces a = previous draft. And this is not the case here. >=20 > That's a debate for the RFC-interest list perhaps. IMHO the issue is = that "Updates" sometimes means "Extends" and sometimes means "Modifies". = "Obsoletes" sometimes also implies "Replaces", but that doesn't seem to = create confusion. Then maybe those words should be used. Dino >=20 > Thanks > Brian >=20 >>=20 >> Dino >>=20 >>> On Dec 20, 2018, at 11:58 AM, Joel M. Halpern = wrote: >>>=20 >>> Dino, Med, please confirm if I am reading the thread properly: >>>=20 >>> I believe that the proposal is to make the small change below to = 6833bis and to drop the "updates" reference from 8113bis to 6833bis. >>>=20 >>> I believe Dino's question was whether Brian agreed that the = combination suggested would address his concern. >>>=20 >>> Yours, >>> Joel >>>=20 >>> On 12/20/18 2:55 PM, Brian E Carpenter wrote: >>>> I may be missing something but I don't see how 8113bis can >>>> logically cite 8113, which it replaces. >>>> Frankly I think you've collectively created a plate of citation >>>> spaghetti by not moving the IANA considerations for the type field >>>> registry into 6830bis, which is where they naturally belong. If you >>>> don't want to do that, I think you have to leave them in 8113bis = and >>>> simply lose the citation of 6833bis, which serves no purpose that >>>> I can see. >>>> Regards >>>> Brian >>>> On 2018-12-21 06:32, Dino Farinacci wrote: >>>>> I=E2=80=99ll make that change if Brian thinks it fixes the issues = he raised. >>>>>=20 >>>>> Dino >>>>> ngo=20 >>>>>> On Dec 19, 2018, at 11:35 PM, = wrote: >>>>>>=20 >>>>>> Hi Dino, >>>>>>=20 >>>>>> OLD: >>>>>>=20 >>>>>> Values in the "Not Assigned" range can be assigned according to >>>>>> procedures in [RFC8126]. >>>>>>=20 >>>>>> NEW: >>>>>>=20 >>>>>> Values in the "Not Assigned" range can be assigned via Standards >>>>>> Action [RFC8113]. >>>>>>=20 >>>>>> Cheers, >>>>>> Med >>>>>>=20 >>>>>>> -----Message d'origine----- >>>>>>> De : Dino Farinacci [mailto:farinacci@gmail.com] >>>>>>> Envoy=C3=A9 : mercredi 19 d=C3=A9cembre 2018 19:00 >>>>>>> =C3=80 : BOUCADAIR Mohamed TGI/OLN >>>>>>> Cc : Joel M. Halpern; Brian E Carpenter; gen-art@ietf.org; = lisp@ietf.org; >>>>>>> draft-ietf-lisp-rfc8113bis.all@ietf.org >>>>>>> Objet : Re: [lisp] Genart last call review of = draft-ietf-lisp-rfc8113bis-01 >>>>>>>=20 >>>>>>> What does fixing in (1) mean? >>>>>>>=20 >>>>>>> Dino >>>>>>>=20 >>>>>>>> On Dec 19, 2018, at 3:51 AM, >>>>>>> wrote: >>>>>>>>=20 >>>>>>>> Hi all, >>>>>>>>=20 >>>>>>>> Brian, whether to maintain the document standalone was = discussed by the WG. >>>>>>> You may refer, for example, to the message from Deborah which = clarifies this >>>>>>> point: = https://www.ietf.org/mail-archive/web/lisp/current/msg07886.html. One >>>>>>> of the outcomes of that discussion is to add an "updates" header = to 8113bis. >>>>>>>>=20 >>>>>>>> FWIW, one of the issues that led to that conclusion was whether = to cite >>>>>>> rfc8113bis as normative in 6833bis (the approach I initially = supported) and >>>>>>> agreed by Dino (https://www.ietf.org/mail- >>>>>>> archive/web/lisp/current/msg07882.html). Deborah convinced me = that citing >>>>>>> 8113bis will lead to circular dependency. Which is a fair = argument. >>>>>>>>=20 >>>>>>>> The "updates" tag was justified as follows: >>>>>>>>=20 >>>>>>>> (1) >>>>>>>>=20 >>>>>>>> RFC6833bis includes the following: >>>>>>>>=20 >>>>>>>> Values in the "Not Assigned" range can be assigned according to >>>>>>>> procedures in [RFC8126]. >>>>>>>>=20 >>>>>>>> That text is updated by RFC8113bis to be aligned with 8113: >>>>>>>>=20 >>>>>>>> Values can be assigned via Standards Action >>>>>>>>=20 >>>>>>>> (2) >>>>>>>>=20 >>>>>>>> RFC8113bis extends the type field to grab more bits/values when = the >>>>>>> available types are exhausted. This is captured in 8113bis: >>>>>>>>=20 >>>>>>>> The values in the range 0-1023 are assigned via Standards = Action. >>>>>>>> This range is provisioned to anticipate, in particular, the >>>>>>>> exhaustion of the LISP Packet types. >>>>>>>>=20 >>>>>>>> Dino: If (1) is fixed directly in RFC6833bis, then I'm fine to = remove the >>>>>>> "updates" header because (2) can be also seen as an extension. >>>>>>>>=20 >>>>>>>> Cheers, >>>>>>>> Med >>>>>>>>=20 >>>>>>>>> -----Message d'origine----- >>>>>>>>> De : Dino Farinacci [mailto:farinacci@gmail.com] >>>>>>>>> Envoy=C3=A9 : mercredi 19 d=C3=A9cembre 2018 06:37 >>>>>>>>> =C3=80 : Joel M. Halpern >>>>>>>>> Cc : Brian E Carpenter; gen-art@ietf.org; lisp@ietf.org; = draft-ietf-lisp- >>>>>>>>> rfc8113bis.all@ietf.org >>>>>>>>> Objet : Re: [lisp] Genart last call review of = draft-ietf-lisp-rfc8113bis- >>>>>>> 01 >>>>>>>>>=20 >>>>>>>>> Mohmad to comment. >>>>>>>>>=20 >>>>>>>>> Dino >>>>>>>>>=20 >>>>>>>>>> On Dec 18, 2018, at 8:49 PM, Joel M. Halpern = wrote: >>>>>>>>>>=20 >>>>>>>>>> That is the other fix he offered. Just remove the updates = tag. >>>>>>>>>> I will leav eit to you and the the authors to determine which = is correct. >>>>>>>>>> Yours, >>>>>>>>>> Joel >>>>>>>>>>=20 >>>>>>>>>> On 12/18/18 11:43 PM, Dino Farinacci wrote: >>>>>>>>>>> 8113bis should say that is it *extending* the type field so = we can have >>>>>>>>> more types. The word =E2=80=9Cupdate=E2=80=9D I always had a = problem with because it can >>>>>>> be >>>>>>>>> interpreted as =E2=80=9Creplacing". Replacing something to fix = a problem. >>>>>>>>>>> 8113 is simply asking for one of the type value codepoint, = so there can >>>>>>> be >>>>>>>>> another format to have more types. >>>>>>>>>>> Dino >>>>>>>>>>>> On Dec 18, 2018, at 9:24 PM, Joel M. Halpern = >>>>>>> wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>> Authors: that sounds like a reasonable addition to me? >>>>>>>>>>>>=20 >>>>>>>>>>>> Yours, >>>>>>>>>>>> Joel >>>>>>>>>>>>=20 >>>>>>>>>>>> On 12/18/18 10:48 PM, Brian E Carpenter wrote: >>>>>>>>>>>>> On 2018-12-19 15:46, Joel M. Halpern wrote: >>>>>>>>>>>>>> This is part of the package to move the coherent set of = base LISP >>>>>>> specs >>>>>>>>>>>>>> to PS. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> The reason we did this rather than folding it into = 6830bis / 6833bis >>>>>>> is >>>>>>>>>>>>>> that we had originally simply cited 8113, and then = realized that >>>>>>> needed >>>>>>>>>>>>>> to move to PS along with everything else. It seemed (and = is) simpler >>>>>>>>> to >>>>>>>>>>>>>> do it separately rather than to further modify 6830bis / = 6933bis. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> As for why it updates 6833bis, that is because one of the = cahnges in >>>>>>>>>>>>>> moving the set to PS was to improve the split as to which = information >>>>>>>>>>>>>> belonged in which document. >>>>>>>>>>>>> OK, but I still don't find it logical The text doesn't = explain which >>>>>>>>> part of >>>>>>>>>>>>> 6833bis is impacted, and normally these days we require = such an >>>>>>>>> explanation. >>>>>>>>>>>>> And if there is an impact, you're missing the opportunity = of fixing >>>>>>> the >>>>>>>>> error >>>>>>>>>>>>> or gap in 6833bis, so the reader of 6833bis will be none = the wiser >>>>>>>>> unless >>>>>>>>>>>>> you insert a reference to 8113bis. >>>>>>>>>>>>> On the other hand, if there is no error or gap, you don't = need >>>>>>>>> "Updates:" >>>>>>>>>>>>> at all. (Unfortunately, we don't have an "Extends:" = header.) >>>>>>>>>>>>> Brian >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Yours, >>>>>>>>>>>>>> Joel >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On 12/18/18 9:25 PM, Brian Carpenter wrote: >>>>>>>>>>>>>>> Reviewer: Brian Carpenter >>>>>>>>>>>>>>> Review result: Ready with Issues >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Gen-ART Last Call review of = draft-ietf-lisp-rfc8113bis-01 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> I am the assigned Gen-ART reviewer for this draft. The = General Area >>>>>>>>>>>>>>> Review Team (Gen-ART) reviews all IETF documents being = processed >>>>>>>>>>>>>>> by the IESG for the IETF Chair. Please treat these = comments just >>>>>>>>>>>>>>> like any other last call comments. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> For more information, please see the FAQ at >>>>>>>>>>>>>>> = . >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Document: draft-ietf-lisp-rfc8113bis-01.txt >>>>>>>>>>>>>>> Reviewer: Brian Carpenter >>>>>>>>>>>>>>> Review Date: 2018-12-19 >>>>>>>>>>>>>>> IETF LC End Date: 2018-12-27 >>>>>>>>>>>>>>> IESG Telechat date: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Summary: Ready with issues >>>>>>>>>>>>>>> -------- >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Comments: >>>>>>>>>>>>>>> --------- >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> I note that this is being raised from Experimental to = the standards >>>>>>>>> track. >>>>>>>>>>>>>>> Presumably that depends on the base LISP spec becoming = PS. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Minor issues: >>>>>>>>>>>>>>> ------------- >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> "This document updates I-D.ietf-lisp-rfc6833bis." The = text doesn't >>>>>>>>>>>>>>> explain which text is updated. This is in contrast to = RFC8113, which >>>>>>>>>>>>>>> explains clearly how it updates RFC6830 (*not* RFC6833). = Why doesn't >>>>>>>>>>>>>>> this draft claim to update rfc6830bis? I'm going to = assume that >>>>>>>>>>>>>>> is an error. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> In fact, why wasn't the definition of the LISP Packet = Types registry >>>>>>>>>>>>>>> moved into the base spec (rfc6830bis)? That is where it = belongs. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Since rfc6830bis (and rfc6833bis) are still under IESG = review, >>>>>>>>> anything >>>>>>>>>>>>>>> in them that needs updating should be updated! The fact = is that >>>>>>>>> rfc8113bis >>>>>>>>>>>>>>> extends rfc6830bis, which is not the same thing as = "updates". >>>>>>>>>>>>>>> If the WG thinks that implementers of 6830bis need to = read 8113bis, >>>>>>>>>>>>>>> there should be a normative reference in 6830bis to = 8113bis. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> lisp mailing list >>>>>>>>>>>> lisp@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/lisp >>>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>=20 >>=20 >=20 From nobody Thu Dec 20 22:50:26 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE7DE12F295; Thu, 20 Dec 2018 22:50:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no 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 V1P2HJOHqH5A; Thu, 20 Dec 2018 22:50:11 -0800 (PST) Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DF23127B4C; Thu, 20 Dec 2018 22:50:11 -0800 (PST) Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 43LfQ94Nd6zFrpk; Fri, 21 Dec 2018 07:50:09 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.58]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 43LfQ92qnmzCqqs; Fri, 21 Dec 2018 07:50:09 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM33.corporate.adroot.infra.ftgroup ([fe80::3881:fc15:b4b2:9017%19]) with mapi id 14.03.0415.000; Fri, 21 Dec 2018 07:50:09 +0100 From: To: Brian E Carpenter , Dino Farinacci CC: "Joel M. Halpern" , "gen-art@ietf.org" , "lisp@ietf.org" , "draft-ietf-lisp-rfc8113bis.all@ietf.org" Thread-Topic: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01 Thread-Index: AQHUmJ4CW7p9wecXJkiATi9lcjGSNqWIwM9A Date: Fri, 21 Dec 2018 06:50:08 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302E05ECE0@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <154518630870.5131.10104452678736081639@ietfa.amsl.com> <407BD77D-F364-4989-A6D2-C75DF9914402@gmail.com> <9cc58af9-2bcf-89d7-a2ae-3fc80e723d78@joelhalpern.com> <787AE7BB302AE849A7480A190F8B93302E05D7D4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302E05E137@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01 X-BeenThere: lisp@ietf.org 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: Fri, 21 Dec 2018 06:50:15 -0000 QnJpYW4sIA0KDQpQbGVhc2Ugc2VlIGlubGluZS4gDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0t TWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBCcmlhbiBFIENhcnBlbnRlciBbbWFpbHRv OmJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbV0NCj4gRW52b3nDqcKgOiBqZXVkaSAyMCBkw6lj ZW1icmUgMjAxOCAyMDo1Ng0KPiDDgMKgOiBEaW5vIEZhcmluYWNjaTsgQk9VQ0FEQUlSIE1vaGFt ZWQgVEdJL09MTg0KPiBDY8KgOiBKb2VsIE0uIEhhbHBlcm47IGdlbi1hcnRAaWV0Zi5vcmc7IGxp c3BAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtbGlzcC0NCj4gcmZjODExM2Jpcy5hbGxAaWV0Zi5vcmcN Cj4gT2JqZXTCoDogUmU6IFtsaXNwXSBHZW5hcnQgbGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1p ZXRmLWxpc3AtcmZjODExM2Jpcy0wMQ0KPiANCj4gSSBtYXkgYmUgbWlzc2luZyBzb21ldGhpbmcg YnV0IEkgZG9uJ3Qgc2VlIGhvdyA4MTEzYmlzIGNhbg0KPiBsb2dpY2FsbHkgY2l0ZSA4MTEzLCB3 aGljaCBpdCByZXBsYWNlcy4NCj4gDQoNCltNZWRdIFRoZSBjaGFuZ2UgaXMgZm9yIDY4MzNiaXMg Tk9UIDgxMTNiaXMuIDY4MzNiaXMgYWxyZWFkeSBjaXRlcyA4MTEzLCB3aGljaCBkZXNjcmliZXMg dGhlIHJ1bGVzIGZvciBhc3NpZ25pbmcgbmV3IHR5cGVzLiANCg0KPiBGcmFua2x5IEkgdGhpbmsg eW91J3ZlIGNvbGxlY3RpdmVseSBjcmVhdGVkIGEgcGxhdGUgb2YgY2l0YXRpb24NCj4gc3BhZ2hl dHRpIGJ5IG5vdCBtb3ZpbmcgdGhlIElBTkEgY29uc2lkZXJhdGlvbnMgZm9yIHRoZSB0eXBlIGZp ZWxkDQo+IHJlZ2lzdHJ5IGludG8gNjgzMGJpcywgd2hpY2ggaXMgd2hlcmUgdGhleSBuYXR1cmFs bHkgYmVsb25nLiBJZiB5b3UNCj4gZG9uJ3Qgd2FudCB0byBkbyB0aGF0LCBJIHRoaW5rIHlvdSBo YXZlIHRvIGxlYXZlIHRoZW0gaW4gODExM2JpcyBhbmQNCj4gc2ltcGx5IGxvc2UgdGhlIGNpdGF0 aW9uIG9mIDY4MzNiaXMsIHdoaWNoIHNlcnZlcyBubyBwdXJwb3NlIHRoYXQNCj4gSSBjYW4gc2Vl Lg0KPiANCj4gUmVnYXJkcw0KPiAgICBCcmlhbg0KPiANCj4gT24gMjAxOC0xMi0yMSAwNjozMiwg RGlubyBGYXJpbmFjY2kgd3JvdGU6DQo+ID4gSeKAmWxsIG1ha2UgdGhhdCBjaGFuZ2UgaWYgQnJp YW4gdGhpbmtzIGl0IGZpeGVzIHRoZSBpc3N1ZXMgaGUgcmFpc2VkLg0KPiA+DQo+ID4gRGlubw0K PiA+DQo+ID4+IE9uIERlYyAxOSwgMjAxOCwgYXQgMTE6MzUgUE0sIDxtb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tPg0KPiA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4gd3JvdGU6DQo+ ID4+DQo+ID4+IEhpIERpbm8sDQo+ID4+DQo+ID4+IE9MRDoNCj4gPj4NCj4gPj4gICBWYWx1ZXMg aW4gdGhlICJOb3QgQXNzaWduZWQiIHJhbmdlIGNhbiBiZSBhc3NpZ25lZCBhY2NvcmRpbmcgdG8N Cj4gPj4gICBwcm9jZWR1cmVzIGluIFtSRkM4MTI2XS4NCj4gPj4NCj4gPj4gTkVXOg0KPiA+Pg0K PiA+PiAgIFZhbHVlcyBpbiB0aGUgIk5vdCBBc3NpZ25lZCIgcmFuZ2UgY2FuIGJlIGFzc2lnbmVk IHZpYSBTdGFuZGFyZHMNCj4gPj4gICBBY3Rpb24gW1JGQzgxMTNdLg0KPiA+Pg0KPiA+PiBDaGVl cnMsDQo+ID4+IE1lZA0KPiA+Pg0KPiA+Pj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ ID4+PiBEZSA6IERpbm8gRmFyaW5hY2NpIFttYWlsdG86ZmFyaW5hY2NpQGdtYWlsLmNvbV0NCj4g Pj4+IEVudm95w6kgOiBtZXJjcmVkaSAxOSBkw6ljZW1icmUgMjAxOCAxOTowMA0KPiA+Pj4gw4Ag OiBCT1VDQURBSVIgTW9oYW1lZCBUR0kvT0xODQo+ID4+PiBDYyA6IEpvZWwgTS4gSGFscGVybjsg QnJpYW4gRSBDYXJwZW50ZXI7IGdlbi1hcnRAaWV0Zi5vcmc7IGxpc3BAaWV0Zi5vcmc7DQo+ID4+ PiBkcmFmdC1pZXRmLWxpc3AtcmZjODExM2Jpcy5hbGxAaWV0Zi5vcmcNCj4gPj4+IE9iamV0IDog UmU6IFtsaXNwXSBHZW5hcnQgbGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLWxpc3AtcmZj ODExM2Jpcy0NCj4gMDENCj4gPj4+DQo+ID4+PiBXaGF0IGRvZXMgZml4aW5nIGluICgxKSBtZWFu Pw0KPiA+Pj4NCj4gPj4+IERpbm8NCj4gPj4+DQo+ID4+Pj4gT24gRGVjIDE5LCAyMDE4LCBhdCAz OjUxIEFNLCA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4NCj4gPj4+IDxtb2hhbWVkLmJv dWNhZGFpckBvcmFuZ2UuY29tPiB3cm90ZToNCj4gPj4+Pg0KPiA+Pj4+IEhpIGFsbCwNCj4gPj4+ Pg0KPiA+Pj4+IEJyaWFuLCB3aGV0aGVyIHRvIG1haW50YWluIHRoZSBkb2N1bWVudCBzdGFuZGFs b25lIHdhcyBkaXNjdXNzZWQgYnkgdGhlDQo+IFdHLg0KPiA+Pj4gWW91IG1heSByZWZlciwgZm9y IGV4YW1wbGUsIHRvIHRoZSBtZXNzYWdlIGZyb20gRGVib3JhaCB3aGljaCBjbGFyaWZpZXMNCj4g dGhpcw0KPiA+Pj4gcG9pbnQ6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIv bGlzcC9jdXJyZW50L21zZzA3ODg2Lmh0bWwuDQo+IE9uZQ0KPiA+Pj4gb2YgdGhlIG91dGNvbWVz IG9mIHRoYXQgZGlzY3Vzc2lvbiBpcyB0byBhZGQgYW4gInVwZGF0ZXMiIGhlYWRlciB0bw0KPiA4 MTEzYmlzLg0KPiA+Pj4+DQo+ID4+Pj4gRldJVywgb25lIG9mIHRoZSBpc3N1ZXMgdGhhdCBsZWQg dG8gdGhhdCBjb25jbHVzaW9uIHdhcyB3aGV0aGVyIHRvIGNpdGUNCj4gPj4+IHJmYzgxMTNiaXMg YXMgbm9ybWF0aXZlIGluIDY4MzNiaXMgKHRoZSBhcHByb2FjaCBJIGluaXRpYWxseSBzdXBwb3J0 ZWQpDQo+IGFuZA0KPiA+Pj4gYWdyZWVkIGJ5IERpbm8gKGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWwtDQo+ID4+PiBhcmNoaXZlL3dlYi9saXNwL2N1cnJlbnQvbXNnMDc4ODIuaHRtbCkuIERlYm9y YWggY29udmluY2VkIG1lIHRoYXQgY2l0aW5nDQo+ID4+PiA4MTEzYmlzIHdpbGwgbGVhZCB0byBj aXJjdWxhciBkZXBlbmRlbmN5LiBXaGljaCBpcyBhIGZhaXIgYXJndW1lbnQuDQo+ID4+Pj4NCj4g Pj4+PiBUaGUgInVwZGF0ZXMiIHRhZyB3YXMganVzdGlmaWVkIGFzIGZvbGxvd3M6DQo+ID4+Pj4N Cj4gPj4+PiAoMSkNCj4gPj4+Pg0KPiA+Pj4+IFJGQzY4MzNiaXMgaW5jbHVkZXMgdGhlIGZvbGxv d2luZzoNCj4gPj4+Pg0KPiA+Pj4+ICBWYWx1ZXMgaW4gdGhlICJOb3QgQXNzaWduZWQiIHJhbmdl IGNhbiBiZSBhc3NpZ25lZCBhY2NvcmRpbmcgdG8NCj4gPj4+PiAgcHJvY2VkdXJlcyBpbiBbUkZD ODEyNl0uDQo+ID4+Pj4NCj4gPj4+PiBUaGF0IHRleHQgaXMgdXBkYXRlZCBieSBSRkM4MTEzYmlz IHRvIGJlIGFsaWduZWQgd2l0aCA4MTEzOg0KPiA+Pj4+DQo+ID4+Pj4gIFZhbHVlcyBjYW4gYmUg YXNzaWduZWQgdmlhIFN0YW5kYXJkcyBBY3Rpb24NCj4gPj4+Pg0KPiA+Pj4+ICgyKQ0KPiA+Pj4+ DQo+ID4+Pj4gUkZDODExM2JpcyBleHRlbmRzIHRoZSB0eXBlIGZpZWxkIHRvIGdyYWIgbW9yZSBi aXRzL3ZhbHVlcyB3aGVuIHRoZQ0KPiA+Pj4gYXZhaWxhYmxlIHR5cGVzIGFyZSBleGhhdXN0ZWQu IFRoaXMgaXMgY2FwdHVyZWQgaW4gODExM2JpczoNCj4gPj4+Pg0KPiA+Pj4+ICBUaGUgdmFsdWVz IGluIHRoZSByYW5nZSAwLTEwMjMgYXJlIGFzc2lnbmVkIHZpYSBTdGFuZGFyZHMgQWN0aW9uLg0K PiA+Pj4+ICBUaGlzIHJhbmdlIGlzIHByb3Zpc2lvbmVkIHRvIGFudGljaXBhdGUsIGluIHBhcnRp Y3VsYXIsIHRoZQ0KPiA+Pj4+ICBleGhhdXN0aW9uIG9mIHRoZSBMSVNQIFBhY2tldCB0eXBlcy4N Cj4gPj4+Pg0KPiA+Pj4+IERpbm86IElmICgxKSBpcyBmaXhlZCBkaXJlY3RseSBpbiBSRkM2ODMz YmlzLCB0aGVuIEknbSBmaW5lIHRvIHJlbW92ZQ0KPiB0aGUNCj4gPj4+ICJ1cGRhdGVzIiBoZWFk ZXIgYmVjYXVzZSAoMikgY2FuIGJlIGFsc28gc2VlbiBhcyBhbiBleHRlbnNpb24uDQo+ID4+Pj4N Cj4gPj4+PiBDaGVlcnMsDQo+ID4+Pj4gTWVkDQo+ID4+Pj4NCj4gPj4+Pj4gLS0tLS1NZXNzYWdl IGQnb3JpZ2luZS0tLS0tDQo+ID4+Pj4+IERlIDogRGlubyBGYXJpbmFjY2kgW21haWx0bzpmYXJp bmFjY2lAZ21haWwuY29tXQ0KPiA+Pj4+PiBFbnZvecOpIDogbWVyY3JlZGkgMTkgZMOpY2VtYnJl IDIwMTggMDY6MzcNCj4gPj4+Pj4gw4AgOiBKb2VsIE0uIEhhbHBlcm4NCj4gPj4+Pj4gQ2MgOiBC cmlhbiBFIENhcnBlbnRlcjsgZ2VuLWFydEBpZXRmLm9yZzsgbGlzcEBpZXRmLm9yZzsgZHJhZnQt aWV0Zi0NCj4gbGlzcC0NCj4gPj4+Pj4gcmZjODExM2Jpcy5hbGxAaWV0Zi5vcmcNCj4gPj4+Pj4g T2JqZXQgOiBSZTogW2xpc3BdIEdlbmFydCBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYt bGlzcC0NCj4gcmZjODExM2Jpcy0NCj4gPj4+IDAxDQo+ID4+Pj4+DQo+ID4+Pj4+IE1vaG1hZCB0 byBjb21tZW50Lg0KPiA+Pj4+Pg0KPiA+Pj4+PiBEaW5vDQo+ID4+Pj4+DQo+ID4+Pj4+PiBPbiBE ZWMgMTgsIDIwMTgsIGF0IDg6NDkgUE0sIEpvZWwgTS4gSGFscGVybiA8am1oQGpvZWxoYWxwZXJu LmNvbT4NCj4gd3JvdGU6DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gVGhhdCBpcyB0aGUgb3RoZXIgZml4 IGhlIG9mZmVyZWQuICBKdXN0IHJlbW92ZSB0aGUgdXBkYXRlcyB0YWcuDQo+ID4+Pj4+PiBJIHdp bGwgbGVhdiBlaXQgdG8geW91IGFuZCB0aGUgdGhlIGF1dGhvcnMgdG8gZGV0ZXJtaW5lIHdoaWNo IGlzDQo+IGNvcnJlY3QuDQo+ID4+Pj4+PiBZb3VycywNCj4gPj4+Pj4+IEpvZWwNCj4gPj4+Pj4+ DQo+ID4+Pj4+PiBPbiAxMi8xOC8xOCAxMTo0MyBQTSwgRGlubyBGYXJpbmFjY2kgd3JvdGU6DQo+ ID4+Pj4+Pj4gODExM2JpcyBzaG91bGQgc2F5IHRoYXQgaXMgaXQgKmV4dGVuZGluZyogdGhlIHR5 cGUgZmllbGQgc28gd2UgY2FuDQo+IGhhdmUNCj4gPj4+Pj4gbW9yZSB0eXBlcy4gVGhlIHdvcmQg 4oCcdXBkYXRl4oCdIEkgYWx3YXlzIGhhZCBhIHByb2JsZW0gd2l0aCBiZWNhdXNlIGl0DQo+IGNh bg0KPiA+Pj4gYmUNCj4gPj4+Pj4gaW50ZXJwcmV0ZWQgYXMg4oCccmVwbGFjaW5nIi4gUmVwbGFj aW5nIHNvbWV0aGluZyB0byBmaXggYSBwcm9ibGVtLg0KPiA+Pj4+Pj4+IDgxMTMgaXMgc2ltcGx5 IGFza2luZyBmb3Igb25lIG9mIHRoZSB0eXBlIHZhbHVlIGNvZGVwb2ludCwgc28gdGhlcmUNCj4g Y2FuDQo+ID4+PiBiZQ0KPiA+Pj4+PiBhbm90aGVyIGZvcm1hdCB0byBoYXZlIG1vcmUgdHlwZXMu DQo+ID4+Pj4+Pj4gRGlubw0KPiA+Pj4+Pj4+PiBPbiBEZWMgMTgsIDIwMTgsIGF0IDk6MjQgUE0s IEpvZWwgTS4gSGFscGVybiA8am1oQGpvZWxoYWxwZXJuLmNvbT4NCj4gPj4+IHdyb3RlOg0KPiA+ Pj4+Pj4+Pg0KPiA+Pj4+Pj4+PiBBdXRob3JzOiB0aGF0IHNvdW5kcyBsaWtlIGEgcmVhc29uYWJs ZSBhZGRpdGlvbiB0byBtZT8NCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4gWW91cnMsDQo+ID4+Pj4+ Pj4+IEpvZWwNCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4gT24gMTIvMTgvMTggMTA6NDggUE0sIEJy aWFuIEUgQ2FycGVudGVyIHdyb3RlOg0KPiA+Pj4+Pj4+Pj4gT24gMjAxOC0xMi0xOSAxNTo0Niwg Sm9lbCBNLiBIYWxwZXJuIHdyb3RlOg0KPiA+Pj4+Pj4+Pj4+IFRoaXMgaXMgcGFydCBvZiB0aGUg cGFja2FnZSB0byBtb3ZlIHRoZSBjb2hlcmVudCBzZXQgb2YgYmFzZSBMSVNQDQo+ID4+PiBzcGVj cw0KPiA+Pj4+Pj4+Pj4+IHRvIFBTLg0KPiA+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4gVGhlIHJl YXNvbiB3ZSBkaWQgdGhpcyByYXRoZXIgdGhhbiBmb2xkaW5nIGl0IGludG8gNjgzMGJpcyAvDQo+ IDY4MzNiaXMNCj4gPj4+IGlzDQo+ID4+Pj4+Pj4+Pj4gdGhhdCB3ZSBoYWQgb3JpZ2luYWxseSBz aW1wbHkgY2l0ZWQgODExMywgYW5kIHRoZW4gcmVhbGl6ZWQgdGhhdA0KPiA+Pj4gbmVlZGVkDQo+ ID4+Pj4+Pj4+Pj4gdG8gbW92ZSB0byBQUyBhbG9uZyB3aXRoIGV2ZXJ5dGhpbmcgZWxzZS4gIEl0 IHNlZW1lZCAoYW5kIGlzKQ0KPiBzaW1wbGVyDQo+ID4+Pj4+IHRvDQo+ID4+Pj4+Pj4+Pj4gZG8g aXQgc2VwYXJhdGVseSByYXRoZXIgdGhhbiB0byBmdXJ0aGVyIG1vZGlmeSA2ODMwYmlzIC8gNjkz M2Jpcy4NCj4gPj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+IEFzIGZvciB3aHkgaXQgdXBkYXRlcyA2 ODMzYmlzLCB0aGF0IGlzIGJlY2F1c2Ugb25lIG9mIHRoZSBjYWhuZ2VzDQo+IGluDQo+ID4+Pj4+ Pj4+Pj4gbW92aW5nIHRoZSBzZXQgdG8gUFMgd2FzIHRvIGltcHJvdmUgdGhlIHNwbGl0IGFzIHRv IHdoaWNoDQo+IGluZm9ybWF0aW9uDQo+ID4+Pj4+Pj4+Pj4gYmVsb25nZWQgaW4gd2hpY2ggZG9j dW1lbnQuDQo+ID4+Pj4+Pj4+PiBPSywgYnV0IEkgc3RpbGwgZG9uJ3QgZmluZCBpdCBsb2dpY2Fs IFRoZSB0ZXh0IGRvZXNuJ3QgZXhwbGFpbg0KPiB3aGljaA0KPiA+Pj4+PiBwYXJ0IG9mDQo+ID4+ Pj4+Pj4+PiA2ODMzYmlzIGlzIGltcGFjdGVkLCBhbmQgbm9ybWFsbHkgdGhlc2UgZGF5cyB3ZSBy ZXF1aXJlIHN1Y2ggYW4NCj4gPj4+Pj4gZXhwbGFuYXRpb24uDQo+ID4+Pj4+Pj4+PiBBbmQgaWYg dGhlcmUgaXMgYW4gaW1wYWN0LCB5b3UncmUgbWlzc2luZyB0aGUgb3Bwb3J0dW5pdHkgb2YgZml4 aW5nDQo+ID4+PiB0aGUNCj4gPj4+Pj4gZXJyb3INCj4gPj4+Pj4+Pj4+IG9yIGdhcCBpbiA2ODMz YmlzLCBzbyB0aGUgcmVhZGVyIG9mIDY4MzNiaXMgd2lsbCBiZSBub25lIHRoZSB3aXNlcg0KPiA+ Pj4+PiB1bmxlc3MNCj4gPj4+Pj4+Pj4+IHlvdSBpbnNlcnQgYSByZWZlcmVuY2UgdG8gODExM2Jp cy4NCj4gPj4+Pj4+Pj4+IE9uIHRoZSBvdGhlciBoYW5kLCBpZiB0aGVyZSBpcyBubyBlcnJvciBv ciBnYXAsIHlvdSBkb24ndCBuZWVkDQo+ID4+Pj4+ICJVcGRhdGVzOiINCj4gPj4+Pj4+Pj4+IGF0 IGFsbC4gKFVuZm9ydHVuYXRlbHksIHdlIGRvbid0IGhhdmUgYW4gIkV4dGVuZHM6IiBoZWFkZXIu KQ0KPiA+Pj4+Pj4+Pj4gIEJyaWFuDQo+ID4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+PiBZb3VycywN Cj4gPj4+Pj4+Pj4+PiBKb2VsDQo+ID4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+PiBPbiAxMi8xOC8x OCA5OjI1IFBNLCBCcmlhbiBDYXJwZW50ZXIgd3JvdGU6DQo+ID4+Pj4+Pj4+Pj4+IFJldmlld2Vy OiBCcmlhbiBDYXJwZW50ZXINCj4gPj4+Pj4+Pj4+Pj4gUmV2aWV3IHJlc3VsdDogUmVhZHkgd2l0 aCBJc3N1ZXMNCj4gPj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4gR2VuLUFSVCBMYXN0IENhbGwg cmV2aWV3IG9mIGRyYWZ0LWlldGYtbGlzcC1yZmM4MTEzYmlzLTAxDQo+ID4+Pj4+Pj4+Pj4+DQo+ ID4+Pj4+Pj4+Pj4+IEkgYW0gdGhlIGFzc2lnbmVkIEdlbi1BUlQgcmV2aWV3ZXIgZm9yIHRoaXMg ZHJhZnQuIFRoZSBHZW5lcmFsDQo+IEFyZWENCj4gPj4+Pj4+Pj4+Pj4gUmV2aWV3IFRlYW0gKEdl bi1BUlQpIHJldmlld3MgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZA0KPiA+Pj4+ Pj4+Pj4+PiBieSB0aGUgSUVTRyBmb3IgdGhlIElFVEYgQ2hhaXIuICBQbGVhc2UgdHJlYXQgdGhl c2UgY29tbWVudHMganVzdA0KPiA+Pj4+Pj4+Pj4+PiBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwg Y29tbWVudHMuDQo+ID4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+IEZvciBtb3JlIGluZm9ybWF0 aW9uLCBwbGVhc2Ugc2VlIHRoZSBGQVEgYXQNCj4gPj4+Pj4+Pj4+Pj4gPGh0dHA6Ly93aWtpLnRv b2xzLmlldGYub3JnL2FyZWEvZ2VuL3RyYWMvd2lraS9HZW5BcnRmYXE+Lg0KPiA+Pj4+Pj4+Pj4+ Pg0KPiA+Pj4+Pj4+Pj4+PiBEb2N1bWVudDogZHJhZnQtaWV0Zi1saXNwLXJmYzgxMTNiaXMtMDEu dHh0DQo+ID4+Pj4+Pj4+Pj4+IFJldmlld2VyOiBCcmlhbiBDYXJwZW50ZXINCj4gPj4+Pj4+Pj4+ Pj4gUmV2aWV3IERhdGU6IDIwMTgtMTItMTkNCj4gPj4+Pj4+Pj4+Pj4gSUVURiBMQyBFbmQgRGF0 ZTogMjAxOC0xMi0yNw0KPiA+Pj4+Pj4+Pj4+PiBJRVNHIFRlbGVjaGF0IGRhdGU6DQo+ID4+Pj4+ Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+IFN1bW1hcnk6IFJlYWR5IHdpdGggaXNzdWVzDQo+ID4+Pj4+ Pj4+Pj4+IC0tLS0tLS0tDQo+ID4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+IENvbW1lbnRzOg0K PiA+Pj4+Pj4+Pj4+PiAtLS0tLS0tLS0NCj4gPj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4gSSBu b3RlIHRoYXQgdGhpcyBpcyBiZWluZyByYWlzZWQgZnJvbSBFeHBlcmltZW50YWwgdG8gdGhlDQo+ IHN0YW5kYXJkcw0KPiA+Pj4+PiB0cmFjay4NCj4gPj4+Pj4+Pj4+Pj4gUHJlc3VtYWJseSB0aGF0 IGRlcGVuZHMgb24gdGhlIGJhc2UgTElTUCBzcGVjIGJlY29taW5nIFBTLg0KPiA+Pj4+Pj4+Pj4+ Pg0KPiA+Pj4+Pj4+Pj4+PiBNaW5vciBpc3N1ZXM6DQo+ID4+Pj4+Pj4+Pj4+IC0tLS0tLS0tLS0t LS0NCj4gPj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4gIlRoaXMgZG9jdW1lbnQgdXBkYXRlcyBJ LUQuaWV0Zi1saXNwLXJmYzY4MzNiaXMuIiBUaGUgdGV4dA0KPiBkb2Vzbid0DQo+ID4+Pj4+Pj4+ Pj4+IGV4cGxhaW4gd2hpY2ggdGV4dCBpcyB1cGRhdGVkLiBUaGlzIGlzIGluIGNvbnRyYXN0IHRv IFJGQzgxMTMsDQo+IHdoaWNoDQo+ID4+Pj4+Pj4+Pj4+IGV4cGxhaW5zIGNsZWFybHkgaG93IGl0 IHVwZGF0ZXMgUkZDNjgzMCAoKm5vdCogUkZDNjgzMykuIFdoeQ0KPiBkb2Vzbid0DQo+ID4+Pj4+ Pj4+Pj4+IHRoaXMgZHJhZnQgY2xhaW0gdG8gdXBkYXRlIHJmYzY4MzBiaXM/IEknbSBnb2luZyB0 byBhc3N1bWUgdGhhdA0KPiA+Pj4+Pj4+Pj4+PiBpcyBhbiBlcnJvci4NCj4gPj4+Pj4+Pj4+Pj4N Cj4gPj4+Pj4+Pj4+Pj4gSW4gZmFjdCwgd2h5IHdhc24ndCB0aGUgZGVmaW5pdGlvbiBvZiB0aGUg TElTUCBQYWNrZXQgVHlwZXMNCj4gcmVnaXN0cnkNCj4gPj4+Pj4+Pj4+Pj4gbW92ZWQgaW50byB0 aGUgYmFzZSBzcGVjIChyZmM2ODMwYmlzKT8gVGhhdCBpcyB3aGVyZSBpdCBiZWxvbmdzLg0KPiA+ Pj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+PiBTaW5jZSByZmM2ODMwYmlzIChhbmQgcmZjNjgzM2Jp cykgYXJlIHN0aWxsIHVuZGVyIElFU0cgcmV2aWV3LA0KPiA+Pj4+PiBhbnl0aGluZw0KPiA+Pj4+ Pj4+Pj4+PiBpbiB0aGVtIHRoYXQgbmVlZHMgdXBkYXRpbmcgc2hvdWxkIGJlIHVwZGF0ZWQhIFRo ZSBmYWN0IGlzIHRoYXQNCj4gPj4+Pj4gcmZjODExM2Jpcw0KPiA+Pj4+Pj4+Pj4+PiBleHRlbmRz IHJmYzY4MzBiaXMsIHdoaWNoIGlzIG5vdCB0aGUgc2FtZSB0aGluZyBhcyAidXBkYXRlcyIuDQo+ ID4+Pj4+Pj4+Pj4+IElmIHRoZSBXRyB0aGlua3MgdGhhdCBpbXBsZW1lbnRlcnMgb2YgNjgzMGJp cyBuZWVkIHRvIHJlYWQNCj4gODExM2JpcywNCj4gPj4+Pj4+Pj4+Pj4gdGhlcmUgc2hvdWxkIGJl IGEgbm9ybWF0aXZlIHJlZmVyZW5jZSBpbiA2ODMwYmlzIHRvIDgxMTNiaXMuDQo+ID4+Pj4+Pj4+ Pj4+DQo+ID4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4+Pj4+ Pj4gbGlzcCBtYWlsaW5nIGxpc3QNCj4gPj4+Pj4+Pj4gbGlzcEBpZXRmLm9yZw0KPiA+Pj4+Pj4+ PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpc3ANCj4gPj4+Pg0KPiA+ Pg0KPiA+DQo+ID4NCg0K From nobody Thu Dec 20 22:51:16 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68BE1127B4C; Thu, 20 Dec 2018 22:51:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no 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 Eux-_RSP4JC2; Thu, 20 Dec 2018 22:51:11 -0800 (PST) Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11AEB12F295; Thu, 20 Dec 2018 22:51:11 -0800 (PST) Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 43LfRK3MxZz8tk7; Fri, 21 Dec 2018 07:51:09 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.43]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 43LfRK1pgczBrQH; Fri, 21 Dec 2018 07:51:09 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5F.corporate.adroot.infra.ftgroup ([fe80::e172:f13e:8be6:71cc%18]) with mapi id 14.03.0415.000; Fri, 21 Dec 2018 07:51:08 +0100 From: To: "Joel M. Halpern" , Brian E Carpenter , Dino Farinacci CC: "gen-art@ietf.org" , "lisp@ietf.org" , "draft-ietf-lisp-rfc8113bis.all@ietf.org" Thread-Topic: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01 Thread-Index: AQHUmJ5hTWzXjFvIOEW2b3A6zGg1AKWIwbZg Date: Fri, 21 Dec 2018 06:51:08 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302E05ECF6@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <154518630870.5131.10104452678736081639@ietfa.amsl.com> <407BD77D-F364-4989-A6D2-C75DF9914402@gmail.com> <9cc58af9-2bcf-89d7-a2ae-3fc80e723d78@joelhalpern.com> <787AE7BB302AE849A7480A190F8B93302E05D7D4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302E05E137@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <583bf0d5-3de8-adba-7445-54ec4779a345@joelhalpern.com> In-Reply-To: <583bf0d5-3de8-adba-7445-54ec4779a345@joelhalpern.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01 X-BeenThere: lisp@ietf.org 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: Fri, 21 Dec 2018 06:51:15 -0000 SSBjb25maXJtLiANCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0t LS0tDQo+IERlwqA6IEpvZWwgTS4gSGFscGVybiBbbWFpbHRvOmptaEBqb2VsaGFscGVybi5jb21d DQo+IEVudm95w6nCoDogamV1ZGkgMjAgZMOpY2VtYnJlIDIwMTggMjA6NTgNCj4gw4DCoDogQnJp YW4gRSBDYXJwZW50ZXI7IERpbm8gRmFyaW5hY2NpOyBCT1VDQURBSVIgTW9oYW1lZCBUR0kvT0xO DQo+IENjwqA6IEpvZWwgTS4gSGFscGVybjsgZ2VuLWFydEBpZXRmLm9yZzsgbGlzcEBpZXRmLm9y ZzsgZHJhZnQtaWV0Zi1saXNwLQ0KPiByZmM4MTEzYmlzLmFsbEBpZXRmLm9yZw0KPiBPYmpldMKg OiBSZTogW2xpc3BdIEdlbmFydCBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtbGlzcC1y ZmM4MTEzYmlzLTAxDQo+IA0KPiBEaW5vLCBNZWQsIHBsZWFzZSBjb25maXJtIGlmIEkgYW0gcmVh ZGluZyB0aGUgdGhyZWFkIHByb3Blcmx5Og0KPiANCj4gSSBiZWxpZXZlIHRoYXQgdGhlIHByb3Bv c2FsIGlzIHRvIG1ha2UgdGhlIHNtYWxsIGNoYW5nZSBiZWxvdyB0byA2ODMzYmlzDQo+IGFuZCB0 byBkcm9wIHRoZSAidXBkYXRlcyIgcmVmZXJlbmNlIGZyb20gODExM2JpcyB0byA2ODMzYmlzLg0K PiANCj4gSSBiZWxpZXZlIERpbm8ncyBxdWVzdGlvbiB3YXMgd2hldGhlciBCcmlhbiBhZ3JlZWQg dGhhdCB0aGUgY29tYmluYXRpb24NCj4gc3VnZ2VzdGVkIHdvdWxkIGFkZHJlc3MgaGlzIGNvbmNl cm4uDQo+IA0KPiBZb3VycywNCj4gSm9lbA0KPiANCj4gT24gMTIvMjAvMTggMjo1NSBQTSwgQnJp YW4gRSBDYXJwZW50ZXIgd3JvdGU6DQo+ID4gSSBtYXkgYmUgbWlzc2luZyBzb21ldGhpbmcgYnV0 IEkgZG9uJ3Qgc2VlIGhvdyA4MTEzYmlzIGNhbg0KPiA+IGxvZ2ljYWxseSBjaXRlIDgxMTMsIHdo aWNoIGl0IHJlcGxhY2VzLg0KPiA+DQo+ID4gRnJhbmtseSBJIHRoaW5rIHlvdSd2ZSBjb2xsZWN0 aXZlbHkgY3JlYXRlZCBhIHBsYXRlIG9mIGNpdGF0aW9uDQo+ID4gc3BhZ2hldHRpIGJ5IG5vdCBt b3ZpbmcgdGhlIElBTkEgY29uc2lkZXJhdGlvbnMgZm9yIHRoZSB0eXBlIGZpZWxkDQo+ID4gcmVn aXN0cnkgaW50byA2ODMwYmlzLCB3aGljaCBpcyB3aGVyZSB0aGV5IG5hdHVyYWxseSBiZWxvbmcu IElmIHlvdQ0KPiA+IGRvbid0IHdhbnQgdG8gZG8gdGhhdCwgSSB0aGluayB5b3UgaGF2ZSB0byBs ZWF2ZSB0aGVtIGluIDgxMTNiaXMgYW5kDQo+ID4gc2ltcGx5IGxvc2UgdGhlIGNpdGF0aW9uIG9m IDY4MzNiaXMsIHdoaWNoIHNlcnZlcyBubyBwdXJwb3NlIHRoYXQNCj4gPiBJIGNhbiBzZWUuDQo+ ID4NCj4gPiBSZWdhcmRzDQo+ID4gICAgIEJyaWFuDQo+ID4NCj4gPiBPbiAyMDE4LTEyLTIxIDA2 OjMyLCBEaW5vIEZhcmluYWNjaSB3cm90ZToNCj4gPj4gSeKAmWxsIG1ha2UgdGhhdCBjaGFuZ2Ug aWYgQnJpYW4gdGhpbmtzIGl0IGZpeGVzIHRoZSBpc3N1ZXMgaGUgcmFpc2VkLg0KPiA+Pg0KPiA+ PiBEaW5vDQo+ID4+DQo+ID4+PiBPbiBEZWMgMTksIDIwMTgsIGF0IDExOjM1IFBNLCA8bW9oYW1l ZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4NCj4gPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+ IHdyb3RlOg0KPiA+Pj4NCj4gPj4+IEhpIERpbm8sDQo+ID4+Pg0KPiA+Pj4gT0xEOg0KPiA+Pj4N Cj4gPj4+ICAgIFZhbHVlcyBpbiB0aGUgIk5vdCBBc3NpZ25lZCIgcmFuZ2UgY2FuIGJlIGFzc2ln bmVkIGFjY29yZGluZyB0bw0KPiA+Pj4gICAgcHJvY2VkdXJlcyBpbiBbUkZDODEyNl0uDQo+ID4+ Pg0KPiA+Pj4gTkVXOg0KPiA+Pj4NCj4gPj4+ICAgIFZhbHVlcyBpbiB0aGUgIk5vdCBBc3NpZ25l ZCIgcmFuZ2UgY2FuIGJlIGFzc2lnbmVkIHZpYSBTdGFuZGFyZHMNCj4gPj4+ICAgIEFjdGlvbiBb UkZDODExM10uDQo+ID4+Pg0KPiA+Pj4gQ2hlZXJzLA0KPiA+Pj4gTWVkDQo+ID4+Pg0KPiA+Pj4+ IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiA+Pj4+IERlIDogRGlubyBGYXJpbmFjY2kg W21haWx0bzpmYXJpbmFjY2lAZ21haWwuY29tXQ0KPiA+Pj4+IEVudm95w6kgOiBtZXJjcmVkaSAx OSBkw6ljZW1icmUgMjAxOCAxOTowMA0KPiA+Pj4+IMOAIDogQk9VQ0FEQUlSIE1vaGFtZWQgVEdJ L09MTg0KPiA+Pj4+IENjIDogSm9lbCBNLiBIYWxwZXJuOyBCcmlhbiBFIENhcnBlbnRlcjsgZ2Vu LWFydEBpZXRmLm9yZzsNCj4gbGlzcEBpZXRmLm9yZzsNCj4gPj4+PiBkcmFmdC1pZXRmLWxpc3At cmZjODExM2Jpcy5hbGxAaWV0Zi5vcmcNCj4gPj4+PiBPYmpldCA6IFJlOiBbbGlzcF0gR2VuYXJ0 IGxhc3QgY2FsbCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1saXNwLQ0KPiByZmM4MTEzYmlzLTAxDQo+ ID4+Pj4NCj4gPj4+PiBXaGF0IGRvZXMgZml4aW5nIGluICgxKSBtZWFuPw0KPiA+Pj4+DQo+ID4+ Pj4gRGlubw0KPiA+Pj4+DQo+ID4+Pj4+IE9uIERlYyAxOSwgMjAxOCwgYXQgMzo1MSBBTSwgPG1v aGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+DQo+ID4+Pj4gPG1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb20+IHdyb3RlOg0KPiA+Pj4+Pg0KPiA+Pj4+PiBIaSBhbGwsDQo+ID4+Pj4+DQo+ID4+ Pj4+IEJyaWFuLCB3aGV0aGVyIHRvIG1haW50YWluIHRoZSBkb2N1bWVudCBzdGFuZGFsb25lIHdh cyBkaXNjdXNzZWQgYnkgdGhlDQo+IFdHLg0KPiA+Pj4+IFlvdSBtYXkgcmVmZXIsIGZvciBleGFt cGxlLCB0byB0aGUgbWVzc2FnZSBmcm9tIERlYm9yYWggd2hpY2ggY2xhcmlmaWVzDQo+IHRoaXMN Cj4gPj4+PiBwb2ludDogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9saXNw L2N1cnJlbnQvbXNnMDc4ODYuaHRtbC4NCj4gT25lDQo+ID4+Pj4gb2YgdGhlIG91dGNvbWVzIG9m IHRoYXQgZGlzY3Vzc2lvbiBpcyB0byBhZGQgYW4gInVwZGF0ZXMiIGhlYWRlciB0bw0KPiA4MTEz YmlzLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBGV0lXLCBvbmUgb2YgdGhlIGlzc3VlcyB0aGF0IGxlZCB0 byB0aGF0IGNvbmNsdXNpb24gd2FzIHdoZXRoZXIgdG8gY2l0ZQ0KPiA+Pj4+IHJmYzgxMTNiaXMg YXMgbm9ybWF0aXZlIGluIDY4MzNiaXMgKHRoZSBhcHByb2FjaCBJIGluaXRpYWxseSBzdXBwb3J0 ZWQpDQo+IGFuZA0KPiA+Pj4+IGFncmVlZCBieSBEaW5vIChodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsLQ0KPiA+Pj4+IGFyY2hpdmUvd2ViL2xpc3AvY3VycmVudC9tc2cwNzg4Mi5odG1sKS4gRGVi b3JhaCBjb252aW5jZWQgbWUgdGhhdA0KPiBjaXRpbmcNCj4gPj4+PiA4MTEzYmlzIHdpbGwgbGVh ZCB0byBjaXJjdWxhciBkZXBlbmRlbmN5LiBXaGljaCBpcyBhIGZhaXIgYXJndW1lbnQuDQo+ID4+ Pj4+DQo+ID4+Pj4+IFRoZSAidXBkYXRlcyIgdGFnIHdhcyBqdXN0aWZpZWQgYXMgZm9sbG93czoN Cj4gPj4+Pj4NCj4gPj4+Pj4gKDEpDQo+ID4+Pj4+DQo+ID4+Pj4+IFJGQzY4MzNiaXMgaW5jbHVk ZXMgdGhlIGZvbGxvd2luZzoNCj4gPj4+Pj4NCj4gPj4+Pj4gICBWYWx1ZXMgaW4gdGhlICJOb3Qg QXNzaWduZWQiIHJhbmdlIGNhbiBiZSBhc3NpZ25lZCBhY2NvcmRpbmcgdG8NCj4gPj4+Pj4gICBw cm9jZWR1cmVzIGluIFtSRkM4MTI2XS4NCj4gPj4+Pj4NCj4gPj4+Pj4gVGhhdCB0ZXh0IGlzIHVw ZGF0ZWQgYnkgUkZDODExM2JpcyB0byBiZSBhbGlnbmVkIHdpdGggODExMzoNCj4gPj4+Pj4NCj4g Pj4+Pj4gICBWYWx1ZXMgY2FuIGJlIGFzc2lnbmVkIHZpYSBTdGFuZGFyZHMgQWN0aW9uDQo+ID4+ Pj4+DQo+ID4+Pj4+ICgyKQ0KPiA+Pj4+Pg0KPiA+Pj4+PiBSRkM4MTEzYmlzIGV4dGVuZHMgdGhl IHR5cGUgZmllbGQgdG8gZ3JhYiBtb3JlIGJpdHMvdmFsdWVzIHdoZW4gdGhlDQo+ID4+Pj4gYXZh aWxhYmxlIHR5cGVzIGFyZSBleGhhdXN0ZWQuIFRoaXMgaXMgY2FwdHVyZWQgaW4gODExM2JpczoN Cj4gPj4+Pj4NCj4gPj4+Pj4gICBUaGUgdmFsdWVzIGluIHRoZSByYW5nZSAwLTEwMjMgYXJlIGFz c2lnbmVkIHZpYSBTdGFuZGFyZHMgQWN0aW9uLg0KPiA+Pj4+PiAgIFRoaXMgcmFuZ2UgaXMgcHJv dmlzaW9uZWQgdG8gYW50aWNpcGF0ZSwgaW4gcGFydGljdWxhciwgdGhlDQo+ID4+Pj4+ICAgZXho YXVzdGlvbiBvZiB0aGUgTElTUCBQYWNrZXQgdHlwZXMuDQo+ID4+Pj4+DQo+ID4+Pj4+IERpbm86 IElmICgxKSBpcyBmaXhlZCBkaXJlY3RseSBpbiBSRkM2ODMzYmlzLCB0aGVuIEknbSBmaW5lIHRv IHJlbW92ZQ0KPiB0aGUNCj4gPj4+PiAidXBkYXRlcyIgaGVhZGVyIGJlY2F1c2UgKDIpIGNhbiBi ZSBhbHNvIHNlZW4gYXMgYW4gZXh0ZW5zaW9uLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBDaGVlcnMsDQo+ ID4+Pj4+IE1lZA0KPiA+Pj4+Pg0KPiA+Pj4+Pj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0t DQo+ID4+Pj4+PiBEZSA6IERpbm8gRmFyaW5hY2NpIFttYWlsdG86ZmFyaW5hY2NpQGdtYWlsLmNv bV0NCj4gPj4+Pj4+IEVudm95w6kgOiBtZXJjcmVkaSAxOSBkw6ljZW1icmUgMjAxOCAwNjozNw0K PiA+Pj4+Pj4gw4AgOiBKb2VsIE0uIEhhbHBlcm4NCj4gPj4+Pj4+IENjIDogQnJpYW4gRSBDYXJw ZW50ZXI7IGdlbi1hcnRAaWV0Zi5vcmc7IGxpc3BAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtDQo+IGxp c3AtDQo+ID4+Pj4+PiByZmM4MTEzYmlzLmFsbEBpZXRmLm9yZw0KPiA+Pj4+Pj4gT2JqZXQgOiBS ZTogW2xpc3BdIEdlbmFydCBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtbGlzcC0NCj4g cmZjODExM2Jpcy0NCj4gPj4+PiAwMQ0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IE1vaG1hZCB0byBjb21t ZW50Lg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IERpbm8NCj4gPj4+Pj4+DQo+ID4+Pj4+Pj4gT24gRGVj IDE4LCAyMDE4LCBhdCA4OjQ5IFBNLCBKb2VsIE0uIEhhbHBlcm4gPGptaEBqb2VsaGFscGVybi5j b20+DQo+IHdyb3RlOg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gVGhhdCBpcyB0aGUgb3RoZXIgZml4 IGhlIG9mZmVyZWQuICBKdXN0IHJlbW92ZSB0aGUgdXBkYXRlcyB0YWcuDQo+ID4+Pj4+Pj4gSSB3 aWxsIGxlYXYgZWl0IHRvIHlvdSBhbmQgdGhlIHRoZSBhdXRob3JzIHRvIGRldGVybWluZSB3aGlj aCBpcw0KPiBjb3JyZWN0Lg0KPiA+Pj4+Pj4+IFlvdXJzLA0KPiA+Pj4+Pj4+IEpvZWwNCj4gPj4+ Pj4+Pg0KPiA+Pj4+Pj4+IE9uIDEyLzE4LzE4IDExOjQzIFBNLCBEaW5vIEZhcmluYWNjaSB3cm90 ZToNCj4gPj4+Pj4+Pj4gODExM2JpcyBzaG91bGQgc2F5IHRoYXQgaXMgaXQgKmV4dGVuZGluZyog dGhlIHR5cGUgZmllbGQgc28gd2UgY2FuDQo+IGhhdmUNCj4gPj4+Pj4+IG1vcmUgdHlwZXMuIFRo ZSB3b3JkIOKAnHVwZGF0ZeKAnSBJIGFsd2F5cyBoYWQgYSBwcm9ibGVtIHdpdGggYmVjYXVzZSBp dA0KPiBjYW4NCj4gPj4+PiBiZQ0KPiA+Pj4+Pj4gaW50ZXJwcmV0ZWQgYXMg4oCccmVwbGFjaW5n Ii4gUmVwbGFjaW5nIHNvbWV0aGluZyB0byBmaXggYSBwcm9ibGVtLg0KPiA+Pj4+Pj4+PiA4MTEz IGlzIHNpbXBseSBhc2tpbmcgZm9yIG9uZSBvZiB0aGUgdHlwZSB2YWx1ZSBjb2RlcG9pbnQsIHNv IHRoZXJlDQo+IGNhbg0KPiA+Pj4+IGJlDQo+ID4+Pj4+PiBhbm90aGVyIGZvcm1hdCB0byBoYXZl IG1vcmUgdHlwZXMuDQo+ID4+Pj4+Pj4+IERpbm8NCj4gPj4+Pj4+Pj4+IE9uIERlYyAxOCwgMjAx OCwgYXQgOToyNCBQTSwgSm9lbCBNLiBIYWxwZXJuIDxqbWhAam9lbGhhbHBlcm4uY29tPg0KPiA+ Pj4+IHdyb3RlOg0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+IEF1dGhvcnM6IHRoYXQgc291bmRz IGxpa2UgYSByZWFzb25hYmxlIGFkZGl0aW9uIHRvIG1lPw0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+ Pj4+IFlvdXJzLA0KPiA+Pj4+Pj4+Pj4gSm9lbA0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+IE9u IDEyLzE4LzE4IDEwOjQ4IFBNLCBCcmlhbiBFIENhcnBlbnRlciB3cm90ZToNCj4gPj4+Pj4+Pj4+ PiBPbiAyMDE4LTEyLTE5IDE1OjQ2LCBKb2VsIE0uIEhhbHBlcm4gd3JvdGU6DQo+ID4+Pj4+Pj4+ Pj4+IFRoaXMgaXMgcGFydCBvZiB0aGUgcGFja2FnZSB0byBtb3ZlIHRoZSBjb2hlcmVudCBzZXQg b2YgYmFzZSBMSVNQDQo+ID4+Pj4gc3BlY3MNCj4gPj4+Pj4+Pj4+Pj4gdG8gUFMuDQo+ID4+Pj4+ Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+IFRoZSByZWFzb24gd2UgZGlkIHRoaXMgcmF0aGVyIHRoYW4g Zm9sZGluZyBpdCBpbnRvIDY4MzBiaXMgLw0KPiA2ODMzYmlzDQo+ID4+Pj4gaXMNCj4gPj4+Pj4+ Pj4+Pj4gdGhhdCB3ZSBoYWQgb3JpZ2luYWxseSBzaW1wbHkgY2l0ZWQgODExMywgYW5kIHRoZW4g cmVhbGl6ZWQgdGhhdA0KPiA+Pj4+IG5lZWRlZA0KPiA+Pj4+Pj4+Pj4+PiB0byBtb3ZlIHRvIFBT IGFsb25nIHdpdGggZXZlcnl0aGluZyBlbHNlLiAgSXQgc2VlbWVkIChhbmQgaXMpDQo+IHNpbXBs ZXINCj4gPj4+Pj4+IHRvDQo+ID4+Pj4+Pj4+Pj4+IGRvIGl0IHNlcGFyYXRlbHkgcmF0aGVyIHRo YW4gdG8gZnVydGhlciBtb2RpZnkgNjgzMGJpcyAvIDY5MzNiaXMuDQo+ID4+Pj4+Pj4+Pj4+DQo+ ID4+Pj4+Pj4+Pj4+IEFzIGZvciB3aHkgaXQgdXBkYXRlcyA2ODMzYmlzLCB0aGF0IGlzIGJlY2F1 c2Ugb25lIG9mIHRoZSBjYWhuZ2VzDQo+IGluDQo+ID4+Pj4+Pj4+Pj4+IG1vdmluZyB0aGUgc2V0 IHRvIFBTIHdhcyB0byBpbXByb3ZlIHRoZSBzcGxpdCBhcyB0byB3aGljaA0KPiBpbmZvcm1hdGlv bg0KPiA+Pj4+Pj4+Pj4+PiBiZWxvbmdlZCBpbiB3aGljaCBkb2N1bWVudC4NCj4gPj4+Pj4+Pj4+ PiBPSywgYnV0IEkgc3RpbGwgZG9uJ3QgZmluZCBpdCBsb2dpY2FsIFRoZSB0ZXh0IGRvZXNuJ3Qg ZXhwbGFpbg0KPiB3aGljaA0KPiA+Pj4+Pj4gcGFydCBvZg0KPiA+Pj4+Pj4+Pj4+IDY4MzNiaXMg aXMgaW1wYWN0ZWQsIGFuZCBub3JtYWxseSB0aGVzZSBkYXlzIHdlIHJlcXVpcmUgc3VjaCBhbg0K PiA+Pj4+Pj4gZXhwbGFuYXRpb24uDQo+ID4+Pj4+Pj4+Pj4gQW5kIGlmIHRoZXJlIGlzIGFuIGlt cGFjdCwgeW91J3JlIG1pc3NpbmcgdGhlIG9wcG9ydHVuaXR5IG9mDQo+IGZpeGluZw0KPiA+Pj4+ IHRoZQ0KPiA+Pj4+Pj4gZXJyb3INCj4gPj4+Pj4+Pj4+PiBvciBnYXAgaW4gNjgzM2Jpcywgc28g dGhlIHJlYWRlciBvZiA2ODMzYmlzIHdpbGwgYmUgbm9uZSB0aGUgd2lzZXINCj4gPj4+Pj4+IHVu bGVzcw0KPiA+Pj4+Pj4+Pj4+IHlvdSBpbnNlcnQgYSByZWZlcmVuY2UgdG8gODExM2Jpcy4NCj4g Pj4+Pj4+Pj4+PiBPbiB0aGUgb3RoZXIgaGFuZCwgaWYgdGhlcmUgaXMgbm8gZXJyb3Igb3IgZ2Fw LCB5b3UgZG9uJ3QgbmVlZA0KPiA+Pj4+Pj4gIlVwZGF0ZXM6Ig0KPiA+Pj4+Pj4+Pj4+IGF0IGFs bC4gKFVuZm9ydHVuYXRlbHksIHdlIGRvbid0IGhhdmUgYW4gIkV4dGVuZHM6IiBoZWFkZXIuKQ0K PiA+Pj4+Pj4+Pj4+ICAgQnJpYW4NCj4gPj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4gWW91cnMs DQo+ID4+Pj4+Pj4+Pj4+IEpvZWwNCj4gPj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4gT24gMTIv MTgvMTggOToyNSBQTSwgQnJpYW4gQ2FycGVudGVyIHdyb3RlOg0KPiA+Pj4+Pj4+Pj4+Pj4gUmV2 aWV3ZXI6IEJyaWFuIENhcnBlbnRlcg0KPiA+Pj4+Pj4+Pj4+Pj4gUmV2aWV3IHJlc3VsdDogUmVh ZHkgd2l0aCBJc3N1ZXMNCj4gPj4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+PiBHZW4tQVJUIExh c3QgQ2FsbCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1saXNwLXJmYzgxMTNiaXMtMDENCj4gPj4+Pj4+ Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+PiBJIGFtIHRoZSBhc3NpZ25lZCBHZW4tQVJUIHJldmlld2Vy IGZvciB0aGlzIGRyYWZ0LiBUaGUgR2VuZXJhbA0KPiBBcmVhDQo+ID4+Pj4+Pj4+Pj4+PiBSZXZp ZXcgVGVhbSAoR2VuLUFSVCkgcmV2aWV3cyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vz c2VkDQo+ID4+Pj4+Pj4+Pj4+PiBieSB0aGUgSUVTRyBmb3IgdGhlIElFVEYgQ2hhaXIuICBQbGVh c2UgdHJlYXQgdGhlc2UgY29tbWVudHMNCj4ganVzdA0KPiA+Pj4+Pj4+Pj4+Pj4gbGlrZSBhbnkg b3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0KPiA+Pj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4+ IEZvciBtb3JlIGluZm9ybWF0aW9uLCBwbGVhc2Ugc2VlIHRoZSBGQVEgYXQNCj4gPj4+Pj4+Pj4+ Pj4+IDxodHRwOi8vd2lraS50b29scy5pZXRmLm9yZy9hcmVhL2dlbi90cmFjL3dpa2kvR2VuQXJ0 ZmFxPi4NCj4gPj4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+PiBEb2N1bWVudDogZHJhZnQtaWV0 Zi1saXNwLXJmYzgxMTNiaXMtMDEudHh0DQo+ID4+Pj4+Pj4+Pj4+PiBSZXZpZXdlcjogQnJpYW4g Q2FycGVudGVyDQo+ID4+Pj4+Pj4+Pj4+PiBSZXZpZXcgRGF0ZTogMjAxOC0xMi0xOQ0KPiA+Pj4+ Pj4+Pj4+Pj4gSUVURiBMQyBFbmQgRGF0ZTogMjAxOC0xMi0yNw0KPiA+Pj4+Pj4+Pj4+Pj4gSUVT RyBUZWxlY2hhdCBkYXRlOg0KPiA+Pj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4+IFN1bW1hcnk6 IFJlYWR5IHdpdGggaXNzdWVzDQo+ID4+Pj4+Pj4+Pj4+PiAtLS0tLS0tLQ0KPiA+Pj4+Pj4+Pj4+ Pj4NCj4gPj4+Pj4+Pj4+Pj4+IENvbW1lbnRzOg0KPiA+Pj4+Pj4+Pj4+Pj4gLS0tLS0tLS0tDQo+ ID4+Pj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+Pj4gSSBub3RlIHRoYXQgdGhpcyBpcyBiZWluZyBy YWlzZWQgZnJvbSBFeHBlcmltZW50YWwgdG8gdGhlDQo+IHN0YW5kYXJkcw0KPiA+Pj4+Pj4gdHJh Y2suDQo+ID4+Pj4+Pj4+Pj4+PiBQcmVzdW1hYmx5IHRoYXQgZGVwZW5kcyBvbiB0aGUgYmFzZSBM SVNQIHNwZWMgYmVjb21pbmcgUFMuDQo+ID4+Pj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+Pj4gTWlu b3IgaXNzdWVzOg0KPiA+Pj4+Pj4+Pj4+Pj4gLS0tLS0tLS0tLS0tLQ0KPiA+Pj4+Pj4+Pj4+Pj4N Cj4gPj4+Pj4+Pj4+Pj4+ICJUaGlzIGRvY3VtZW50IHVwZGF0ZXMgSS1ELmlldGYtbGlzcC1yZmM2 ODMzYmlzLiIgVGhlIHRleHQNCj4gZG9lc24ndA0KPiA+Pj4+Pj4+Pj4+Pj4gZXhwbGFpbiB3aGlj aCB0ZXh0IGlzIHVwZGF0ZWQuIFRoaXMgaXMgaW4gY29udHJhc3QgdG8gUkZDODExMywNCj4gd2hp Y2gNCj4gPj4+Pj4+Pj4+Pj4+IGV4cGxhaW5zIGNsZWFybHkgaG93IGl0IHVwZGF0ZXMgUkZDNjgz MCAoKm5vdCogUkZDNjgzMykuIFdoeQ0KPiBkb2Vzbid0DQo+ID4+Pj4+Pj4+Pj4+PiB0aGlzIGRy YWZ0IGNsYWltIHRvIHVwZGF0ZSByZmM2ODMwYmlzPyBJJ20gZ29pbmcgdG8gYXNzdW1lIHRoYXQN Cj4gPj4+Pj4+Pj4+Pj4+IGlzIGFuIGVycm9yLg0KPiA+Pj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+ Pj4+IEluIGZhY3QsIHdoeSB3YXNuJ3QgdGhlIGRlZmluaXRpb24gb2YgdGhlIExJU1AgUGFja2V0 IFR5cGVzDQo+IHJlZ2lzdHJ5DQo+ID4+Pj4+Pj4+Pj4+PiBtb3ZlZCBpbnRvIHRoZSBiYXNlIHNw ZWMgKHJmYzY4MzBiaXMpPyBUaGF0IGlzIHdoZXJlIGl0IGJlbG9uZ3MuDQo+ID4+Pj4+Pj4+Pj4+ Pg0KPiA+Pj4+Pj4+Pj4+Pj4gU2luY2UgcmZjNjgzMGJpcyAoYW5kIHJmYzY4MzNiaXMpIGFyZSBz dGlsbCB1bmRlciBJRVNHIHJldmlldywNCj4gPj4+Pj4+IGFueXRoaW5nDQo+ID4+Pj4+Pj4+Pj4+ PiBpbiB0aGVtIHRoYXQgbmVlZHMgdXBkYXRpbmcgc2hvdWxkIGJlIHVwZGF0ZWQhIFRoZSBmYWN0 IGlzIHRoYXQNCj4gPj4+Pj4+IHJmYzgxMTNiaXMNCj4gPj4+Pj4+Pj4+Pj4+IGV4dGVuZHMgcmZj NjgzMGJpcywgd2hpY2ggaXMgbm90IHRoZSBzYW1lIHRoaW5nIGFzICJ1cGRhdGVzIi4NCj4gPj4+ Pj4+Pj4+Pj4+IElmIHRoZSBXRyB0aGlua3MgdGhhdCBpbXBsZW1lbnRlcnMgb2YgNjgzMGJpcyBu ZWVkIHRvIHJlYWQNCj4gODExM2JpcywNCj4gPj4+Pj4+Pj4+Pj4+IHRoZXJlIHNob3VsZCBiZSBh IG5vcm1hdGl2ZSByZWZlcmVuY2UgaW4gNjgzMGJpcyB0byA4MTEzYmlzLg0KPiA+Pj4+Pj4+Pj4+ Pj4NCj4gPj4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+ Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4+ Pj4+Pj4+IGxpc3AgbWFpbGluZyBsaXN0DQo+ID4+Pj4+Pj4+PiBsaXNwQGlldGYub3JnDQo+ID4+ Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpc3ANCj4gPj4+ Pj4NCj4gPj4+DQo+ID4+DQo+ID4+DQo+ID4NCg== From nobody Thu Dec 20 22:57:13 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ADA512D4E7; Thu, 20 Dec 2018 22:57:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no 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 K_MkBquHH4RO; Thu, 20 Dec 2018 22:57:09 -0800 (PST) Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3006127B4C; Thu, 20 Dec 2018 22:57:08 -0800 (PST) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 43LfZC2sGrzFqbW; Fri, 21 Dec 2018 07:57:07 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.59]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 43LfZC1MYrzCqkM; Fri, 21 Dec 2018 07:57:07 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c%19]) with mapi id 14.03.0415.000; Fri, 21 Dec 2018 07:57:06 +0100 From: To: Dino Farinacci , Brian E Carpenter CC: "Joel M. Halpern" , "gen-art@ietf.org" , "lisp@ietf.org" , "draft-ietf-lisp-rfc8113bis.all@ietf.org" Thread-Topic: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01 Thread-Index: AQHUmLvbCwfwx6VMa06162KZncjK06WIwf9g Date: Fri, 21 Dec 2018 06:57:06 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302E05ED1C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <154518630870.5131.10104452678736081639@ietfa.amsl.com> <407BD77D-F364-4989-A6D2-C75DF9914402@gmail.com> <9cc58af9-2bcf-89d7-a2ae-3fc80e723d78@joelhalpern.com> <787AE7BB302AE849A7480A190F8B93302E05D7D4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302E05E137@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <583bf0d5-3de8-adba-7445-54ec4779a345@joelhalpern.com> <48ED1BED-7055-4DF4-AF69-E764E5ADABDB@gmail.com> <41802D01-0195-464C-9044-9AB0B58F8B72@gmail.com> In-Reply-To: <41802D01-0195-464C-9044-9AB0B58F8B72@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01 X-BeenThere: lisp@ietf.org 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: Fri, 21 Dec 2018 06:57:12 -0000 UmUtLA0KDQpTZWVtcyB3ZSBhcmUgYWxsIGluIGFncmVlbWVudC4gDQoNCkkgaW1wbGVtZW50ZWQg dGhlIGNoYW5nZXMgdG8gODExM2JpcyBpbiBteSBsb2NhbCBjb3B5LiANCg0KVGhhbmsgeW91LCBC cmlhbi4gDQoNCkNoZWVycywNCk1lZCANCg0KPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0N Cj4gRGXCoDogRGlubyBGYXJpbmFjY2kgW21haWx0bzpmYXJpbmFjY2lAZ21haWwuY29tXQ0KPiBF bnZvecOpwqA6IHZlbmRyZWRpIDIxIGTDqWNlbWJyZSAyMDE4IDAwOjI5DQo+IMOAwqA6IEJyaWFu IEUgQ2FycGVudGVyDQo+IENjwqA6IEpvZWwgTS4gSGFscGVybjsgQk9VQ0FEQUlSIE1vaGFtZWQg VEdJL09MTjsgZ2VuLWFydEBpZXRmLm9yZzsNCj4gbGlzcEBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1s aXNwLXJmYzgxMTNiaXMuYWxsQGlldGYub3JnDQo+IE9iamV0wqA6IFJlOiBbbGlzcF0gR2VuYXJ0 IGxhc3QgY2FsbCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1saXNwLXJmYzgxMTNiaXMtMDENCj4gDQo+ ID4gT24gMjAxOC0xMi0yMSAwOToxOCwgRGlubyBGYXJpbmFjY2kgd3JvdGU6DQo+ID4+IEJyaWFu IHdhbnRzIHRvIGRyb3AgdGhlIHJlZmVyZW5jZSB0byA2ODMzYmlzIGZyb20gODExM2Jpcy4gSSBh bSBmaW5lIHdpdGgNCj4gdGhhdC4gVGhhdCByZWZlcmVuY2UgYmVpbmcgYXQgdGhlIHRvcCBvZiB0 aGUgZHJhZnQgc2F5aW5nIOKAnFVwZGF0ZXMgNjgzM2Jpc+KAnS4NCj4gSWYgd2UgcmVtb3ZlIHRo YXQsIGhlIG1heSBjb25jdXIuIFBsZWFzZSBjb25maXJtIEJyaWFuIChhZ2FpbikuDQo+ID4NCj4g PiBZZXMsIHRoYXQgd291bGQgcmVzb2x2ZSBteSBjb25jZXJuLg0KPiANCj4gVGhhbmtzLg0KPiAN Cj4gPj4gTGlrZSBJIGhhdmUgbWVudGlvbmVkIHRvIHlvdSBiZWZvcmUsIHRoZSBJRVRGIOKAnFVw ZGF0ZXPigJ0gbGluZ28gaXMgY29uZnVzaW5nDQo+IGFuZCByZWFsbHkgbm90IHVzZWZ1bCB1bmxl c3MgYSBkcmFmdCByZXBsYWNlcyBhIHByZXZpb3VzIGRyYWZ0LiBBbmQgdGhpcyBpcw0KPiBub3Qg dGhlIGNhc2UgaGVyZS4NCj4gPg0KPiA+IFRoYXQncyBhIGRlYmF0ZSBmb3IgdGhlIFJGQy1pbnRl cmVzdCBsaXN0IHBlcmhhcHMuIElNSE8gdGhlIGlzc3VlIGlzIHRoYXQNCj4gIlVwZGF0ZXMiIHNv bWV0aW1lcyBtZWFucyAiRXh0ZW5kcyIgYW5kIHNvbWV0aW1lcyBtZWFucyAiTW9kaWZpZXMiLg0K PiAiT2Jzb2xldGVzIiBzb21ldGltZXMgYWxzbyBpbXBsaWVzICJSZXBsYWNlcyIsIGJ1dCB0aGF0 IGRvZXNuJ3Qgc2VlbSB0bw0KPiBjcmVhdGUgY29uZnVzaW9uLg0KPiANCj4gVGhlbiBtYXliZSB0 aG9zZSB3b3JkcyBzaG91bGQgYmUgdXNlZC4NCj4gDQo+IERpbm8NCj4gDQo+ID4NCj4gPiBUaGFu a3MNCj4gPiAgIEJyaWFuDQo+ID4NCj4gPj4NCj4gPj4gRGlubw0KPiA+Pg0KPiA+Pj4gT24gRGVj IDIwLCAyMDE4LCBhdCAxMTo1OCBBTSwgSm9lbCBNLiBIYWxwZXJuIDxqbWhAam9lbGhhbHBlcm4u Y29tPg0KPiB3cm90ZToNCj4gPj4+DQo+ID4+PiBEaW5vLCBNZWQsIHBsZWFzZSBjb25maXJtIGlm IEkgYW0gcmVhZGluZyB0aGUgdGhyZWFkIHByb3Blcmx5Og0KPiA+Pj4NCj4gPj4+IEkgYmVsaWV2 ZSB0aGF0IHRoZSBwcm9wb3NhbCBpcyB0byBtYWtlIHRoZSBzbWFsbCBjaGFuZ2UgYmVsb3cgdG8g NjgzM2Jpcw0KPiBhbmQgdG8gZHJvcCB0aGUgInVwZGF0ZXMiIHJlZmVyZW5jZSBmcm9tIDgxMTNi aXMgdG8gNjgzM2Jpcy4NCj4gPj4+DQo+ID4+PiBJIGJlbGlldmUgRGlubydzIHF1ZXN0aW9uIHdh cyB3aGV0aGVyIEJyaWFuIGFncmVlZCB0aGF0IHRoZSBjb21iaW5hdGlvbg0KPiBzdWdnZXN0ZWQg d291bGQgYWRkcmVzcyBoaXMgY29uY2Vybi4NCj4gPj4+DQo+ID4+PiBZb3VycywNCj4gPj4+IEpv ZWwNCj4gPj4+DQo+ID4+PiBPbiAxMi8yMC8xOCAyOjU1IFBNLCBCcmlhbiBFIENhcnBlbnRlciB3 cm90ZToNCj4gPj4+PiBJIG1heSBiZSBtaXNzaW5nIHNvbWV0aGluZyBidXQgSSBkb24ndCBzZWUg aG93IDgxMTNiaXMgY2FuDQo+ID4+Pj4gbG9naWNhbGx5IGNpdGUgODExMywgd2hpY2ggaXQgcmVw bGFjZXMuDQo+ID4+Pj4gRnJhbmtseSBJIHRoaW5rIHlvdSd2ZSBjb2xsZWN0aXZlbHkgY3JlYXRl ZCBhIHBsYXRlIG9mIGNpdGF0aW9uDQo+ID4+Pj4gc3BhZ2hldHRpIGJ5IG5vdCBtb3ZpbmcgdGhl IElBTkEgY29uc2lkZXJhdGlvbnMgZm9yIHRoZSB0eXBlIGZpZWxkDQo+ID4+Pj4gcmVnaXN0cnkg aW50byA2ODMwYmlzLCB3aGljaCBpcyB3aGVyZSB0aGV5IG5hdHVyYWxseSBiZWxvbmcuIElmIHlv dQ0KPiA+Pj4+IGRvbid0IHdhbnQgdG8gZG8gdGhhdCwgSSB0aGluayB5b3UgaGF2ZSB0byBsZWF2 ZSB0aGVtIGluIDgxMTNiaXMgYW5kDQo+ID4+Pj4gc2ltcGx5IGxvc2UgdGhlIGNpdGF0aW9uIG9m IDY4MzNiaXMsIHdoaWNoIHNlcnZlcyBubyBwdXJwb3NlIHRoYXQNCj4gPj4+PiBJIGNhbiBzZWUu DQo+ID4+Pj4gUmVnYXJkcw0KPiA+Pj4+ICAgQnJpYW4NCj4gPj4+PiBPbiAyMDE4LTEyLTIxIDA2 OjMyLCBEaW5vIEZhcmluYWNjaSB3cm90ZToNCj4gPj4+Pj4gSeKAmWxsIG1ha2UgdGhhdCBjaGFu Z2UgaWYgQnJpYW4gdGhpbmtzIGl0IGZpeGVzIHRoZSBpc3N1ZXMgaGUgcmFpc2VkLg0KPiA+Pj4+ Pg0KPiA+Pj4+PiBEaW5vDQo+ID4+Pj4+IG5nbw0KPiA+Pj4+Pj4gT24gRGVjIDE5LCAyMDE4LCBh dCAxMTozNSBQTSwgPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+DQo+IDxtb2hhbWVkLmJv dWNhZGFpckBvcmFuZ2UuY29tPiB3cm90ZToNCj4gPj4+Pj4+DQo+ID4+Pj4+PiBIaSBEaW5vLA0K PiA+Pj4+Pj4NCj4gPj4+Pj4+IE9MRDoNCj4gPj4+Pj4+DQo+ID4+Pj4+PiAgVmFsdWVzIGluIHRo ZSAiTm90IEFzc2lnbmVkIiByYW5nZSBjYW4gYmUgYXNzaWduZWQgYWNjb3JkaW5nIHRvDQo+ID4+ Pj4+PiAgcHJvY2VkdXJlcyBpbiBbUkZDODEyNl0uDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gTkVXOg0K PiA+Pj4+Pj4NCj4gPj4+Pj4+ICBWYWx1ZXMgaW4gdGhlICJOb3QgQXNzaWduZWQiIHJhbmdlIGNh biBiZSBhc3NpZ25lZCB2aWEgU3RhbmRhcmRzDQo+ID4+Pj4+PiAgQWN0aW9uIFtSRkM4MTEzXS4N Cj4gPj4+Pj4+DQo+ID4+Pj4+PiBDaGVlcnMsDQo+ID4+Pj4+PiBNZWQNCj4gPj4+Pj4+DQo+ID4+ Pj4+Pj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ID4+Pj4+Pj4gRGUgOiBEaW5vIEZh cmluYWNjaSBbbWFpbHRvOmZhcmluYWNjaUBnbWFpbC5jb21dDQo+ID4+Pj4+Pj4gRW52b3nDqSA6 IG1lcmNyZWRpIDE5IGTDqWNlbWJyZSAyMDE4IDE5OjAwDQo+ID4+Pj4+Pj4gw4AgOiBCT1VDQURB SVIgTW9oYW1lZCBUR0kvT0xODQo+ID4+Pj4+Pj4gQ2MgOiBKb2VsIE0uIEhhbHBlcm47IEJyaWFu IEUgQ2FycGVudGVyOyBnZW4tYXJ0QGlldGYub3JnOw0KPiBsaXNwQGlldGYub3JnOw0KPiA+Pj4+ Pj4+IGRyYWZ0LWlldGYtbGlzcC1yZmM4MTEzYmlzLmFsbEBpZXRmLm9yZw0KPiA+Pj4+Pj4+IE9i amV0IDogUmU6IFtsaXNwXSBHZW5hcnQgbGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLWxp c3AtDQo+IHJmYzgxMTNiaXMtMDENCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IFdoYXQgZG9lcyBmaXhp bmcgaW4gKDEpIG1lYW4/DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiBEaW5vDQo+ID4+Pj4+Pj4NCj4g Pj4+Pj4+Pj4gT24gRGVjIDE5LCAyMDE4LCBhdCAzOjUxIEFNLCA8bW9oYW1lZC5ib3VjYWRhaXJA b3JhbmdlLmNvbT4NCj4gPj4+Pj4+PiA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4gd3Jv dGU6DQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+IEhpIGFsbCwNCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+ Pj4gQnJpYW4sIHdoZXRoZXIgdG8gbWFpbnRhaW4gdGhlIGRvY3VtZW50IHN0YW5kYWxvbmUgd2Fz IGRpc2N1c3NlZCBieQ0KPiB0aGUgV0cuDQo+ID4+Pj4+Pj4gWW91IG1heSByZWZlciwgZm9yIGV4 YW1wbGUsIHRvIHRoZSBtZXNzYWdlIGZyb20gRGVib3JhaCB3aGljaA0KPiBjbGFyaWZpZXMgdGhp cw0KPiA+Pj4+Pj4+IHBvaW50OiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLQ0KPiBhcmNoaXZl L3dlYi9saXNwL2N1cnJlbnQvbXNnMDc4ODYuaHRtbC4gT25lDQo+ID4+Pj4+Pj4gb2YgdGhlIG91 dGNvbWVzIG9mIHRoYXQgZGlzY3Vzc2lvbiBpcyB0byBhZGQgYW4gInVwZGF0ZXMiIGhlYWRlciB0 bw0KPiA4MTEzYmlzLg0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+PiBGV0lXLCBvbmUgb2YgdGhlIGlz c3VlcyB0aGF0IGxlZCB0byB0aGF0IGNvbmNsdXNpb24gd2FzIHdoZXRoZXIgdG8NCj4gY2l0ZQ0K PiA+Pj4+Pj4+IHJmYzgxMTNiaXMgYXMgbm9ybWF0aXZlIGluIDY4MzNiaXMgKHRoZSBhcHByb2Fj aCBJIGluaXRpYWxseQ0KPiBzdXBwb3J0ZWQpIGFuZA0KPiA+Pj4+Pj4+IGFncmVlZCBieSBEaW5v IChodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLQ0KPiA+Pj4+Pj4+IGFyY2hpdmUvd2ViL2xpc3Av Y3VycmVudC9tc2cwNzg4Mi5odG1sKS4gRGVib3JhaCBjb252aW5jZWQgbWUgdGhhdA0KPiBjaXRp bmcNCj4gPj4+Pj4+PiA4MTEzYmlzIHdpbGwgbGVhZCB0byBjaXJjdWxhciBkZXBlbmRlbmN5LiBX aGljaCBpcyBhIGZhaXIgYXJndW1lbnQuDQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+IFRoZSAidXBk YXRlcyIgdGFnIHdhcyBqdXN0aWZpZWQgYXMgZm9sbG93czoNCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+ Pj4gKDEpDQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+IFJGQzY4MzNiaXMgaW5jbHVkZXMgdGhlIGZv bGxvd2luZzoNCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4gVmFsdWVzIGluIHRoZSAiTm90IEFzc2ln bmVkIiByYW5nZSBjYW4gYmUgYXNzaWduZWQgYWNjb3JkaW5nIHRvDQo+ID4+Pj4+Pj4+IHByb2Nl ZHVyZXMgaW4gW1JGQzgxMjZdLg0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+PiBUaGF0IHRleHQgaXMg dXBkYXRlZCBieSBSRkM4MTEzYmlzIHRvIGJlIGFsaWduZWQgd2l0aCA4MTEzOg0KPiA+Pj4+Pj4+ Pg0KPiA+Pj4+Pj4+PiBWYWx1ZXMgY2FuIGJlIGFzc2lnbmVkIHZpYSBTdGFuZGFyZHMgQWN0aW9u DQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+ICgyKQ0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+PiBSRkM4 MTEzYmlzIGV4dGVuZHMgdGhlIHR5cGUgZmllbGQgdG8gZ3JhYiBtb3JlIGJpdHMvdmFsdWVzIHdo ZW4gdGhlDQo+ID4+Pj4+Pj4gYXZhaWxhYmxlIHR5cGVzIGFyZSBleGhhdXN0ZWQuIFRoaXMgaXMg Y2FwdHVyZWQgaW4gODExM2JpczoNCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4gVGhlIHZhbHVlcyBp biB0aGUgcmFuZ2UgMC0xMDIzIGFyZSBhc3NpZ25lZCB2aWEgU3RhbmRhcmRzIEFjdGlvbi4NCj4g Pj4+Pj4+Pj4gVGhpcyByYW5nZSBpcyBwcm92aXNpb25lZCB0byBhbnRpY2lwYXRlLCBpbiBwYXJ0 aWN1bGFyLCB0aGUNCj4gPj4+Pj4+Pj4gZXhoYXVzdGlvbiBvZiB0aGUgTElTUCBQYWNrZXQgdHlw ZXMuDQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+IERpbm86IElmICgxKSBpcyBmaXhlZCBkaXJlY3Rs eSBpbiBSRkM2ODMzYmlzLCB0aGVuIEknbSBmaW5lIHRvDQo+IHJlbW92ZSB0aGUNCj4gPj4+Pj4+ PiAidXBkYXRlcyIgaGVhZGVyIGJlY2F1c2UgKDIpIGNhbiBiZSBhbHNvIHNlZW4gYXMgYW4gZXh0 ZW5zaW9uLg0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+PiBDaGVlcnMsDQo+ID4+Pj4+Pj4+IE1lZA0K PiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ID4+ Pj4+Pj4+PiBEZSA6IERpbm8gRmFyaW5hY2NpIFttYWlsdG86ZmFyaW5hY2NpQGdtYWlsLmNvbV0N Cj4gPj4+Pj4+Pj4+IEVudm95w6kgOiBtZXJjcmVkaSAxOSBkw6ljZW1icmUgMjAxOCAwNjozNw0K PiA+Pj4+Pj4+Pj4gw4AgOiBKb2VsIE0uIEhhbHBlcm4NCj4gPj4+Pj4+Pj4+IENjIDogQnJpYW4g RSBDYXJwZW50ZXI7IGdlbi1hcnRAaWV0Zi5vcmc7IGxpc3BAaWV0Zi5vcmc7IGRyYWZ0LQ0KPiBp ZXRmLWxpc3AtDQo+ID4+Pj4+Pj4+PiByZmM4MTEzYmlzLmFsbEBpZXRmLm9yZw0KPiA+Pj4+Pj4+ Pj4gT2JqZXQgOiBSZTogW2xpc3BdIEdlbmFydCBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWll dGYtbGlzcC0NCj4gcmZjODExM2Jpcy0NCj4gPj4+Pj4+PiAwMQ0KPiA+Pj4+Pj4+Pj4NCj4gPj4+ Pj4+Pj4+IE1vaG1hZCB0byBjb21tZW50Lg0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+IERpbm8N Cj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4gT24gRGVjIDE4LCAyMDE4LCBhdCA4OjQ5IFBNLCBK b2VsIE0uIEhhbHBlcm4gPGptaEBqb2VsaGFscGVybi5jb20+DQo+IHdyb3RlOg0KPiA+Pj4+Pj4+ Pj4+DQo+ID4+Pj4+Pj4+Pj4gVGhhdCBpcyB0aGUgb3RoZXIgZml4IGhlIG9mZmVyZWQuICBKdXN0 IHJlbW92ZSB0aGUgdXBkYXRlcyB0YWcuDQo+ID4+Pj4+Pj4+Pj4gSSB3aWxsIGxlYXYgZWl0IHRv IHlvdSBhbmQgdGhlIHRoZSBhdXRob3JzIHRvIGRldGVybWluZSB3aGljaCBpcw0KPiBjb3JyZWN0 Lg0KPiA+Pj4+Pj4+Pj4+IFlvdXJzLA0KPiA+Pj4+Pj4+Pj4+IEpvZWwNCj4gPj4+Pj4+Pj4+Pg0K PiA+Pj4+Pj4+Pj4+IE9uIDEyLzE4LzE4IDExOjQzIFBNLCBEaW5vIEZhcmluYWNjaSB3cm90ZToN Cj4gPj4+Pj4+Pj4+Pj4gODExM2JpcyBzaG91bGQgc2F5IHRoYXQgaXMgaXQgKmV4dGVuZGluZyog dGhlIHR5cGUgZmllbGQgc28gd2UNCj4gY2FuIGhhdmUNCj4gPj4+Pj4+Pj4+IG1vcmUgdHlwZXMu IFRoZSB3b3JkIOKAnHVwZGF0ZeKAnSBJIGFsd2F5cyBoYWQgYSBwcm9ibGVtIHdpdGggYmVjYXVz ZQ0KPiBpdCBjYW4NCj4gPj4+Pj4+PiBiZQ0KPiA+Pj4+Pj4+Pj4gaW50ZXJwcmV0ZWQgYXMg4oCc cmVwbGFjaW5nIi4gUmVwbGFjaW5nIHNvbWV0aGluZyB0byBmaXggYSBwcm9ibGVtLg0KPiA+Pj4+ Pj4+Pj4+PiA4MTEzIGlzIHNpbXBseSBhc2tpbmcgZm9yIG9uZSBvZiB0aGUgdHlwZSB2YWx1ZSBj b2RlcG9pbnQsIHNvDQo+IHRoZXJlIGNhbg0KPiA+Pj4+Pj4+IGJlDQo+ID4+Pj4+Pj4+PiBhbm90 aGVyIGZvcm1hdCB0byBoYXZlIG1vcmUgdHlwZXMuDQo+ID4+Pj4+Pj4+Pj4+IERpbm8NCj4gPj4+ Pj4+Pj4+Pj4+IE9uIERlYyAxOCwgMjAxOCwgYXQgOToyNCBQTSwgSm9lbCBNLiBIYWxwZXJuDQo+ IDxqbWhAam9lbGhhbHBlcm4uY29tPg0KPiA+Pj4+Pj4+IHdyb3RlOg0KPiA+Pj4+Pj4+Pj4+Pj4N Cj4gPj4+Pj4+Pj4+Pj4+IEF1dGhvcnM6IHRoYXQgc291bmRzIGxpa2UgYSByZWFzb25hYmxlIGFk ZGl0aW9uIHRvIG1lPw0KPiA+Pj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4+IFlvdXJzLA0KPiA+ Pj4+Pj4+Pj4+Pj4gSm9lbA0KPiA+Pj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4+IE9uIDEyLzE4 LzE4IDEwOjQ4IFBNLCBCcmlhbiBFIENhcnBlbnRlciB3cm90ZToNCj4gPj4+Pj4+Pj4+Pj4+PiBP biAyMDE4LTEyLTE5IDE1OjQ2LCBKb2VsIE0uIEhhbHBlcm4gd3JvdGU6DQo+ID4+Pj4+Pj4+Pj4+ Pj4+IFRoaXMgaXMgcGFydCBvZiB0aGUgcGFja2FnZSB0byBtb3ZlIHRoZSBjb2hlcmVudCBzZXQg b2YgYmFzZQ0KPiBMSVNQDQo+ID4+Pj4+Pj4gc3BlY3MNCj4gPj4+Pj4+Pj4+Pj4+Pj4gdG8gUFMu DQo+ID4+Pj4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+Pj4+IFRoZSByZWFzb24gd2UgZGlkIHRo aXMgcmF0aGVyIHRoYW4gZm9sZGluZyBpdCBpbnRvIDY4MzBiaXMgLw0KPiA2ODMzYmlzDQo+ID4+ Pj4+Pj4gaXMNCj4gPj4+Pj4+Pj4+Pj4+Pj4gdGhhdCB3ZSBoYWQgb3JpZ2luYWxseSBzaW1wbHkg Y2l0ZWQgODExMywgYW5kIHRoZW4gcmVhbGl6ZWQNCj4gdGhhdA0KPiA+Pj4+Pj4+IG5lZWRlZA0K PiA+Pj4+Pj4+Pj4+Pj4+PiB0byBtb3ZlIHRvIFBTIGFsb25nIHdpdGggZXZlcnl0aGluZyBlbHNl LiAgSXQgc2VlbWVkIChhbmQgaXMpDQo+IHNpbXBsZXINCj4gPj4+Pj4+Pj4+IHRvDQo+ID4+Pj4+ Pj4+Pj4+Pj4+IGRvIGl0IHNlcGFyYXRlbHkgcmF0aGVyIHRoYW4gdG8gZnVydGhlciBtb2RpZnkg NjgzMGJpcyAvDQo+IDY5MzNiaXMuDQo+ID4+Pj4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+Pj4+ IEFzIGZvciB3aHkgaXQgdXBkYXRlcyA2ODMzYmlzLCB0aGF0IGlzIGJlY2F1c2Ugb25lIG9mIHRo ZQ0KPiBjYWhuZ2VzIGluDQo+ID4+Pj4+Pj4+Pj4+Pj4+IG1vdmluZyB0aGUgc2V0IHRvIFBTIHdh cyB0byBpbXByb3ZlIHRoZSBzcGxpdCBhcyB0byB3aGljaA0KPiBpbmZvcm1hdGlvbg0KPiA+Pj4+ Pj4+Pj4+Pj4+PiBiZWxvbmdlZCBpbiB3aGljaCBkb2N1bWVudC4NCj4gPj4+Pj4+Pj4+Pj4+PiBP SywgYnV0IEkgc3RpbGwgZG9uJ3QgZmluZCBpdCBsb2dpY2FsIFRoZSB0ZXh0IGRvZXNuJ3QgZXhw bGFpbg0KPiB3aGljaA0KPiA+Pj4+Pj4+Pj4gcGFydCBvZg0KPiA+Pj4+Pj4+Pj4+Pj4+IDY4MzNi aXMgaXMgaW1wYWN0ZWQsIGFuZCBub3JtYWxseSB0aGVzZSBkYXlzIHdlIHJlcXVpcmUgc3VjaCBh bg0KPiA+Pj4+Pj4+Pj4gZXhwbGFuYXRpb24uDQo+ID4+Pj4+Pj4+Pj4+Pj4gQW5kIGlmIHRoZXJl IGlzIGFuIGltcGFjdCwgeW91J3JlIG1pc3NpbmcgdGhlIG9wcG9ydHVuaXR5IG9mDQo+IGZpeGlu Zw0KPiA+Pj4+Pj4+IHRoZQ0KPiA+Pj4+Pj4+Pj4gZXJyb3INCj4gPj4+Pj4+Pj4+Pj4+PiBvciBn YXAgaW4gNjgzM2Jpcywgc28gdGhlIHJlYWRlciBvZiA2ODMzYmlzIHdpbGwgYmUgbm9uZSB0aGUN Cj4gd2lzZXINCj4gPj4+Pj4+Pj4+IHVubGVzcw0KPiA+Pj4+Pj4+Pj4+Pj4+IHlvdSBpbnNlcnQg YSByZWZlcmVuY2UgdG8gODExM2Jpcy4NCj4gPj4+Pj4+Pj4+Pj4+PiBPbiB0aGUgb3RoZXIgaGFu ZCwgaWYgdGhlcmUgaXMgbm8gZXJyb3Igb3IgZ2FwLCB5b3UgZG9uJ3QgbmVlZA0KPiA+Pj4+Pj4+ Pj4gIlVwZGF0ZXM6Ig0KPiA+Pj4+Pj4+Pj4+Pj4+IGF0IGFsbC4gKFVuZm9ydHVuYXRlbHksIHdl IGRvbid0IGhhdmUgYW4gIkV4dGVuZHM6IiBoZWFkZXIuKQ0KPiA+Pj4+Pj4+Pj4+Pj4+IEJyaWFu DQo+ID4+Pj4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+Pj4+IFlvdXJzLA0KPiA+Pj4+Pj4+Pj4+ Pj4+PiBKb2VsDQo+ID4+Pj4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+Pj4+IE9uIDEyLzE4LzE4 IDk6MjUgUE0sIEJyaWFuIENhcnBlbnRlciB3cm90ZToNCj4gPj4+Pj4+Pj4+Pj4+Pj4+IFJldmll d2VyOiBCcmlhbiBDYXJwZW50ZXINCj4gPj4+Pj4+Pj4+Pj4+Pj4+IFJldmlldyByZXN1bHQ6IFJl YWR5IHdpdGggSXNzdWVzDQo+ID4+Pj4+Pj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+Pj4+Pj4gR2Vu LUFSVCBMYXN0IENhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtbGlzcC1yZmM4MTEzYmlzLTAxDQo+ ID4+Pj4+Pj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+Pj4+Pj4gSSBhbSB0aGUgYXNzaWduZWQgR2Vu LUFSVCByZXZpZXdlciBmb3IgdGhpcyBkcmFmdC4gVGhlDQo+IEdlbmVyYWwgQXJlYQ0KPiA+Pj4+ Pj4+Pj4+Pj4+Pj4gUmV2aWV3IFRlYW0gKEdlbi1BUlQpIHJldmlld3MgYWxsIElFVEYgZG9jdW1l bnRzIGJlaW5nDQo+IHByb2Nlc3NlZA0KPiA+Pj4+Pj4+Pj4+Pj4+Pj4gYnkgdGhlIElFU0cgZm9y IHRoZSBJRVRGIENoYWlyLiAgUGxlYXNlIHRyZWF0IHRoZXNlIGNvbW1lbnRzDQo+IGp1c3QNCj4g Pj4+Pj4+Pj4+Pj4+Pj4+IGxpa2UgYW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy4NCj4gPj4+ Pj4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+Pj4+PiBGb3IgbW9yZSBpbmZvcm1hdGlvbiwgcGxl YXNlIHNlZSB0aGUgRkFRIGF0DQo+ID4+Pj4+Pj4+Pj4+Pj4+PiA8aHR0cDovL3dpa2kudG9vbHMu aWV0Zi5vcmcvYXJlYS9nZW4vdHJhYy93aWtpL0dlbkFydGZhcT4uDQo+ID4+Pj4+Pj4+Pj4+Pj4+ Pg0KPiA+Pj4+Pj4+Pj4+Pj4+Pj4gRG9jdW1lbnQ6IGRyYWZ0LWlldGYtbGlzcC1yZmM4MTEzYmlz LTAxLnR4dA0KPiA+Pj4+Pj4+Pj4+Pj4+Pj4gUmV2aWV3ZXI6IEJyaWFuIENhcnBlbnRlcg0KPiA+ Pj4+Pj4+Pj4+Pj4+Pj4gUmV2aWV3IERhdGU6IDIwMTgtMTItMTkNCj4gPj4+Pj4+Pj4+Pj4+Pj4+ IElFVEYgTEMgRW5kIERhdGU6IDIwMTgtMTItMjcNCj4gPj4+Pj4+Pj4+Pj4+Pj4+IElFU0cgVGVs ZWNoYXQgZGF0ZToNCj4gPj4+Pj4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+Pj4+PiBTdW1tYXJ5 OiBSZWFkeSB3aXRoIGlzc3Vlcw0KPiA+Pj4+Pj4+Pj4+Pj4+Pj4gLS0tLS0tLS0NCj4gPj4+Pj4+ Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+Pj4+PiBDb21tZW50czoNCj4gPj4+Pj4+Pj4+Pj4+Pj4+ IC0tLS0tLS0tLQ0KPiA+Pj4+Pj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4+Pj4+IEkgbm90ZSB0 aGF0IHRoaXMgaXMgYmVpbmcgcmFpc2VkIGZyb20gRXhwZXJpbWVudGFsIHRvIHRoZQ0KPiBzdGFu ZGFyZHMNCj4gPj4+Pj4+Pj4+IHRyYWNrLg0KPiA+Pj4+Pj4+Pj4+Pj4+Pj4gUHJlc3VtYWJseSB0 aGF0IGRlcGVuZHMgb24gdGhlIGJhc2UgTElTUCBzcGVjIGJlY29taW5nIFBTLg0KPiA+Pj4+Pj4+ Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4+Pj4+IE1pbm9yIGlzc3VlczoNCj4gPj4+Pj4+Pj4+Pj4+ Pj4+IC0tLS0tLS0tLS0tLS0NCj4gPj4+Pj4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+Pj4+PiAi VGhpcyBkb2N1bWVudCB1cGRhdGVzIEktRC5pZXRmLWxpc3AtcmZjNjgzM2Jpcy4iIFRoZSB0ZXh0 DQo+IGRvZXNuJ3QNCj4gPj4+Pj4+Pj4+Pj4+Pj4+IGV4cGxhaW4gd2hpY2ggdGV4dCBpcyB1cGRh dGVkLiBUaGlzIGlzIGluIGNvbnRyYXN0IHRvDQo+IFJGQzgxMTMsIHdoaWNoDQo+ID4+Pj4+Pj4+ Pj4+Pj4+PiBleHBsYWlucyBjbGVhcmx5IGhvdyBpdCB1cGRhdGVzIFJGQzY4MzAgKCpub3QqIFJG QzY4MzMpLiBXaHkNCj4gZG9lc24ndA0KPiA+Pj4+Pj4+Pj4+Pj4+Pj4gdGhpcyBkcmFmdCBjbGFp bSB0byB1cGRhdGUgcmZjNjgzMGJpcz8gSSdtIGdvaW5nIHRvIGFzc3VtZQ0KPiB0aGF0DQo+ID4+ Pj4+Pj4+Pj4+Pj4+PiBpcyBhbiBlcnJvci4NCj4gPj4+Pj4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+ Pj4+Pj4+PiBJbiBmYWN0LCB3aHkgd2Fzbid0IHRoZSBkZWZpbml0aW9uIG9mIHRoZSBMSVNQIFBh Y2tldCBUeXBlcw0KPiByZWdpc3RyeQ0KPiA+Pj4+Pj4+Pj4+Pj4+Pj4gbW92ZWQgaW50byB0aGUg YmFzZSBzcGVjIChyZmM2ODMwYmlzKT8gVGhhdCBpcyB3aGVyZSBpdA0KPiBiZWxvbmdzLg0KPiA+ Pj4+Pj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4+Pj4+IFNpbmNlIHJmYzY4MzBiaXMgKGFuZCBy ZmM2ODMzYmlzKSBhcmUgc3RpbGwgdW5kZXIgSUVTRw0KPiByZXZpZXcsDQo+ID4+Pj4+Pj4+PiBh bnl0aGluZw0KPiA+Pj4+Pj4+Pj4+Pj4+Pj4gaW4gdGhlbSB0aGF0IG5lZWRzIHVwZGF0aW5nIHNo b3VsZCBiZSB1cGRhdGVkISBUaGUgZmFjdCBpcw0KPiB0aGF0DQo+ID4+Pj4+Pj4+PiByZmM4MTEz YmlzDQo+ID4+Pj4+Pj4+Pj4+Pj4+PiBleHRlbmRzIHJmYzY4MzBiaXMsIHdoaWNoIGlzIG5vdCB0 aGUgc2FtZSB0aGluZyBhcyAidXBkYXRlcyIuDQo+ID4+Pj4+Pj4+Pj4+Pj4+PiBJZiB0aGUgV0cg dGhpbmtzIHRoYXQgaW1wbGVtZW50ZXJzIG9mIDY4MzBiaXMgbmVlZCB0byByZWFkDQo+IDgxMTNi aXMsDQo+ID4+Pj4+Pj4+Pj4+Pj4+PiB0aGVyZSBzaG91bGQgYmUgYSBub3JtYXRpdmUgcmVmZXJl bmNlIGluIDY4MzBiaXMgdG8gODExM2Jpcy4NCj4gPj4+Pj4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+ Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+Pj4+ Pj4+Pj4+PiBsaXNwIG1haWxpbmcgbGlzdA0KPiA+Pj4+Pj4+Pj4+Pj4gbGlzcEBpZXRmLm9yZw0K PiA+Pj4+Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9saXNw DQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pg0KPiA+Pj4+Pg0KPiA+Pj4+Pg0KPiA+Pg0KPiA+Pg0KPiA+ DQoNCg== From nobody Fri Dec 21 11:35:48 2018 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5349130E8C; Fri, 21 Dec 2018 11:35:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 T0qZQ4XDju5X; Fri, 21 Dec 2018 11:35:39 -0800 (PST) Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8C9B1200B3; Fri, 21 Dec 2018 11:35:38 -0800 (PST) Received: by mail-pf1-x430.google.com with SMTP id g62so3024248pfd.12; Fri, 21 Dec 2018 11:35:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=t5g25y0ELmDQbqxwD9bJHwkobBbLkjJbEljFRJ0sqno=; b=p+rumhbLP+wbHI/C14Mqn5OAq3FVkwLP3uuMjjMMCcp7TOB+VE/Vp/dlYk7dWbG8K3 +etOIiUm2SYtl6EKPIRtN0+9CUvSFyq5mND9y7uPf21wRex8uDddRTWP22nIaDkso59B csmmjksu/JcABcVGwgW2MD3iUmkJLgFoyaB14dirnnSUlM/9UF2s8I5o79IxfD1CYVRB mvZIu5Qy3RPrPABQ/XD9T1ukRPU/8o4e6AfoGFsewG5kqsQbRUkvnYoNVeo/TvTyVFC3 Z5eeOvBADmJUKLjCZ5R3j2Xw/JUTkNYrDhwc8f5VUn0Ee7xQV/XRQ+f1mW+mpiqV9p7H t5SQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=t5g25y0ELmDQbqxwD9bJHwkobBbLkjJbEljFRJ0sqno=; b=EZ7o9/uTwX31h25c1tboh7MykdQMtPq+zYayePdDXs1U/zNHHsDeIFJBqkvuuM1dl4 s+3pWZeBIoExrIFgP5L1AnRswXYRW2ozzvymT4pyEt5my1Ynu+Xvakw85LQOrhsMvgCi Hsf6H0ile5OJf3Yef4lDGplxTHQM4JJZ5uJFaILTSIFpLqtIf4hGCt1UhwxmkQ1c8zm9 G5PpeTqyGcKJpEgrdiKhDSguc8fV/Z+Qh8U4dxOhNe7NAHFwjMo+oHI/1SBlOBlCyDwS GPW1bgyQwQEKSsTNvAIUDpgnApOsnvGi3EprW5L66/I0KFDVmUQptvQI1QbFGCyVoe0r Urgg== X-Gm-Message-State: AJcUukeMa3LuZP8nCWYyVQZqbf56fwyvCF/1rjYXin5B6J50WekyBH0O ci9MGtrkMgwXjwBVlXcfLu3lcPrQ X-Google-Smtp-Source: ALg8bN7XEjPjCRCVv1b+rKvdKeesm5syN982iR8LOyaOFIHKJrLubhwtex32P0UMzFKdUAs5Ev4fvg== X-Received: by 2002:a63:ce08:: with SMTP id y8mr3580139pgf.388.1545420938264; Fri, 21 Dec 2018 11:35:38 -0800 (PST) Received: from [192.168.20.38] ([205.157.148.20]) by smtp.gmail.com with ESMTPSA id 202sm46103258pfy.87.2018.12.21.11.35.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Dec 2018 11:35:37 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Dino Farinacci In-Reply-To: <787AE7BB302AE849A7480A190F8B93302E05ED1C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Fri, 21 Dec 2018 11:35:33 -0800 Cc: Brian E Carpenter , "Joel M. Halpern" , "gen-art@ietf.org" , "lisp@ietf.org" , "draft-ietf-lisp-rfc8113bis.all@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <523C6581-A549-43D1-BC76-5EF88A158B13@gmail.com> References: <154518630870.5131.10104452678736081639@ietfa.amsl.com> <407BD77D-F364-4989-A6D2-C75DF9914402@gmail.com> <9cc58af9-2bcf-89d7-a2ae-3fc80e723d78@joelhalpern.com> <787AE7BB302AE849A7480A190F8B93302E05D7D4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302E05E137@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <583bf0d5-3de8-adba-7445-54ec4779a345@joelhalpern.com> <48ED1BED-7055-4DF4-AF69-E764E5ADABDB@gmail.com> <41802D01-0195-464C-9044-9AB0B58F8B72@gmail.com> <787AE7BB302AE849A7480A190F8B93302E05ED1C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> To: mohamed.boucadair@orange.com X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01 X-BeenThere: lisp@ietf.org 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: Fri, 21 Dec 2018 19:35:42 -0000 Thanks all. Dino > On Dec 20, 2018, at 10:57 PM, = wrote: >=20 > Re-, >=20 > Seems we are all in agreement.=20 >=20 > I implemented the changes to 8113bis in my local copy.=20 >=20 > Thank you, Brian.=20 >=20 > Cheers, > Med=20 >=20 >> -----Message d'origine----- >> De : Dino Farinacci [mailto:farinacci@gmail.com] >> Envoy=C3=A9 : vendredi 21 d=C3=A9cembre 2018 00:29 >> =C3=80 : Brian E Carpenter >> Cc : Joel M. Halpern; BOUCADAIR Mohamed TGI/OLN; gen-art@ietf.org; >> lisp@ietf.org; draft-ietf-lisp-rfc8113bis.all@ietf.org >> Objet : Re: [lisp] Genart last call review of = draft-ietf-lisp-rfc8113bis-01 >>=20 >>> On 2018-12-21 09:18, Dino Farinacci wrote: >>>> Brian wants to drop the reference to 6833bis from 8113bis. I am = fine with >> that. That reference being at the top of the draft saying =E2=80=9CUpda= tes 6833bis=E2=80=9D. >> If we remove that, he may concur. Please confirm Brian (again). >>>=20 >>> Yes, that would resolve my concern. >>=20 >> Thanks. >>=20 >>>> Like I have mentioned to you before, the IETF =E2=80=9CUpdates=E2=80=9D= lingo is confusing >> and really not useful unless a draft replaces a previous draft. And = this is >> not the case here. >>>=20 >>> That's a debate for the RFC-interest list perhaps. IMHO the issue is = that >> "Updates" sometimes means "Extends" and sometimes means "Modifies". >> "Obsoletes" sometimes also implies "Replaces", but that doesn't seem = to >> create confusion. >>=20 >> Then maybe those words should be used. >>=20 >> Dino >>=20 >>>=20 >>> Thanks >>> Brian >>>=20 >>>>=20 >>>> Dino >>>>=20 >>>>> On Dec 20, 2018, at 11:58 AM, Joel M. Halpern = >> wrote: >>>>>=20 >>>>> Dino, Med, please confirm if I am reading the thread properly: >>>>>=20 >>>>> I believe that the proposal is to make the small change below to = 6833bis >> and to drop the "updates" reference from 8113bis to 6833bis. >>>>>=20 >>>>> I believe Dino's question was whether Brian agreed that the = combination >> suggested would address his concern. >>>>>=20 >>>>> Yours, >>>>> Joel >>>>>=20 >>>>> On 12/20/18 2:55 PM, Brian E Carpenter wrote: >>>>>> I may be missing something but I don't see how 8113bis can >>>>>> logically cite 8113, which it replaces. >>>>>> Frankly I think you've collectively created a plate of citation >>>>>> spaghetti by not moving the IANA considerations for the type = field >>>>>> registry into 6830bis, which is where they naturally belong. If = you >>>>>> don't want to do that, I think you have to leave them in 8113bis = and >>>>>> simply lose the citation of 6833bis, which serves no purpose that >>>>>> I can see. >>>>>> Regards >>>>>> Brian >>>>>> On 2018-12-21 06:32, Dino Farinacci wrote: >>>>>>> I=E2=80=99ll make that change if Brian thinks it fixes the = issues he raised. >>>>>>>=20 >>>>>>> Dino >>>>>>> ngo >>>>>>>> On Dec 19, 2018, at 11:35 PM, >> wrote: >>>>>>>>=20 >>>>>>>> Hi Dino, >>>>>>>>=20 >>>>>>>> OLD: >>>>>>>>=20 >>>>>>>> Values in the "Not Assigned" range can be assigned according to >>>>>>>> procedures in [RFC8126]. >>>>>>>>=20 >>>>>>>> NEW: >>>>>>>>=20 >>>>>>>> Values in the "Not Assigned" range can be assigned via = Standards >>>>>>>> Action [RFC8113]. >>>>>>>>=20 >>>>>>>> Cheers, >>>>>>>> Med >>>>>>>>=20 >>>>>>>>> -----Message d'origine----- >>>>>>>>> De : Dino Farinacci [mailto:farinacci@gmail.com] >>>>>>>>> Envoy=C3=A9 : mercredi 19 d=C3=A9cembre 2018 19:00 >>>>>>>>> =C3=80 : BOUCADAIR Mohamed TGI/OLN >>>>>>>>> Cc : Joel M. Halpern; Brian E Carpenter; gen-art@ietf.org; >> lisp@ietf.org; >>>>>>>>> draft-ietf-lisp-rfc8113bis.all@ietf.org >>>>>>>>> Objet : Re: [lisp] Genart last call review of draft-ietf-lisp- >> rfc8113bis-01 >>>>>>>>>=20 >>>>>>>>> What does fixing in (1) mean? >>>>>>>>>=20 >>>>>>>>> Dino >>>>>>>>>=20 >>>>>>>>>> On Dec 19, 2018, at 3:51 AM, >>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>> Hi all, >>>>>>>>>>=20 >>>>>>>>>> Brian, whether to maintain the document standalone was = discussed by >> the WG. >>>>>>>>> You may refer, for example, to the message from Deborah which >> clarifies this >>>>>>>>> point: https://www.ietf.org/mail- >> archive/web/lisp/current/msg07886.html. One >>>>>>>>> of the outcomes of that discussion is to add an "updates" = header to >> 8113bis. >>>>>>>>>>=20 >>>>>>>>>> FWIW, one of the issues that led to that conclusion was = whether to >> cite >>>>>>>>> rfc8113bis as normative in 6833bis (the approach I initially >> supported) and >>>>>>>>> agreed by Dino (https://www.ietf.org/mail- >>>>>>>>> archive/web/lisp/current/msg07882.html). Deborah convinced me = that >> citing >>>>>>>>> 8113bis will lead to circular dependency. Which is a fair = argument. >>>>>>>>>>=20 >>>>>>>>>> The "updates" tag was justified as follows: >>>>>>>>>>=20 >>>>>>>>>> (1) >>>>>>>>>>=20 >>>>>>>>>> RFC6833bis includes the following: >>>>>>>>>>=20 >>>>>>>>>> Values in the "Not Assigned" range can be assigned according = to >>>>>>>>>> procedures in [RFC8126]. >>>>>>>>>>=20 >>>>>>>>>> That text is updated by RFC8113bis to be aligned with 8113: >>>>>>>>>>=20 >>>>>>>>>> Values can be assigned via Standards Action >>>>>>>>>>=20 >>>>>>>>>> (2) >>>>>>>>>>=20 >>>>>>>>>> RFC8113bis extends the type field to grab more bits/values = when the >>>>>>>>> available types are exhausted. This is captured in 8113bis: >>>>>>>>>>=20 >>>>>>>>>> The values in the range 0-1023 are assigned via Standards = Action. >>>>>>>>>> This range is provisioned to anticipate, in particular, the >>>>>>>>>> exhaustion of the LISP Packet types. >>>>>>>>>>=20 >>>>>>>>>> Dino: If (1) is fixed directly in RFC6833bis, then I'm fine = to >> remove the >>>>>>>>> "updates" header because (2) can be also seen as an extension. >>>>>>>>>>=20 >>>>>>>>>> Cheers, >>>>>>>>>> Med >>>>>>>>>>=20 >>>>>>>>>>> -----Message d'origine----- >>>>>>>>>>> De : Dino Farinacci [mailto:farinacci@gmail.com] >>>>>>>>>>> Envoy=C3=A9 : mercredi 19 d=C3=A9cembre 2018 06:37 >>>>>>>>>>> =C3=80 : Joel M. Halpern >>>>>>>>>>> Cc : Brian E Carpenter; gen-art@ietf.org; lisp@ietf.org; = draft- >> ietf-lisp- >>>>>>>>>>> rfc8113bis.all@ietf.org >>>>>>>>>>> Objet : Re: [lisp] Genart last call review of = draft-ietf-lisp- >> rfc8113bis- >>>>>>>>> 01 >>>>>>>>>>>=20 >>>>>>>>>>> Mohmad to comment. >>>>>>>>>>>=20 >>>>>>>>>>> Dino >>>>>>>>>>>=20 >>>>>>>>>>>> On Dec 18, 2018, at 8:49 PM, Joel M. Halpern = >> wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>> That is the other fix he offered. Just remove the updates = tag. >>>>>>>>>>>> I will leav eit to you and the the authors to determine = which is >> correct. >>>>>>>>>>>> Yours, >>>>>>>>>>>> Joel >>>>>>>>>>>>=20 >>>>>>>>>>>> On 12/18/18 11:43 PM, Dino Farinacci wrote: >>>>>>>>>>>>> 8113bis should say that is it *extending* the type field = so we >> can have >>>>>>>>>>> more types. The word =E2=80=9Cupdate=E2=80=9D I always had a = problem with because >> it can >>>>>>>>> be >>>>>>>>>>> interpreted as =E2=80=9Creplacing". Replacing something to = fix a problem. >>>>>>>>>>>>> 8113 is simply asking for one of the type value codepoint, = so >> there can >>>>>>>>> be >>>>>>>>>>> another format to have more types. >>>>>>>>>>>>> Dino >>>>>>>>>>>>>> On Dec 18, 2018, at 9:24 PM, Joel M. Halpern >> >>>>>>>>> wrote: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Authors: that sounds like a reasonable addition to me? >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Yours, >>>>>>>>>>>>>> Joel >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On 12/18/18 10:48 PM, Brian E Carpenter wrote: >>>>>>>>>>>>>>> On 2018-12-19 15:46, Joel M. Halpern wrote: >>>>>>>>>>>>>>>> This is part of the package to move the coherent set of = base >> LISP >>>>>>>>> specs >>>>>>>>>>>>>>>> to PS. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> The reason we did this rather than folding it into = 6830bis / >> 6833bis >>>>>>>>> is >>>>>>>>>>>>>>>> that we had originally simply cited 8113, and then = realized >> that >>>>>>>>> needed >>>>>>>>>>>>>>>> to move to PS along with everything else. It seemed = (and is) >> simpler >>>>>>>>>>> to >>>>>>>>>>>>>>>> do it separately rather than to further modify 6830bis = / >> 6933bis. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> As for why it updates 6833bis, that is because one of = the >> cahnges in >>>>>>>>>>>>>>>> moving the set to PS was to improve the split as to = which >> information >>>>>>>>>>>>>>>> belonged in which document. >>>>>>>>>>>>>>> OK, but I still don't find it logical The text doesn't = explain >> which >>>>>>>>>>> part of >>>>>>>>>>>>>>> 6833bis is impacted, and normally these days we require = such an >>>>>>>>>>> explanation. >>>>>>>>>>>>>>> And if there is an impact, you're missing the = opportunity of >> fixing >>>>>>>>> the >>>>>>>>>>> error >>>>>>>>>>>>>>> or gap in 6833bis, so the reader of 6833bis will be none = the >> wiser >>>>>>>>>>> unless >>>>>>>>>>>>>>> you insert a reference to 8113bis. >>>>>>>>>>>>>>> On the other hand, if there is no error or gap, you = don't need >>>>>>>>>>> "Updates:" >>>>>>>>>>>>>>> at all. (Unfortunately, we don't have an "Extends:" = header.) >>>>>>>>>>>>>>> Brian >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Yours, >>>>>>>>>>>>>>>> Joel >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> On 12/18/18 9:25 PM, Brian Carpenter wrote: >>>>>>>>>>>>>>>>> Reviewer: Brian Carpenter >>>>>>>>>>>>>>>>> Review result: Ready with Issues >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> Gen-ART Last Call review of = draft-ietf-lisp-rfc8113bis-01 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> I am the assigned Gen-ART reviewer for this draft. The >> General Area >>>>>>>>>>>>>>>>> Review Team (Gen-ART) reviews all IETF documents being >> processed >>>>>>>>>>>>>>>>> by the IESG for the IETF Chair. Please treat these = comments >> just >>>>>>>>>>>>>>>>> like any other last call comments. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> For more information, please see the FAQ at >>>>>>>>>>>>>>>>> = . >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> Document: draft-ietf-lisp-rfc8113bis-01.txt >>>>>>>>>>>>>>>>> Reviewer: Brian Carpenter >>>>>>>>>>>>>>>>> Review Date: 2018-12-19 >>>>>>>>>>>>>>>>> IETF LC End Date: 2018-12-27 >>>>>>>>>>>>>>>>> IESG Telechat date: >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> Summary: Ready with issues >>>>>>>>>>>>>>>>> -------- >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> Comments: >>>>>>>>>>>>>>>>> --------- >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> I note that this is being raised from Experimental to = the >> standards >>>>>>>>>>> track. >>>>>>>>>>>>>>>>> Presumably that depends on the base LISP spec becoming = PS. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> Minor issues: >>>>>>>>>>>>>>>>> ------------- >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> "This document updates I-D.ietf-lisp-rfc6833bis." The = text >> doesn't >>>>>>>>>>>>>>>>> explain which text is updated. This is in contrast to >> RFC8113, which >>>>>>>>>>>>>>>>> explains clearly how it updates RFC6830 (*not* = RFC6833). Why >> doesn't >>>>>>>>>>>>>>>>> this draft claim to update rfc6830bis? I'm going to = assume >> that >>>>>>>>>>>>>>>>> is an error. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> In fact, why wasn't the definition of the LISP Packet = Types >> registry >>>>>>>>>>>>>>>>> moved into the base spec (rfc6830bis)? That is where = it >> belongs. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> Since rfc6830bis (and rfc6833bis) are still under IESG >> review, >>>>>>>>>>> anything >>>>>>>>>>>>>>>>> in them that needs updating should be updated! The = fact is >> that >>>>>>>>>>> rfc8113bis >>>>>>>>>>>>>>>>> extends rfc6830bis, which is not the same thing as = "updates". >>>>>>>>>>>>>>>>> If the WG thinks that implementers of 6830bis need to = read >> 8113bis, >>>>>>>>>>>>>>>>> there should be a normative reference in 6830bis to = 8113bis. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> lisp mailing list >>>>>>>>>>>>>> lisp@ietf.org >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/lisp >>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>=20 >>>>=20 >>>=20 >=20