Re: [Lsr] AD Review of draft-ietf-isis-yang-isis-cfg-35

Alvaro Retana <aretana.ietf@gmail.com> Tue, 30 July 2019 19:29 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 185AA1201AF; Tue, 30 Jul 2019 12:29:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.736
X-Spam-Level:
X-Spam-Status: No, score=-1.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 qJQtp5J1-oLR; Tue, 30 Jul 2019 12:29:20 -0700 (PDT)
Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (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 7D5A912010F; Tue, 30 Jul 2019 12:29:19 -0700 (PDT)
Received: by mail-ed1-x533.google.com with SMTP id m10so63546122edv.6; Tue, 30 Jul 2019 12:29:19 -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; bh=gZSBFgtffKGO082X+VtqT7cjxwVJ7+sWFSaZZPgDYtg=; b=VALAOuC1Q6qMDx0MNMxtB9UtmsMQKRDNwLRfWZh8Wyb96fkqgJ+AZJKi2+Ooj798AM edP/aLktgctXh0ElCJ9l7y/dm3EYWzDrtv1lfcQ5ZDxqABq5eyX0v2SgTZ2sAcQsZfYj EuQb5+cArozSEHl7D8L381r48BjXbig1iY0C/RGa68ViYrXlM6YS1yrbpnfRKyDoBzb8 p5R8TQK+ts00lDWjJWgNGLiFICFJp0WelMISJd8e4XwTGp5/S+vD+vqg4Q0WrJSnHjip TXJ31UDyyTxSbGlBMA5dG3vrDv7NNMklUqmpD7W/6MvD3A4TGuxDWtVN7yvF3pGIg7YN xPbQ==
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; bh=gZSBFgtffKGO082X+VtqT7cjxwVJ7+sWFSaZZPgDYtg=; b=qM8Foyt4B46qMzlXkzSROJB4YFrMakHlmn4F0glBMTxkv8aXLaUdgwCAjpdnxRBvvf ACK27mDrUsrmaFFWLfb41+3qL/vJhvlISrtsFugkS9PYuIbI7h2zyp1tfpQhERYvQlmt z+idoTczmbWYtxHtzAg3eQHW2bR2gIF1m0eJL+FdATwIm1m87qlU8T0/w39rneKxYc8m tnTze6hPNPEmZoURJLfu1L/oen+HkFBCUhiN9ETszWlxmPDiYGEX0Tmb+N2X+IUH+rG6 tjMu6zreitbzDbGzq7R8F04Axl6xNHm3/8BGH24ZH30jmgnks4lHy8z16F3/bKclXOHx cqTw==
X-Gm-Message-State: APjAAAXBo81RTQBb3aCmMEc82atTtu1Ea2jDslui+qCIKp0K9YYU8BAK yIaaL+Gul9NbZayqSz0z5hxZuQUsZMf0O/UkMoGRwcHi
X-Google-Smtp-Source: APXvYqxOp6k9b55qbBhNqO3C3sPPOpvdSAEqklsM43zaKDtwjDbsx9LPC0O/eaBc4mQI5OTtImmi+FQjCji1xGfzZYI=
X-Received: by 2002:aa7:ca49:: with SMTP id j9mr21504567edt.148.1564514957854; Tue, 30 Jul 2019 12:29:17 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 30 Jul 2019 15:29:16 -0400
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <19628_1561638987_5D14B84B_19628_476_1_9E32478DFA9976438E7A22F69B08FF924C25B532@OPEXCAUBMA3.corporate.adroot.infra.ftgroup>
References: <CAMMESsxQGGj_PmmjeRqBfTgU=Z2=Eu8Yn9FXLHgEm1PorTaUqA@mail.gmail.com> <19628_1561638987_5D14B84B_19628_476_1_9E32478DFA9976438E7A22F69B08FF924C25B532@OPEXCAUBMA3.corporate.adroot.infra.ftgroup>
MIME-Version: 1.0
Date: Tue, 30 Jul 2019 15:29:16 -0400
Message-ID: <CAMMESszTQodYdTUc1y=vO_ppROOTWJiY9pxrsNdtDgLU3PfkZg@mail.gmail.com>
To: "draft-ietf-isis-yang-isis-cfg@ietf.org" <draft-ietf-isis-yang-isis-cfg@ietf.org>, stephane.litkowski@orange.com
Cc: Yingzhen Qu <yingzhen.ietf@gmail.com>, "lsr@ietf.org" <lsr@ietf.org>, "lsr-chairs@ietf.org" <lsr-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004f0db0058eeb0687"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/XWalpx4lL37QPfonyI9dWTwLCVU>
Subject: Re: [Lsr] AD Review of draft-ietf-isis-yang-isis-cfg-35
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: Tue, 30 Jul 2019 19:29:23 -0000

On June 27, 2019 at 8:36:46 AM, stephane.litkowski@orange.com (
stephane.litkowski@orange.com) wrote:

Stephane:

Hi!

Sorry it took me while to get to your reply.

Thanks for your comments. We are working on updating the document
accordingly.

Please find some replies inline that may require more discussion.

I have stripped the comments that will be fixed in the next revision.

Just leaving some text with answers.

Thanks!

Alvaro.

...

474         Some parameters like "overload bit" and "route preference" are
not

475         modeled to support a per level configuration.  If an
implementation

476         supports per level configuration for such parameter, this

477         implementation SHOULD augment the current model by adding both

478         level-1 and level-2 containers and SHOULD reuse existing

479         configuration groupings.



[major] "...SHOULD augment the current model by adding both level-1 and
level-2 containers"  What other way would that be done?  I think that
Normative language is not needed in this case.

[SLI] Using YANG there are multiple ways to do things. People may create
new containers, use different namings… and we want to keep the modeling
consistency even in the future augmentations.

Ok…why not use MUST then?  Are there cases where it would be ok to not be
consistent?  IOW, the current wording doesn’t guarantee consistency…


...

978            sequence-number-skipped: This notification is sent when the
system

979            receives a PDU with its own system ID and different
contents.  The

980            system has to reissue the LSP with a higher sequence number.



[nit] That's the last thing I would have guessed that this action would
have been called...  Maybe it's just me...

[SLI] This is inherited from RFC4444





982            authentication-type-failure: This notification is sent when
the

983            system receives a PDU with the wrong authentication type
field.



985            authentication-failure: This notification is sent when the
system

986            receives a PDU with the wrong authentication information.



[minor] Why do we need both of these?  Given that they both provide the
same information (including the raw PDU), and that
authentication-type-failure is a specific case of receiving "a PDU with the
wrong authentication information"

[SLI] This is inherited from RFC4444

You used this reply in several places.

Inheriting things from rfc4444 doesn’t mean it is ok…or the best solution…

In either case, most are minor comments, so no big deal.  I just want to
make sure that some of the points were considered.

...

1239         feature nsr {

1240           description

1241             "Non-Stop-Routing (NSR) support.";

1242         }



[minor] Reference?

[SLI] NSR is a local well known and deployed mechanism. We may enhance the
description if required, however we cannot really provide a reference.

Yes, please do.  See the description in draft-ietf-ospf-yang.


...

3995         grouping tlv242-router-capabilities {

3996           container router-capabilities {

3997             list router-capability {

3998                 leaf flags {

3999                   type bits {

4000                     bit flooding {

4001                       position 0;

4002                       description

4003                         "If the S bit is set, the IS-IS Router
CAPABILITY

4004                          TLV MUST be flooded across the entire routing

4005                          domain. If the S bit is clear, the TLV MUST
NOT

4006                          be leaked between levels. This bit MUST NOT

4007                           be altered during the TLV leaking.";

4008                     }



[major] This is a description of the behavior (copied from rfc7981!), not a
description of the field.

[SLI] Yes, but this provides an accurate description on the conditions of
the flag setting.

But this document is not Normative in the behavior above…. If anything,
Normative language should not be used unless making it clear that it is a
direct quote.

...

4540         notification lsp-too-large {

4541           uses notification-instance-hdr;

4542           uses notification-interface-hdr;



4544           leaf pdu-size {

4545             type uint32;

4546             description "Size of the LSP PDU";

4547           }

4548           leaf lsp-id {

4549             type lsp-id;

4550             description "LSP ID";



4552           }

4553           description

4554             "This notification is sent when we attempt to propagate

4555              an LSP that is larger than the dataLinkBlockSize for the

4556              circuit.  The notification generation must be throttled

4557              with at least 5 seconds between successive

4558              notifications.";

4559         }


...

[major] "must be throttled"  Why is this text not Normative?  It seems to
me that throttling is a good practice...in fact, it may be a good idea to
specify it for all notifications.  There are 12 total instances of the same
text.

[SLI] The text is mirrored from RFC4444.


I think this was the only “major” point what you replied with rfc4444….
Just leaving it here…. No further comments. ;-)