Re: [Teas] [Lsr] WG Last Call for draft-ietf-lsr-isis-rfc5316bis

Donald Eastlake <d3e3e3@gmail.com> Wed, 03 March 2021 21:22 UTC

Return-Path: <d3e3e3@gmail.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 834283A1B47; Wed, 3 Mar 2021 13:22:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.847
X-Spam-Level:
X-Spam-Status: No, score=-1.847 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6i0lEmvq4zrO; Wed, 3 Mar 2021 13:22:56 -0800 (PST)
Received: from mail-il1-x134.google.com (mail-il1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (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 8AC773A1B45; Wed, 3 Mar 2021 13:22:56 -0800 (PST)
Received: by mail-il1-x134.google.com with SMTP id g9so22838934ilc.3; Wed, 03 Mar 2021 13:22:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nJBqb3Ry5tdu5q6xcwMZP6nSjK9/o1sAAmtn+HDnCLk=; b=VYavqVznGjDwYHyiZqueaWtn53kz59hZTI6Z9D7C7rS7jdK7UGFkUo6gmL8lLnr72P j3xIDAJ2rQTrY5GG6LdH5/3MKAeTTPSKwunyZAmEVuxv3TlZ5KG5p+lphR2iAbW5+wE/ K+DfGeBXxRnqT81ZAVKwPtUgCapAx3l94/5lfVbYIRL7y3LkEdX94YRWJ1SSQ9B/0m0j e8dBJ4Z4mSdp7HrU3gTqCHQed3SzJdH/LVYnSrVT2So/dMBv2ip1c4w6xZynHyVHBHBG GsPzaCqsBasqmUIKVFXO/jhDbW7Ehfa81xCc8Rnzt6s7a83lQFYIYO2nSvk84hvt8NAv zK5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nJBqb3Ry5tdu5q6xcwMZP6nSjK9/o1sAAmtn+HDnCLk=; b=MuGlvsF2ciSsByHS1IZdnhh8qDhypFTdA5c3FE4BDm/nfErSzOVndk+qqajB5r5zwe /WJk/aC5ZFymlwjw3GH1WoM5LygHXtU5xFR1LYzNZvVNhaIMgA0S3KB83Bg6bd68/tpt JqJH2KvodxBsQzqwLfMytVGARAMo+O95vsk7+rX5LFIIjNBxcVi6f3NK1/D1glYhwGK/ Nh/Hctiz17nWsisFPoiuTvN+vyCsOks7xbxXUbElewEI2tYms1wpshxhevQpelU2a6pu Sy/NWELG1NDaUg3T7lMxDRBrsVqhfTSJpxeE4s5V8yQTrKzpVhcWyRlReCCwuVby92Rf LRgw==
X-Gm-Message-State: AOAM532q7Igy3V5uUnzgxJ+h6RufZ3zQLav5Ewa8kFB8M2UBG/zQI9qB ZZYKHv7uZ50Bb/1c1EGjwGofIg49IPfKg5Hfgq0=
X-Google-Smtp-Source: ABdhPJw7afjI4OQOG28S+Br1R6T92hF7726CJn0vqgAi6M29clNIzoz2Q5/BvWSI2Fo46DusHHOdMv5bjqGu6ywLM7U=
X-Received: by 2002:a05:6e02:c2d:: with SMTP id q13mr1162071ilg.83.1614806575123; Wed, 03 Mar 2021 13:22:55 -0800 (PST)
MIME-Version: 1.0
References: <A31F6308-B1A4-4CD7-AC71-BB6722CAC1A7@chopps.org> <CAF4+nEHc=ZsLMAijh94PFg8C23_BSYP2VtJNPmFLAxst8K9P-g@mail.gmail.com> <BY5PR11MB4337C87749153805EC6B7AA1C1989@BY5PR11MB4337.namprd11.prod.outlook.com>
In-Reply-To: <BY5PR11MB4337C87749153805EC6B7AA1C1989@BY5PR11MB4337.namprd11.prod.outlook.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Wed, 3 Mar 2021 16:22:43 -0500
Message-ID: <CAF4+nEGr8hxsW0jPr=mysZJM1rnBMjko39Rk6iYE3DucYOTncw@mail.gmail.com>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
Cc: Christian Hopps <chopps@chopps.org>, "teas-chairs@ietf.org" <teas-chairs@ietf.org>, "teas-ads@ietf.org" <teas-ads@ietf.org>, "teas@ietf.org" <teas@ietf.org>, "lsr-chairs@ietf.org" <lsr-chairs@ietf.org>, "lsr@ietf.org" <lsr@ietf.org>, "lsr-ads@ietf.org" <lsr-ads@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004a911b05bca87401"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/V7U4bff8xUggpe40FP9rAGG8kYc>
Subject: Re: [Teas] [Lsr] WG Last Call for draft-ietf-lsr-isis-rfc5316bis
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Mar 2021 21:23:00 -0000

Hi Les,

See below at <de>

On Wed, Mar 3, 2021 at 3:47 PM Les Ginsberg (ginsberg) <ginsberg@cisco.com>
wrote:

> Donald -
>
> Thanx for your careful review and your support of the draft.
> Replies inline.
>
> > -----Original Message-----
> > From: Lsr <lsr-bounces@ietf.org> On Behalf Of Donald Eastlake
> > Sent: Wednesday, March 03, 2021 10:32 AM
> > To: Christian Hopps <chopps@chopps.org>
> > Cc: teas-chairs@ietf.org; teas-ads@ietf.org; teas@ietf.org; lsr-
> > chairs@ietf.org; lsr@ietf.org; lsr-ads@ietf.org
> > Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-isis-rfc5316bis
> >
> > Hi,
> >
> > I have a few comments. Sorry to send these so late in the process. I
> > support publication of this draft regardless of whether any action is
> > taken on my comments.
> >
> > 1. Since there are non-allocation actions, I suggest that the first
> > sentence of Section 6 be more like "IANA is requested to take the
> > following actions."
>
> [Les:] I understand your point.
> However, in this case we are inheriting allocations made by RFC5316 AND
> adding a new code point for the new IPv6 local ASBR identifier sub-TLV.
> Being 100% accurate requires identifying what has been done already vs
> what is new.
> But once the RFC is published the text will change to " IANA has made..."
> (as it is in RFC 5316) for all the code points (new and old).
> Having worked w IANA folks many times, I have great confidence that they
> will get things right even with the current less than 100% strictly
> accurate text - so I prefer not to invest time here.
> Hope that is OK with you.
>

<de> I agree that IANA will fix this so it is OK to not change.


> > 2. It should be called out as an explicit IANA action to replace all
> > References to "[RFC5316]" on the IANA IS-IS TLV Codepoints web page
> > with References to "[this document]".
> >
>
> [Les:] OK
>
> > 3. Use of "new" throughout the document for codepoints that were
> > assigned for RFC 5316 more than a decade ago should be eliminated.
>
> [Les:] Well, this document replaces RFC 5316. Which means future readers
> need not ever look at RFC 5316. In which case the distinction between what
> was "new" in 5316 and what is "new" in 5316bis becomes moot.
> So while I agree that strictly speaking you are correct I am not convinced
> that doing as you suggest aids clarity.


 <de> I was not suggesting making any distinction between what is or isn't
new in 5316bis, except by implication in the IANA Considerations Section.
I actually just don't see any need to use the word "new" in this document.

> 4. I generally think it is better for implementation requirements to
> > be in the main text rather than the IANA Considerations, so I suggest
> > moving "Note that all four sub-TLVs SHOULD NOT appear in TLVs 22, 23,
> > 25, 222, or 223 and MUST be ignored if they are included in any of
> > these TLVs." up to near the end of Section 3.1.
>
> [Les:] I have looked at other documents with similar cases (i.e., a
> sub-TLV that is permitted in only a subset of the TLVs in the combined
> registry) and they do not have such a statement at all. The "N" indication
> in the registry columns is deemed sufficient.
> I am therefore inclined to remove the Note altogether.
>

<de> OK.


> > 2. I like diagrams and enjoy doing ASCII art, so I suggest replacing
> > the prose table at the beginning of 3.1 with the following. In any
> > case note that the usual IETF admonition regarding the reserved bits,
> > that they MUST be sent as zero and ignored on receipt, seems to be
> > missing in the document.
> >
> >     0                   1                   2                   3
> >     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |   Router ID                                     (4 octets)    |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |   default metric                              | (3 octets)
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |S|D| Rsvd      |                                 (1 octet)
> >    +-+-+-+-+-+-+-+-+
> >    |sub-TLVs length|                                 (1 octet)
> >    +-+-+-+-+-+-+-+-+-+-+-+-
> >    | sub-TLVs ...                                    (0-246 octets)
> >    +-+-+-+-+-+-+-+-+-+-+-+-
> >
> >      - S, D: Flooding-scope and up/down information discussed below.
> >      - Rsvd: 6 reserved bits that MUST be sent as zero and ignored
> >              on receipt.
> >      - sub-TLVs length: gives the total number of octets of sub-TLVs,
> >              which is variable from zero to 246 octets, as an unsigned
> >              integer. sub-TLVs are structured as shown below. sub-TLVs
> >              with an unknown type MUST be ignored. If the value of the
> >              sub-TLVs length field is larger than 246, or the last
> >              sub-TLV extends beyond the sub-TLVs length, the TLV is
> >              malformed and MUST be ignored.
> >
> >    +-+-+-+-+-+-+-+-+
> >    | sub-type      |                                 (1 octet)
> >    +-+-+-+-+-+-+-+-+
> >    | sub-TLV length|                                 (1 octet)
> >    +-+-+-+-+-+-+-+-+-+-+-+-
> >    | sub-TLV value ...                               (variable)
> >    +-+-+-+-+-+-+-+-+-+-+-+-
>
> [Les:] OK
> It was not done this way in RFC 5316. When writing bis documents I am
> biased to NOT changing existing presentation if there is no actual change
> in functionality to that section.
> But I agree diagrams are easier to read and it would be more consistent
> with other sections of the document.
>

<de> I think there are actually two intertwined changes: a change to
presentation and more specific RFC 2119 language. I think both are an
improvement so thanks for agreeing to them.

<de>Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e3e3@gmail.com


>    Les
>
> >
> >
> > Thanks,
> > Donald
> > ===============================
> >  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
> >  2386 Panoramic Circle, Apopka, FL 32703 USA
> >  d3e3e3@gmail.com
> >
> > On Wed, Feb 17, 2021 at 10:30 AM Christian Hopps <chopps@chopps.org>
> > wrote:
> > >
> > > Hi LSR and TEAS,
> > >
> > > This begins a joint WG last call for:
> > >
> > >   https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-rfc5316bis/
> > >
> > > Please discuss any issues on the LSR mailing list. The WGLC will end
> March
> > 3, 2021.
> > >
> > > Authors, please indicate wether you are aware of any IPR related to
> this
> > document to the list.
> > >
> > > Thanks,
> > > Chris, Acee, (Lou and Pavan).
> >
> > _______________________________________________
> > Lsr mailing list
> > Lsr@ietf.org
> > https://www.ietf.org/mailman/listinfo/lsr
>