[RTG-DIR] RtgDir Early review: draft-ietf-lisp-name-encoding-00

Christian Hopps <chopps@chopps.org> Tue, 25 October 2022 18:43 UTC

Return-Path: <chopps@chopps.org>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EEEAC14CF10; Tue, 25 Oct 2022 11:43:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level:
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fItk81hI0r44; Tue, 25 Oct 2022 11:43:14 -0700 (PDT)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 0DFD6C14F607; Tue, 25 Oct 2022 11:43:10 -0700 (PDT)
Received: from ja.int.chopps.org.chopps.org (172-222-113-012.res.spectrum.com [172.222.113.12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 33D877D07F; Tue, 25 Oct 2022 18:43:10 +0000 (UTC)
User-agent: mu4e 1.8.5; emacs 28.0.92
From: Christian Hopps <chopps@chopps.org>
To: rtg-dir@ietf.org
Cc: lisp@ietf.org, lisp-chairs@ietf.org, draft-ietf-lisp-name-encoding.all@ietf.org, chopps@chopps.org
Date: Tue, 25 Oct 2022 14:38:03 -0400
Message-ID: <m2r0yvagn6.fsf@ja.int.chopps.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/x-b4I6uko8dhtCiTJcdijuM4vzg>
Subject: [RTG-DIR] RtgDir Early review: draft-ietf-lisp-name-encoding-00
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Oct 2022 18:43:18 -0000

Hello,

    I have been selected to do a routing directorate "early" review of
    this draft.

https://datatracker.ietf.org/doc/draft-ietf-lisp-name-encoding/

    The routing directorate will, on request from the working group
    chair, perform an "early" review of a draft before it is submitted
    for publication to the IESG. The early review can be performed at
    any time during the draft’s lifetime as a working group document.
    The purpose of the early review depends on the stage that the
    document has reached.

    As this document is in working group last call, my focus for the
    review was to determine whether the document is ready to be
    published. Please consider my comments along with the other
    working group last call comments.

    For more information about the Routing Directorate, please see
    ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Document: draft-ietf-lisp-name-encoding-00
Reviewer: Christian Hopps
Review Date: October 25, 2022
Intended Status: Experimental

    Summary:

No issues found. This documents is ready to proceed to the IESG.

    Comments:

The document is well written and easy to understand. Personally, I
would have gone with a length value for performance and implementation
simplicity; however, seeing as this document has already been around
and reviewed for a while (and I believe from reading the mailing list,
it's already deployed), and more importantly the WG (the experts in
LISP) have had this point brought up and are happy with the existing
solution, I see no reason to push back against it.

Thanks,
Chris.