Re: [yang-doctors] Yangdoctors last call review of draft-ietf-ospf-yang-09

"Acee Lindem (acee)" <> Tue, 13 March 2018 21:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 82855126CF6; Tue, 13 Mar 2018 14:19:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.53
X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iRs_0-Ltn6B5; Tue, 13 Mar 2018 14:19:16 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0D4EE126CD6; Tue, 13 Mar 2018 14:19:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=4578; q=dns/txt; s=iport; t=1520975956; x=1522185556; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=3fKabHOv6c3MCubGCXxVs0spTXjx0nmBMUE/Rut0I5U=; b=IOkyf4HjcI8CpZL3ItW8c8z+q7wf5rqdki5t9IoCifPnHHDLIqjyI0ft euSUIO2wo4jBLRqbo5z0fLRSNXkUzci5WbIyqgtFiotKVXZVS3QZZjbSO +KBCpYrCJBLC/XQial/k8oE7YHIZLHNSC2W8oHHJ0+Ui5hHTrq30dzPLv o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DnAAAhP6ha/5tdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNQZXAoCoNGih2NdIFbgT+UMYIVCiOFAgIagwYhNBgBAgEBAQE?= =?us-ascii?q?BAQJrJ4UkBiMRRRACAQgSCAImAgICMBUCDgIEAQ0FhRgPrAiCJohhggUFgQ2EK?= =?us-ascii?q?IIugzwpDIJ5gy4CAwGEdTCCEiAEmlYJAoZCiiCBY4Q1iEmFYYQZhykCERMBgSs?= =?us-ascii?q?BHjhAgRJwFRlLAYIYhEd3jimBGAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.47,466,1515456000"; d="scan'208";a="82992363"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Mar 2018 21:19:15 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id w2DLJE9k018197 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 13 Mar 2018 21:19:14 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 13 Mar 2018 17:19:13 -0400
Received: from ([]) by ([]) with mapi id 15.00.1320.000; Tue, 13 Mar 2018 17:19:13 -0400
From: "Acee Lindem (acee)" <>
To: Ladislav Lhotka <>, YANG Doctors <>
CC: "" <>, "" <>, "" <>
Thread-Topic: Yangdoctors last call review of draft-ietf-ospf-yang-09
Thread-Index: AQHTuxAlB+GkraWOBU+qDRqEXQX+KKPOq76A
Date: Tue, 13 Mar 2018 21:19:13 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [yang-doctors] Yangdoctors last call review of draft-ietf-ospf-yang-09
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Email list of the yang-doctors directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 13 Mar 2018 21:19:17 -0000

 Hi Lada, 
 We believe that satisfies your comments. Please take a look ASAP as we intend to WG last called the ietf-ospf YANG model imminently. 
    On 12/6/17, 6:26 AM, "Ladislav Lhotka" <> wrote:
        Reviewer: Ladislav Lhotka
        Review result: Ready with Issues
        The data model defined in this document is a massive piece of work: it
        consists of 11 YANG modules and defines around 1200 schema nodes. The
        "ietf-ospf@2017-10-30" module is compatible with the NMDA architecture.
        **** Comments
        1. Unless there is a really compelling reason not to do so, the
           "ietf-ospf" should declare YANG version 1.1. For one,
           "ietf-routing" that is being augmented by "ietf-ospf" already
           declares this version. Some of my suggestions below also assume
           version 1.1.
        2. The "ietf-ospf" can work only with the new NMDA-compatible
           revisions of some modules, such as "ietf-interfaces" and
           "ietf-routing". I understand it is not desirable to import such
           modules by revision, but at least it should be mentioned in a
           description attached to every such import.
        3. Maybe the draft could mention that implementations should supply a
           default routing domain as a system-controlled resource.
        4. In "when" expressions, the module uses literal strings for
           identities. This is known to be problematic, the XPath functions
           derived-from() or derived-from-or-self() should be used instead.
        5. Some enumerations, such as "packet-type" and "if-state-type"
           define enum identifiers with uppercase letters and/or underscores,
           for example "Database-Description" or "LONG_WAIT". RFC6087bis
           recommends that only lowercase letters, numbers and dashes. I think
           this convention should be observed despite the fact that the
           current names are traditionally used in OSPF specs. The
           "ietf-routing" module also defines "router-id" even though the
           documents use "Router ID".
        6. The types of LSA headers are modelled as integers. While OSPF gurus
           probably know these numbers by heart, it is not very
           reader-frienly. So at least some references to documents defining
           these numbers should be provided, but my suggestion is to consider
           implementing them with identities. It seems it might also be useful
           to define some "abstract" identities for these types. For example,
           if "opaque-lsa" is defined, then the definition of container
           "opaque" could simply use
             when "derived-from(../../header/type, 'ospf:opaque-lsa')";
           instead of
              when "../../header/type = 9 or "
                      + "../../header/type = 10 or "
                      + "../../header/type = 11";
        7. The title of sec. 2.9 should be "OSPF Notifications" rather than
           "OSPF notification".