IETF Logo Mail Archive

Re: [Last-Call] Rtgdir last call review of draft-ietf-lisp-vendor-lcaf-10

Luigi Iannone <ggx@gigix.net> Wed, 27 April 2022 11:31 UTC

Return-Path: <ggx@gigix.net>
X-Original-To: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E1E6C23902B for <last-call@ietfa.amsl.com>; Wed, 27 Apr 2022 04:31:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-net.20210112.gappssmtp.com
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 eEIq7ruN5S6L for <last-call@ietfa.amsl.com>; Wed, 27 Apr 2022 04:31:49 -0700 (PDT)
Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF699C06DB1A for <last-call@ietf.org>; Wed, 27 Apr 2022 04:31:49 -0700 (PDT)
Received: by mail-wm1-x336.google.com with SMTP id m62so960649wme.5 for <last-call@ietf.org>; Wed, 27 Apr 2022 04:31:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20210112.gappssmtp.com; s=20210112; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=AaCEuey68ZR49WnWaTgk57xNhDuuv1e0/qH7SgfVkko=; b=qYhi7o9xFJnofSaF9lxCuerHeDiUg4BlTbF1gjcuEGsVmzULvQSYyf0rwEBBeZrxcC fUp0EoiRr+0QDnQaJy+gllga45x7lZzcE9oYnnRzVTcf9iXhADl/dcEJIzZcwCOt9v0Z 6XpxERqpixPNlIAaoCavqSLy0khItCYzxvXEf3NLhGtxjZtxIK+gQbgkDLoduld7Pxf9 14aOd2HtHIKGkqkveUJqtjZwd96HWjOeZzT/Py7k+iH3jKoXiDiJNpFcE9DnWVj5dq43 ZNXMA1KF5xHpsMCOopyEqXxdyQNQRgeGgcn9Hv7SnX6aGrTfNLtZV9CQ7GjE6I2oKlvO m7Dg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=AaCEuey68ZR49WnWaTgk57xNhDuuv1e0/qH7SgfVkko=; b=keKkIbFUx34e1OBKHI6VlcRwoEt9P4aaKeHMTIe0hv2zXX8hkLcWbOlcxg0mE6I5Uw T8l9u1+VRt+IpTIt5X4f2qo7Fs92wa3EjaFMzThzCeQZQEoluApEnVU2m6+QXZJv9z2R I8rEyskCvlxqfkNKcgntVNNxGLHPfwAr4Vwkk2LLOXZMXsPOTLON8N1x4xJi0zK3Sird x+AJwquVpDQsHR6YqlZNquQ31JcEO0LzkIHdxiWtZ/DA+m0s4LGbgBAy52HpCwgxFY0R +AFXRbpAF13K98+LLO3kJw6QyGCGenzec360ChOSasVL/R8D0DEqSV8qmWzQ7kKDhQyk F1FQ==
X-Gm-Message-State: AOAM532RTSVDHokZSbqZJO6MGWdBDAcBilk8JfGiD9SzOcOO+sRdW+MV 5305U74p56cChhl+5BPMS46xEQ==
X-Google-Smtp-Source: ABdhPJxFznLYZF7Xsb8cbzzIqrdPbLgl2TZoiaut5X1ZeSQ/ydZY4x/mGUe1L3JyTEp0VME+vP8owQ==
X-Received: by 2002:a05:600c:6d3:b0:38e:c692:d50a with SMTP id b19-20020a05600c06d300b0038ec692d50amr34669552wmn.30.1651059107684; Wed, 27 Apr 2022 04:31:47 -0700 (PDT)
Received: from smtpclient.apple ([37.171.140.136]) by smtp.gmail.com with ESMTPSA id az30-20020a05600c601e00b0038ebd950caesm1381746wmb.30.2022.04.27.04.31.45 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Apr 2022 04:31:46 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\))
From: Luigi Iannone <ggx@gigix.net>
In-Reply-To: <CAP7zK5bL0ZOjw_93Q1OSe_nyVELUhs3PFZwBMcqbC6QMcVGuMg@mail.gmail.com>
Date: Wed, 27 Apr 2022 13:31:43 +0200
Cc: Dino Farinacci <farinacci@gmail.com>, "Alberto Rodriguez-Natal (natal)" <natal@cisco.com>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "draft-ietf-lisp-vendor-lcaf.all@ietf.org" <draft-ietf-lisp-vendor-lcaf.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "lisp@ietf.org" <lisp@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <0F77FADF-2408-4855-AD9E-58164AFFA744@gigix.net>
References: <165098180257.525.977533583517805963@ietfa.amsl.com> <BYAPR11MB3591085FFE95328E988F8334B6FB9@BYAPR11MB3591.namprd11.prod.outlook.com> <31ABB7B9-239C-4D19-8257-81211B76E868@gmail.com> <CAP7zK5bL0ZOjw_93Q1OSe_nyVELUhs3PFZwBMcqbC6QMcVGuMg@mail.gmail.com>
To: Dhruv Dhody <dd@dhruvdhody.com>
X-Mailer: Apple Mail (2.3696.80.82.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/_Zd-eXCm3ggFUZms5HaPa4CEvBA>
Subject: Re: [Last-Call] Rtgdir last call review of draft-ietf-lisp-vendor-lcaf-10
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Apr 2022 11:31:52 -0000

Hi Dhruv,

Indeed in 8060 the length unit is one single byte, hence there is no need of padding.
Thanks for your review.

Ciao

L.


> On 27 Apr 2022, at 05:48, Dhruv Dhody <dd@dhruvdhody.com> wrote:
> 
> Hi Dino,
> 
> In some protocols that I am aware of, it is usual to state that the
> variable-length portion in the TLVs/objects is 4-byte aligned. But looking
> at RFC 8060, I see that LISP does not follow this approach for any of the
> LCAF and it works just fine without it. I agree with you that no change is
> required then. Thanks for taking my comment into consideration.
> 
> Thanks!
> Dhruv
> 
> On Wed, Apr 27, 2022 at 3:19 AM Dino Farinacci <farinacci@gmail.com> wrote:
> 
>> Dhruv, can you explain more specifically what you mean by padding? Since
>> any LCAF encoding (even a vendor LCAF) has a length field, the encoding can
>> be the exact number of bytes described by the length. So no padding is
>> required.
>> 
>> Or did you mean something else?
>> 
>> Dino
>> 
>>> On Apr 26, 2022, at 7:49 AM, Alberto Rodriguez-Natal (natal) <
>> natal@cisco.com> wrote:
>>> 
>>> Hi Dhruv,
>>> 
>>> Thanks for your review! You’re bringing good points.
>>> 
>>> As per your comment on padding, it’s a good question but I cannot recall
>> right now any padding requirement in other LISP docs. A a quick search for
>> ‘padding' in rfc6833bis and RFC8060 shows not results. Maybe someone else
>> on the list can comment on padding requirements in LISP (if any)?
>>> 
>>> Also, good point on expanding LISP on first use, we’ll make sure to do
>> so in the revised draft.
>>> 
>>> Thanks!
>>> Alberto
>>> 
>>> From: Dhruv Dhody via Datatracker <noreply@ietf.org>
>>> Date: Tuesday, April 26, 2022 at 4:03 PM
>>> To: rtg-dir@ietf.org <rtg-dir@ietf.org>
>>> Cc: draft-ietf-lisp-vendor-lcaf.all@ietf.org <
>> draft-ietf-lisp-vendor-lcaf.all@ietf.org>gt;, last-call@ietf.org <
>> last-call@ietf.org>gt;, lisp@ietf.org<lisp@ietf.org>
>>> Subject: Rtgdir last call review of draft-ietf-lisp-vendor-lcaf-10
>>> 
>>> Reviewer: Dhruv Dhody
>>> Review result: Has Issues
>>> 
>>> I was assigned the reviewer today. I noticed that the IESG ballot is
>> done and
>>> the document is approved, I am not sure how valuable this review would
>> be but
>>> anyways...
>>> 
>>> Hello,
>>> 
>>> I have been selected as the Routing Directorate reviewer for this draft

v2.8.7 | Report a Bug | By Email