Re: [RTG-DIR] Rtgdir last call review of draft-ietf-idr-rfc7752bis-11

Joel Halpern <jmh@joelhalpern.com> Mon, 07 November 2022 12:52 UTC

Return-Path: <jmh@joelhalpern.com>
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 47B6DC1524A2; Mon, 7 Nov 2022 04:52:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.807
X-Spam-Level:
X-Spam-Status: No, score=-2.807 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, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=joelhalpern.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 2UyX4BlDAAEf; Mon, 7 Nov 2022 04:52:45 -0800 (PST)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5652FC1522CF; Mon, 7 Nov 2022 04:52:45 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4N5WNY22ykz6GrKR; Mon, 7 Nov 2022 04:52:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1667825565; bh=15aCVKYHmap5mkC6uUaytduzNrQ3EoZEGeMbUYOH1aI=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=L2GKYl4BjNLW4hRy3D/uGD0Mm0LEhcjdEqWFVCHWZW+0KrYRL4jvcWRoNl+oGWpSt ICgzNzi9nLaMqPOMQvV1oZwMtw9i0n6VaLWo1pawRa5f/fZjycKyM0hEW/3IYwcNRt jEqH7egATrEvNRN5o5Vnwn2CP7jxw+BwQcp1LKnA=
X-Quarantine-ID: <qWJnXwmrFsGj>
X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net
Received: from [IPV6:2001:67c:370:128:d567:860e:8447:3401] (unknown [IPv6:2001:67c:370:128:d567:860e:8447:3401]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4N5WNW50mJz6G96L; Mon, 7 Nov 2022 04:52:43 -0800 (PST)
Content-Type: multipart/alternative; boundary="------------brRbhqYNatMjnwa8YAAAvXqA"
Message-ID: <267fc91d-1025-f7c0-2829-60cce7af9740@joelhalpern.com>
Date: Mon, 07 Nov 2022 07:52:42 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.4.1
Content-Language: en-US
To: Ketan Talaulikar <ketant.ietf@gmail.com>
Cc: rtg-dir@ietf.org, draft-ietf-idr-rfc7752bis.all@ietf.org, idr@ietf.org, last-call@ietf.org
References: <166687930912.48245.7099679165950186076@ietfa.amsl.com> <CAH6gdPxHvCN4N29CCWHw8XqLqZmQSpJxibyBNbNBZ_LiLfXmmg@mail.gmail.com> <2e83b437-2cf1-6d37-d84f-78d8eded1264@joelhalpern.com> <CAH6gdPy7KjhX0vn_y7aqeM=37yykZKcBLKmO0av=fWC9LosxiA@mail.gmail.com>
From: Joel Halpern <jmh@joelhalpern.com>
In-Reply-To: <CAH6gdPy7KjhX0vn_y7aqeM=37yykZKcBLKmO0av=fWC9LosxiA@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/8-F-193IuLXkHKUSi0ziLY4kQIQ>
Subject: Re: [RTG-DIR] Rtgdir last call review of draft-ietf-idr-rfc7752bis-11
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: Mon, 07 Nov 2022 12:52:49 -0000

Thanks.  Both those fixes work for me.

Yours,

Joel

On 11/7/2022 7:50 AM, Ketan Talaulikar wrote:
> Hi Joel
>
> Please check inline below for responses with KT2.
>
> On Mon, Nov 7, 2022 at 4:58 PM Joel Halpern <jmh@joelhalpern.com> wrote:
>
>     Slightly trimmed, two comments.  Joel
>
>
>     On 11/7/2022 1:03 AM, Ketan Talaulikar wrote:
>>     Hi Joel,
>>
>>     Thanks for your review and please check inline below for responses.
>>
>>     On Thu, Oct 27, 2022 at 7:32 PM Joel Halpern via Datatracker
>>     <noreply@ietf.org> wrote:
>>
>>         ..
>>             None
>>
>>         Nits:
>>           At the end of the first paragraph of section 4, could we
>>         add a sentence
>>           saying "the BGP-LS attributes appear within the
>>         corresponding new BGP NLRI"
>>           or similar?  While that is explained later in section 4,
>>         the length of the
>>           section means that a new reader is left wondering for quite
>>         some time.
>>
>>
>>     KT> The BGP-LS Attribute TLVs do not appear within the NLRI. Sec
>>     4.2 introduces BGP-LS NLRIs and indicates that they are carried
>>     within the MP_REACH/UNREACH. Further Sec 4.3 introduces the
>>     BGP-LS Attribute and indicates that they are carried as part of
>>     the BGP update along with the Link State NLRIs (and other
>>     attributes). Perhaps we can clarify a bit upfront that the new
>>     NLRI types are carried in the MP_REACH/UNREACH?
>
>     <jmh> Apparently I still managed to misread it. Sorry.  It would
>     help if you could put a little more context at the front of
>     section 4. </jmh>
>
>
> KT2> How about the following?
>
>     The link-state information is carried in BGP UPDATE messages as:
>     (1) BGP NLRI information carried within MP_REACH_NLRI and
>     MP_UNREACH_NLRI attributes that describes link, node, or
>     prefix object, and (2) a new BGP path attribute (BGP-LS
>     Attribute) that carries properties of the link, node, or
>     prefix objects such as the link and prefix metric or
>     auxiliary Router-IDs of nodes, etc..
>
>
>>
>>          Section 4.1 has the paragraph:
>>            All TLVs within the NLRI that are not specified as
>>         mandatory are
>>            considered optional.  All TLVs within the BGP-LS Attribute are
>>            considered optional unless specified otherwise.
>>           As far as I can tell, those two sentences are saying, about
>>         two different
>>           aspects of the encoding, the same thing.  But they say it
>>         in different ways.
>>           If there is some subtle difference in meaning taht is
>>         intended, please
>>           clarify.  If the meaning is indeed the same, could we use
>>         parallel
>>           construction to avoid readers thinking there is a difference?
>>
>>
>>     KT> They are talking about two different "containers" - the NLRI
>>     and the BGP-LS Attribute. The "default" is different for them.
>     <jmh>I am having trouble parsing the distinction, even if the
>     external default is different.  The two sentences both seem to say
>     that the only mandatory items are those which are specified as
>     mandatory.  They simply say it in two different ways.  Why is the
>     sentence construction different?  If there is an actual difference
>     in intended effect, I think a few more words would be helpful. </jmh>
>
>
> KT2> How about the following?
>     For both the NLRI and BGP-LS Attribute parts, all TLVs are
>     considered as optional except where explicitly specified as
>     mandatory or required in specific conditions.
> Thanks,
> Ketan
>
>>
>>     Thanks,
>>     Ketan
>>