Re: [lisp] Review 6833bis

Dino Farinacci <> Sun, 18 March 2018 17:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9D8B9129502 for <>; Sun, 18 Mar 2018 10:20:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
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, FREEMAIL_FROM=0.001, 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 ORQ51yE50ezq for <>; Sun, 18 Mar 2018 10:20:28 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0B6C4129C6C for <>; Sun, 18 Mar 2018 10:20:28 -0700 (PDT)
Received: by with SMTP id a20so9481043wmd.1 for <>; Sun, 18 Mar 2018 10:20:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VKDnfXeAVXtB1XABmkPP3jf3OX6L7eHpyA3uO2iGQ9k=; b=ByDEJntel+yHiOXu0czJdGsgmakBEqfPAXDlA3LeZHPIa1eSoyrvNKQK11+5dOSVL8 YUgCdwqY1TnwLfpoKhXB8pJK5D3nlapGh9Y+so4pgog5C8X64bp3I6OHLNmw3j6V2eom DOy6RKtn1FonDyMNvbq8y9VnVqNodd56E6aewasGHJ9DL7wQN57N/28tjxC+l4DE/oiu XBr7iBFGem/y97lIKPIpTmR8uPA/HBcXofSAhoUTDKiAKkbwVaGlY5s677VO7EhkjTUk Yl+p/MbGZgQKg34WodYj3UHiFoR6S6JWymQmFWoUd7j9W7SW8cZ9XJl9u/uBuJTJO3mA Medg==
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=VKDnfXeAVXtB1XABmkPP3jf3OX6L7eHpyA3uO2iGQ9k=; b=TVGEz8RltKJzhSFFksbn9YutMKpYxJvv5i8PrFafohv6lQzO8bLsWQ55xvBqwJm8PU ozaNSIS6PdPHHwpy5dQhA82kr4hVwfmW4DX1QT5QlpJ0HVYxN5Ofv34NX+7xe73Y8UKA OPxNkZCleCC88/SXVKFoMEi/ne9bHnwcePJJRvf3zn8wnPE5Aq9Y8Mw5Nl+CVUkdup8y ZoWS17NdxQHyYwPDaMF+ozAGz1J6Wu5xy+41wLMwXiwQa5o4tYvq9f0jhmZfR5WxF/To 6pg+0LWVWVk+qTcfKe/0mnVPwroa7anx2Ckic+6d7+zyb7H42vE5QFPBL2wJfJcRYqvZ nn+g==
X-Gm-Message-State: AElRT7EH/s1yN8JYmZ81hXZSOX0ve+jkOiUXzZBBQcGlX1dTK9SEhOk+ PxdW/+hhTeOhCTYZcX0MlTg=
X-Google-Smtp-Source: AG47ELu+zjgOaWl0ceZL0CBDutyykEuSwjE7fYqmVNOWkBNSmV0LSRF96V6GYkHhXuWbRvGsAfklUQ==
X-Received: by with SMTP id u68mr7142476wmd.107.1521393626599; Sun, 18 Mar 2018 10:20:26 -0700 (PDT)
Received: from ?IPv6:2001:67c:1232:144:842e:efaf:8aec:de31? ([2001:67c:1232:144:842e:efaf:8aec:de31]) by with ESMTPSA id a23sm14431708wra.3.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Mar 2018 10:20:25 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: Dino Farinacci <>
In-Reply-To: <>
Date: Sun, 18 Mar 2018 10:20:24 -0700
Cc: " list" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Luigi Iannone <>
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:20:30 -0000

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

I didn’t disagree. I think I missed it. Will fix.

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

Fine with me. I’ll change.

Should I submit the new draft now?