Re: [lisp] Review 6833bis

Luigi Iannone <> Sun, 18 March 2018 17:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AF8DE129C6C for <>; Sun, 18 Mar 2018 10:18:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IQiAPgbiIwEh for <>; Sun, 18 Mar 2018 10:18:32 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1D4AF126DFF for <>; Sun, 18 Mar 2018 10:18:24 -0700 (PDT)
Received: by with SMTP id a20so9476685wmd.1 for <>; Sun, 18 Mar 2018 10:18:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=f6/7/zA5WZaVy3jPD5nxNFQhz1Zz3ww/Kax511KLNPk=; b=VnYPHpfVfaoRSXt9XFzp61l/x7yILJTy5uME3fLnpn5Cbppd7pZotW+EKfXKczO+B5 2ONCYfYj471X+ukeeQZiz1oboD2Q0A8Dbdo4RGbM8pa64pQI0YDXRa7z/YjvLDkfxSLT tJMczWjMNckWiNAFSyHNBuFn+nAG2derAaZwFC4rMxSw+AIvK9Y/FWwo87V3v1NevLVi ftVPyk6u6ns4vb+PabL+Xsu5axb+IxAku85lMlezZ0b21t4xtQw1axHCYfKmwk1WpVck NrtfZ01SLpAdTrFBUbC5w4Jn0cWLBPip1hEbu1B5QwZQBbNH6n35AhciThyYQLc1gbto URdQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=f6/7/zA5WZaVy3jPD5nxNFQhz1Zz3ww/Kax511KLNPk=; b=cRp3adgWoAr/Lttiof8+yKZsJ6q5D+afZQiDLv/cQejUu1I75SX5zIUh8IDhibmKNt YjvIVHBjv1CwYCs/IFYLdDeyg5cWzNT3jskGxcUfrdBubD4+Qtg1E7bbia18mIGhaTQ8 ViQdHfneHD9xDulQmD4hdFM1y2mSjnq+wdnrOENV3wobzpBaoJC25XNeV9lHm8a7VMEE ZpTZ7J6KD8bUjmbAn9BiSqm3iU1+vB9sq/rIWW5IWNqHZ1UaFSjT/eFgP/6Pc5W22QMM 6ortRR3iaJYWc/zoYZ7GBAQYedtjJzka+x1WGt5+4OU8I8eUCr18LpFQB30MsyJ3JVf/ mWzA==
X-Gm-Message-State: AElRT7FGpX/Fu1EmLmzcgLxEmpp6PIqF5AkXekrFzpUA5a6GCQmOsxH8 DfP2k87NUK2wUE73iOVK+DEl5w==
X-Google-Smtp-Source: AG47ELugDG/I3bJzb2xgEvDcaaZ5WgA4vc1u7BYPBoNxHh3/jLXXAOkQtWKBbPjk33GUoCdSKz/vdw==
X-Received: by with SMTP id 63mr6440065wmy.115.1521393502512; Sun, 18 Mar 2018 10:18:22 -0700 (PDT)
Received: from ?IPv6:2001:67c:1232:144:a531:7ab:91a1:6942? ([2001:67c:1232:144:a531:7ab:91a1:6942]) by with ESMTPSA id u127sm14838359wmd.30.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Mar 2018 10:18:21 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: Luigi Iannone <>
In-Reply-To: <>
Date: Sun, 18 Mar 2018 17:18:19 +0000
Cc: " list" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Dino Farinacci <>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <>
Subject: Re: [lisp] Review 6833bis
X-Mailman-Version: 2.1.22
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, 18 Mar 2018 17:18:35 -0000

Hi Dino,

thanks for the changes. For me is all good, except the two following points:

>>>   Note that while it is conceivable that a Map-Resolver could cache
>>>   responses to improve performance, issues surrounding cache management
>>>   will need to be resolved so that doing so will be reliable and
>>>   practical.  As initially deployed, Map-Resolvers will operate only in
>>>   a non-caching mode, decapsulating and forwarding Encapsulated Map
>>>   Requests received from ITRs.  Any specification of caching
>>>   functionality is left for future work.
>> s/left for future work/ out of the scope of this document/

You do not agree with this suggestion? Sounds more neutral to me.

>>>   Values in the "Not Assigned" range can be assigned according to
>>>   procedures in [RFC8126].  Documents that request for a new LISP
>>>   packet type MAY indicate a preferred value in Section 10.4.
>> Don’t understand the “in Section 10.4” part. Should be deleted.
> This was added when we were writing draft-ietf-lisp-type-iana (RFC8113). It was a request from someone (not Mohammad) I think. Didn’t change.

I am not against the sentence, is just the "Section 10.4” part, why should a document indicate a preference in a section 10.4?????
If you change the sentence to:

Values in the "Not Assigned" range can be assigned according to
  procedures in [RFC8126].  Documents that request for a new LISP
  packet type MAY indicate a preferred value.

That makes more sens to me.