Re: [Idr] Lars Eggert's No Objection on draft-ietf-idr-rfc7752bis-14: (with COMMENT)

Lars Eggert <lars@eggert.org> Fri, 17 February 2023 12:03 UTC

Return-Path: <lars@eggert.org>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10417C14CE2C; Fri, 17 Feb 2023 04:03:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org
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 FTt4VbRn4X8l; Fri, 17 Feb 2023 04:03:34 -0800 (PST)
Received: from mail.eggert.org (mail.eggert.org [IPv6:2a00:ac00:4000:400:211:32ff:fe22:186f]) (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 DE0C0C14CF1F; Fri, 17 Feb 2023 04:03:33 -0800 (PST)
Received: from smtpclient.apple (unknown [IPv6:2a00:ac00:4000:400:7d40:4f11:d182:a060]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 3D1AB1D2F8B; Fri, 17 Feb 2023 14:03:24 +0200 (EET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1676635404; bh=Fw49vOK05vZQrpx6KVsLskFl8RzBvsjTYcsoaTn6sTc=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=CwPxDJqUQ4tqel2qUUwMSSd1L11ose11tlc+Vg37jAZzJ/41tTt3RxFU92GzAlMy7 WAqMd1Qwk+c/aDXQmIQYXffQW5yJwYc31jCpdhPok/aciWUCM80UwFq9V/miv5Ub6N imORSwkJBoIcH6SOAWkfLH+D+pvHuLDKfiL0lLpw=
Content-Type: multipart/signed; boundary="Apple-Mail=_BA3E777B-529B-43A6-B6C6-18FAAF1E75BB"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\))
From: Lars Eggert <lars@eggert.org>
In-Reply-To: <CAH6gdPyJZL72TFZ1XbU3DaTwCR9BftCkPtxGQ+3wSTJ-yYrofQ@mail.gmail.com>
Date: Fri, 17 Feb 2023 14:03:18 +0200
Cc: The IESG <iesg@ietf.org>, draft-ietf-idr-rfc7752bis@ietf.org, idr-chairs@ietf.org, idr@ietf.org, shares@ndzh.com, jhaas@pfrc.org, aretana.ietf@gmail.com
Message-Id: <26F6790A-6F09-4CB9-83CA-AFF2CA5B2E1E@eggert.org>
References: <167110671278.47364.16506124207984879789@ietfa.amsl.com> <CAH6gdPxw=bvr+cU3khvC2Fmkvf86UdQu35_R+h9qtK1dtL8Hmg@mail.gmail.com> <58257CA6-2A38-4FDE-A2E0-BA5839626DBD@eggert.org> <CAH6gdPyJZL72TFZ1XbU3DaTwCR9BftCkPtxGQ+3wSTJ-yYrofQ@mail.gmail.com>
To: Ketan Talaulikar <ketant.ietf@gmail.com>
X-MailScanner-ID: 3D1AB1D2F8B.A5FBE
X-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details
X-MailScanner-From: lars@eggert.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/R9oIFHAbudm_rCAFsZgzJ0yG5rA>
Subject: Re: [Idr] Lars Eggert's No Objection on draft-ietf-idr-rfc7752bis-14: (with COMMENT)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Feb 2023 12:03:40 -0000

Hi,

On Feb 17, 2023, at 13:54, Ketan Talaulikar <ketant.ietf@gmail.com> wrote:
> > ```
> >      To compare NLRIs with unknown TLVs, all TLVs within the NLRI MUST be
> >      ordered in ascending order by TLV Type.  If there are multiple TLVs
> >      of the same type within a single NLRI, then the TLVs sharing the same
> >      type MUST be in ascending order based on the value field.  Comparison
> >      of the value fields is performed by treating the entire field as
> >      opaque binary data and ordered lexicographically.
> > ```
...
> KT2> Are you suggesting that the description in the text is insufficient? I am not sure if a Wikipedia article would fly as a (in this case normative?) reference.

Yes, I think you need to say something more, because the current text says

1. order TLVs by type
2. if there are multiple TLVs of the same type, order them by value
3. to order by value, order lexicographically

My point is that in step 3, the values may be of different lengths, and so you need to say what *kind* of lexicographic order you intend (= shortlex).

You don't need to cite Wikipedia, you could also just require that values are first compare solely by length and lexicographically when the lengths are equal.

Lars