Re: [Lsr] AD Review of draft-ietf-lsr-isis-invalid-tlv-01

Alvaro Retana <aretana.ietf@gmail.com> Mon, 22 June 2020 22:05 UTC

Return-Path: <aretana.ietf@gmail.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68AFE3A0C52; Mon, 22 Jun 2020 15:05:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 mAlTsYhb0Jb4; Mon, 22 Jun 2020 15:05:17 -0700 (PDT)
Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (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 3C87A3A0C3A; Mon, 22 Jun 2020 15:05:17 -0700 (PDT)
Received: by mail-wr1-x435.google.com with SMTP id z13so6596312wrw.5; Mon, 22 Jun 2020 15:05:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=jp+Jew7B3DhixFzmkjZY12TV3Jesk0hb31BEZU8pWb8=; b=QCwObGJj8g+73V7zYreh4Czf5jFNnkWdbi7dI8M91mq8xy6JzDLNBRwi5VGZk5r6Oj rkIOnIPOUo5mKcnr4VJ7f/7kF5nzwD5bqG+guZRQAOdFEihhMbW/H+95lhngETkBmBsF Y7xnB0TXwmIy9T1ab0UFRsS5cKNJ62bfc3Wn5S3ZLz5rq5gI8vOJHA+KljL67N/xmt+4 duRqHEPX+O7vZdfW+QG9t+g7KP6awqfBLx4AINARISv4In39vEI3MrMhiiF0MoKbwYMz YxJNTjR1VOpFH8/NjQlChTRhFuDykRla9EZ6e/D9y/HpJKB0TdIqTnx96L7ylSgeI3/x SAog==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=jp+Jew7B3DhixFzmkjZY12TV3Jesk0hb31BEZU8pWb8=; b=l6hitQICz9UohDzNJxA7PM8f2c792oi6I/UMOvqjSqUIPe9fDiyQkK1ftww6DtN+mh HNFsNoyAhLpksZybmrJLNE8LqyYpn/8fNUfDI3Dhv+/EutA+XUmD/huUnVrzRGHpPsNd kaxBk8Stz3El+jyyzZvC/F3vsX8du32oMeko3MjH1VegWkE5wvjRyBKTy4WqG3O82kw5 hZG9WXB7BElzxcE+XUnsWz9Mhd+Yl11UaxSUfhJOLk7RDiiopW2/5GcymapZ+mQZbRWc 0g+58EApxln6Bq/Hq/VYhM2/mIQFdEF8Cp8ZofEDvjbK0esmx6SA6BnNZNomDuAIIzDr yibw==
X-Gm-Message-State: AOAM533kpUvfReXagN/43nZdiV/Fkec9UoZFe57SEfL+dlP+g+ltTGx/ V5+rXAL5II6eiyPzmXlzlaspoEt0pL2aAiH4wIg=
X-Google-Smtp-Source: ABdhPJwoYWOLWkDygLzXmjG5ofvN43kMqKVUNRZSM90jcZ0T4r1AAhU5YMnuKd9N3X/K8HxTOyzGnzuXyn+fQRiioVc=
X-Received: by 2002:a5d:4bc8:: with SMTP id l8mr5844827wrt.159.1592863515468; Mon, 22 Jun 2020 15:05:15 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 22 Jun 2020 15:05:14 -0700
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <BY5PR11MB4337292DAAB89B754559E56DC1980@BY5PR11MB4337.namprd11.prod.outlook.com>
References: <CAMMESszYKXBwBi3zTtrY2qNAs8+zLZ65an4buzRt6Jt14Ew83g@mail.gmail.com> <BY5PR11MB4337292DAAB89B754559E56DC1980@BY5PR11MB4337.namprd11.prod.outlook.com>
MIME-Version: 1.0
Date: Mon, 22 Jun 2020 15:05:14 -0700
Message-ID: <CAMMESsxRwNtPY4PCE8ETVQ8jWDnBvjq-qnZupq-GoKLOQe_ELw@mail.gmail.com>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, "draft-ietf-lsr-isis-invalid-tlv@ietf.org" <draft-ietf-lsr-isis-invalid-tlv@ietf.org>
Cc: "lsr-chairs@ietf.org" <lsr-chairs@ietf.org>, "lsr@ietf.org" <lsr@ietf.org>, Christian Hopps <chopps@chopps.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/ldtPHCNheJUTYJxNdRWstll3H-M>
Subject: Re: [Lsr] AD Review of draft-ietf-lsr-isis-invalid-tlv-01
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Jun 2020 22:05:20 -0000

On June 19, 2020 at 11:49:51 AM, Les Ginsberg wrote:


Les:

Hi!

Just a couple of in-line answers.

We should be ready to move forward once you submit the update.

Thanks!!

Alvaro.


...
> > I'm writing all this here to have a record of this decision and to
> > give anyone in the WG the opportunity to raise concerns, if any.
>
> [Les:] Just to be sure I understand, you are documenting that we need do
> nothing in this regard?

Correct.



...
> > [major] s/5304/5305 Is §3.2 intended to update rfc5304?
>
> [Les:] 3.2 updates RFC 5304 to the extent that it recommends controls for
> behaviors that might not be backwards compatible. (Similar for RFC 6233)
>
> Section 3.3 clearly updates RFC 5305, so I have added that here.
>
> But it is a fair question to ask if RFC 5304 should be added to the list of
> documents updated? It currently is NOT listed - which makes me wonder why
> we include RFC 6233 in the list of updated documents.
>
> I am inclined to not include either in the list of updated documents.
>
> Please comment.

I agree that it is not necessary to formally Update either.




...
> > [major] An important clarification, which I don't think is explicitly
> > made, is that the behavior for unknown is being applied to disallowed.
> > Not knowing and not expecting (= disallowed) are different things, but
> > this document is saying that the document treats them the same:
> > ignore. I think adding a sentence about that relationship would help
> > a lot, and it may help us cover any cases that may have been missed (I
> > don't think there are any, but just in case)...maybe something like
> > this (I'm sure you can come up with much better words):
> >
> > This document extends the concept of unknown to disallowed.
> >
> >
> > [major] Related to the last comment... The title of the document
> > mentions "Invalid" TLVs. (1) there is no other mention of an invalid
> > TLV in the text, and (2) there is no connection made between "invalid"
> > (in the title) and "disallowed" (in the text).
>
>
> [Les:] It seems to me that Section 3.1 is very clear on this point. I
> prefer not to change/add text as you have suggested.
>
> I did add some examples of "invalid".

As long as it is clear to other reviewers that invalid, disallowed and
unknown have the same behavior...we can go ahead with no changes.


...
> [Les:] It isn’t clear to me that we have updated RFC3563 - unless you
> presume that anything that alters the registries in any way is considered
> an update to RFC 3563.
>
> RFC3563 created the registry based on RFC 3359 - which had the columns in
> there.
>
> The description of the columns is present in this document to provide
> context for the rest of the document. I don’t believe this description
> represents any change to the registry.
>
> Specifically, we are not proposing that the registry be altered to include
> the description.
>
> If you agree, should we then remove RFC 3563 from the list of RFCs updated
> by this document??


Yes, I agree.

BTW, this request..

   "IANA is requested to update the TLV Codepoints Registry to reference
   this document."

...is to add a reference to this document, and not to remove the others, right?

If so, then maybe "IANA is requested to add this document as a
reference for the TLV Codepoints Registry." might be better.



...
> > 215 "The additional values for this TLV should be IIH:n, LSP:y, SNP:n,
> > 216 and Purge:y. "
> >
> > [nit] s/y. "/y."
>
> [Les:] This is a direct quote from RFC6232.
>
> Sorry, you don’t get to edit it. 😊

Not editing the quote...just the extra space after the period. ;-)