[lisp] Tsvart last call review of draft-ietf-lisp-6834bis-10
Yoshifumi Nishida via Datatracker <noreply@ietf.org> Tue, 17 May 2022 08:22 UTC
Return-Path: <noreply@ietf.org>
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 A2731C157B5D; Tue, 17 May 2022 01:22:14 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Yoshifumi Nishida via Datatracker <noreply@ietf.org>
To: tsv-art@ietf.org
Cc: draft-ietf-lisp-6834bis.all@ietf.org, last-call@ietf.org, lisp@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 8.2.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <165277573465.63464.14494815453477247059@ietfa.amsl.com>
Reply-To: Yoshifumi Nishida <nsd.ietf@gmail.com>
Date: Tue, 17 May 2022 01:22:14 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/Mz-jcme82y6h3VlXaFraFk7q8aA>
Subject: [lisp] Tsvart last call review of draft-ietf-lisp-6834bis-10
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.34
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 May 2022 08:22:14 -0000
Reviewer: Yoshifumi Nishida Review result: Almost Ready This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@ietf.org if you reply to or forward this review. Summary: This document is almost ready for publication as a Proposed Standard document. but I believe it will be better to address the following points. 1: It would be better to clarify the following points in the protocol for registering Map Version number. * How many versions of mapping should be maintained by routers and servers? Only the latest one or else? * Are we allowed to send a new Map-Register message while waiting for another Map-Register message? * What will be the action when Map-Server receives the version number that they are not expecting? Discard or else? * What will be the action when Map-Register message reaches retransmission limits? 2: Page 3 Section 1: "If this is not the case, the ETR can directly send a Map-Request containing the updated mapping to the ETR," -> could it be "to the ITR"? 3: Page 6 Section 6: "An update in the version number (i.e., a newer version) consists of incrementing by one the older version number" -> This seems to be an integral part of the protocol. I think using MUST here would be preferable. 4: Page 6 Section 6: I am wondering what is the use case for comparing two version numbers. I might miss something, but it seems to me that we just need to check whether the version number is the expected one or not. It might be better to explain the use case for it if there is any. -- Yoshi
- [lisp] Tsvart last call review of draft-ietf-lisp… Yoshifumi Nishida via Datatracker
- Re: [lisp] Tsvart last call review of draft-ietf-… Luigi Iannone
- Re: [lisp] Tsvart last call review of draft-ietf-… Yoshifumi Nishida
- Re: [lisp] Tsvart last call review of draft-ietf-… Luigi Iannone