[Lsr] Roman Danyliw’s DISCUSS on draft-ietf-ospf-yang-26

Alvaro Retana <aretana.ietf@gmail.com> Wed, 21 August 2019 15:08 UTC

Return-Path: <aretana.ietf@gmail.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 6095612090C; Wed, 21 Aug 2019 08:08:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Status: No, score=-1.996 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, 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id v9VVQPsvLfuu; Wed, 21 Aug 2019 08:08:29 -0700 (PDT)
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (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 C81891208D4; Wed, 21 Aug 2019 08:08:28 -0700 (PDT)
Received: by mail-ed1-x529.google.com with SMTP id a21so3305356edt.11; Wed, 21 Aug 2019 08:08:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:date:message-id:subject:to:cc; bh=EtTJ7D6XsVQyCeFpMqbEuN411XQzk13F+YDh8ngElMI=; b=mzMJ70s3n6najKVko8nTyXn3TaFuBFPy6YWeeatirIW6xqQB/xQgiW8dr2T7lYMPzx H1YvyKP0nk8WfhfriqLgPMttT+VIMc2R7f3UcnfmLC0c2b0O4M00mRXt82GASbA+/O4z +M0sbfoEacD1B/RwDzu4AW+h0osIJvqP4xAGYTKl33g7OnnpuFKri3qlTS00col9YG7Y Yfxc727Rw+NMXOXI2Br78f27s8hBzYS3I8+Lq7LtKqQLYBAj53Yn5RG9dbgKm1KA5D/K JWYgOz8lu5cuNqdvTZRIsjRdrmA0WHPkUC62pIQYL81fOkSCmD+bNAWas7YUdQcOz7eh 2bRA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to:cc; bh=EtTJ7D6XsVQyCeFpMqbEuN411XQzk13F+YDh8ngElMI=; b=lHhpkmoB1vbx/08nfTnPv6aQyPIBXjRMj2HJsDcAYbG3FXQuakqjImKPm6omBGbkCB O7i7fKv8cPOqqJEYmaeHPsDQD8CesN34CmJ+iV+Me+N1XlCI8I1itw7cd39WmfSqFAkl 0WPWXjjwVvSNwYqLf7hfc9No8E6FWVde6LWzL7HLvqpIkEM8QY7+bxxX8eoe0CgkUj88 GA3cefekD+sBTZHEzHgUu2+lkAPHDEH+oxFbggPr2S1C80Nhg9zsnHtLUzE/jgONboV5 LsTpj0+6CV9uef/ePuasqaspiYqUTMGJ/WTHdVUD/QDCmiOIM5gOZKjJf/wCu5c95/rV s5RQ==
X-Gm-Message-State: APjAAAVh2LfnxPCFy196Oll25FhZb18iHM0il1VTS5I8AOk6WvASYhq4 9zvPTRI4lnt4k3a3KN4/SVR9t3BoR6GQFwK9m3mTivsP
X-Google-Smtp-Source: APXvYqyuqKqUzPVshOaV+m02A/FIvguhRgnNEQCjQS16FDR7hozyXRNudXqzYurjKeflh+icAZ1QsAOPHTAK0cirFz0=
X-Received: by 2002:aa7:c35a:: with SMTP id j26mr33433951edr.270.1566400107205; Wed, 21 Aug 2019 08:08:27 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 21 Aug 2019 08:08:26 -0700
From: Alvaro Retana <aretana.ietf@gmail.com>
MIME-Version: 1.0
Date: Wed, 21 Aug 2019 08:08:26 -0700
Message-ID: <CAMMESswWu7E+DHW+8t9y5BXTGn3tqYo=vTR+j536MXcdsNEpog@mail.gmail.com>
To: draft-ietf-ospf-yang@ietf.org
Cc: Roman Danyliw <rdd@cert.org>, Stephane Litkowski <stephane.litkowski@orange.com>, "lsr-chairs@ietf.org" <lsr-chairs@ietf.org>, "lsr@ietf.org" <lsr@ietf.org>, The IESG <iesg@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f7559a0590a1f13a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/3Ave-PqamRry9qrOMvn2-YR7sgQ>
Subject: [Lsr] =?utf-8?q?Roman_Danyliw=E2=80=99s_DISCUSS_on_draft-ietf-os?= =?utf-8?q?pf-yang-26?=
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: Wed, 21 Aug 2019 15:08:32 -0000

[It looks like the datatracker didn’t send out the text to Roman’s
DISCUSS.  I didn’t receive it, nor do I see it in the mail archive.  So I’m
pasting it here. — Alvaro.]

- - - - - - - - - - -
- - - - - - - - - - -

A “discuss to discuss”.  Per the convention outlined in
https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines, thank you for
clearly noting the implication of not securing these nodes properly.

Furthermore, following the convention, I would have expected Section 4 to
have enumerated the sensitive writeable/creatable/deletable data nodes; and
the sensitive readable nodes individually.  For a model this large, I can
imagine that individual enumeration would be a long list.

In the case of read operations, the text opens with saying that “some of
the readable data nodes ...” and later says “The exposure of the ... LSDB
will expose the detailed topology ...”.  Can you help me understand which
part of ietf-ospf.yang is the LSDB and which parts refer to “some of the
readable nodes”?  Is there are a difference, or is this text asserting that
all parts of the modules are sensitive and need access control?

A related line of questioning for the write operation.  The text opens with
saying that “There are a number of data nodes defined in ietf-ospf.yang ...
[and that] [w]rite operations ... to these nodes without proper protection
can have a negative effect on the network operations ... [and] ... the
ability to modify OSPF configuration ...” is problematic.  Can you help me
understand which parts of the text is the “OSPF configuration” vs. “there
are number of data nodes ...”?  If there isn’t a different, is the text
asserting that all parts of the modules are sensitive and need access

- - - - - - - - - - -
- - - - - - - - - - -

(1) Idnits returned a seemingly valid few reference issues:

  ** Downref: Normative reference to an Experimental RFC: RFC 1765

  ** Downref: Normative reference to an Experimental RFC: RFC 4973

(2) Editorial
-- Section 4.  Isn’t RFC8341, “the Network Configuration Access Control
Model” rather than the “NETCONF access control model”?

-- Section 4.  Typo.  s/specificationn/specification/

-- Section 4.  Remove the duplicate instance of the phrase “for legacy
implementations that do not support key-chains”.

-- Section 4.  Typo.  s/The OSPF YANG module support/the OSPF YANG module

Alvaro Retana